6 ms·

Static linking -- always the ready-to-go response for anything ABI-related. But does it really help? What use is a statically linked glibc+Xlib when your deskto

Static linking -- always the ready-to-go response for anything ABI-related. But does it really help? What use is a statically linked glibc+Xlib when your desktop no longer sets resolv.conf in the usual place and no longer speaks the X11 protocol (perhaps in the name of security) ?

gabereiser 4y ago
Even statically linked, the problems you just described are valid. The issue is x11 isn’t holding up and no one wants to change. Wayland was that promise of change but has taken 15+ years to develop (and still developing). Linux desktop is a distro concern now. Not an ecosystem concern. It’s long left the realm of an linux concern when MacOS went free (with paid hardware of course) and Windows was giving away free windows 10 licenses to anyone who asked for it. Deepin desktop and elementary are on the top of my list for elegance and ease of use. Apps and games need a solid ABI and this back and forth between gnome and kde doesn’t help. With so many different wm’s and desktop environments, x11 is still the only method of getting a window with an opengl context in any kind of standard way. Wayland, X12, whatever it is, we need a universal ABI for window dressing for Linux to be taken seriously on the desktop.
- pengaru 4y ago
  > Linux desktop is a distro concern now. Not an ecosystem concern. It’s long left the realm of an linux concern when MacOS went free (with paid hardware of course) and Windows was giving away free windows 10 licenses to anyone who asked for it. You seem fixated on the Free Beer misinterpretation of Free Software.
  - gabereiser 4y ago
    No, but it sounds that way I guess. It’s more about where the developer en-masse focus lays. Few developers are interested in the desktop for Linux because they are supported on windows or Mac and during the time period I mentioned, it didn’t cost them anything monetary. There were indications that windows and Linux May converge. Instead we got WSL2. A lot of times we decide to develop something because of the pain of using the other thing. Sometimes we develop something as a “me too”. Sometimes we develop something that is just better. Sometimes, it’s worse. My point is the fight for a foothold in Linux desktop looked promising for a bit. SteamOS looked like it was gaining, steam… The reality is there are complexities at that level that people don’t want to deal with and we all have opinions on how it should work, should look, and should be called. Red Hat (former RH’er myself) should take this on and really standardize something outside of core and server land. And no, it should not be Gnome.
