A standard /etc/os-release would be nice, but I've been doing pretty well with this:

http://ciar.org/ttk/codecloset/self-id

It's hardly universal, but emits pretty good output for many distributions (plus NetBSD).

(just edited it to make JSON support optional. If you want it to emit JSON formatted output, you may require: "sudo cpan" "install JSON".)

He he, yeah I must admit, even though I like the idea, this was the very first thing I thought of as well. ;)

Perhaps, but several distros (Angstrom, ArchLinux, Debian, Fedora, Frugalware, OpenSUSE, Fedora, Mageia and probably several more) have already started using os-release now. If there are competing names, the whole idea is immediately broken.

If he really had called it /etc/bikeshed as he joked and other distros had still taken it up I would have requested it in Slackware nonetheless. The name of the file matters far less than the fact that it is a standard that a number of distros have settled on.

os-release is better because non-Linux *nix operating systems (BSDs etc) can adhere to the same standard.

Most of the fields are optional. Even NAME, ID and PRETTY_NAME will fall back to Linux/linux if unset. Personally I would set the name and version related stings and be done with it. If a truly crazy extension appears and is made mandatory by Lennart and friends I am sure our BDFL would be wise enough to ignore it. It is only a standard if people accept it. I think this iteration of the idea is good enough to accept and help make it a standard. If a future version isn't, then it should be ignored. I know that Pat has no qualms about making such hard decisions. He hasn't been railroaded into systemd or pam adoption yet.

With regards to various comments in this thread about how the standard should have been developed, sure the process could have been better but we have something now that is already fairly widely adopted and pretty workable. Whilst there are things that arguably could have been improved with regards to naming the file and perhaps more time could have been spent considering if extensibility was really a good idea, I do think that os-release is good enough to fix the problem of distro detection, so long as enough distros choose to take it up. "An imperfect plan today is better than a perfect plan tomorrow." (General George Patton). Not my favourite quote but perhaps applicable here. ;)

Actually it wasn't (isn't) straightforward at all to detect the underlying distro as I already demonstrated with various examples. /etc/slackware-version (and similar files on other distros) don't really fix the problem of detecting which distro you are on. Their purpose is to help you know the version of distro, where you already know which distro is running. This type of information is still helpful in its own right. If you have a large number of machines under your control, all running the same distro but with some at different versions the quickest way to find out which ones you might want to consider upgrading is to look at the version file. It can also be handy in scripts (or applications) that need to behave or work differently due to features that are different or not present in different versions of that distro. /etc/os-release however fixes the additional (related) problem, where you don't even know what distro you are running on. There has not been an adequate solution to that problem (IMHO), until now.

Because the NAME of file should reflect the content ! No kernel line for example, for an os-release file I think that's been too fastly thought AND proposed. The guy is changing some specs even after the standard has been already adopted by some ditros (I quote you "but several distros (Angstrom, ArchLinux, Debian, Fedora, Frugalware, OpenSUSE, Fedora, and probably several more) have already started using os-release now. If there are competing names, the whole idea is immediately broken") ...
I'm proud Slack THINKS before adopting an "already adopted standard" that's Work In Progress ...
See the comments on Lennart's blog about quoting for example. He just wants it to work for ITS needs, not everyone else.
I agree with your Patton citation, however and luckily for us, it's not the time for war, but for planning specs. So we CAN use time to think things thoroughly.
So IMHO, whether a os-release file that HAS a STANDARD kernel line (to distinguish Linux and BSD) AND a distro line (to have in it lets say, Slackware or FreeBSD) OR the name must be changed.

By the way, as this file would be also used by *BSD OSes, I ask this again: why not simply modifying uname ?! Didn't get an answer about that :)

You answered this yourself:

I think you meant 'could' but your point is answered. os-release is more generic and hence could be used by the *BSD OSes. If it was called distro-release it would not make sense for them.

Your right but this is os-release, not kernel-release. Also consider the fact that a given os-release might update its kernel due to a security flaw or a user could update the kernel independently of the distro. Hence os-release would not be the right place for kernel information. Otherwise where do you stop, should I also include the the glibc version in this file or the version of X? No, once the user or script querying this files knows the distro/distro version it can use other commands to work out the other information. This also prevents the file from having to be constantly updated with every update of one of the OS components. It only needs update when there is an upgrade of the OS.

P.S. "uname --kernel-release" already tells me the kernel release. So it doesn't need to be added in os-release. uname is and remains the right place to get kernel information. If you want to know about glibc, X or some other component a script could query the package manager. The difference in the case of OS information is that there was no standard place to work this out from within the OS itself, until now.

