5 ms·

> knowing that if I build an app and it probably won’t work in 5 years Would you say MacOS, Android, and iPhone are also hobbyist toys then? And by the way, i

> knowing that if I build an app and it probably won’t work in 5 years Would you say MacOS, Android, and iPhone are also hobbyist toys then? And by the way, if you statically compile your app for Linux it will basically work forever. Linus's mantra: We Do Not Break Userspace. These are userland problems and can all be avoided with a linker flag if it's a priority for you.

gjsman-1000 2y ago
A statically compiled app that used Xorg won’t run on many Linux distributions at the moment. A statically compiled app that used Jack for audio might have problems running on PipeWire. A statically compiled app from 2012 that used PolicyKit for authorization might not work today when asking for sudo. Everyone’s moved on to polkit. The meme is wrong, don’t regurgitate nonsense. I can guarantee you my Windows app compiled in 2007 still has the UAC prompt and the audio system working correctly.
- do_not_redeem 2y ago
  What distro are you using that doesn't package Xwayland or pipewire-jack? Sure those are compatibility layers, but so is WoW64. The Linux and Windows backcompat strategies aren't all that different here.
  - bandrami 2y ago
    pipewire-jack won't work with a program that links libjack statically. Pipewire preloads its own .so and hijacks those library calls.
- ben-schaaf 2y ago
  > A statically compiled app that used Xorg won’t run on many Linux distributions at the moment. Not a single major distribution doesn't ship Xwayland by default. The entire gaming community relies on X11 continuing to work, just like they rely on x86 libraries to stick around. > A statically compiled app that used Jack for audio might have problems running on PipeWire. A statically compiled app that uses Jack for audio might have problems running on Pulseaudio/ALSA/OSS. Jack's never a thing that's generally available, so claiming it's a backwards compatibility issue is nonsense. If your application requires Jack, then you need to ship it. Note that you'll also have issues on Windows and Mac because Jack - unsurprisingly - is not installed by default on those platforms either. > A statically compiled app from 2012 that used PolicyKit for authorization might not work today when asking for sudo. Everyone’s moved on to polkit. If you used policykit correctly you should have either used the dbus protocol, or the command line utilities. These are the APIs for userspace and they haven't changed since 2012.
cloudsec9 2y ago
This is a broken mindset, that you should be able to take an app and use it for 5+ years. When computers were in their infancy, and systems were only updated every 4-6 years, it might have made sense, but this doesn't in our modern software environment. Nowadays all software is built on libraries and frameworks, and they have security issues and even just bugs, and you want to get those fixes. If you want to run 5+ year old software, you can now do it natively in a VM in almost any computer; so why does my shiny new OS have to run ancient binaries again?
- rerdavies 2y ago
  Because you might want to run more than one program at a time without having to spin up a VM to do it.
  - cloudsec9 2y ago
    I run many programs at the same time AND run VMs; as long as you have enough memory, this shouldn't be an issue.
- RossBencina 2y ago
  Without intending to be inflammatory, I think that the mindset that you are espousing is broken. Security is is a real issue for a subset of computing tasks. To further your point, for those tasks you can argue that constant vigilance and patching are a necessity of the modern world (an alternative and arguably better approach would be that formal verification and not updating, as often applied in safety critical control systems.) However, security is often used as a pernicious ruse for forcing obsolesence: want the latest security patches? update to the latest OS version. Oh look, the latest OS version no longer runs on your perfectly good hardware. Or similarly, oh look, your perfectly good software no longer runs on the latest OS version. But now consider the subset of computing that does not need to involve security either because it has literally no security implications, or because it can be sandboxed by the OS (e.g. games, music and video production, architectural design, scientific simulation, mathematical research, ...) There is a large body of this kind of software that works perfectly well for any number of years (modulo forced obsolesce initiatives like "modernising" the UI or moving to the cloud). I would argue that the primary function of the OS should be to provide a stable platform for running such software securely. Yes, the user could learn how run it under emulation, in a container or VM, but then what is the purpose of the OS? The alternative is a high software maintenance burden/cost to everyone (for applications to just keep the lights on, or users to stay current in a churning software landscape) and/or the destruction of a massive amount value in developed but no longer easily able to be run software: this value destruction here is twofold: (1) the licensee can no longer run the software that they pay for, and (2) the effort expended to develop said software is discarded.