- cogman10 4y ago
  With the rise of WSL, I have a real hard time justifying wanting a linux desktop. I've got a VM with a full linux distro at my fingertips. Virtualization has gotten more than fast enough. And now, with windows 11, I get an X server integrated with my WSL instance so even if I WANTED a linux app, I can launch it just like I would if I were using linux as my host. It does suck that the WSL1 notion of "not a vm" didn't take off, but at the same time, when the VM looks and behaves like a regular bash terminal, what more could you realistically want?
  - blibble 4y ago
    > what more could you realistically want? some privacy, no telemetry, no ads, and the computer only applying updates that I choose and only rebooting when I ask it to? (I know it's a lot to ask for these days...)
    - gabereiser 4y ago
      :pulls out wallet: where?
    - CoolCold 4y ago
      I opted in telemetry to ensure OS vendor has data on usage, issues, crashes. The same for say Firefox. I believe providing it helps vendors to improve and fix issues quicker.
  - gabereiser 4y ago
    Yeah, WSL(2) was a huge huge win for Microsoft. It seems silly, but it’s kept thousands of devs from dual booting…
    - blibble 4y ago
      I dunno it's quite possible it'll work out as well as IBM's OS/2 running Windows apps did
    - CoolCold 4y ago
      Since when saving time and increasing productivity became silly? Not even saying getting rid of Linux VMs, shared folders and similar annoying things is a good thing overall.
Beltalowda 4y ago
I guess that kind of proves the point that there is no "stable", well, anything on Linux. Something like /etc/resolv.conf is part of the user-visible API on Linux; if you change that, you're going to break applications. /etc/sysctl.conf is a good example; on some systems it just works, on some systems you need to enable a systemd service thingy for it, but on some systems the systemd thingy doesn't read /etc/sysctl.conf and only /etc/sysctl.d. So a simple "if you're running Linux, edit /etc/sysctl.conf to make these changes persist" has now become a much more complicated story. Writing a script to work on all Linux distros is much harder than it needs to be.
- vetinari 4y ago
  > Something like /etc/resolv.conf is part of the user-visible API on Linux; if you change that, you're going to break applications. Apps were not supposed to open /etc/resolv.conf by themselves. If they did, they are broken. Just because the file is available, transparently, doesn't mean it is not a part of the internal implementation. Even golang runtime checks nsswitch for known, good configuration before using resolv.conf instead of thunking to glibc.
  - Beltalowda 4y ago
    The point was that if you're statically linking something that paths such as /etc/resolv.conf become "hard-coded", so that seems like an unimportant detail; something needs to check it, whether that's an application or an application through a library call: it's the same thing. /etc/nsswitch.conf is just kicking the can down the road from /etc/resolv.conf to /etc/nsswitch.conf.
    - vetinari 4y ago
      What would exactly be that "something"? Statically linking glibc was always strongly discouraged. Even if you did it, nss and iconv are always dynamically loaded, and they need symbols from glibc itself, so your statically-glibc-linked binary would need to load dynamic libc anyway! No, something doesn't need to check it, today it exists only to serve broken applications (and systems broken by their admins). Its semantic doesn't allow to express the needs of resolvers today (like per-interface or per-zone resolving or other mechanisms, like mDNS). How the resolver is configured is its internal issue; apps should just use getnameinfo().

gabereiser 4y ago

Even statically linked, the problems you just described are valid. The issue is x11 isn’t holding up and no one wants to change. Wayland was that promise of change but has taken 15+ years to develop (and still developing). Linux desktop is a distro concern now. Not an ecosystem concern. It’s long left the realm of an linux concern when MacOS went free (with paid hardware of course) and Windows was giving away free windows 10 licenses to anyone who asked for it. Deepin desktop and elementary are on the top of my list for elegance and ease of use. Apps and games need a solid ABI and this back and forth between gnome and kde doesn’t help. With so many different wm’s and desktop environments, x11 is still the only method of getting a window with an opengl context in any kind of standard way. Wayland, X12, whatever it is, we need a universal ABI for window dressing for Linux to be taken seriously on the desktop.

pengaru 4y ago
> Linux desktop is a distro concern now. Not an ecosystem concern. It’s long left the realm of an linux concern when MacOS went free (with paid hardware of course) and Windows was giving away free windows 10 licenses to anyone who asked for it. You seem fixated on the Free Beer misinterpretation of Free Software.
- gabereiser 4y ago
  No, but it sounds that way I guess. It’s more about where the developer en-masse focus lays. Few developers are interested in the desktop for Linux because they are supported on windows or Mac and during the time period I mentioned, it didn’t cost them anything monetary. There were indications that windows and Linux May converge. Instead we got WSL2. A lot of times we decide to develop something because of the pain of using the other thing. Sometimes we develop something as a “me too”. Sometimes we develop something that is just better. Sometimes, it’s worse. My point is the fight for a foothold in Linux desktop looked promising for a bit. SteamOS looked like it was gaining, steam… The reality is there are complexities at that level that people don’t want to deal with and we all have opinions on how it should work, should look, and should be called. Red Hat (former RH’er myself) should take this on and really standardize something outside of core and server land. And no, it should not be Gnome.
cogman10 4y ago
With the rise of WSL, I have a real hard time justifying wanting a linux desktop. I've got a VM with a full linux distro at my fingertips. Virtualization has gotten more than fast enough. And now, with windows 11, I get an X server integrated with my WSL instance so even if I WANTED a linux app, I can launch it just like I would if I were using linux as my host. It does suck that the WSL1 notion of "not a vm" didn't take off, but at the same time, when the VM looks and behaves like a regular bash terminal, what more could you realistically want?
- blibble 4y ago
  > what more could you realistically want? some privacy, no telemetry, no ads, and the computer only applying updates that I choose and only rebooting when I ask it to? (I know it's a lot to ask for these days...)
  - gabereiser 4y ago
    :pulls out wallet: where?
  - CoolCold 4y ago
    I opted in telemetry to ensure OS vendor has data on usage, issues, crashes. The same for say Firefox. I believe providing it helps vendors to improve and fix issues quicker.
- gabereiser 4y ago
  Yeah, WSL(2) was a huge huge win for Microsoft. It seems silly, but it’s kept thousands of devs from dual booting…
  - blibble 4y ago
    I dunno it's quite possible it'll work out as well as IBM's OS/2 running Windows apps did
  - CoolCold 4y ago
    Since when saving time and increasing productivity became silly? Not even saying getting rid of Linux VMs, shared folders and similar annoying things is a good thing overall.

Beltalowda 4y ago

I guess that kind of proves the point that there is no "stable", well, anything on Linux. Something like /etc/resolv.conf is part of the user-visible API on Linux; if you change that, you're going to break applications. /etc/sysctl.conf is a good example; on some systems it just works, on some systems you need to enable a systemd service thingy for it, but on some systems the systemd thingy doesn't read /etc/sysctl.conf and only /etc/sysctl.d. So a simple "if you're running Linux, edit /etc/sysctl.conf to make these changes persist" has now become a much more complicated story. Writing a script to work on all Linux distros is much harder than it needs to be.

vetinari 4y ago
> Something like /etc/resolv.conf is part of the user-visible API on Linux; if you change that, you're going to break applications. Apps were not supposed to open /etc/resolv.conf by themselves. If they did, they are broken. Just because the file is available, transparently, doesn't mean it is not a part of the internal implementation. Even golang runtime checks nsswitch for known, good configuration before using resolv.conf instead of thunking to glibc.
- Beltalowda 4y ago
  The point was that if you're statically linking something that paths such as /etc/resolv.conf become "hard-coded", so that seems like an unimportant detail; something needs to check it, whether that's an application or an application through a library call: it's the same thing. /etc/nsswitch.conf is just kicking the can down the road from /etc/resolv.conf to /etc/nsswitch.conf.
  - vetinari 4y ago
    What would exactly be that "something"? Statically linking glibc was always strongly discouraged. Even if you did it, nss and iconv are always dynamically loaded, and they need symbols from glibc itself, so your statically-glibc-linked binary would need to load dynamic libc anyway! No, something doesn't need to check it, today it exists only to serve broken applications (and systems broken by their admins). Its semantic doesn't allow to express the needs of resolvers today (like per-interface or per-zone resolving or other mechanisms, like mDNS). How the resolver is configured is its internal issue; apps should just use getnameinfo().