I think many a FreeBSD user would take offence to the idea that FreeBSD is a "distro". Try calling it a distro on their forums and see how popular that makes you. ;) FreeBSD is a complete OS with a kernel called the FreeBSD kernel. For that matter Slackware is also complete OS, with a kernel called the Linux kernel. The fact that the FreeBSD OS and FreeBSD kernel have the same version number is due to the fact that they are developed in sync with one another, within the same source repository, whereas in the Linux world the kernel and other OS components are developed in isolation of one another.

Granted, in common usage we use the name Linux to refer to more than kernel (i.e. complete OSes) and the term distro is widely used to differentiate these "Linux" versions, but in the very strictest sense Linux really is a kernel. Now I'm not trying to be Stallman here. I'm totally fine with using the name Linux to refer to "distros" and distros to mean OSes (I do it myself all the time, even in this thread) but it is worth appreciating that really if you want to be completely and technically correct about it, there is difference. The fact that we often refer to Linux as the OS may be what lead to your line of thinking that os-release should mention the kernel. If you accept that the distro is really the OS and the kernel is the kernel, then the naming of the file and its contents make a lot more sense.

P.S You might have noticed that many of the popular "distros" have started calling themselves OSes. From the Debian and Ubuntu homepages respectively, "Debian is a free operating system (OS) for your computer." and "Fast, secure and stylishly simple, the Ubuntu operating system is used by 20 million people worldwide every day.". The first time you read statements like these they sound kinda arrogant as OS sounds more important than distro but actually I think they cause less confusion. My preferred way of phrasing things would be the description on the Wikipedia Slackware page. It currently (as I write this) describes Slackware as follows, "Slackware is a free and open source Linux-based operating system". It uses the term operating system but makes it clear it runs on the Linux kernel. I think this is better than the Ubuntu method as it doesn't feel like it steals all the credit. Debian have an excuse because they have a version running the FreeBSD kernel, so they aren't always Linux-based.

What would be handy to me as a QA working for a software developer, is that it is often enough just to know the distro/distro version to spot trends in incoming bug reports, which is why I would love it if all (or at least most) of our incoming bug and crash reports already had this info.

In any case, finding out the versions of the major components (including the "default" kernel) within a specific OS version is fairly easy, even if you don't have the OS installed to run commands against. For example, if I know that a user is using Slackware 12.1 I can look in the slackware-12.1 directory on one of the mirrors to find out the versions of the software that make up that release.

If I notice two different distros account for the majority (or all) of the reports for a given bug I can consider similarities between them. This can still help me narrow down the problem, and may save an additionally distro installation to my growing set of virtual machines.

Here is an example from a while back:

http://my.opera.com/ruario/blog/2011...-sabayon-users

At first I thought this might be a more generic issue affecting a range of distros. Then after a few references to Gentoo in bug reports I thought it might only be Gentoo, which concerned me as I didn't have a VM of Gentoo setup at the time and it is certainly time consuming to setup for a few quick tests. Then I mass mailed the reporters and asked them their distro and noticed a couple Sabayon users and recalled that Sabayon was Gentoo-based. So it was still likely a Gentoo-specific Opera issue but now I was able to use a Sabayon LiveCD/DVD to replicate because the reporters response proved to me that it was close enough. After finding out that the video hardware and driver also mattered following feedback from my blog I was able to get to the bottom of it and come up with a work around for users in the mean time. Having OS information in the the bug reports from the outset would have allowed me to skip the mass mail, which would have been better and faster for everyone.

To raise another point, an oft requested piece of information here on LQ is how to add the distro name to the user agent of the browser to get the funky distro icons on the side of their posts. If there was an easy and reliable way to get this information from the distro, then it would be trivial for Opera (or any other browser) to include a preference (perhaps a checkbox) to automatically add this (Note: I am not a fan of adding it to the UA by default, as many users feel uncomfortable with leaking this level of system information in their browser headers, so a choice is better with the default being to leak as little information as possible).

Yes, there are methods in all of the major browsers to manually customise the UA and include whatever you want (including a distro name) and this is what the current threads here at LQ tell users to do. The problem with these methods however is that often users add the distro name in the wrong place or include characters that should not be in the UA string and hence totally (and unintentionally) break compatibility with certain websites. A pref that just adds the information in the right place and in the right format would therefore be less risky and much easier for the user.

IMHO, distros call themselves OS because they want to reach the mass market. They want us to think that Linux is not an IT toy, but a real way to make things work. Don't tell the John Does that Linux is a kernel, they'll freak out. Or call that a "mass market easy term" to be able to say, Windows is an OS, so is <type distro here>. The purpose is nice, but it's just "marketing". For a free product, and based on a valuable intention, but still. Anyway, that's not the point.

