Re:Building a “real” Linux distro
by peterwwillis on Friday May 05, 2017 @05:58PM
(#14277123)
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.
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.