I think he made a point saying that lsb_release needs to spawn a process to get the result, while /etc/os-release it's just opening a simple text file and parsing it.
That lsb_release is "an optional package in many distributions" is only a minor complain:
> There's already the lsb_release tool for this, why don't you just use that? Well, it's a very strange interface: a shell script you have to invoke (and hence spawn asynchronously from your C code), and it's not written to be extensible. It's an optional package in many distributions, and nothing we'd be happy to invoke as part of early boot in order to show a welcome message. (In times with sub-second userspace boot times we really don't want to invoke a huge shell script for a triviality like showing the welcome message). The lsb_release tool to us appears to be an attempt of abstracting distribution checks, where standardization of distribution checks is needed. It's simply a badly designed interface. In our opinion, it has its use as an interface to determine the LSB version itself, but not for checking the distribution or version.
And I guess distributions are far more reluctant to install a shell script than adding a file to /etc
If only Linux packaging system had some kind of dependency system. That way systemd and other LSB needing packages could require lsb. You could even have some kind of automated packaging tool, or perhaps modify yellowdog updater, to fetch those dependencies automatically.
Attempting to install redhat-lsb on CentOS 6 drags in:
alsa
cups
ghostscript
gstreamer
pixman
qt
fonts
poppler
and more (102 packages in total!)
Now, this is on a server, so I have no use for audio, printing, streaming, pdf creation, nor any sort of GUI components. Do you really think it's reasonable that all that needs to be installed just to tell me what version of the operating system is running?
Nice summary. And when people ask me why Linux is the way it is, I point at an example like this one and say 'This is why.'
It would be 'hard' to make lsb_release do what they want (either the maintainers reject their pull requests, or perhaps outright reject their ideas) and its 'easy' to create a new way to do it.
Hence every copy of Linux has some percentage of the 'boring' stuff which works the same everywhere, and the 'interesting' stuff works differently between major distros,
Things are 'boring' if nobody cares about them.
Things are 'interesting' if they are user facing, and especially self contained enough that the entire feature can be shipped in one moderate sized patch.
Comments
Author complains 'lsb_release -d', the standard from ten years ago, isn't always there.
Proposes alternative to fix this, by changing to a new system , which will solve this problem, once it's always there.
I think he made a point saying that lsb_release needs to spawn a process to get the result, while /etc/os-release it's just opening a simple text file and parsing it.
That lsb_release is "an optional package in many distributions" is only a minor complain:
> There's already the lsb_release tool for this, why don't you just use that? Well, it's a very strange interface: a shell script you have to invoke (and hence spawn asynchronously from your C code), and it's not written to be extensible. It's an optional package in many distributions, and nothing we'd be happy to invoke as part of early boot in order to show a welcome message. (In times with sub-second userspace boot times we really don't want to invoke a huge shell script for a triviality like showing the welcome message). The lsb_release tool to us appears to be an attempt of abstracting distribution checks, where standardization of distribution checks is needed. It's simply a badly designed interface. In our opinion, it has its use as an interface to determine the LSB version itself, but not for checking the distribution or version.
And I guess distributions are far more reluctant to install a shell script than adding a file to /etc
> It's an optional package in many distributions
If only Linux packaging system had some kind of dependency system. That way systemd and other LSB needing packages could require lsb. You could even have some kind of automated packaging tool, or perhaps modify yellowdog updater, to fetch those dependencies automatically.
Attempting to install redhat-lsb on CentOS 6 drags in:
Now, this is on a server, so I have no use for audio, printing, streaming, pdf creation, nor any sort of GUI components. Do you really think it's reasonable that all that needs to be installed just to tell me what version of the operating system is running?> Do you really think it's reasonable that all that needs to be installed just to tell me what version of the operating system is running?
(assuming redhat-lsb is the package that owns $(which lsb_release) )
No. Red Hat should fix that.
Nice summary. And when people ask me why Linux is the way it is, I point at an example like this one and say 'This is why.'
It would be 'hard' to make lsb_release do what they want (either the maintainers reject their pull requests, or perhaps outright reject their ideas) and its 'easy' to create a new way to do it.
Hence every copy of Linux has some percentage of the 'boring' stuff which works the same everywhere, and the 'interesting' stuff works differently between major distros,
Things are 'boring' if nobody cares about them.
Things are 'interesting' if they are user facing, and especially self contained enough that the entire feature can be shipped in one moderate sized patch.
"Proposes alternative to fix this, by changing to a new system , which will solve this problem, once it's always there"
Aye, and if you don't implement it you are "working towards the further balkanization of the Linux landscape".
Is this arrogance? Dictatorship? Am I being too sensitive? Whatever it is, it does not strike me as an effective way to get people on board.
Tell us why it is better, not that we are wrong if we don't do it.