On the one hand the idea is good. In libguestfs we go to huge lengths to deal with the release files of many different Linux and BSD distributions[1].<p>On the other hand, when was this discussed? Are <i>all</i> the Linux distros and BSD on board? OS X? Windows? (I'm serious)<p>/etc/os-release has all the problems of /etc/lsb-release, but even fewer people will use it (if you count distro numbers rather than users, hardly anyone is using lsb-release).<p>This file <i>could</i> have been a lot more useful <i>if</i> it had been discussed with people who might consume it. As it is, we'll be parsing this as a fallback, but continue using distro-specific release files.<p>[1] <a href="https://github.com/libguestfs/libguestfs/blob/84a4160fd30c46575b93f87f6ffc7cc556b0af93/src/inspect_fs_unix.c#L51" rel="nofollow">https://github.com/libguestfs/libguestfs/blob/84a4160fd30c46...</a>
Author complains 'lsb_release -d', the standard from ten years ago, isn't always there.<p>Proposes alternative to fix this, by changing to a new system , which will solve this problem, once it's always there.
While I see no problem with having a centralized file to get OS information from, I do have two issues with the file that's proposed here:<p>One is that I believe it shouldn't be in /etc which is generally used for configuration data, not for static distribution info. I'd put it somewhere in /usr/lib or /usr/share.<p>Second, I think that the linked documentation (<a href="http://www.freedesktop.org/software/systemd/man/os-release.html" rel="nofollow">http://www.freedesktop.org/software/systemd/man/os-release.h...</a>) is incomplete in that it doesn't specify quoting behavior: The file doesn't say anything about when or if at all values need to be quoted but the has quotes on some string values (but not all) in the example.<p>Are the quotes part of the value and thus should be displayed? Or are quotes needed for values with spaces in them?<p>Yes. I'm nit-picking, but IF you have to start off a new standard, please be sufficiently precise in order to reduce the need for somebody else having to do the same a few years down the road.<p>Other possible questions: Do custom keys need to be uppercase? Can they contain spaces themselves? ANSI_COLOR is a nice idea, can we also have a background color? Are spaces allowed in front and after the = sign? Are spaces in front and after the = sign part of the key or value? Or are they to be ignored?<p>Maybe use a standard format like YAML or JSON or (god forbid) XML which already has things like this covered.<p>Yes. This is all really small stuff, but in the end it's this unspecified small stuff that causes everybody to implement their solution differently which in turn makes writing a parser needlessly hard (or even impossible if there are conflicting interpretations)
<i>recently the majority of the big distributions adopted /etc/os-release and many small ones did, too[2]</i><p><i>[2] To our knowledge at least OpenSUSE, Fedora, ArchLinux, Angstrom, Frugalware have adopted this.</i><p>So "OpenSUSE, Fedora, ArchLinux, Angstrom, Frugalware" is "the majority of the big distributions" now?
He complains about the lsb_release executable, but why not use the /etc/lsb-release file directly?<p><a href="http://linux.die.net/man/1/lsb_release" rel="nofollow">http://linux.die.net/man/1/lsb_release</a>
I loved this, from the FAQ:<p><i>Why didn't you call this file /etc/bikeshed instead?</i><p>Nothing like good self-referential, recursive, meta humor. :)
Relying on some hint system (whatever it might be) to infer how the system is configured is a bad practice; it could lead to faulty assumptions because the administrator is free to change anything post hoc.<p>Scripts that care where things are should do their own investigation and determine the locations of files and how daemons are configured themselves. In other words, use the primary sources.
What I want to see (Or make) is a system that's extensible enough to be made compatible with current package managers simply through extension modules. (Something like VLC levels of customization.) But that has a native package format so that most software providers can expect to find this skeleton-package-manager on the system.<p>Though I'm not even sure if thats really possible.
Those who cannot learn from history are doomed to repeat it.<p>I've never understood why most major Linux distribution creators chose to come up with their own /etc/*-release files. Why make it distribution-specific at all?<p>In all seriousness, what's wrong with the /etc/release file (Solaris) that predates Linux?
The name is obvious, terse, and easy to remember.
It's interesting that someone supposedly from Red Hat decided to drop support for anything without this. I just checked on a CentOS 6 box (closest thing I have) and it doesn't have /etc/os-release