20 ms·

Debian Dropping the Linux Standard Base

285 points by vezzy-fnord 11y ago

hlmencken 11y ago
https://www.debian.org/releases/ https://www.debian.org/releases/
alrs 11y ago
So long as this isn't to make way for Redhat's vision of systemd as the base system, I shrug.
- vezzy-fnord 11y ago
  LSB is actually somewhat to blame for prolonging sysvinit's lifespan, in its specification of standard initscript functions (which ultimately were seldom used and laughable compared to /etc/rc.subr in BSD-land) and the awkward dependency headers that required a preprocessor like insserv(8) to scan them. systemd as base system will certainly happen, regardless.
  - duncan_bayne 11y ago
    :(
  - AdmiralACK 11y ago
    I, and many others, prefer sysvinit over systemd, which I consider overly bloaty and not in-line with the unix philosophy of 'do one thing and do it well'. It's far too involved in the overall systems where, now, some desktop environments require it? That's absolute crap.
    - cakes 11y ago
      Though I'm not going to say I really care for sysvinit - I prefer it to systemd as well. Every interaction I've had with systemd just ends up confusing me until I either successfully get it work _somehow_ outside of logic I can actually comprehend or giving up entirely. A lot of people I know have had similar experiences.
      - stephen_g 11y ago
        Interesting perspective. My experience has been the complete opposite - writing unit scripts used to be a real pain, but systemd unit files take two minutes and just work every time. My machines start much faster with systemd too, which is a nice side effect.
      - deckard1 11y ago
        I used to be on the fence. I knew I hated journald with a passion. But for systemd, the last straw was trying to mount a USB drive one day. I would do "mount", and nothing was mounted. I looked through the logs and noticed it was being unmounted on mount. What the fuck, right? Turns out, a prior unmount of a USB stick killed some service that systemd runs. So systemd thinks the service is dead, which means it should not be mounted, which means it keeps umounting the damn thing. Totally braindead. That's also when I learned systemd was running an entire virtual fstab layer. Because, you know, /etc/fstab just isn't good enough anymore.
        sandGorgon 11y ago
        This is actually a good thing. You might have found it bothersome, but what it was doing was intelligently trying to reason whether a device would cause problems in your machine. It did not make the correct decision, but the infrastructure is there. I would file a bug on systemd mentioning this behavior. But I like the fact that that my usb wifi card will not screw my system.
        mrob 11y ago
        I don't want intelligent tools. The smarter the tool the more difficult it is to fix when it inevitably breaks. The intelligence might save a few minutes every so often, but the failures can cost hours, and at a time when you might urgently need things to work correctly. Predictability is more valuable.
        weland 11y ago
        > You might have found it bothersome, but what it was doing was intelligently trying to reason whether a device would cause problems in your machine. What was intelligent about that? I don't need intelligent tools, I need tools that do what I say! That's why they're tools, damn it!
    - simoncion 11y ago
      > I, and many others, prefer sysvinit over systemd... Do you prefer sysvrc over -say- OpenRC, Upstart, runit, etc, etc?
    - _delirium 11y ago
      > not in-line with the unix philosophy of 'do one thing and do it well' I'm not sure how you could, with a straight face, claim that sysvinit fits this description. It does many things, none of them particularly well.
      - na85 11y ago
        Replacing a bad system (sysvinit) with another bad system (systemd) is just change for change's sake.
        throwaway2048 11y ago
        ah yes, the old "everything must be perfect before we are allowed to change anything" scree. The only thing this accomplishes is ensuring no progress is made, ever.
        vezzy-fnord 11y ago
        Well, in fairness, systemd isn't really a matter of changing sysvinit. It's changing the entire low-level userspace, so there's a lot more one can object to, in principle.
    - vezzy-fnord 11y ago
      I don't know of many people who actually liked sysvinit. It's mostly apathy due to its low surface (though actually sysvinit is still monolithic and overly coupled compared to members of the daemontools family like runit or s6). It's a red herring, anyway. People have been replacing classic BSD and SysV initialization schemes since 1992 [1], but systemd was the first to penetrate the scene quite massively for a plethora of reasons that no one can seem to agree on. [1] http://blog.darknedgy.net/technology/2015/09/05/0/ http://blog.darknedgy.net/technology/2015/09/05/0/
      - ewzimm 11y ago
        Responses to software seem to follow patterns. Sysvinit is basically Windows XP. People hated it for its lack of sophistication until it got replaced by Vista with its enhanced permissions, which people found inconvenient because they required slightly different interactions, and then XP became, if not good, at least the best in existence. Systemd will eventually be replaced by a minor revision which addresses the main complaints of the vocal minority, and then when NeoUpstart establishes dominance despite a massive list of bugs, systemd will rise to immaculate status and everyone will brag about how they used it before it was cool.
        rodgerd 11y ago
        > Sysvinit is basically Windows XP. Honestly that's unfair to XP/Windows Server 2003 which had much better supervisor capability than sysvinit provides.
        togusa 11y ago
        To be fair NT4 had a better service management story in 1996.
        JdeBP 11y ago
        And it would be interesting to see how much of that it took from VMS.
  - beedogs 11y ago
    > systemd as base system will certainly happen, regardless. That's really a shame. Systemd is almost comically bad.
    - sanderjd 11y ago
      Has someone made a resource where noobs like me can go and read about why systemd is "almost comically bad" in a succinct fashion? I've seen a lot of political stuff, and a lot of claims that sysvinit ain't broke so we shouldn't fix it (which makes little sense to me), but haven't seen a good resource discussing technical merits, or the lack thereof.
      - vezzy-fnord 11y ago
        Ugh. I could probably do it, but in all honesty, the "debate" has been so spoiled that I doubt anyone would take it seriously. My relatively technical article about FreeBSD and launchd (which had only one error about where plists were parsed, a relatively minor gripe in the text) was near-universally misunderstood and derailed by commentators who went on rants tangential to what I actually discussed. Same with my init history article. But, if enough people want to, maybe I'll bite the bullet. Not sure if I'd like to subject myself to it, but I think I might end up writing a rather long treatise if there's demand and I do go with it.
        chris_wot 11y ago
        I'd be interested :-)
        insulanian 11y ago
        Bring it on!
        throwaway7767 11y ago
        I'd also be interested. I kinda like systemd as far as I've tried it, but as you say, the discussion around it is just inane. I'm sure there are valid complaints buried in there, and you seem to be a reasonable sort about these things. There are other pages out there claiming to be neutral overviews, but they generally just take a neutral tone while rehashing the same long-debunked myths and spreading FUD. The specific thing I like about systemd is the init replacement. It's just so much better! Automatically tracking daemon child processes, even detached ones. Supporting all the different modes daemons work, so I don't need to write yet another damn clean-up-all-the-children function in a SysVinit script. It's wonderful. But systemd is a lot more than an init system and I don't really have strongly formed opinions on those.
- rmdoss 11y ago
  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).
  - tene 11y ago
    I've been a sys admin for ten years. I like systemd.
  - SEJeff 11y ago
    I've managed Unix and Linux systems for over 10 years. I prefer systemd based systems where possible. Hit me up offline (email is in the resume linked in my profile) for technical reasons if you care.
    - euyyn 11y ago
      Why not explain them here? It's probably interesting for a lot of people.
      - XorNot 11y ago
        Unit files are simple to write, and make incorporating new custom processes even simpler (does it log to stdout? It'll log to journald and then syslog perfectly fine). Process management is built in and sophisticated (restarts, timeouts, conditions, limits etc.). The dependency system is amazing for ensuring your system fails sensibly: I can link mountpoints to processes, and easily guarantee that a mail daemon only runs when its network mount is ready, and then make it also shutdown if that mount goes away for any reason. This is huge for self-documenting infrastructure - you can ensure that even manual intervention in the system won't leave it in a weird state, and the why is all right there.
    - click170 11y ago
      Please don't take this conversation offline, share your thoughts here instead. Taking a conversation that started in public offline when there is an expressed interest in this very thread just doesn't follow.
krschultz 11y ago
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.
pippy 11y ago
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
- vezzy-fnord 11y ago
  Don't count on it. It's probably going to be this: http://www.freedesktop.org/software/systemd/man/file-hierarchy.html http://www.freedesktop.org/software/systemd/man/file-hierarc...
  - craftkiller 11y ago
    Why is /usr/bin being adopted as the place for binaries with /bin linking to it instead of the other way around? Since they're essentially the same directory under this setup why not favor the short path?
    - zarvox 11y ago
      http://www.freedesktop.org/wiki/Software/systemd/TheCaseForTheUsrMerge/ http://www.freedesktop.org/wiki/Software/systemd/TheCaseForT... In short: because having things in /usr is equally compatible, and makes some useful things like atomically snapshotting /usr to snapshot all executables, mounting /usr readonly, etc. possible.
      - craftkiller 11y ago
        Ah I had not considered snapshotting just /usr before. Thanks for the link, it makes a lot more sense now!
    - jonhohle 11y ago
      In addition, on more complex setups, `/usr` might not be mounted during certain failure modes.
deleted 11y ago
[deleted]
bbanyc 11y ago
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?
- SEJeff 11y ago
  You just completely nailed it. Unix is now relevant, but only in niches, where as Linux used to only be relevant in niches.
  - bbanyc 11y ago
    To the point, the rest of the discussion here revolves around init scripts and the filesystem hierarchy, which are the only parts of LSB that anyone actually used. (And they're sticking around in Debian, at least for now.) In theory LSB meant a vendor could ship an RPM that would work flawlessly on any Linux distro supporting that LSB release (which on Debian meant supporting RPM alongside DEB as a package format). In practice vendors would just target RHEL and/or Ubuntu and call it a day.
- marcosdumay 11y ago
  Well, that and making cut-and-paste work across X applications.
- pquerna 11y ago
  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.
  - zurn 11y ago
    What kind of problems did you have with trying to make common binaries? The old wisdom is that you can make it work by building against an old enough glibc (and maybe other conservative deps like base X libs) and then ship other libraries along with your binary.
rhabarba 11y ago
Oh, so the replacement for POSIX because POSIX is too established needs a replacement now? Funny Linux guys.
uxcn 11y ago
Speaking of standards, has anything happened with POSIX since '08?
- caf 11y ago
  The current edition of POSIX is from 2013: http://pubs.opengroup.org/onlinepubs/9699919799/ http://pubs.opengroup.org/onlinepubs/9699919799/
  - uxcn 11y ago
    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 11y ago
      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 11y ago
        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 11y ago
        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?)
shadytrees 11y ago
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.
SwellJoe 11y ago
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 11y ago
  Well 1 thing of LSB does help in 1 case: init.d return codes, very important with some HA tools.
  - SwellJoe 11y ago
    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).
