14 ms·

I think the premise is wrong when there still doesn’t exist a core set of frameworks that are abi stable on Linux. On competing platforms there are way more fra

I think the premise is wrong when there still doesn’t exist a core set of frameworks that are abi stable on Linux. On competing platforms there are way more frameworks out of the box (CoreImage, CoreAudio, CodeML, SceneKit, AppKit, etc) and they don’t break as often. I know in Linux they have fun things like snap and flatpak but it is really solving the problem using a bit of infrastructure and package management instead of doing it in the frameworks and programming languages themselves (which are what you are asking people to write apps in).

smoldesu 3y ago
Stuff like Flatpak and Snap exists because the framework side kinda is built-out. Isolation technology had matured, newer desktops emphasized per-window security and needed APIs to portal in and out of each instance. The desktops needed a packaging/infrastructure solution to tie that together and make it presentable to the user.
- zer0zzz 3y ago
  Yet I still can't compile an app on some arbitrary release of some arbitrary distro and just run the darn exe on another and be 100% sure it will work.
  - smoldesu 3y ago
    On a large enough timescale I don't think you can reasonably expect this on any of this big 3 OSes. From a less macro perspective, I think tools like Appimage and Flatpak will fill that role.
    - zer0zzz 3y ago
      On a long enough time scale we are all dead, and Linux doesn't exist. That doesn't mean that in the decades that computer software has to be useful to actual people that things have to suck this badly right now.
      - smoldesu 3y ago
        The "actual people" using Linux on the desktop are not running .so files off the internet. I get what you're saying, but you know it's facetious to pretend that packaging is simple on Mac and Windows too.
        api 3y ago
        Packaging is fairly simple on Mac and Windows if you use the dev tools for the platform and are not doing things like installing services or drivers or changing OS configuration. Your packaged app will almost always work too. There are not 50 distributions of these OSes.
        zer0zzz 3y ago
        exactly
        zer0zzz 3y ago
        > The "actual people" using Linux on the desktop are not running .so files off the internet. They do this all day every day when they use a little something called Steam or when they install Google Chrome. > I get what you're saying, but you know it's facetious to pretend that packaging is simple on Mac and Windows too. It is...
        account42 3y ago
        > They do this all day every day when they use a little something called Steam Which while (initially) officially only released for a specific Ubuntu version ran on pretty much any up to date distro from day zero.
  - AnthonyMouse 3y ago
    The trouble is you're trying to distribute it as a binary yourself. The there are two traditional ways for distributing software for Linux: 1) The system package manager. It will download a binary from the repository which is the right one for that system. 2) make && make install. This is mostly for software in development that hasn't made it into the package manager yet. It will compile from source and produce a binary for the target system. All the problems are from people trying to do something other than this.
    - zer0zzz 3y ago
      That's the problem. The Linux way of distributing apps is wrong for trying to compete with the other consumer platforms. The ChromeOS or electron style of doing things is another story though.
      - AnthonyMouse 3y ago
        What exactly is wrong with it? If you have a stable widely used application suitable for being installed by unsophisticated consumers, have the distributions put it in their package managers. This is hardly any different than consumer mobile platforms that require you to use an app store, except that it isn't actually required, just the thing you ought to do absent a good reason to do otherwise. If you're distributing something sufficiently esoteric or experimental that the package managers won't touch it, your correspondingly sophisticated or adventurous users can compile it from source. We don't need some malware-facilitating norm that encourages users to install opaque binaries from random websites.
      - tripleo1 3y ago
        Alot of you may be looking at it wrong. Each distribution is a different operating system. You cannot package the "same" app for Windows and mac, so why should you be able to package the same application for Debian and Arch, which, even though they run a lot of the same code, have different underlying layers and assumptions?
  - eternityforest 3y ago
    On other platforms people don't even try to support anything but one "distro". You could make an AppImage or snap that would work across pretty much any mainstream non-hobbist-oriented distro, and Snap/AppImages is pretty much the Linux equivalent of EXE. Raspberry Pi OS just moved to NetworkManager and they have PipeWire, which was the last reason I had to deal with less common software stacks, so it seems like stuff is getting more standardized.
    - night-rider 3y ago
      +1 AppImages. And the beauty is you can make them portable by creating a folder with the same name as the AppImage and append .home to the end, and boom: portable software. For example image-editor.AppImage image-editor.AppImage.home (folder, all settings are stored there)
      - zer0zzz 3y ago
        Actually, I don't think I've tried AppImage. Does it do static linking or does it do something more similar to flatpak?
        account42 3y ago
        It's a self-mounting image so closer to flatpak than static linking but without the strict isolation.
    - account42 3y ago
      Snaps will not work on anything but Ubuntu. AppImages are just a fancy self-mounting disk image. If you do it right and include all required contents then it will work ~anywhere but you can just as well do that in a .tar.{gz,xz,zstd}/whatever archive.
      - hollerith 3y ago
        >Snaps will not work on anything but Ubuntu. I installed VSCode as a snap on my Fedora install and it worked fine as far as I could tell. This was in Mar 2021, and I chose the snap because code.visualstudio.com/docs/setup/linux said that "Due to the manual signing process and the system we use to publish, the yum repo may lag behind and not get the latest version of VS Code immediately. . . . Updates are automatic and run in the background for the Snap package." (I don't have an opinion on Snap as compared to Flatpak or AppImage or none of the 3.)
sylware 3y ago
Cuplrits are mostly glibc devs with their manic abuse of version names (and very recently, a GENIUS who added a new ELF relocation type): this is a pain for game developers to provide binaries which span a reasonable set of distros in time. Basic game devs install one of the latest mainstream and massive distros, build there, and throw the binaries on steam... but that recent distro had a glibc 2.36 and now their binaries have version names requiring at least a glibc 2.36 (often, rarely not). They have to force the right version names with... the binutils gas symver directive (see binutils manual) until all their version names are compatible with a glibc reasonably "old" (I would go for a reasonable 5 years... 7/8 years?): https://sourceware.org/glibc/wiki/Glibc%20Timeline https://sourceware.org/glibc/wiki/Glibc%20Timeline Of course normal game devs have not the slightest idea of those issues, and even so, they won't do it because it is a pain, that for 1% of their market. Not to mention they better statically link libgcc (and libstdc++ if they use c++) to avoid the ABI issues of those abominations (the word is fair) which have been plagging game binaries for TEN F.... YEARS ! (getting better has more and more game binaries default to -static-libgcc and -static-libstdc++, if c++, gcc/clang options). There is light at the end of the tunnel though as godot engine is providing build containers which are very careful of all that (unity seems clean there too, dunno for UT5.x though). But you have engines really not ready, for instance electron based games: you don't have the right version of the GTK+ toolkit installed on your enlightenment/Qt/raw X11/wayland/etc distro? Nah, won't run. And packaging properly a full google blink engine for binary distribution targetting a wide spectum of elf/linux distros? Yeah... good luck with that. elf/linux is hostile to anything binary only, that due to manic ABI breakage all over the board, all the time (accute in the SDK and core libs). If it is already that hard for game binaries, good luck with apps. I can hear already their devs saying: "we don't care, just use and install microsoft suze gnu/linux, every else is unsupported"... I think you get the picture where all that is going.
- zer0zzz 3y ago
  I agree. I recall a talk from Linux Torvalds on how bad the glibc folks break things and why he won't ship a binary version of his scuba tool. If the binary breakages start with the darn C lib, you're gonna have recurring problems all the way up the stack on a regular basis I feel.
pjmlp 3y ago
That core would be GNOME or KDE frameworks, coupled with the FreeDesktop standards, at least that was the plan about 20 years ago. However as the site says doing distributions is what most folks keep doing, and naturally there isn't a single stack that can keep up with snowflake distributions. In the end, Google took the Linux kernel, placed two core set of frameworks, one in Java, and the other in JavaScript, and naturally those are the winning Linux distributions for regular consumers.
- zer0zzz 3y ago
  None of that core is standardized across even a hand full of distros.
  - fragmede 3y ago
    Chrome/Chromium is quite standardized, across many distros.
    - zer0zzz 3y ago
      Name one distro that ships with chrome out of the box? I dont even think ubuntu comes with a chromium browser. That means devs cant write apps against it and just hand out exes like they do on Mac and windows.
      - charcircuit 3y ago
        Play Protect Certified Android and ChromeOS are popular ones among consumers
        zer0zzz 3y ago
        Nice. Maybe more desktop distros should build on android as a core. That could solve a lot of problems.
        charcircuit 3y ago
znpy 3y ago
> and they don’t break as often. Meh, kinda. It's not a case that proprietary software vendors only target RHEL, Suse and Ubuntu. RHEL is a perfect target for stable software and Ubuntu might be as well if you decide to only support LTS releases.
- zer0zzz 3y ago
  Targeting only a hand full of frozen releases is not abi stability. Abi stability is when any app can be compiled off any release and run on any future release (and ideally older releases too).
  - yjftsjthsd-h 3y ago
    > Abi stability is when any app can be compiled off any release and run on any future release (and ideally older releases too). Hang on, if that's the standard why is MacOS getting a pass? I'd believe that Windows meets that bar, but I see posts on a routine enough basis about Apple forcing rewrites, unless I really misunderstood something there.
    - zer0zzz 3y ago
      Apple's actually quite good at this, but they do break things on purpose from time to time for reasons which they announce pretty publicly at WWDC when they do (32->64bit, deprecating GL, etc). So, for example a dev can target an app at iOS 8 and it still works fine on iOS 17. Thats almost a decade of OS updates that didn't affect an app. Here's an example: https://apps.apple.com/us/app/bebot-robot-synth/id300309944 https://apps.apple.com/us/app/bebot-robot-synth/id300309944
      - jwells89 3y ago
        Similarly, it’s possible to compile a Mac app that targets PowerPC, x86, and ARM supporting all of the versions of macOS implied by that spread of CPUs. X Lossless Decoder[0] is one such app, supporting all three archs and Mac OS X 10.4 up through macOS 14.x (current) in a single binary. It’ll work just as well on that circa 2000 400Mhz G3 iMac you picked up from a local yard sale as it will on a brand new M3 Pro MBP. [0]: https://tmkk.undo.jp/xld/index_e.html https://tmkk.undo.jp/xld/index_e.html
abhinavk 3y ago
I had read somewhere that Win32 (via Wine or Proton) is the most stable target for Linux right now.
- zer0zzz 3y ago
  Yeah exactly!
- FirmwareBurner 3y ago
  >Win32 (via Wine or Proton) is the most stable target for Linux right now Tangential, Winamp 2.xx from the '90s runs and plays MP3s just fine on Windows 11 today. There are better apps for that today, but I still use it because nostalgia really whips the llama's ass. Pretty wild that the same thing is not the norm in other OSs. Even wilder is that I still have my installed copy of Unreal Tournament 99 from my childhood PC copied over to my current Win 11 machine, and guess what, it just works out of the box, 3D graphics, sound, everything. That's nearly 25 years of backwards compatibility at this point. If that's not stable, I don't know what is.
  - zer0zzz 3y ago
    The most underrated feature of windows probably ever.
    - Dalewyn 3y ago
      It really is mindblowing that Windows 11 is still capable of running 32-bit programs written for Windows 95, that's 28~29 years of backwards compatibility and environmental stability. If we look back to programs written for Windows NT 3.1, released in 1993, and assume they run on Windows 11 (because why not?) then that's 30 years of backwards compatibility. Did I say mindblowing? It's downright mythological what Microsoft achieves and continues to do.
      - EvanAnderson 3y ago
        NTVDM could have been ported to 64-bit Windows, but MSFT declined to do so. Leaked Windows source code shows it would have worked[0]. That would have given 16, 32, and 64 bit compatibility. [0] https://github.com/leecher1337/ntvdmx64 https://github.com/leecher1337/ntvdmx64
chefandy 3y ago
People like to shit on tools like Electron, but there's a reason they're popular. If you need to reach a broad audience with a native tool, using heavy-handed web-based plumbing is a bigger win for Linux users than supporting only windows and macos where like 97% of desktop users are.
- deleted 3y ago
  [deleted]
- FirmwareBurner 3y ago
  Hold on mate, isn't that what Java was supposed to solve. I remember before the days of electron when I was a wee lad in the 2000s, all cross platforms apps were Java. Look at Ghidra, it's a Java app for Windows, Linux and Mac. The "holy trinity" of operating systems, covered with one language and framework. So what happened? Did devs forgot Java exists and felt like reinventing the wheel but worse this time?
  - zer0zzz 3y ago
    Java is objectively terrible for writing good apps on modern personal computers. The one platform that did adopt it (android) had to practically rework the entire byte code and VM as well as the set of APIs for writing apps to make it work.
    - FirmwareBurner 3y ago
      Why is it terrible? Asking for real.
      - LeoNatan25 3y ago
        Because it’s not “sexy” anymore. Now “sexiness” lies with web crap, so Electron is a “great tool”, while Java is “terrible”.
      - zer0zzz 3y ago
        Well, so I can only tell you as much as I know and understand. Some of this pulls in some outdated information too. So, JVMs and languages that abstract the underlying machine are always going to have overhead. The original interpreted stack-based JVM model is really bad for performance because you can't do great optimizations on the code because you can't have a great view of the operands that are being defined and then subsequently used, on top of that you have to either JIT or interpret code which also has overhead. This is why Android's original Dalvik VM originally started by converting the Sun byte code format to a register based format. So, now you have a format you can do some optimizations on: great. But you still depend on a VM to generate and optimize for native code: that means code-caches and that means using excess memory to store the fast optimized code you want to run (which could have been evicted, so more overhead when you have to regenerate). Next you have frameworks like the classic Swing in Java that were frankly implemented with priorities that did not include having a really great and responsive experience even though its platform agnostic as far as the way it draws widgets. These days we can take GPUs for granted to make this approach work, but a lot of the Java UI stuff came from another era. I am not really sure if I am right here, but to me all this means that to have made the Java system work well for modern PCs and mobile it would have required a ton of investment. As it turns out, a lot of that investment went into the web and android instead of polishing Sun and Oracle's uh... product. Java's also kinda been sidelined because for years Oracle threatened to sue anyone that dared fork it as Google had, and Microsoft kinda spent a decade making C# and .NET more confusing than it already was so theres that too.
jwells89 3y ago
If I could have that spread of frameworks that macOS offers on Linux, I’d be targeting Linux with my side projects yesterday. Having such a wide selection of tools to readily reach for with zero consideration about how long it’ll be supported, which fork is best, how well it meshes with a pile of other third party libraries, etc is amazing. It reduces friction massively and you just build stuff. The KDE Qt ecosystem and its GNOME/GTK analogue are closest but still aren’t quite there.
- deleted 3y ago
  [deleted]
- WillAdams 3y ago
  Have you looked into GNUstep? https://gnustep.github.io/ https://gnustep.github.io/
  - jwells89 3y ago
    Yep, have been aware of it for a long time. It’s great in concept but as far as I’m aware a good deal behind current macOS — last I knew it was compatible with OS X 10.6 (released 2009) with no support for Swift or for any of the advancements in Objective-C made since then. I’m also not sure how well GNUStep apps would fit into a modern GTK or Qt-based desktop, e.g. if they’d theme controls to match.
    - LargoLasskhyfv 3y ago
      Have you had a look at https://github.com/trunkmaster/nextspace https://github.com/trunkmaster/nextspace ?
- account42 3y ago
  > If I could have that spread of frameworks that macOS offers on Linux, I’d be targeting Linux with my side projects yesterday. I doubt it. More likely, you would be complaining that you need to spend effort rewring your code to use Linux frameworks for a tiny userbase. That's why most cross-platform software ends up using OS frameworks only where neccessary and ships its own version for most stuff. Coincidentally, that approach matches which stable ABIs are available on Linux.
tempodox 3y ago
And on a lower level, `fgetwc()` gets crashed deliberately in `libc` when applied to a stream created with `fopencookie()`. It should be incredible, but Linux `libc` is not Unicode-capable in 2023.
- zlg_codes 3y ago
  Which libc? There's glibc, musl libc, etc. Also consider you may be using the functions incorrectly.
  - tempodox 3y ago
    Seriously? “You're holding it wrong”? Read the comment at the crash site (line 584) yourself: https://elixir.bootlin.com/glibc/glibc-2.38/source/libio/genops.c#L561 https://elixir.bootlin.com/glibc/glibc-2.38/source/libio/gen...
    - zlg_codes 3y ago
      I wrote "consider", not "you are without a doubt at fault here". Learn how to read.
      - tripleo1 3y ago
        He did consider it; You are without a doubt at fault.
- account42 3y ago
  Wide chars were a mistake and are not required to support Unicode.
eternityforest 3y ago
The Linux enthusiast community actively fights against anything like this because they want everything to be modular and made to fit specific applications. Linux does have a de facto set of standards, they're not quite as stable because they change them and deprecate old stuff, but it's better than it looks, and with Snaps you can at least partially solve the issue. But people choose distros that don't have those standards, and then you lose half your potential users if you don't support all the niche configurations.
- xkekjrktllss 3y ago
  The so-called "Linux enthusiast community" is better described as the Linux corporate enterprise community. Understanding this makes your comment make a lot more sense. The "specific applications" are in fact merely the priorities of the giant corporations who fund the overwhelming majority of Linux development for the purpose of accumulating profit.
  - eternityforest 3y ago
    The corporate enterprise community is who appears to create most of the attempts at user friendly, one size fits all, stable standards, because.... that's what seems to sell, and what saves development budgets not having to support lots of different OSes, as Windows has shown. Many of the non corporate hobbyists are fine with everything needing tweaking and maintenance, they chose Linux specifically because they want to tweak stuff.
    - xkekjrktllss 3y ago
      Not sure what point you're trying to make but the "non corporate hobbyists" are ineffective to the point of irrelevance when it comes to Linux core development. Everything they do is downstream from the influence of giant corporations.
    - deleted 3y ago
      [deleted]
  - 3y ago
isodev 3y ago
Ensuring an app looks and feels the same across various distributions seems quite challenging when it’s not only different flavours of the OS but also different desktop environments. At the same time, the OS flavours don’t seem to offer a unified way for handling payments, subscriptions and in-app purchases which is a significant burden to implement from scratch by every app developer.
- tristan957 3y ago
  Why do distributions need to offer this when SDKs exist for services like Stripe and PayPal?
  - isodev 3y ago
    Because a Linux distributions are used all over the world. Stripe and PayPal are good, but insufficient as a choice - one can't be expected to pick SDKs that work equally well in all regions, preferring local payment options, registering with local tax authorities etc. Also, Stripe and PayPal don't offer tools to check if an app is running with a valid license/subscription, it's not pirated etc. (the equivalent of the App Store receipt signature).
- michaelmrose 3y ago
  The "feel" of the app is identical across distributions because the app controls everything inside its window and the look only varies slightly in terms of colorscheme and window decoration if that. There is absolutely no legit purpose for in app purchases on a desktop OS. Its not hard to pay for substantial software suites and most of what would be an app on platforms which at one point would have had an anemic browser experience is simply a website on platforms where fast cpus and 14-28" screens are normal. Nobody needs a bunch of adware apps you can pay $3 to decrapify or games that are a slog if you don't buy fake potions for real money. There are enough good free basic apps for virtually any use case and the more complex use cases need up front investment and users not in app purchases. What use case do you imagine for this feature?
  - isodev 3y ago
realusername 3y ago
> On competing platforms there are way more frameworks out of the box (CoreImage, CoreAudio, CodeML, SceneKit, AppKit, etc) and they don’t break as often. I would not use MacOS as an example of stability, each version breaks and deprecates a massive amount of API and old apps will require changes. Windows is the only OS with serious backward compatibility.
hulitu 3y ago
> there still doesn’t exist a core set of frameworks that are abi stable on Linux Motif ? WxWidgets ? Openstep ? Gnome and Kde do reinvent the wheel with every release, but they shoouldn't be taken seriously. There is a general problem on the SW world. They like to reinvent the wheel every now and then.
- zer0zzz 3y ago
  How many distros are motif and wxwindows installed on by default? How many distros come with the full GL and vulkan stack?
  - account42 3y ago
    > How many distros come with the full GL and vulkan stack All of the ones intended to run grahical applications. Unless extraneoous stuff like GLUT which noone should be using anyway.

smoldesu 3y ago

Stuff like Flatpak and Snap exists because the framework side kinda is built-out. Isolation technology had matured, newer desktops emphasized per-window security and needed APIs to portal in and out of each instance. The desktops needed a packaging/infrastructure solution to tie that together and make it presentable to the user.

zer0zzz 3y ago
Yet I still can't compile an app on some arbitrary release of some arbitrary distro and just run the darn exe on another and be 100% sure it will work.
- smoldesu 3y ago
  On a large enough timescale I don't think you can reasonably expect this on any of this big 3 OSes. From a less macro perspective, I think tools like Appimage and Flatpak will fill that role.
  - zer0zzz 3y ago
    On a long enough time scale we are all dead, and Linux doesn't exist. That doesn't mean that in the decades that computer software has to be useful to actual people that things have to suck this badly right now.
    - smoldesu 3y ago
      The "actual people" using Linux on the desktop are not running .so files off the internet. I get what you're saying, but you know it's facetious to pretend that packaging is simple on Mac and Windows too.
      - api 3y ago
        Packaging is fairly simple on Mac and Windows if you use the dev tools for the platform and are not doing things like installing services or drivers or changing OS configuration. Your packaged app will almost always work too. There are not 50 distributions of these OSes.
        zer0zzz 3y ago
        exactly
      - zer0zzz 3y ago
        > The "actual people" using Linux on the desktop are not running .so files off the internet. They do this all day every day when they use a little something called Steam or when they install Google Chrome. > I get what you're saying, but you know it's facetious to pretend that packaging is simple on Mac and Windows too. It is...
        account42 3y ago
        > They do this all day every day when they use a little something called Steam Which while (initially) officially only released for a specific Ubuntu version ran on pretty much any up to date distro from day zero.
- AnthonyMouse 3y ago
  The trouble is you're trying to distribute it as a binary yourself. The there are two traditional ways for distributing software for Linux: 1) The system package manager. It will download a binary from the repository which is the right one for that system. 2) make && make install. This is mostly for software in development that hasn't made it into the package manager yet. It will compile from source and produce a binary for the target system. All the problems are from people trying to do something other than this.
  - zer0zzz 3y ago
    That's the problem. The Linux way of distributing apps is wrong for trying to compete with the other consumer platforms. The ChromeOS or electron style of doing things is another story though.
    - AnthonyMouse 3y ago
      What exactly is wrong with it? If you have a stable widely used application suitable for being installed by unsophisticated consumers, have the distributions put it in their package managers. This is hardly any different than consumer mobile platforms that require you to use an app store, except that it isn't actually required, just the thing you ought to do absent a good reason to do otherwise. If you're distributing something sufficiently esoteric or experimental that the package managers won't touch it, your correspondingly sophisticated or adventurous users can compile it from source. We don't need some malware-facilitating norm that encourages users to install opaque binaries from random websites.
    - tripleo1 3y ago
      Alot of you may be looking at it wrong. Each distribution is a different operating system. You cannot package the "same" app for Windows and mac, so why should you be able to package the same application for Debian and Arch, which, even though they run a lot of the same code, have different underlying layers and assumptions?
- eternityforest 3y ago
  On other platforms people don't even try to support anything but one "distro". You could make an AppImage or snap that would work across pretty much any mainstream non-hobbist-oriented distro, and Snap/AppImages is pretty much the Linux equivalent of EXE. Raspberry Pi OS just moved to NetworkManager and they have PipeWire, which was the last reason I had to deal with less common software stacks, so it seems like stuff is getting more standardized.
  - night-rider 3y ago
    +1 AppImages. And the beauty is you can make them portable by creating a folder with the same name as the AppImage and append .home to the end, and boom: portable software. For example image-editor.AppImage image-editor.AppImage.home (folder, all settings are stored there)
    - zer0zzz 3y ago
      Actually, I don't think I've tried AppImage. Does it do static linking or does it do something more similar to flatpak?
      - account42 3y ago
        It's a self-mounting image so closer to flatpak than static linking but without the strict isolation.
  - account42 3y ago
    Snaps will not work on anything but Ubuntu. AppImages are just a fancy self-mounting disk image. If you do it right and include all required contents then it will work ~anywhere but you can just as well do that in a .tar.{gz,xz,zstd}/whatever archive.
    - hollerith 3y ago
      >Snaps will not work on anything but Ubuntu. I installed VSCode as a snap on my Fedora install and it worked fine as far as I could tell. This was in Mar 2021, and I chose the snap because code.visualstudio.com/docs/setup/linux said that "Due to the manual signing process and the system we use to publish, the yum repo may lag behind and not get the latest version of VS Code immediately. . . . Updates are automatic and run in the background for the Snap package." (I don't have an opinion on Snap as compared to Flatpak or AppImage or none of the 3.)

sylware 3y ago

Cuplrits are mostly glibc devs with their manic abuse of version names (and very recently, a GENIUS who added a new ELF relocation type): this is a pain for game developers to provide binaries which span a reasonable set of distros in time. Basic game devs install one of the latest mainstream and massive distros, build there, and throw the binaries on steam... but that recent distro had a glibc 2.36 and now their binaries have version names requiring at least a glibc 2.36 (often, rarely not). They have to force the right version names with... the binutils gas symver directive (see binutils manual) until all their version names are compatible with a glibc reasonably "old" (I would go for a reasonable 5 years... 7/8 years?): https://sourceware.org/glibc/wiki/Glibc%20Timeline https://sourceware.org/glibc/wiki/Glibc%20Timeline Of course normal game devs have not the slightest idea of those issues, and even so, they won't do it because it is a pain, that for 1% of their market. Not to mention they better statically link libgcc (and libstdc++ if they use c++) to avoid the ABI issues of those abominations (the word is fair) which have been plagging game binaries for TEN F.... YEARS ! (getting better has more and more game binaries default to -static-libgcc and -static-libstdc++, if c++, gcc/clang options). There is light at the end of the tunnel though as godot engine is providing build containers which are very careful of all that (unity seems clean there too, dunno for UT5.x though). But you have engines really not ready, for instance electron based games: you don't have the right version of the GTK+ toolkit installed on your enlightenment/Qt/raw X11/wayland/etc distro? Nah, won't run. And packaging properly a full google blink engine for binary distribution targetting a wide spectum of elf/linux distros? Yeah... good luck with that. elf/linux is hostile to anything binary only, that due to manic ABI breakage all over the board, all the time (accute in the SDK and core libs). If it is already that hard for game binaries, good luck with apps. I can hear already their devs saying: "we don't care, just use and install microsoft suze gnu/linux, every else is unsupported"... I think you get the picture where all that is going.

zer0zzz 3y ago
I agree. I recall a talk from Linux Torvalds on how bad the glibc folks break things and why he won't ship a binary version of his scuba tool. If the binary breakages start with the darn C lib, you're gonna have recurring problems all the way up the stack on a regular basis I feel.

pjmlp 3y ago

That core would be GNOME or KDE frameworks, coupled with the FreeDesktop standards, at least that was the plan about 20 years ago. However as the site says doing distributions is what most folks keep doing, and naturally there isn't a single stack that can keep up with snowflake distributions. In the end, Google took the Linux kernel, placed two core set of frameworks, one in Java, and the other in JavaScript, and naturally those are the winning Linux distributions for regular consumers.

zer0zzz 3y ago
None of that core is standardized across even a hand full of distros.
- fragmede 3y ago
  Chrome/Chromium is quite standardized, across many distros.
  - zer0zzz 3y ago
    Name one distro that ships with chrome out of the box? I dont even think ubuntu comes with a chromium browser. That means devs cant write apps against it and just hand out exes like they do on Mac and windows.
    - charcircuit 3y ago
      Play Protect Certified Android and ChromeOS are popular ones among consumers
      - zer0zzz 3y ago
        Nice. Maybe more desktop distros should build on android as a core. That could solve a lot of problems.
        charcircuit 3y ago

znpy 3y ago

> and they don’t break as often. Meh, kinda. It's not a case that proprietary software vendors only target RHEL, Suse and Ubuntu. RHEL is a perfect target for stable software and Ubuntu might be as well if you decide to only support LTS releases.

zer0zzz 3y ago
Targeting only a hand full of frozen releases is not abi stability. Abi stability is when any app can be compiled off any release and run on any future release (and ideally older releases too).
- yjftsjthsd-h 3y ago
  > Abi stability is when any app can be compiled off any release and run on any future release (and ideally older releases too). Hang on, if that's the standard why is MacOS getting a pass? I'd believe that Windows meets that bar, but I see posts on a routine enough basis about Apple forcing rewrites, unless I really misunderstood something there.
  - zer0zzz 3y ago
    Apple's actually quite good at this, but they do break things on purpose from time to time for reasons which they announce pretty publicly at WWDC when they do (32->64bit, deprecating GL, etc). So, for example a dev can target an app at iOS 8 and it still works fine on iOS 17. Thats almost a decade of OS updates that didn't affect an app. Here's an example: https://apps.apple.com/us/app/bebot-robot-synth/id300309944 https://apps.apple.com/us/app/bebot-robot-synth/id300309944
    - jwells89 3y ago
      Similarly, it’s possible to compile a Mac app that targets PowerPC, x86, and ARM supporting all of the versions of macOS implied by that spread of CPUs. X Lossless Decoder[0] is one such app, supporting all three archs and Mac OS X 10.4 up through macOS 14.x (current) in a single binary. It’ll work just as well on that circa 2000 400Mhz G3 iMac you picked up from a local yard sale as it will on a brand new M3 Pro MBP. [0]: https://tmkk.undo.jp/xld/index_e.html https://tmkk.undo.jp/xld/index_e.html

abhinavk 3y ago

I had read somewhere that Win32 (via Wine or Proton) is the most stable target for Linux right now.

zer0zzz 3y ago
Yeah exactly!
FirmwareBurner 3y ago
>Win32 (via Wine or Proton) is the most stable target for Linux right now Tangential, Winamp 2.xx from the '90s runs and plays MP3s just fine on Windows 11 today. There are better apps for that today, but I still use it because nostalgia really whips the llama's ass. Pretty wild that the same thing is not the norm in other OSs. Even wilder is that I still have my installed copy of Unreal Tournament 99 from my childhood PC copied over to my current Win 11 machine, and guess what, it just works out of the box, 3D graphics, sound, everything. That's nearly 25 years of backwards compatibility at this point. If that's not stable, I don't know what is.
- zer0zzz 3y ago
  The most underrated feature of windows probably ever.
  - Dalewyn 3y ago
    It really is mindblowing that Windows 11 is still capable of running 32-bit programs written for Windows 95, that's 28~29 years of backwards compatibility and environmental stability. If we look back to programs written for Windows NT 3.1, released in 1993, and assume they run on Windows 11 (because why not?) then that's 30 years of backwards compatibility. Did I say mindblowing? It's downright mythological what Microsoft achieves and continues to do.
    - EvanAnderson 3y ago
      NTVDM could have been ported to 64-bit Windows, but MSFT declined to do so. Leaked Windows source code shows it would have worked[0]. That would have given 16, 32, and 64 bit compatibility. [0] https://github.com/leecher1337/ntvdmx64 https://github.com/leecher1337/ntvdmx64

chefandy 3y ago

People like to shit on tools like Electron, but there's a reason they're popular. If you need to reach a broad audience with a native tool, using heavy-handed web-based plumbing is a bigger win for Linux users than supporting only windows and macos where like 97% of desktop users are.

deleted 3y ago
[deleted]
FirmwareBurner 3y ago
Hold on mate, isn't that what Java was supposed to solve. I remember before the days of electron when I was a wee lad in the 2000s, all cross platforms apps were Java. Look at Ghidra, it's a Java app for Windows, Linux and Mac. The "holy trinity" of operating systems, covered with one language and framework. So what happened? Did devs forgot Java exists and felt like reinventing the wheel but worse this time?
- zer0zzz 3y ago
  Java is objectively terrible for writing good apps on modern personal computers. The one platform that did adopt it (android) had to practically rework the entire byte code and VM as well as the set of APIs for writing apps to make it work.
  - FirmwareBurner 3y ago
    Why is it terrible? Asking for real.
    - LeoNatan25 3y ago
      Because it’s not “sexy” anymore. Now “sexiness” lies with web crap, so Electron is a “great tool”, while Java is “terrible”.
    - zer0zzz 3y ago
      Well, so I can only tell you as much as I know and understand. Some of this pulls in some outdated information too. So, JVMs and languages that abstract the underlying machine are always going to have overhead. The original interpreted stack-based JVM model is really bad for performance because you can't do great optimizations on the code because you can't have a great view of the operands that are being defined and then subsequently used, on top of that you have to either JIT or interpret code which also has overhead. This is why Android's original Dalvik VM originally started by converting the Sun byte code format to a register based format. So, now you have a format you can do some optimizations on: great. But you still depend on a VM to generate and optimize for native code: that means code-caches and that means using excess memory to store the fast optimized code you want to run (which could have been evicted, so more overhead when you have to regenerate). Next you have frameworks like the classic Swing in Java that were frankly implemented with priorities that did not include having a really great and responsive experience even though its platform agnostic as far as the way it draws widgets. These days we can take GPUs for granted to make this approach work, but a lot of the Java UI stuff came from another era. I am not really sure if I am right here, but to me all this means that to have made the Java system work well for modern PCs and mobile it would have required a ton of investment. As it turns out, a lot of that investment went into the web and android instead of polishing Sun and Oracle's uh... product. Java's also kinda been sidelined because for years Oracle threatened to sue anyone that dared fork it as Google had, and Microsoft kinda spent a decade making C# and .NET more confusing than it already was so theres that too.

jwells89 3y ago

If I could have that spread of frameworks that macOS offers on Linux, I’d be targeting Linux with my side projects yesterday. Having such a wide selection of tools to readily reach for with zero consideration about how long it’ll be supported, which fork is best, how well it meshes with a pile of other third party libraries, etc is amazing. It reduces friction massively and you just build stuff. The KDE Qt ecosystem and its GNOME/GTK analogue are closest but still aren’t quite there.

deleted 3y ago
[deleted]
WillAdams 3y ago
Have you looked into GNUstep? https://gnustep.github.io/ https://gnustep.github.io/
- jwells89 3y ago
  Yep, have been aware of it for a long time. It’s great in concept but as far as I’m aware a good deal behind current macOS — last I knew it was compatible with OS X 10.6 (released 2009) with no support for Swift or for any of the advancements in Objective-C made since then. I’m also not sure how well GNUStep apps would fit into a modern GTK or Qt-based desktop, e.g. if they’d theme controls to match.
  - LargoLasskhyfv 3y ago
    Have you had a look at https://github.com/trunkmaster/nextspace https://github.com/trunkmaster/nextspace ?
account42 3y ago
> If I could have that spread of frameworks that macOS offers on Linux, I’d be targeting Linux with my side projects yesterday. I doubt it. More likely, you would be complaining that you need to spend effort rewring your code to use Linux frameworks for a tiny userbase. That's why most cross-platform software ends up using OS frameworks only where neccessary and ships its own version for most stuff. Coincidentally, that approach matches which stable ABIs are available on Linux.

tempodox 3y ago

And on a lower level, `fgetwc()` gets crashed deliberately in `libc` when applied to a stream created with `fopencookie()`. It should be incredible, but Linux `libc` is not Unicode-capable in 2023.

zlg_codes 3y ago
Which libc? There's glibc, musl libc, etc. Also consider you may be using the functions incorrectly.
- tempodox 3y ago
  Seriously? “You're holding it wrong”? Read the comment at the crash site (line 584) yourself: https://elixir.bootlin.com/glibc/glibc-2.38/source/libio/genops.c#L561 https://elixir.bootlin.com/glibc/glibc-2.38/source/libio/gen...
  - zlg_codes 3y ago
    I wrote "consider", not "you are without a doubt at fault here". Learn how to read.
    - tripleo1 3y ago
      He did consider it; You are without a doubt at fault.
account42 3y ago
Wide chars were a mistake and are not required to support Unicode.

eternityforest 3y ago

The Linux enthusiast community actively fights against anything like this because they want everything to be modular and made to fit specific applications. Linux does have a de facto set of standards, they're not quite as stable because they change them and deprecate old stuff, but it's better than it looks, and with Snaps you can at least partially solve the issue. But people choose distros that don't have those standards, and then you lose half your potential users if you don't support all the niche configurations.

xkekjrktllss 3y ago
The so-called "Linux enthusiast community" is better described as the Linux corporate enterprise community. Understanding this makes your comment make a lot more sense. The "specific applications" are in fact merely the priorities of the giant corporations who fund the overwhelming majority of Linux development for the purpose of accumulating profit.
- eternityforest 3y ago
  The corporate enterprise community is who appears to create most of the attempts at user friendly, one size fits all, stable standards, because.... that's what seems to sell, and what saves development budgets not having to support lots of different OSes, as Windows has shown. Many of the non corporate hobbyists are fine with everything needing tweaking and maintenance, they chose Linux specifically because they want to tweak stuff.
  - xkekjrktllss 3y ago
    Not sure what point you're trying to make but the "non corporate hobbyists" are ineffective to the point of irrelevance when it comes to Linux core development. Everything they do is downstream from the influence of giant corporations.
  - deleted 3y ago
    [deleted]
- 3y ago

isodev 3y ago

Ensuring an app looks and feels the same across various distributions seems quite challenging when it’s not only different flavours of the OS but also different desktop environments. At the same time, the OS flavours don’t seem to offer a unified way for handling payments, subscriptions and in-app purchases which is a significant burden to implement from scratch by every app developer.

tristan957 3y ago
Why do distributions need to offer this when SDKs exist for services like Stripe and PayPal?
- isodev 3y ago
  Because a Linux distributions are used all over the world. Stripe and PayPal are good, but insufficient as a choice - one can't be expected to pick SDKs that work equally well in all regions, preferring local payment options, registering with local tax authorities etc. Also, Stripe and PayPal don't offer tools to check if an app is running with a valid license/subscription, it's not pirated etc. (the equivalent of the App Store receipt signature).
michaelmrose 3y ago
The "feel" of the app is identical across distributions because the app controls everything inside its window and the look only varies slightly in terms of colorscheme and window decoration if that. There is absolutely no legit purpose for in app purchases on a desktop OS. Its not hard to pay for substantial software suites and most of what would be an app on platforms which at one point would have had an anemic browser experience is simply a website on platforms where fast cpus and 14-28" screens are normal. Nobody needs a bunch of adware apps you can pay $3 to decrapify or games that are a slog if you don't buy fake potions for real money. There are enough good free basic apps for virtually any use case and the more complex use cases need up front investment and users not in app purchases. What use case do you imagine for this feature?
- isodev 3y ago

realusername 3y ago

> On competing platforms there are way more frameworks out of the box (CoreImage, CoreAudio, CodeML, SceneKit, AppKit, etc) and they don’t break as often. I would not use MacOS as an example of stability, each version breaks and deprecates a massive amount of API and old apps will require changes. Windows is the only OS with serious backward compatibility.

hulitu 3y ago

> there still doesn’t exist a core set of frameworks that are abi stable on Linux Motif ? WxWidgets ? Openstep ? Gnome and Kde do reinvent the wheel with every release, but they shoouldn't be taken seriously. There is a general problem on the SW world. They like to reinvent the wheel every now and then.

zer0zzz 3y ago
How many distros are motif and wxwindows installed on by default? How many distros come with the full GL and vulkan stack?
- account42 3y ago
  > How many distros come with the full GL and vulkan stack All of the ones intended to run grahical applications. Unless extraneoous stuff like GLUT which noone should be using anyway.