itvision 2y ago
You cannot statically compile a lot of stuff. Too many Linux libraries are GPLed, and that only works for open source applications. And then one day the underlying libraries will have security problems. Your statically linked application has just become a gaping hole. And finally, you don't want your statically compiled binary to be hundreds of megabytes and take forever to launch, do you? But seeing how many people here are advocating Snap/Flat/AppImage, I guess it's not a problem? But why would you need a Linux userspace or OS in the first place when all you are doing is running virtual containers? You can run them on Windows or MacOS as well.
- ryao 2y ago
  Not many libraries use the GPL because “that only works for open source applications”. That said, you can just copy the .so files if you want to run the old binary. Furthermore, binaries are mmapped, so even if it is very large, it will still launch relatively quickly since only the parts needed to launch are read into memory.
  - itvision 2y ago
    LD_LIBRARY_PATH again? Can you stop for a second and realize your "solutions" are absolute unmitigated crap and 99.999% of people of the world wouldn't bother even if they could? In Windows you don't have to do that. You can compile an application in Windows 11 and run it in Windows XP for Christ's sake (if you don't use new Windows APIs). Show me a way to compile anything in Ubuntu 24 using only its own libraries and have it run in Ubuntu 6, huh? Without virtualizating/chrooting/crap like that. No, you can't? Fine. > Not many libraries use the GPL Let me start: Qt. Before your spew "GTK", who is going to pay for porting the code to GTK/GTKMM (since GTK is C only)? End of your wonderful story. You really want to bend reality to make Linux look "OK". It's not. It's bad.
    - ryao 2y ago
      First, LD_LIBRARY_PATH works well (or has for me). If for some reason the elf interpreter is unable to use the older libc, just use the old elf interpreter. Second, do static linking to achieve what you want. Then it will run on the older Ubuntu trivially. That of course requires updating the application when a vulnerability is found in a library, but this is no different from Windows where you have to update many applications to fix vulnerabilities in third party libraries. The number of vendor updates to fix the same libjpeg of libpng issues on Windows is truly staggering. The Qt libraries do not use the GPL. They use the same LGPL that GTK does. You are making stuff up to bash open source UNIX machines (which is what Linux machines are).

gjsman-1000 2y ago

A statically compiled app that used Xorg won’t run on many Linux distributions at the moment. A statically compiled app that used Jack for audio might have problems running on PipeWire. A statically compiled app from 2012 that used PolicyKit for authorization might not work today when asking for sudo. Everyone’s moved on to polkit. The meme is wrong, don’t regurgitate nonsense. I can guarantee you my Windows app compiled in 2007 still has the UAC prompt and the audio system working correctly.

do_not_redeem 2y ago
What distro are you using that doesn't package Xwayland or pipewire-jack? Sure those are compatibility layers, but so is WoW64. The Linux and Windows backcompat strategies aren't all that different here.
- bandrami 2y ago
  pipewire-jack won't work with a program that links libjack statically. Pipewire preloads its own .so and hijacks those library calls.
ben-schaaf 2y ago
> A statically compiled app that used Xorg won’t run on many Linux distributions at the moment. Not a single major distribution doesn't ship Xwayland by default. The entire gaming community relies on X11 continuing to work, just like they rely on x86 libraries to stick around. > A statically compiled app that used Jack for audio might have problems running on PipeWire. A statically compiled app that uses Jack for audio might have problems running on Pulseaudio/ALSA/OSS. Jack's never a thing that's generally available, so claiming it's a backwards compatibility issue is nonsense. If your application requires Jack, then you need to ship it. Note that you'll also have issues on Windows and Mac because Jack - unsurprisingly - is not installed by default on those platforms either. > A statically compiled app from 2012 that used PolicyKit for authorization might not work today when asking for sudo. Everyone’s moved on to polkit. If you used policykit correctly you should have either used the dbus protocol, or the command line utilities. These are the APIs for userspace and they haven't changed since 2012.

cloudsec9 2y ago

