LWN: Comments on "Debian dropping the Linux Standard Base"

Debian dropping the Linux Standard Base

dbp — Wed, 28 Oct 2015 09:54:24 +0000

As from what commercial products (at the range of USD 10K - USD 100K) my company used, there is nowhere to mention "LSB" at all.

Most of the products require specific distro and major version, some relax to more distros and versions. The point is once the vendor claim which platform is supported, they need to support until EOL.

Claiming to support "LSB" is just too uncertain and risky to the vendor, as stated by jbailey.

Debian dropping the Linux Standard Base

Wol — Sun, 11 Oct 2015 10:28:23 +0000

Yep. I was heavily involved in the LSB as a private individual way back when. And I felt it was addressing the wrong target.

As a keen WordPerfect user, I wanted some way of specifying "these are the requirements to run commercial program X", and the LSB just seemed to me to be completely missing the point.

If we want to install commercial programs on linux, it would make life so much easier if the LSB just defined a bunch of pseudo-packages the distribution installers all understood, that would make sure the pre-requisites are installed on the system so the commercial installer "just runs". And it looked reasonably easy to me back then - except I just got the feel that the LSB was intent on going in a different direction :-(

Cheers,
Wol

Debian dropping the Linux Standard Base

jbailey — Sat, 10 Oct 2015 15:30:13 +0000

I was on the LSB committee when I worked at Canonical (mid 2000's). I tried to argue at the time (to both Ian Murdock and Jim Zemlin) that the LSB was completely unrealized value. The challenge is that if a vendor produces an LSB-using binary, they *still* have to test across each distribution on which they intend to be used and face a support burden if a customer installs it on a random other distro that happens to be LSB-certified.

Instead, I proposed using the Technical Support Alliance (https://www.tsanet.org/) to build a partnership for ISVs to work with distros. The idea being that if someone has a support contract with OEM, OS vendor and ISV, the support ticket can be placed to whomever, and the vendors have means to talk to one another and actually resolve problems on behalf of the customer. This provides appropriate incentives to everyone in support of their mutual customer and encourages recurring revenue through support contracts to involved vendors.

I saw this as the best way for Ubuntu to be taken seriously on servers. Most of the ISVs we wanted were already part of TSANet, so I felt pretty confident in our ability to bring them on over a few years, starting with smaller ones. Unfortunately, between Murdock doing his Champagne Supernova and me leaving Canonical, the idea never went any further.

Debian dropping the Linux Standard Base

dlang — Fri, 09 Oct 2015 16:19:12 +0000

> We had this tool at the time (which was made by researchers at a major computer science academy) which could analyze the ABI interfaces available in a given distro (the tool was intended to be used as a way to easily determine LSB compliance). That tool could have easily been used to determine ABI commonality among major distros, which could have then been used to defined the LSB in a very relevant and real way. Re-running this tool every 6 months or so, and generating the LSB based upon what the distros were actually doing, would have kept the LSB current.

such a tool (and a report like you are describing) would do wonders to deal with the "linux is fragmented, every distro requires it's own build" meme. It would either confirm that this is the case (and point at what distros or upstream projects are the cause of breakage), or provide very solid information to combat the meme.

Debian dropping the Linux Standard Base

orclev — Fri, 09 Oct 2015 15:43:49 +0000

Technically you're correct on 1, but from a practical standpoint OpenJDK is making significant inroads. Most of the new Java development is heading to OpenJDK, for recent JDK releases people seem to favor OpenJDK over Oracle JDK, and a lot of distros are distributing OpenJDK as the de facto standard. Based on that I'd argue the fight is still ongoing in the case of Java, but the open version is definitely looking good to score the win.

The fact that the standards process still involves Oracle in any significant fashion I think is largely a red herring, if OpenJDK decided to deviate from Oracle I suspect most developers would go with it and abandon Oracle JDK. The only really troubling part there is the recent court case between Google and Oracle over the copyright-abiltity of the Java API, which might prove troublesome for OpenJDK should they decide to part ways with Oracle entirely.

Debian dropping the Linux Standard Base

criswell — Fri, 09 Oct 2015 13:17:04 +0000

So I'm a bit biased about this. I used to be employed by the LF to work on the LSB (circa 2008). I worked for two long years striving to make the LSB relevant.

The problems the Debian developers point out are nothing new. The LSB has had these problems for years.

The crux of the problem is that the LSB is a trailing standard and that it has (or had, I honestly can't say for certain if this is still the case) a heavy corporate interest. This creates a situation where the LSB is always REACTING to the changing Linux distro universe, which means it can never, really, be relevant as it is always just a bit out of date. In turn, this creates problems for distros wanting to be LSB compliant as they, essentially, have to have these backwards shims in place to keep the LSB checkers happy.

The LSB's modus operandi is to debate and reach consensus on each and every change. On paper, this sounds good. However, in practice it's absolutely miserable. It means that discussions drag on forever and things are added, updated, or removed long after they've ceased to be relevant in mainstream distros. Additionally, you have corporations (or had, again, it could be different) which would lobby for particular technologies and often get them included in the LSB not based upon technical merit but instead upon how much noise the company was able to generate with the LSB and the Linux Foundation. Personally, I butted against this problem back in my day at the LSB as a major change I thought was absolutely stupid (allowing non-root users to modify package management DBs like the RPM DB- a feature MANY companies trying to make packages for Linux wanted at the time) kept being brought up again and again largely because the companies in question were also Linux Foundation contributors. (This change never made it in, of course, as doing so would have made every distro in the world reject it, but it didn't change the fact that the stupid suggestion kept getting proposed and shot down on a nearly monthly basis and that there was pressure from management in the LF to keep these companies happy since they were giving so much money.)

The only solution to these problems is to ditch the "LSB by committee" approach and, instead, have the LSB be semi auto-magickally generated based upon what REAL distros are doing. We had this tool at the time (which was made by researchers at a major computer science academy) which could analyze the ABI interfaces available in a given distro (the tool was intended to be used as a way to easily determine LSB compliance). That tool could have easily been used to determine ABI commonality among major distros, which could have then been used to defined the LSB in a very relevant and real way. Re-running this tool every 6 months or so, and generating the LSB based upon what the distros were actually doing, would have kept the LSB current. This was something I advocated for at the time, but was ultimately rejected (again, largely because of the corporate interests involved that had very specific agendas for the LSB).

Anyway, while it makes me sad to see the LSB fall further into obscurity (it really was a good idea and had noble goals) this doesn't exactly surprise me
because it was something easily predictable as far back as 2008.

Debian dropping the Linux Standard Base

linuxrocks123 — Fri, 09 Oct 2015 03:29:27 +0000

Well, Oracle probably pays him, so "moving away from Oracle's sphere of influence" probably isn't really an option.

Short list of Oracle's Sun acquisitions and what's happened since:
1. Java: Main distribution still under Oracle's control
2. Solaris: un-open-sourced by Oracle; IllumOS fork "won" by virtue of being only remaining option
3. MySQL: developer revolt; MariaDB fork won
4. OpenOffice: developer revolt; LibreOffice fork won
5. Hudson: developer revolt; Jenkins fork won
6. VirtualBox: Oracle still in control

So, of those six OSS projects, Oracle has managed to alienate the communities of three and unsuccessfully attempted to outright kill one. Good job, Oracle.

Oracle OSS is dying. Java and VirtualBox are all that remains. Red ink flows like a river of blood ;)

But, Java and VirtualBox are probably still around because Oracle pays most of the developers. So, if we want those projects to be better governed, someone will need to step forward to hire those guys away or hire new guys to replace them. Java is likely recognized as "too big to fail" by Oracle, so their funding is why they're in control, and VirtualBox is probably just basically on ice and no one has cared enough to fork it yet. Both of those situations could change in time -- but, without some catalyst, probably won't change any time soon.

How to find out the system's codename without lsb_release?

rschroev — Thu, 08 Oct 2015 18:59:46 +0000

I'm ashamed to say that yes, indeed, I managed to miss that. On multiple occasions no less.

How to find out the system's codename without lsb_release?

pabs — Thu, 08 Oct 2015 14:59:46 +0000

I guess you missed the Debian releases page?

https://www.debian.org/releases/

Debian dropping the Linux Standard Base

pabs — Thu, 08 Oct 2015 14:58:15 +0000

You could either push Oracle to fix their security policies or move away from their sphere of influence.

Debian dropping the Linux Standard Base

ewan — Fri, 02 Oct 2015 09:34:28 +0000

The suggestion that Oracle would be interested in working well with anyone was clearly a joke.

Debian dropping the Linux Standard Base

mjthayer — Thu, 01 Oct 2015 10:14:01 +0000

This is probably not what you want to hear, but we are as open with security issues as Oracle's security policy allows. Since Oracle develops VirtualBox I'm afraid their policy applies to its development.

How to find out the system's codename without lsb_release?

rschroev — Thu, 01 Oct 2015 09:48:22 +0000

Oops, I missed that. Sorry!

How to find out the system's codename without lsb_release?

noirbee — Thu, 01 Oct 2015 09:25:33 +0000

They *won't* drop lsb-release, precisely because it's needed to at least identify the distro type and version, typically for automated deploy or inventory tools (it's common to use it in ansible to find out whether to use apt or yum for installing packages for example):

« Raboud proposed that Debian drop everything except for the lsb-base […] and the lsb-release package »

In addition to /etc/os-release, /etc/debian_version also contains some codename information, but I'd advise against using anythin

How to find out the system's codename without lsb_release?

zwenna — Thu, 01 Oct 2015 09:22:20 +0000

> Does anyone know how I can find out the Debian codename of a system? Currently I can use the lsb_release command to find out that information, but that won't work anymore if the package is dropped.

The lsb-release package containing the lsb_release command is going to stay, as mentioned in the article.

How to find out the system's codename without lsb_release?

rschroev — Thu, 01 Oct 2015 09:17:20 +0000

Ah yes, thanks!

How to find out the system's codename without lsb_release?

cortana — Thu, 01 Oct 2015 09:01:42 +0000

It's in /etc/os-release.

How to find out the system's codename without lsb_release?

rschroev — Thu, 01 Oct 2015 08:52:52 +0000

Does anyone know how I can find out the Debian codename of a system? Currently I can use the lsb_release command to find out that information, but that won't work anymore if the package is dropped.

It's easy enough to find the release number, but I'm always having trouble finding the mapping between release numbers and codenames. I haven't found an overview on Debian's website; I need to resort to Wikipedia or the source of the lsb-release package.

Debian dropping the Linux Standard Base

pabs — Thu, 01 Oct 2015 08:45:24 +0000

That sounds similar to what distributions do with the code they package. If you're interested in working better with distributions, being more open about VirtualBox security issues would be a great start, more tips here:

https://wiki.debian.org/UpstreamGuide

Debian dropping the Linux Standard Base

mjthayer — Thu, 01 Oct 2015 08:12:33 +0000

VirtualBox provides a package which aims to run on random Linux distributions. We do not pay attention to the LSB, instead we try to work with what distributions actually do. More specifically, we are moving to looking at the tools present on a system (e.g. systemd, insserv for system services) rather than the actual distribution and working with those, fixing things when that breaks in some particular configuration which we think is worth supporting.