From man uname: "uname - print system information". Isn't the system based on a kernel AND an "OS" ? At least in Linux, because others don't distinguish both (Apple, BSDs, Windows, ...), I mean from the outside.
Again, it's a matter of terminology. We all say that Linux is an OS, because at the end, its Operating your System.
The name of the file may be anecdotic, but it's like an iceberg. And it seems the guy doesn't know that 90% is hidden.
Now you pointed me the *BSD problem out, I agree that my /etc/distro may not be suitable.
But having more and more useless stuff doesn't help. NEVER. A problem is to be taken AT ITS ROOTS.

As a conclusion, the idea seems nice but the implementation weak. Not thought enough. And a weak standard provides headaches for everyone. Why such a rush ?
I don't hate the guy himself (first time I hear from him), I hate his way to put things.
A comment on his blog about a problem == "okay, standart's fixed to reflect your thoughts". Yurk. Just yurk.
And cmon, colors ?! In a system file ?! Is this a (bad) joke ???

Nothing to argue anymore, it seems people are already following someone that thinks "follow me or die". If that's how standards are made, no wonder why there are so many. Hence so much poor implementations.
It seems the word "consensus" has no meaning for this guy. And I feel like it's the most disturbing part. Where all Linux people should unite, he likes to divide us. Definitely NOT a leader, in any way. He could succeed in politics, though. An we all know where politicians lead us.

@zithro: I actually agree with much of what you say, indeed your comments about Lennart and his way of doing things are spot on.

Though I do disagree with this:

os-release is not useless. It solves a genuine problem for which there is no other proper solution at present. And whilst the way in ended up in some of the other distros may be "wrong", that does not change the fact that this is the best chance we currently have of fixing Linux distro detection.

Debian has adopted os-release (and hence it will make its way into Ubuntu and Mint in the future), Fedora has it (which means that RHEL and derivatives will in the future), OpenSUSE, Mageia, and Arch also all have the file now. These (along with Slackware) are the primary sources of development to the overwhelming majority of the other smaller distros out there. If Slackware adopts the file as well then I predict that within a few years it will be ubiquitous and hence we will finally have a solution to the problem of distro detection (at least for modern distros).

Sure, perhaps an alternative, "better" standard could be developed but what good would it do now? It will just be a competitor to os-release with very little hope of challenging it when the other major distributions have already selected os-release. How would you sell an improved file format to the other distros? There isn't enough leeway to make a standard that is dazzlingly better. So rather than helping, a rival standard would simply mean that the problem remained unfixed, and what good would this do anyone?

Rather than spend too much time worrying about Lennart, his methods of pushing for things or if there is some theoretical better standard with no hope of acceptance, I think we should be pragmatic and accept the solution that is available.

What are the actual downsides of Slackware including this one extra text file, especially when compared with the advantages?

ruario, since You maintaining Opera next packages for Slackware You are free to generate packages which will create os-release file(or don't touch it if it exists) and fill it with proper information(in doinst.sh). (As far as I understood most bug-rich releases is -next snapshots so it is more important to support feature You requested in snapshot builds than in releases). Also You can try to convince Opera Slackbuild maintainer at SBo to do the same. It will not break anything in Slackware(because nothing relays on it) but will help Opera. And if/when mr.Volkerding will decide to introduce os-release all you have to do is rollback doinst.sh.
By the way, You(or specified maintainer) can do that for other packages types(deb, rpms) - teach post-install step to (re)generate os-release file(or some other file from where Opera browser can gather information - Opera will become more independent from 3rd-party decisions).

This file seems harmless enough, although it does make me think of this:

http://en.wikipedia.org/wiki/You_ain%27t_gonna_need_it

I guess the question that comes to my mind, is: If you didn't know enough about a given distribution to detect that you were running on it through the distro-specific file, how are you possibly going to know enough about it to be able to have your software tailor itself for that distribution?

Firstly, thanks for the reply, I very much appreciate the chance to make my case to the decision maker directly! :)

I am a QA at Opera Software. In my specific case it is not so much about tailoring Opera to Slackware or indeed some lesser known distro I may never have heard of in advance (although as it happens Opera already runs pretty well on most distros I have come across). How it would help me personally, is that it would allow Opera to include the distro name and version in our bug and crash reports. This would make it easier for me to notice trends or problems on specific distros. I could then more easily find what the issue is by testing against the distro(s) where users are reporting problems and have a better chance of improving how Opera performs on those distros.

So I am better able to tailor Opera for a given distro after I am made aware of a problem because I am more easily able to find out where the issue lies.

P.S. I do give further examples of the advantages and fleshed these ideas out further in this thread, though I appreciate you are a busy guy and hence might not have to the time to filter through all the mountain of text I have written. :) Here are some quick quotes: