The Still New What Did You Last Do Thread

[Graf Zahl]

The "attitude of non-problem solving" here refers to the reluctance to fix up the things that Apple fixed up in macOS in the Linux distributions.

...

On Windows and macOS, you have multiple UI toolkits that will look and feel nearly the same in a single OS, whereas on Linux the usage of a different toolkit can be enough to make your app stick out like a sore thumb. And because libraries are far more often than not released without any synchronization with LTS releases, the moment you step outside Windows and macOS into Linux will be the moment when you have to degrade your software to appease the LTS users because the people who still think a centralized package repository of a distribution is still a far better idea than the rest still overwhelms everyone else who consider AppImages and Flatpaks the way to go forward.

... and long as this problem persists, there is zero chance for Linux to become mainstream. For that it is an essential necessity that downloading self-contained app packages becomes widely accepted as the right thing to distribute sofware.

That entire package management system is not only horrendously labour intensive for developes (geez, how many Linux packages must I create???) but also comes with the neverending problem of dependency hell - and you become dependent on the maintainers of these systems.

Just one example: These days libsndfile supports MP3 out of the box - but we cannot drop the direct libmpg123 support in ZMusic yet because it'd throw LTS users under the bus. Or why do we still have to consider GCC 7 as a compile target? It is years out of date and limits our migration to more modern C++ standards. All that only because someone once decided that LTS is a good choice for end users, and it's the software developers that need to adapt to dealing with outdated libraries.

The inevitable end result of such a setup is technical issues. I do not even know how many indirect dependencies GZDoom has - but only one of them needs to have an issue to get a report on our forum. Well, good luck finding the cause then...

Or one other recent thing: Randi recently wrote a glib wrapper for Windows so that FluidSynth can be compiled without dragging in a huge shitload of baggage. I used that opportunity to integrate it directly into ZMusic. Many Linux users said this worked a lot better than the standalone library. Which is not really surprising because FluidSynth is an extremely poorly constructed library that not only contains the actual softsynth but also a full MIDI player including the needed OS support. And apparently you cannot initialize the synth without initializing all the baggage as well. None of this code exists in ZMusic - it is just the pure synth. But wanna bet that some package maintainers will not like this and edit the project to pull in the bad "system library" again? I have seen one distro doing similar shenanigans with other libraries we statically link to for good reasons. If someone using such a package encounters problems with it there's nothing we can do.

[yum13241]

On Windows and macOS, you have multiple UI toolkits that will look and feel nearly the same in a single OS, whereas on Linux the usage of a different toolkit can be enough to make your app stick out like a sore thumb. And because libraries are far more often than not released without any synchronization with LTS releases, the moment you step outside Windows and macOS into Linux will be the moment when you have to degrade your software to appease the LTS users because the people who still think a centralized package repository of a distribution is still a far better idea than the rest still overwhelms everyone else who consider AppImages and Flatpaks the way to go forward.

Bolded statement is false. That was only ever true with Windows's classic theme (it kinda still exists, see SimpleClassicTheme)


Which can be solved. What CAN'T be solved is the whole Metro/Win32 debacle on Windows, or macOS's locked-downness.


