3 ms·

>I have 878 unique shared libraries shared between currently running processes on my Linux laptop at this moment, with the amount of processes sharing a library

>I have 878 unique shared libraries shared between currently running processes on my Linux laptop at this moment, with the amount of processes sharing a library ranging from 2 processes to 820. Most may have few in common, but there are a lot of them, and the mean is 62, mode is 4. Good god, this tells half the story. An agunix install booted to a shell will typically only have 3 processes running: runit, a getty, and your shell. I don't think I've ever had more than 50 processes running on my agunix system at any given moment. >As far as the botched update argument: When does anybody botch an update of a shared library? When they're forcing something to install, or they don't know what they're doing. For any number of reasons. This has happened to me dozens of times in the past year. You also run into issues with any software you compiled yourself that aren't managed by the package manager (or at least not supported by your distro). You know what's better? An executable that works on any Linux system and will continue to work for the next 20 years without any changes. How about running two executables that need different versions of a library? >On the other hand, mis-matches in applications using different versions of the same code causes silent, unexpected, difficult to debug errors. I haven't run into this yet. Have you? >I'd also be interested in seeing actual "RAM and disk footprint" numbers as a comparison for the same applications and libraries, because that doesn't really make sense. Even if applications only copy a couple small functions each, they add up, whereas the shared library only has one copy. My laptop is currently running runit, 8 gettys, sshd, wpa_supplicant, crond, udevd, and dhcpcd. It's using 60 MiB of RAM. So far as disk footprint is concerned, see package sizes at https://repo.agunix.org/ https://repo.agunix.org/. Base system is ~350 MiB on disk and there's still room for improvement. From the agunix home page: >Our first concern is to build a lightweight POSIX environment - a familiar design for users familiar with other Linux distributions is not our goal. It's better to think of this as a new operating system entirely than as a new Linux distro.

peterwwillis 10y ago
It sounds like you're running a hobby Linux distribution. I have nothing against that, but please don't make it seem like somehow it is superior just because it is different. I used to make Linux distributions that could fit on a floppy disk, but I wouldn't brag about how fantastically small it is and how that obviously runs much better. If you are compiling source code by hand, you are circumventing the entire distribution. Do not expect it to work. Just because it may work a lot of the time for you does not mean you should expect it to. If updating a shared library broke something, it's because you didn't know what you were doing. This does not mean shared libraries are bad. In fact, a great feature of shared libraries is the ability to update thousands of applications by simply changing one object file. LD_PRELOAD and many other features are incredibly handy, and don't work with statically compiled apps. Yes, I have run into dependency incompatibility bugs. It happens when expected behavior in library code changes. If an application was not written expecting that behavior, then when it interacts with another application, it may have a conflict. The common places it will crop up are IPC, protocol, and file format changes, but also locking, support for optional functions, infrequently used features, etc. It can also happen from updating software's configuration in a way that is incompatible with some older version of some software that was using it, even though some other software supports the newer functionality. If you were around during the Linux desktop wars this was common. It happens less often with distributed applications since they mostly use APIs now, but some APIs suck balls and don't have versioning, and people will change the functionality of some part of the API that old code was depending on somewhere. Copy an application from 5 years ago into a new system, and copy all the shared libraries into the new system too, and it should run, just like a static binary would run. And it will then immediately die, because all the other dependencies that don't have anything to do with linking weren't there, like kernel feature or modules changes, missing or changed non-library files, protocol changes, missing/incompatible daemons, abandoned deps, security paradigm shifts, etc etc. Honestly, tracking and updating multiple copies of software with different dependencies is not difficult. We were doing that a decade ago at scale (tens of thousands of servers, thousands of individual software packages). People just don't like dealing with reality. So instead of dealing with the fact that they are doing complex things, they pick up their mess and throw it into a spare room. Look, the living room is clean now! Let's hope nobody looks in the other room.

peterwwillis 10y ago

It sounds like you're running a hobby Linux distribution. I have nothing against that, but please don't make it seem like somehow it is superior just because it is different. I used to make Linux distributions that could fit on a floppy disk, but I wouldn't brag about how fantastically small it is and how that obviously runs much better. If you are compiling source code by hand, you are circumventing the entire distribution. Do not expect it to work. Just because it may work a lot of the time for you does not mean you should expect it to. If updating a shared library broke something, it's because you didn't know what you were doing. This does not mean shared libraries are bad. In fact, a great feature of shared libraries is the ability to update thousands of applications by simply changing one object file. LD_PRELOAD and many other features are incredibly handy, and don't work with statically compiled apps. Yes, I have run into dependency incompatibility bugs. It happens when expected behavior in library code changes. If an application was not written expecting that behavior, then when it interacts with another application, it may have a conflict. The common places it will crop up are IPC, protocol, and file format changes, but also locking, support for optional functions, infrequently used features, etc. It can also happen from updating software's configuration in a way that is incompatible with some older version of some software that was using it, even though some other software supports the newer functionality. If you were around during the Linux desktop wars this was common. It happens less often with distributed applications since they mostly use APIs now, but some APIs suck balls and don't have versioning, and people will change the functionality of some part of the API that old code was depending on somewhere. Copy an application from 5 years ago into a new system, and copy all the shared libraries into the new system too, and it should run, just like a static binary would run. And it will then immediately die, because all the other dependencies that don't have anything to do with linking weren't there, like kernel feature or modules changes, missing or changed non-library files, protocol changes, missing/incompatible daemons, abandoned deps, security paradigm shifts, etc etc. Honestly, tracking and updating multiple copies of software with different dependencies is not difficult. We were doing that a decade ago at scale (tens of thousands of servers, thousands of individual software packages). People just don't like dealing with reality. So instead of dealing with the fact that they are doing complex things, they pick up their mess and throw it into a spare room. Look, the living room is clean now! Let's hope nobody looks in the other room.