
Debian Dropping the Linux Standard Base - vezzy-fnord
https://lwn.net/Articles/658809/
======
pippy
I've always liked the concept behind GoboLinux[1], it makes so much more sense
in comparison to the legacy mainframe style file structure other linux distros
use. Debian dropping LSB might pave the way for more distros adopting a more
modern and sensible file structure.

1
[http://www.gobolinux.org/?page=at_a_glance](http://www.gobolinux.org/?page=at_a_glance)

~~~
JdeBP
This is nothing new, of course. NeXTStep introduced things like ~/Apps,
/LocalLibrary, and /LocalApps back in the early 1990s.

Daniel J. Bernstein, around the turn of the century, proposed a /package
hierarchy (for package management without the need for conflict resolution)
and a /command directory.
([http://cr.yp.to/slashpackage.html](http://cr.yp.to/slashpackage.html)) Their
major problem was the idea that one had to register things with what was to
most of the world just some bloke on another continent. But they had concepts
like a hierarchical package naming scheme ("admin/", "mail/", &c.), self-
contained build trees with versioned names, and an "index" directory full of
symbolic links.

~~~
smegger001
I do not seem to understand, so forgive my ignorance if you will but; Why do
we need a /Apps directory isn't that what /bin /sbin and /usr/bin are for? And
as for /LocalApps is that not what /home/$user/bin is for? this seems fairly
redundant, or needless wheel reinventing?

~~~
wtallis
On NeXTSTEP and OS X, the /Apps (/Applications) directory is for self-
contained application bundles that hold a GUI application and all of its
dependencies that aren't part of the base OS, and they can be installed and
removed by dragging and dropping that one bundle (which is a directory, but
appears in the graphical file manager as a single object). There was also a
distinction between locally-installed stuff and network resources which made
things a little more complex but more manageable if you were actually working
in an office full of NeXT boxes. OS X still has /usr and it still has pretty
much the same meaning, but GUI apps live in a separate and more user-friendly
domain.

~~~
pjmlp
Known on Windows world as xcopy install, due to the similar way MS-DOS
software used to be bundled and everyone used xcopy instead of the pretty
basic copy that didn't do recursive copies.

But sadly it doesn't present the nice object concept NeXTSTEP and OS X have.

------
SwellJoe
We package our software for CentOS, Debian, Ubuntu, and have occasionally
supported a few others. We never even considered targeting the LSB. It is so
much simpler to target the defaults on the system, build for the top three or
four or five distros (which actually ends up working on several spin off
systems, by virtue of similarity), and when problems arise we know we're not
the only ones running into it because we are using the same libs as the rest
of the system.

The idea of one package for all distros is cute but not at all realistic. And
it isn't pleasant for the end user, who wants everything in their native
package manager and things to be configured in the same ways as everything
else.

LSB was a well-meaning idea, but it doesn't actually do anything to improve
openness or interoperability.

~~~
Qantourisc
Well 1 thing of LSB does help in 1 case: init.d return codes, very important
with some HA tools.

~~~
SwellJoe
We support and manage all of the major init systems (initscripts, systemd,
Upstart, BSD, etc.) so we don't care about that (or we do, but the software
already has configuration and code for all of the possibilities).

------
simula67
About a year back I was tasked with porting an installer for a proprietary
product to work on Linux. I wanted to show the log files to the user in the
graphical installer and I ended up using xdg-open, which as it turns out opens
text files in Firefox, even though light weight editors are present on the
system.

I also found that some scripts had the hashbang line as /bin/env which works
on RHEL, but not on SuSE.

I have also been trying to write some scripts that work across multiple
distros. Detecting distros is wierd. "lsb-release" is not present in most
distros. "/etc/issue.net" is present in some, but not on ArchLinux.

No wonder ISVs find it hard to support Linux. I suspect the technical side of
this problem is probably trivial, the leadership side, not so much.

~~~
nailer
/bin/env was always a bad idea. Way before Linux was even a thing, every Unix
used /usr/bin/env - and that was the point of it being used to find an
interpreter. Red Hat (where I worked at the time, man years ago) realised the
mistake, but alas didn't want to break compatibility.

'lsb-release' was always hilarious: the one thing about Linux that is almost
standard is that the LSB tools are never present.

~~~
JupiterMoon
Why is this a bad idea?

~~~
rleigh
Because the whole point is portability, so hardcoding /bin/env when the rest
of the world is using /usr/bin/env makes it nonportable!

~~~
JupiterMoon
I'm still confused should I use: #!/usr/bin/env python #!/usr/bin/python

And why?

~~~
takeda
You should use:

    
    
        #!/usr/bin/env python
    

or preferably

    
    
        #!/usr/bin/env python2
    

or

    
    
        #!/usr/bin/env python3
    

env supposed to always be in /usr/bin, while python doesn't. On FreeBSD for
example it is in /usr/local/bin because it is not integral part of the OS.

------
bbanyc
The impression I get is that the main point of LSB was to combat FUD from
commercial Unix vendors about Linux being fragmented and nonstandardized and
lacking binary compatibility. Once Linux supplanted Solaris in the corporate
world this all became unnecessary. Is this right?

~~~
pquerna
As someone shipping proprietary applications on Linux, the lack of binary
compat is still not fun at all. In a previous gig, we ended up with 20 odd
build slaves ({x86, x86_64} * Common RHEL, Ubuntu, Debian), and making
binaries for each, rather than trying to make LSB based binaries.

~~~
FooBarWidget
Maybe this will help you: [http://phusion.github.io/holy-build-
box/](http://phusion.github.io/holy-build-box/)

~~~
McP
I was very excited until I saw: "Supporting graphical applications such as
those based on GTK, Qt, SDL, OpenGL etc is outside the scope of this project."

~~~
benwaffle
xdg-app by GNOME solves this problem

[https://wiki.gnome.org/Projects/SandboxedApps](https://wiki.gnome.org/Projects/SandboxedApps)

It's already in a working state - you can try running GIMP nightlies

------
krschultz
It's not worth conforming to a standard that no one uses, it's just extra
overhead.

One of the many reasons that the best standards are reflective of what most
people do than prescriptive of what they should do.

------
pjmlp
Has any distribution ever complied to it?

I remember back in the day, LSB was announced as a means to avoid the return
of UNIX wars in GNU/Linux.

Here we are with each distribution having its own way how to do things, so now
we do have GNU/Linux wars, with a few selected distributions just like the old
commercial UNIXes, because no one can bare to support X thousand variants.

~~~
the_why_of_y
Here's a list:

[https://www.linuxbase.org/lsb-
cert/productdir.php?by_lsb](https://www.linuxbase.org/lsb-
cert/productdir.php?by_lsb)

As you can see it has the big name distributions on it, except for Debian and
Gentoo, plus many obscure ones.

However, the list of LSB certified _applications_ is rather remarkably short,
which suggests that the real problem is that ISVs are much less interested in
LSB than one would expect.

------
shadytrees
_In a follow-up message, he noted that changing the LSB to be, essentially,
"whatever Debian as well as all other actors in the FLOSS world are _actually
_doing" might make the standard—and the effort to support it in Debian—more
valuable._

I think this strategy worked remarkably well for HTML5. Standards is a two-way
conversation with the community.

------
dnlrn
The problem with LSB is that no application used it, because not every distro
supports it. I hope that xdg-app application containerization[1] will change
that and make it finally possible to write an application that targets all
distributions. Well, all distributions that implement xdg-app ;).

[1]:
[https://wiki.gnome.org/Projects/SandboxedApps](https://wiki.gnome.org/Projects/SandboxedApps)

~~~
bkor
Suggest to just ask various distributions nicely if they could package xdg-
app. Especially the ones that you target and/or use frequently. I quite like
the idea behind xdg-app and I've packaged xdg-app for Mageia Cauldron (think
Fedora rawhide). As I did that only yesterday I don't know if it works. But
next stable release of Mageia will have it.

[http://pkgs.org/search/xdg-app](http://pkgs.org/search/xdg-app)

Apparently only available on Fedora, openSUSE and Mageia at the moment.

------
jbb555
Seems to me that linux is self destructing, causes by people who think new is
better than working.

First systemd pretty much ruined linux, I know so many people who lost
interest in promoting or using linux what that was forced on us.

Now they seem to want to change this.

Yeah.... I'll just go back to windows.

~~~
listic
I suspect Windows/Microsoft is capable of self-destruction, too. Remember
Windows Mobile? It used to be the dominant OS on smartphones before the iPhone
and Android came along.

~~~
janvidar
Really?

I don't remember Windows Mobile having any relevance.

Symbian was pretty much alone at the throne for years before iOS and Android.

------
uxcn
Speaking of standards, has anything happened with POSIX since '08?

~~~
caf
The current edition of POSIX is from 2013:
[http://pubs.opengroup.org/onlinepubs/9699919799/](http://pubs.opengroup.org/onlinepubs/9699919799/)

~~~
uxcn
I guess what I was really wondering was why so little has changed with respect
to multiprocessing, modern filesystems, resource quotas, virtualization,
etc... since '08.

~~~
caf
I think it would be hard to give an answer without a more specific question,
this just seems like a kind of nonspecific gripe.

~~~
uxcn
I personally have a number of specific _gripes_ , but more importantly it
seems odd the committee hasn't added anything to the standard since '08
(especially since good portable software generally needs more functionality
now).

As an easy example, multiprocessing has become more important between now and
then. Why are things like processor affinities still not defined?

~~~
caf
There has been recent movement in multiprocessing - for example robust and
errorchecking mutexes are now in the base spec.

In the case of processor affinity, it looks to me like no-one has ever
suggested it. Participating in the Austin Group is pretty open - why don't you
put a proposal forward? (Maybe affinity can be added to struct sched_param
somehow?)

~~~
drewcrawford
> Participating in the Austin Group is pretty open

Not really. I know someone who's spent ages trying to get O_CREATE added as an
alias for O_CREAT.

[http://spiegelmock.com/2015/01/23/fixing-a-typo-the-hard-
way...](http://spiegelmock.com/2015/01/23/fixing-a-typo-the-hard-way-unix-
standards-style/)

~~~
uxcn
This was a bit disheartening to read. I didn't see a any problem proper
versioning couldn't address. Breaking backward compatibility shouldn't be an
issue as long as you generally don't break forward compatibility. I was under
the impression this was what the _POSIX_C_SOURCE_ macro was meant for.

------
debacle
I worry this will make things more complicated than necessary in the future.
The LSB is one of those things that you don't really miss until it's gone.

------
lifeisstillgood
Is this a solvable problem via package tools? Can (and maybe my ignorance
isshowing) can say apt-get not interrogate a .deb file and ask "which files re
your config?". Ok for this distro, they go under /GOBO/yourapp/config or
/usr/etc in that distro.

A final single constants file could be handed back to the app Saying
"CONFIGDIR=/foo/bar/bad"

~~~
Karunamon
Apt considers everything under /etc as a "config file", or any file mentioned
in the special CONFFILES package file.

~~~
lifeisstillgood
So it could write the files to any location. But how to tell the application
it should now look in a different place ? That's probably impossible to get
every developer to do.

Symlink everything?

------
gaius
With systemd too it's clear that Linux sees its future as something distinct
from POSIX.

------
rhabarba
Oh, so the replacement for POSIX because POSIX is too established needs a
replacement now?

Funny Linux guys.

------
alrs
So long as this isn't to make way for Redhat's vision of systemd as the base
system, I shrug.

~~~
rmdoss
I am still to find a sys admin that likes systemd.

On the other hand, developers seem to enjoy it quite a bit.

That's what happens when you have developers developing for themselves, not
for sys admins (the end users of their work).

~~~
rconti
As a sysadmin, I find that every time I rail against systemd here, I get
constantly challenged by developers who know far more about, well developing,
than I do.

Is it so hard to avoid change for change's sake? I'm not opposed to learning
new things, but we're all _really busy_ , and when the standard way of
accomplishing things changes in every major release (which you're usually
trying to deploy to stay on top of the latest developer demand, or audit
requirements or whatever) just adds a massive learning curve. Now I've got to
learn something new, rewrite a bunch of tools, all because.. why?

~~~
geofft
There will always be busy sysadmins; there will also always be new sysadmins.
If we agree that systemd is a good thing, the best thing to do is to switch
over quickly and bite the bullet on the re-learning problem. I understand why
it happened that way and there were excellent technical reasons for it, but
Debian's and Ubuntu's slow transitions (through insserv and Upstart + logind,
respectively) were probably a disservice in the end, if you somehow magically
knew that systemd would be the end state for both distros.

I don't expect it to change again in the next 10-15 years, except potentially
to a competitor that is designed very similarly but just plain better.

I _would_ like to see more empathy for the fact that systemd is a complex,
underdocumented system. Lennart's blog series is great for the "why," but very
sparse on "how" and especially "how do I fix it".

------
hlmencken
[https://www.debian.org/releases/](https://www.debian.org/releases/)