- the_why_of_y 11y ago
  It is possible to build one binary that run on all reasonably popular distributions, even for quite complex software; there is just pretty much no documentation on how to set up a build environment to do so (there is no "GNU/Linux SDK"). A project I was familiar with some years ago used essentially a NFS mount containing a subset of a 4 year old "enterprise distro" and then built with GCC --sysroot plus some vars like PATH, PKG_CONFIG_PATH etc set appropriately. One of the problems is, beyond the few things listed in LSB (so it's not entirely useless!) it's not at all obvious what libraries you can expect to be on the system in an ABI compatible way - if you want to use something as unstable as OpenSSL you have to bundle it.
simula67 11y ago
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 11y ago
  /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 11y ago
    Why is this a bad idea?
    - rleigh 11y ago
      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 11y ago
        I'm still confused should I use: #!/usr/bin/env python #!/usr/bin/python And why?
lifeisstillgood 11y ago
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 11y ago
  Apt considers everything under /etc as a "config file", or any file mentioned in the special CONFFILES package file.
  - lifeisstillgood 11y ago
    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?
dnlrn 11y ago
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 11y ago
  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.
pjmlp 11y ago
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 11y ago
  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.
jbb555 11y ago
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 11y ago
  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 11y ago
    Really? I don't remember Windows Mobile having any relevance. Symbian was pretty much alone at the throne for years before iOS and Android.
debacle 11y ago
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.
gaius 11y ago
With systemd too it's clear that Linux sees its future as something distinct from POSIX.

285 points by vezzy-fnord 11y ago

hlmencken 11y ago

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

alrs 11y ago

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

vezzy-fnord 11y ago
LSB is actually somewhat to blame for prolonging sysvinit's lifespan, in its specification of standard initscript functions (which ultimately were seldom used and laughable compared to /etc/rc.subr in BSD-land) and the awkward dependency headers that required a preprocessor like insserv(8) to scan them. systemd as base system will certainly happen, regardless.
- duncan_bayne 11y ago
  :(
- AdmiralACK 11y ago
  I, and many others, prefer sysvinit over systemd, which I consider overly bloaty and not in-line with the unix philosophy of 'do one thing and do it well'. It's far too involved in the overall systems where, now, some desktop environments require it? That's absolute crap.
  - cakes 11y ago
    Though I'm not going to say I really care for sysvinit - I prefer it to systemd as well. Every interaction I've had with systemd just ends up confusing me until I either successfully get it work _somehow_ outside of logic I can actually comprehend or giving up entirely. A lot of people I know have had similar experiences.
    - stephen_g 11y ago
      Interesting perspective. My experience has been the complete opposite - writing unit scripts used to be a real pain, but systemd unit files take two minutes and just work every time. My machines start much faster with systemd too, which is a nice side effect.
    - deckard1 11y ago
      I used to be on the fence. I knew I hated journald with a passion. But for systemd, the last straw was trying to mount a USB drive one day. I would do "mount", and nothing was mounted. I looked through the logs and noticed it was being unmounted on mount. What the fuck, right? Turns out, a prior unmount of a USB stick killed some service that systemd runs. So systemd thinks the service is dead, which means it should not be mounted, which means it keeps umounting the damn thing. Totally braindead. That's also when I learned systemd was running an entire virtual fstab layer. Because, you know, /etc/fstab just isn't good enough anymore.
      - sandGorgon 11y ago
        This is actually a good thing. You might have found it bothersome, but what it was doing was intelligently trying to reason whether a device would cause problems in your machine. It did not make the correct decision, but the infrastructure is there. I would file a bug on systemd mentioning this behavior. But I like the fact that that my usb wifi card will not screw my system.
        mrob 11y ago
        I don't want intelligent tools. The smarter the tool the more difficult it is to fix when it inevitably breaks. The intelligence might save a few minutes every so often, but the failures can cost hours, and at a time when you might urgently need things to work correctly. Predictability is more valuable.
        weland 11y ago
        > You might have found it bothersome, but what it was doing was intelligently trying to reason whether a device would cause problems in your machine. What was intelligent about that? I don't need intelligent tools, I need tools that do what I say! That's why they're tools, damn it!
  - simoncion 11y ago
    > I, and many others, prefer sysvinit over systemd... Do you prefer sysvrc over -say- OpenRC, Upstart, runit, etc, etc?
  - _delirium 11y ago
    > not in-line with the unix philosophy of 'do one thing and do it well' I'm not sure how you could, with a straight face, claim that sysvinit fits this description. It does many things, none of them particularly well.
    - na85 11y ago
      Replacing a bad system (sysvinit) with another bad system (systemd) is just change for change's sake.
      - throwaway2048 11y ago
        ah yes, the old "everything must be perfect before we are allowed to change anything" scree. The only thing this accomplishes is ensuring no progress is made, ever.
        vezzy-fnord 11y ago
        Well, in fairness, systemd isn't really a matter of changing sysvinit. It's changing the entire low-level userspace, so there's a lot more one can object to, in principle.
  - vezzy-fnord 11y ago
    I don't know of many people who actually liked sysvinit. It's mostly apathy due to its low surface (though actually sysvinit is still monolithic and overly coupled compared to members of the daemontools family like runit or s6). It's a red herring, anyway. People have been replacing classic BSD and SysV initialization schemes since 1992 [1], but systemd was the first to penetrate the scene quite massively for a plethora of reasons that no one can seem to agree on. [1] http://blog.darknedgy.net/technology/2015/09/05/0/ http://blog.darknedgy.net/technology/2015/09/05/0/
    - ewzimm 11y ago
      Responses to software seem to follow patterns. Sysvinit is basically Windows XP. People hated it for its lack of sophistication until it got replaced by Vista with its enhanced permissions, which people found inconvenient because they required slightly different interactions, and then XP became, if not good, at least the best in existence. Systemd will eventually be replaced by a minor revision which addresses the main complaints of the vocal minority, and then when NeoUpstart establishes dominance despite a massive list of bugs, systemd will rise to immaculate status and everyone will brag about how they used it before it was cool.
      - rodgerd 11y ago
        > Sysvinit is basically Windows XP. Honestly that's unfair to XP/Windows Server 2003 which had much better supervisor capability than sysvinit provides.
        togusa 11y ago
        To be fair NT4 had a better service management story in 1996.
        JdeBP 11y ago
        And it would be interesting to see how much of that it took from VMS.
- beedogs 11y ago
  > systemd as base system will certainly happen, regardless. That's really a shame. Systemd is almost comically bad.
  - sanderjd 11y ago
    Has someone made a resource where noobs like me can go and read about why systemd is "almost comically bad" in a succinct fashion? I've seen a lot of political stuff, and a lot of claims that sysvinit ain't broke so we shouldn't fix it (which makes little sense to me), but haven't seen a good resource discussing technical merits, or the lack thereof.
    - vezzy-fnord 11y ago
      Ugh. I could probably do it, but in all honesty, the "debate" has been so spoiled that I doubt anyone would take it seriously. My relatively technical article about FreeBSD and launchd (which had only one error about where plists were parsed, a relatively minor gripe in the text) was near-universally misunderstood and derailed by commentators who went on rants tangential to what I actually discussed. Same with my init history article. But, if enough people want to, maybe I'll bite the bullet. Not sure if I'd like to subject myself to it, but I think I might end up writing a rather long treatise if there's demand and I do go with it.
      - chris_wot 11y ago
        I'd be interested :-)
      - insulanian 11y ago
        Bring it on!
      - throwaway7767 11y ago
        I'd also be interested. I kinda like systemd as far as I've tried it, but as you say, the discussion around it is just inane. I'm sure there are valid complaints buried in there, and you seem to be a reasonable sort about these things. There are other pages out there claiming to be neutral overviews, but they generally just take a neutral tone while rehashing the same long-debunked myths and spreading FUD. The specific thing I like about systemd is the init replacement. It's just so much better! Automatically tracking daemon child processes, even detached ones. Supporting all the different modes daemons work, so I don't need to write yet another damn clean-up-all-the-children function in a SysVinit script. It's wonderful. But systemd is a lot more than an init system and I don't really have strongly formed opinions on those.
rmdoss 11y ago
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).
- tene 11y ago
  I've been a sys admin for ten years. I like systemd.
- SEJeff 11y ago
  I've managed Unix and Linux systems for over 10 years. I prefer systemd based systems where possible. Hit me up offline (email is in the resume linked in my profile) for technical reasons if you care.
  - euyyn 11y ago
    Why not explain them here? It's probably interesting for a lot of people.
    - XorNot 11y ago
      Unit files are simple to write, and make incorporating new custom processes even simpler (does it log to stdout? It'll log to journald and then syslog perfectly fine). Process management is built in and sophisticated (restarts, timeouts, conditions, limits etc.). The dependency system is amazing for ensuring your system fails sensibly: I can link mountpoints to processes, and easily guarantee that a mail daemon only runs when its network mount is ready, and then make it also shutdown if that mount goes away for any reason. This is huge for self-documenting infrastructure - you can ensure that even manual intervention in the system won't leave it in a weird state, and the why is all right there.
  - click170 11y ago
    Please don't take this conversation offline, share your thoughts here instead. Taking a conversation that started in public offline when there is an expressed interest in this very thread just doesn't follow.

krschultz 11y ago

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.

pippy 11y ago

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

vezzy-fnord 11y ago
Don't count on it. It's probably going to be this: http://www.freedesktop.org/software/systemd/man/file-hierarchy.html http://www.freedesktop.org/software/systemd/man/file-hierarc...
- craftkiller 11y ago
  Why is /usr/bin being adopted as the place for binaries with /bin linking to it instead of the other way around? Since they're essentially the same directory under this setup why not favor the short path?
  - zarvox 11y ago
    http://www.freedesktop.org/wiki/Software/systemd/TheCaseForTheUsrMerge/ http://www.freedesktop.org/wiki/Software/systemd/TheCaseForT... In short: because having things in /usr is equally compatible, and makes some useful things like atomically snapshotting /usr to snapshot all executables, mounting /usr readonly, etc. possible.
    - craftkiller 11y ago
      Ah I had not considered snapshotting just /usr before. Thanks for the link, it makes a lot more sense now!
  - jonhohle 11y ago
    In addition, on more complex setups, `/usr` might not be mounted during certain failure modes.

deleted 11y ago

[deleted]

bbanyc 11y ago

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?

SEJeff 11y ago
You just completely nailed it. Unix is now relevant, but only in niches, where as Linux used to only be relevant in niches.
- bbanyc 11y ago
  To the point, the rest of the discussion here revolves around init scripts and the filesystem hierarchy, which are the only parts of LSB that anyone actually used. (And they're sticking around in Debian, at least for now.) In theory LSB meant a vendor could ship an RPM that would work flawlessly on any Linux distro supporting that LSB release (which on Debian meant supporting RPM alongside DEB as a package format). In practice vendors would just target RHEL and/or Ubuntu and call it a day.
marcosdumay 11y ago
Well, that and making cut-and-paste work across X applications.
pquerna 11y ago
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.
- zurn 11y ago
  What kind of problems did you have with trying to make common binaries? The old wisdom is that you can make it work by building against an old enough glibc (and maybe other conservative deps like base X libs) and then ship other libraries along with your binary.

rhabarba 11y ago

Oh, so the replacement for POSIX because POSIX is too established needs a replacement now? Funny Linux guys.

uxcn 11y ago

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

caf 11y ago
The current edition of POSIX is from 2013: http://pubs.opengroup.org/onlinepubs/9699919799/ http://pubs.opengroup.org/onlinepubs/9699919799/
- uxcn 11y ago
  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 11y ago
    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 11y ago
      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 11y ago
        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?)

shadytrees 11y ago

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.

SwellJoe 11y ago

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 11y ago
Well 1 thing of LSB does help in 1 case: init.d return codes, very important with some HA tools.
- SwellJoe 11y ago
  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).
the_why_of_y 11y ago
It is possible to build one binary that run on all reasonably popular distributions, even for quite complex software; there is just pretty much no documentation on how to set up a build environment to do so (there is no "GNU/Linux SDK"). A project I was familiar with some years ago used essentially a NFS mount containing a subset of a 4 year old "enterprise distro" and then built with GCC --sysroot plus some vars like PATH, PKG_CONFIG_PATH etc set appropriately. One of the problems is, beyond the few things listed in LSB (so it's not entirely useless!) it's not at all obvious what libraries you can expect to be on the system in an ABI compatible way - if you want to use something as unstable as OpenSSL you have to bundle it.

simula67 11y ago

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 11y ago
/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 11y ago
  Why is this a bad idea?
  - rleigh 11y ago
    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 11y ago
      I'm still confused should I use: #!/usr/bin/env python #!/usr/bin/python And why?

lifeisstillgood 11y ago

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 11y ago
Apt considers everything under /etc as a "config file", or any file mentioned in the special CONFFILES package file.
- lifeisstillgood 11y ago
  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?

dnlrn 11y ago

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 11y ago
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.

pjmlp 11y ago

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 11y ago
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.

jbb555 11y ago

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 11y ago
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 11y ago
  Really? I don't remember Windows Mobile having any relevance. Symbian was pretty much alone at the throne for years before iOS and Android.

debacle 11y ago

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.

gaius 11y ago

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