This is a broken mindset, that you should be able to take an app and use it for 5+ years. When computers were in their infancy, and systems were only updated every 4-6 years, it might have made sense, but this doesn't in our modern software environment. Nowadays all software is built on libraries and frameworks, and they have security issues and even just bugs, and you want to get those fixes. If you want to run 5+ year old software, you can now do it natively in a VM in almost any computer; so why does my shiny new OS have to run ancient binaries again?

rerdavies 2y ago
Because you might want to run more than one program at a time without having to spin up a VM to do it.
- cloudsec9 2y ago
  I run many programs at the same time AND run VMs; as long as you have enough memory, this shouldn't be an issue.
RossBencina 2y ago
Without intending to be inflammatory, I think that the mindset that you are espousing is broken. Security is is a real issue for a subset of computing tasks. To further your point, for those tasks you can argue that constant vigilance and patching are a necessity of the modern world (an alternative and arguably better approach would be that formal verification and not updating, as often applied in safety critical control systems.) However, security is often used as a pernicious ruse for forcing obsolesence: want the latest security patches? update to the latest OS version. Oh look, the latest OS version no longer runs on your perfectly good hardware. Or similarly, oh look, your perfectly good software no longer runs on the latest OS version. But now consider the subset of computing that does not need to involve security either because it has literally no security implications, or because it can be sandboxed by the OS (e.g. games, music and video production, architectural design, scientific simulation, mathematical research, ...) There is a large body of this kind of software that works perfectly well for any number of years (modulo forced obsolesce initiatives like "modernising" the UI or moving to the cloud). I would argue that the primary function of the OS should be to provide a stable platform for running such software securely. Yes, the user could learn how run it under emulation, in a container or VM, but then what is the purpose of the OS? The alternative is a high software maintenance burden/cost to everyone (for applications to just keep the lights on, or users to stay current in a churning software landscape) and/or the destruction of a massive amount value in developed but no longer easily able to be run software: this value destruction here is twofold: (1) the licensee can no longer run the software that they pay for, and (2) the effort expended to develop said software is discarded.

itvision 2y ago

You cannot statically compile a lot of stuff. Too many Linux libraries are GPLed, and that only works for open source applications. And then one day the underlying libraries will have security problems. Your statically linked application has just become a gaping hole. And finally, you don't want your statically compiled binary to be hundreds of megabytes and take forever to launch, do you? But seeing how many people here are advocating Snap/Flat/AppImage, I guess it's not a problem? But why would you need a Linux userspace or OS in the first place when all you are doing is running virtual containers? You can run them on Windows or MacOS as well.

ryao 2y ago
Not many libraries use the GPL because “that only works for open source applications”. That said, you can just copy the .so files if you want to run the old binary. Furthermore, binaries are mmapped, so even if it is very large, it will still launch relatively quickly since only the parts needed to launch are read into memory.
- itvision 2y ago
  LD_LIBRARY_PATH again? Can you stop for a second and realize your "solutions" are absolute unmitigated crap and 99.999% of people of the world wouldn't bother even if they could? In Windows you don't have to do that. You can compile an application in Windows 11 and run it in Windows XP for Christ's sake (if you don't use new Windows APIs). Show me a way to compile anything in Ubuntu 24 using only its own libraries and have it run in Ubuntu 6, huh? Without virtualizating/chrooting/crap like that. No, you can't? Fine. > Not many libraries use the GPL Let me start: Qt. Before your spew "GTK", who is going to pay for porting the code to GTK/GTKMM (since GTK is C only)? End of your wonderful story. You really want to bend reality to make Linux look "OK". It's not. It's bad.
  - ryao 2y ago
    First, LD_LIBRARY_PATH works well (or has for me). If for some reason the elf interpreter is unable to use the older libc, just use the old elf interpreter. Second, do static linking to achieve what you want. Then it will run on the older Ubuntu trivially. That of course requires updating the application when a vulnerability is found in a library, but this is no different from Windows where you have to update many applications to fix vulnerabilities in third party libraries. The number of vendor updates to fix the same libjpeg of libpng issues on Windows is truly staggering. The Qt libraries do not use the GPL. They use the same LGPL that GTK does. You are making stuff up to bash open source UNIX machines (which is what Linux machines are).