IMO AppImages, Flatpaks and Snaps (which suck hard) all have way too many things going on to go forward. AppImages remind me of downloading random .exe's like I'd do on Windwoes, Flatpaks suck on the command line (try the GZDoom flatpak with the CLI, it'll be fun ) and Snaps were screwed from the beginning. (read: https://old.reddit.com/r/linuxmemes/com ... u/hd7jg1p/)


IMO the perfect packaging format would be smth like this:

-Sandboxing is optional (flatpak's /var/app/... really sucks)
-Can have custom repos (so censorship isn't a problem)
-Can be integrated natively into the system package manager, or at least easy enough to do
-doesn't have org.blah.blah names like FlatPak.
-ISN'T controlled by 1 single person/business ala Snap (it's also not fully open source)
-Uses the native system theme like native apps
-A version WITH and WITHOUT bundled dependencies (aka static distribution)


Anyways, the whole "downgrade your software to appease the LTS users" sentiment is not Linux's fault but rather the user's fault for believing ancient=stable. Rolling release ftw.

[Graf Zahl]

So you want to have your cake and eat it too? I don't think that this way there will ever be a working format.
Also, if you say "version with or without dependencies" would be an instant no.go for developers, who, above everything else want reliability. Which would be thrown out of the window if the known dependency hell crept in again.

In this case you would have to compromise to give the developers some means to set up something that doesn't need separate testing and packaging for 5+ distros that use different package managers or have different installed libraries and such. In the end you want to provide a nice environment for non-techy users and that won't happen if it has to account for all eventualities.

[yum13241]

At least I'm not wasting disk space on a billion copies of glibc for every program when dynamic distribution is a thing. Maybe the dependencies could just be added in automatically.


Edit: AppImage is very close to being perfect. All it needs is it being able to have custom repos and being able to be installed via a package manager of its own ala flatpak or snap.

[Rachael]

I'd rather have those, as you put it, "billion copies of glibc" and have a solid, reliable system where I can count on my programs working, than dealing with a situation exactly that Graf has described, even as an end-user: where sometimes I have to dread "apt-get update" because of the breaking changes it brings.

Not saying it does it often, but it does it often enough - and more than Windows ever has.

I usually compile my Linux binaries meant for distributions with glibc statically linked, anyhow, though, if it's easy enough to do.

[yum13241]

*sudo apt update && sudo apt upgrade.


I dunno about you, but "free ram is wasted ram" doesn't necessarily apply to storage.


I will agree, statically linking is a way to have it reliable. But in a perfect world it'd be optional. But we aren't in a perfect world (read: we're in The Age Before the Surveillance By Big Tech Age)

[Graf Zahl]

I dunno about you, but "free ram is wasted ram" doesn't necessarily apply to storage.

I'd rather waste some storage than my precious time getting something to wotk that depends on some version specific quirk of a library.
Also, how large is glibc?

In GZDoom's Windows version there's approx. 500kb of library code, but a large chunk of that is the C++ multithreading library. That means 1000 applications to fill half a gigabyte. I never install that much -and the two largest things I installed are mostly data anyway, not code.

There's also this thing that once a library gets swapped out behind my back I cannot give you any guarantees anymore that my software will still work as intended. Therefore I wouild not be able to distribute such a thing commercially because as a commercial distributor I could be held liable. And it's right here where the story ends.

[Chris]

The "attitude of non-problem solving" here refers to the reluctance to fix up the things that Apple fixed up in macOS in the Linux distributions.

Reluctance, or being preoccupied with other issues, or not knowing it's a big problem? A few random people complaining on the internet that something doesn't work exactly the way they want it to doesn't inherently mean making it work that way is a good idea (especially when other people want it to work the exact opposite way), or particularly important compared to everything else the project needs to do. This happens all the time. And plenty of arm-chair analysts will say they know exactly why something has a hard time taking off, while offering little to no proof that uptake will noticeably improve by taking their advice. Plenty of times people have tried to improve things by taking advice like that, with the result being creating more fractures with little improvement.

That doesn't mean there aren't things to fix and improve, or that they shouldn't be. Projects and various aspects of the system are constantly being fixed and improved, and looking for new ways to improve, but we're not wizards with crystal balls that can divine what really needs to be worked on given all the noise, from inside and out. We can only take the route that seems most logical from our perspective. If there's issues with that route, reasoned discussion (rather than just pointing, complaining, and stating The Obvious Truth) is the best way to help.

Remember that their Wayland push is bad enough it led to even FreeBSD users complaining about it getting force-fed into everyone's mouths.

And things like this. The irony of complaining that there's a "reluctance to fix" problems, then turning around and saying you don't want the fixes to problems. People have been complaining for decades that X is old and needs to be replaced. Outside people have been saying X is made for times past and is holding back Linux from mainstream adoption. Well, here we have the Xorg developers themselves agreeing, "shit's fucked, yo. there's too much legacy baggage here, a codebase that's way too long in the tooth, and many of the purported benefits aren't actually there or useful anymore. it'd be far better to start fresh with a focus on what a modern compositor and windowing system needs." So they put Xorg into maintenance mode as they went work on Wayland. Years later, Wayland is slowly gaining traction (thank nVidia for that slowness), and some people are turning around and going "why are you making Wayland? X is fine, don't replace it!".

On Windows and macOS, you have multiple UI toolkits that will look and feel nearly the same in a single OS, whereas on Linux the usage of a different toolkit can be enough to make your app stick out like a sore thumb.

Yet, apps on Windows can and do look jarringly different from each other, even when they use the native GUI APIs, and plenty of apps willingly go out of their way to avoid a native UI look (hi, Electron!). Hell, one of the longest-standing complaints on Linux (that I've had too) is how different Qt and GTK apps look from one another. On the one hand, you have the KDE devs (who use Qt) doing their damnedest to get GTK apps to look similar to Qt apps, with a fair amount of success. Yet on the other hand, many developers themselves (Linux or not) seem to have a disdain for the idea of a native UI; it seemed just as that was getting into a reasonable state for KDE users, the entire computer industry jumped to making web apps, or making their app stand out with a unique look, completely crapping on any semblance of native UI consistency. The irony here being, a legitimate complaint thrown toward Linux, which a group of people worked diligently to fix, ended up being what developers wanted to do elsewhere. At this point, I'm just happy to see a web browser that knows what a modal dialog box is, rather than making everything a web page in a tab.

And because libraries are far more often than not released without any synchronization with LTS releases, the moment you step outside Windows and macOS into Linux will be the moment when you have to degrade your software to appease the LTS users because the people who still think a centralized package repository of a distribution is still a far better idea than the rest still overwhelms everyone else who consider AppImages and Flatpaks the way to go forward.

Most people have no need for LTS, and a belief you do is a misunderstanding of what it's for (there is of course a use for it, otherwise it wouldn't exist, but you'd know if you needed it). It's essentially when you need a set, unchanging system, only receiving critical security updates, but otherwise keeping the system locked to a specific set of packages and package versions. I'm positive Windows has a similar concept. Complaining about how out of date things get with LTS and how new apps can't run on LTS, is like complaining about how out of date things get when you don't update Windows and new apps can't run when you don't update Windows (which I have seen people do in this forum).

If there are more people than necessary using LTS when they don't actually need it, that would seem to be a messaging problem that could be improved.

Only like Google, Valve (only recently) and Apple like understands what makes anything Linux/UNIX a sell. And Valve doesn't use Wayland for the Plasma Desktop, only for Gamescope. Google intentionally kept their Steam gaming parts inside an Arch VM.

Google Stadia also avoided anything X or Window Manager related, because it's not for a desktop environment. It's the main reason they didn't use Wine and rolled their own WinAPI layer, as Wine is designed to run desktop apps (which includes games) on a desktop, whereas Stadia only needed to run fullscreen games and capture the output. And being a cloud service, they needed to cut as much overhead as they could.

As for Gamescope, it's telling they went Game->Xwayland->Wayland (where Xwayland is an X compatibility layer for Wayland) instead of Game->X. Meaning that even with an Xwayland compatibility layer, there were benefits to having Wayland for display and input compared to native X.

[Graf Zahl]

Most people have no need for LTS, and a belief you do is a misunderstanding of what it's for (there is of course a use for it, otherwise it wouldn't exist, but you'd know if you needed it). It's essentially when you need a set, unchanging system, only receiving critical security updates, but otherwise keeping the system locked to a specific set of packages and package versions. I'm positive Windows has a similar concept. Complaining about how out of date things get with LTS and how new apps can't run on LTS, is like complaining about how out of date things get when you don't update Windows and new apps can't run when you don't update Windows (which I have seen people do in this forum).

If there are more people than necessary using LTS when they don't actually need it, that would seem to be a messaging problem that could be improved.

Fun thing: LTS wouldn't be a problem if the apps would bundle the libraries they need. It also would render half of the motivation for LTS obsolete.
Yes, such a thing also exists for Windows, but it doesn't freeze the system's global library state everything depends on - for the simple reason that no such thing exists to begin with!

[Cacodemon345]

And things like this. The irony of complaining that there's a "reluctance to fix" problems, then turning around and saying you don't want the fixes to problems. People have been complaining for decades that X is old and needs to be replaced. Outside people have been saying X is made for times past and is holding back Linux from mainstream adoption. Well, here we have the Xorg developers themselves agreeing, "shit's fucked, yo. there's too much legacy baggage here, a codebase that's way too long in the tooth, and many of the purported benefits aren't actually there or useful anymore. it'd be far better to start fresh with a focus on what a modern compositor and windowing system needs." So they put Xorg into maintenance mode as they went work on Wayland. Years later, Wayland is slowly gaining traction (thank nVidia for that slowness), and some people are turning around and going "why are you making Wayland? X is fine, don't replace it!".

You do know the reasons why people don't want Wayland, right?

You do know why X11 is still the best choice of usage, right?

You do understand the proverb "if it ain't broke, don't fix it", right?

https://dudemanguy.github.io/blog/posts ... -xorg.html

Developers aren't going to waste their time and resources trying to retrofit their already-working custom X11 solutions into something as incomplete as Wayland, especially when said resources are so scarce. It doesn't even make sense with less than 10% of Firefox Linux users on XWayland/Wayland.

SDL2 also tried to make Wayland the default the first time and it backfired pretty hard on them, so they had to revert it for a while. They are trying again recently with the ongoing SDL3 development but there's no guarantee it won't end up the same exact time again.

It also took them 14-fucking-years to finally get off their asses and actually add fractional scaling. If that's the prevalent pace of Wayland development, don't be surprised when people too start complaining about problems with it after X11 is actually dead, because they absolutely will as nothing is perfect.

And one more thing about that is that it wasn't even originally designed as a X11 replacement when it got created in 2008; it was targeting the likes of TVs, infotainment systems and smartphones when it became a thing. It had no desire to target desktops. That came out as an afterthought. Which means that the move to replace X11 by something not designed to fully replace it in the first place is a bad one. That's why Valve chose Gamescope for Steam Deck's default UI but elected to avoid Plasma Wayland for the desktop UI because Wayland is a perfect fit for kiosk/fullscreen programs but a bad fit for desktops.

Many game developers already moved away from supporting Linux because the sales numbers didn't justify the amount of bug reports they got bombarded with from that platform, and Wayland will make that even more worse.

Google Stadia also avoided anything X or Window Manager related, because it's not for a desktop environment. It's the main reason they didn't use Wine and rolled their own WinAPI layer, as Wine is designed to run desktop apps (which includes games) on a desktop, whereas Stadia only needed to run fullscreen games and capture the output. And being a cloud service, they needed to cut as much overhead as they could.

Google Stadia has thoroughly failed. It's not the example I was referring to as well. I was referring more to how they managed to sell their Chromebooks very well and also managed to get Steam into ChromeOS, thereby opening up adoption of Linux to a wider audience.

[Graf Zahl]

You do know the reasons why people don't want Wayland, right?

You do know why X11 is still the best choice of usage, right?

You do understand the proverb "if it ain't broke, don't fix it", right?

https://dudemanguy.github.io/blog/posts ... -xorg.html

Developers aren't going to waste their time and resources trying to retrofit their already-working custom X11 solutions into something as incomplete as Wayland, especially when said resources are so scarce. It doesn't even make sense with less than 10% of Linux users on XWayland/Wayland.

SDL2 also tried to make Wayland the default the first time and it backfired pretty hard on them, so they had to revert it for a while. They are trying again recently with the ongoing SDL3 development but there's no guarantee it won't end up the same exact time again.

It also took them 14-fucking-years to finally get off their asses and actually add fractional scaling. If that's the prevalent pace of Wayland development, don't be surprised when people too start complaining about problems with it after X11 is actually dead, because they absolutely will as nothing is perfect.

All this can also be summed up as "Large parts of the Linux community are very reluctant to change."
And that is a problem all by itself.

The worst thing about Wayland is not its technical issues, but that it's yet another thing that will cause fragmentation which keeps Linux numbers down.
There was a recent discussion that we might migrate our GUI parts in GZDoom to FLTK but that drew heavy complaints from some Linux users because the library is not yet ready for Wayland. So well, we are still stuck with 3 native, wildly diverging GUI parts and that stupid terminal fallback because *some* Linux users wouldn't accept anything else for a user interface.

But it has always been like that - nearly any time we run into a wall with our cross-platform support it is Linux causing the problems.

[Marisa the Magician]

Also, how large is glibc?

libc itself is 2MB, though gzdoom also pulls in libm and libmvec, which are 1MB each.

[Graf Zahl]

It surely does not use everything from it, so when statically linking I'd guess the final footprint is a lot less.

Microsoft's full CRT is also a lot larger than the parts GZDoom actually adds to its EXE.
But where went the times where the average size the CRT added to an EXE was some 64-128 kb? Because that's what older ZDoom's use...

[yum13241]

IMO what should be done is that you are able to opt in to static linking, as in being able to dload the static libraries separately, but not be default. Or at the very least an app should throw its static libraries in smth like /lib/static/ (which doesn't exist) so that other apps that happen to use the same version can use THAT version rather than having redundant copies.


Also, when will potato friendly DEs be Wayland compatible? Once XFCE is ported I might as well switch.


Change isn't inherently good or bad. If I have to change my workflow and deal with memory hogging just to switch to beta software, no thanks.

[Graf Zahl]

IMO what should be done is that you are able to opt in to static linking, as in being able to dload the static libraries separately, but not be default. Or at the very least an app should throw its static libraries in smth like /lib/static/ (which doesn't exist) so that other apps that happen to use the same version can use THAT version rather than having redundant copies.

No, no, no! Absolutely not! The entire point here is NOT sharing binaries with other applications,
Then we got the exact same problem all over again that everything depends on external data and breaks if something gets changed behind the application's back.
There's very good reasons why this is NOT the default on both macOS and Windows where every application is responsible for its own dependencies and keeps them locally to the application binary.

Even with this, nothing is keeping you to continue the old ways. But for a sane and robust general distribution format any of this is a very bad idea. (And in case anyone raises their hand - yes I think that it's also very bad how Microsoft manages their runtime library. Which is why I never ship executables that need it.)

For christ's sake, we have terabyte SSDs by now, can't you set aside a single gigyabyte of it just to ensure that overall system stability improves and maybe more users pick up Linux?
This has never become a storage space issue on either Windows or Mac. On my system the added requirements of this is probably 200 MB right now, and the worst culprit by a wide margin here is Git which statically links the same internal library into multiple executables. And even so, this is well below 100 MB.