361–370 of 459 posts
Earlier quoted context omitted.
Yeah, that has been the default for a lot of Linux distributions for quite some time now (if you install wine).
not sure I want my parents to be able to double click Windows binaries and have them execute with their privs
> Thesis: We should create a distro of Linux that runs Windows binaries by default via Wine. On Debian you're one package away: sudo apt install wine-binfmt Otherwise you're still pretty close: echo 'none /proc/sys/fs/binfmt_misc binfmt_misc defaults 0 0' >> /etc/fstab mount -a echo ':DOSWin:M::MZ::/usr/bin/wine:' > /proc/sys/fs/binfmt_misc/register
Is it just me or wine needs a bit more polish? Dialogs and menus are rendered with some weird microscopic font. GDI text rendering seemingly doesn't use font fallbacks, so even something like Scintilla or ebook reader don't quite work under wine.
It's just you. I set up the DPI and high res option to run old Office apps, and they have very nice fonts both on my 2k laptop 4k screen.
Try `xprop -root -f _XWAYLAND_GLOBAL_OUTPUT_SCALE 32c -set _XWAYLAND_GLOBAL_OUTPUT_SCALE 2`
I think this attitude to the Linux ABI is maybe out of date - with a 20 year old Linux binary, that's only 2005, so it will almost certainly be using glibc (no archaic libc5). Glibc has great backwards compatibility and the binary will work on any glibc distribution today as long as you have all the .so's, same as needing the .dll's on Windows.
Thankfully gtk2 is now stable too.
> I can pull down a 20 year old exe and still run it today on Windows. Try doing the same with a Linux binary that's just a year old. There's no guarantee that it will be able to run based off some update that has happened IMHO, you just compare two different things. Traditional method of installing apps on Windows is packing all dynamic dependencies with it. While on linux dynamic dependencies are shared between app…
I'm not sure about linux syscall ABI stability either, or maybe other things that live in the kernel?
I think this attitude to the Linux ABI is maybe out of date - with a 20 year old Linux binary, that's only 2005, so it will almost certainly be using glibc (no archaic libc5). Glibc has great backwards compatibility and the binary will work on any glibc distribution today as long as you have all the .so's, same as needing the .dll's on Windows.
I hit quirks with glib semi-regularly (~1/year) For example, recently I tried to run Emacs' Appimage and it has a glib issue https://github.com/probonopd/Emacs.AppImage/issues/22#issuec...
Glib is a library from the GTK project which offers utility functionality related to the GTK widget toolkit, while glibc is the GNU C Library.
Amusingly, these kinds of beyond-the-core libraries are the ones that have always caused problems for me, never actual core GNU C Library.
> I can pull down a 20 year old exe and still run it today on Windows. Try doing the same with a Linux binary that's just a year old. There's no guarantee that it will be able to run based off some update that has happened IMHO, you just compare two different things. Traditional method of installing apps on Windows is packing all dynamic dependencies with it. While on linux dynamic dependencies are shared between app…
Aside from comparing two different things, as you correctly identify, I believe that even the author's original assertion just isn't true. Maybe for some exe files, but I doubt for all or even most. I was involved in replacing Windows systems with Linux + Wine, because (mission-critical industrial) legacy software stopped working. No amount of tweaking could get it to work on modern Windows system. With Wine without…
I moved from Windows 11 to Linux for the same reason: I was using an old version of Office because it was faster than the included apps: the full Word started faster than Wordpad (it was even on par with Notepad!) The Outlook from an old Office used less ram and was more responsive than the one included with Windows!
When I got a new laptop, I had problems with the installation of each the old versions of Office I had around, and there were rumors old versions Office would be blocked.
I didn't want to take the risk, so I started my migration.
> While Windows is often claimed to be backwards compatible, in practice your mileage may vary
It was perfectly backwards compatible: Windows was working fine with very old versions of everything until some versions of Windows 11 started playing tricks (even with a Pro license)
I really loved Windows (and AutoHotKey and many other things), but now I'm happy with Linux.
Earlier quoted context omitted.
Yeah, glibc is extremely stable and you can be sure that an app compiled against it now will work well into the future. People just completely ignore that fact based on hearsay, and that the removal of a unused symbol hashing table from the glibc binary broke a few anticheat systems that were attempting to parse it. Other libraries are the problem, usually. People are generally really good about changing the .so vers…
Everything is fine until it isn't when you run into mismatch like 64bit file offsets and time_t.
Earlier quoted context omitted.
> sub-par desktop experience. I strongly disagree. Linux (KDE) is a far superior desktop experience these days, compared to Windows 11. Have you even seen the new Win11 taskbar and the shitty Start Menu - they ruined something which they perfected in Win7. The overall UX has taken a deep dive - like with the unwanted removal of classic Control Panel applets like "Window Color and Appearance" (which doesn't have a rep…
"Maybe don't use an ancient distro that's stuck in the past? Try a modern immutable distro like Aurora [3] or Bazzite [4] and see for yourself how much things have changed." This has always been the riposte to Linux-for-normies sceptics - "you haven't tried these modern distros, X, Y, Z". I've gone down that route several times and they always have issues, from drivers to config settings to just being too different c…
You really should give KDE-based distros a try, the UI isn't that much different from the traditional Windows UI paradigm. In fact I'd say KDE is more similar to the Windows 7 UI, than Windows 11 is.
Also, drivers aren't really a problem with compatible hardware. As the person recommending/installing Linux, it is your duty to ensure that they've got compatible hardware. In my experience, anything older than a couple of years, from mainstream brands, work fine. The only couple of cases where I've had to manually install a driver was for printers, but even that is now almost a non-issue these days thanks to driverless/IPP printing.
> Non-tech (and especially older) people will generally have expectations that obscure linux distros (despite their good intentions) cannot meet
I'm surprised you mentioned non-tech and older people, because that's exactly who my ideal targets for Linux are, because their needs are simple, predictable and generally unchanging. It's usually the tech-savvy and younger people who've got complex software needs and specific workflows that find it hard to adjust to Linux. This was also the case for me, I had over a decade worth of custom AutoHotkey scripts + mental dependencies on various proprietary software that I had to wean myself off from, before I ultimately switched.
Older, non-techy folks are mostly fine with just a browser and a document editor. This was the case with my mum, and pretty much most of my older relatives. As long as you set up the desktop in a way it looks familiar (aka creating shortcuts on the desktop), they don't cause too much of a fuss. Initially there may be a "how do I do this" or "where did xxxx go?" depending on their needs/workflow. At least in my mum's case, there wasn't much of an issue after showing her the basics.
I'm curious what needs the older folks you know have, which can't be met with an atomic KDE-based distro like Aurora.
Earlier quoted context omitted.
> So everything is properly designed but somehow there's a lot of general incompetence preventing it from working. But it is working, actually: * If you update your distro with binaries from apt, yum, zypper etc. - they work. * If you download statically-linked binaries - they work. * If you download Snaps/Flatpak, they work. > it means that you have to build on the oldest bistro you can find so that the built binari…
> Only if you want to distribute a dynamically-linked binary Even statically linked code tends to be dynamically linked against glibc. You’ve basically said “it works but only if you use the package manager in your OS”. In other words, it’s broken and hostile for commercial 3p binary distribution which explains the state of commercial 3p binary ecosystem on Linux (there’s more to it than just that, but being actively…
If you build a statically linked program with only glibc dynamically linked, and you do that on Linux from 2005,then that program should run exactly the same today on Linux. The same is true for Windows software.