Follow Slashdot blog updates by subscribing to our blog RSS feed

 



Forgot your password?
typodupeerror
Linux

Choose Your Side On the Linux Divide 826

Posted by samzenpus
from the picking-a-team dept.
snydeq writes The battle over systemd exposes a fundamental gap between the old Unix guard and a new guard of Linux developers and admins, writes Deep End's Paul Venezia. "Last week I posted about the schism brewing over systemd and the curiously fast adoption of this massive change to many Linux distributions. If there's one thing that systemd does extremely well, it is to spark heated discussions that devolve into wild, teeth-gnashing rants from both sides. Clearly, systemd is a polarizing subject. If nothing else, that very fact should give one pause. Fundamental changes in the structure of most Linux distributions should not be met with such fervent opposition. It indicates that no matter how reasonable a change may seem, if enough established and learned folks disagree with the change, then perhaps it bears further inspection before going to production. Clearly, that hasn't happened with systemd."
This discussion has been archived. No new comments can be posted.

Choose Your Side On the Linux Divide

Comments Filter:
  • by Z00L00K (682162) on Monday August 25, 2014 @01:57PM (#47750173) Homepage

    Who really needs systemd?

    It may provide some features not previously existing, but it also breaks a lot of stuff that people "knew" were there.

  • by NotDrWho (3543773) on Monday August 25, 2014 @02:00PM (#47750197)

    And THAT pretty much sums up what has always held Linux back (and probably always will).

  • by MobyDisk (75490) on Monday August 25, 2014 @02:11PM (#47750331) Homepage

    This article is just a rant, full one one-liner insults and clichés. There are probably good debates on this topic, but this is not one of them.

  • Re:Display server (Score:5, Insightful)

    by psergiu (67614) on Monday August 25, 2014 @02:17PM (#47750399)

    As long as xterm & the web browser are running on Wayland, nobody will complain.
    X.org has became such a mess itself (compared to the old XFree86) so anything smaller, simpler, faster and 100% compatible is welcome.

    OTOH systemD is not smaller, simpler and 100% compatible with the systemV init and BSD rc - so it requires everybody relearning a lot of concepts for scratch just to gain 4-5 seconds at boot time - unsually on a server that you reboot only a couple of times a year.

  • by jedidiah (1196) on Monday August 25, 2014 @02:17PM (#47750409) Homepage

    > Fundamental changes in the structure of most Linux distributions should not be met with such fervent opposition.

    Sure it should. At the very least, such sweeping changes should be met with some skepticism based purely on mundane ideas about change control. Why are changes with such a massive impact being considered? What is being done to mitigate risks? How is this going to impact how Linux fits in with other Unixen?

    What's broken exactly?

  • by loony (37622) on Monday August 25, 2014 @02:17PM (#47750411)

    Who cares if you have to relearn stuff? Its the fact that systemd is less than stable... In many cases, you end up with corrupt binary log file after a crash, have services that don't (run a process that does heavy syslogging to the tune of 25-30K messages per second. Yes, its bad app design but come on - this thing worked for years and now its suddenly broken???) that used to work just fine before and then top it off with really braindead configuration options (go ahead and change the pgsql listen port - and see how long it takes you...)

    I'm all for systemd - once its been stable for a while, but till then it would be nice to have at least a choice...

    Peter.

  • It's job security (Score:2, Insightful)

    by realmolo (574068) on Monday August 25, 2014 @02:22PM (#47750479)

    Old-school Unix admins don't WANT anything to change, or get easier. It threatens their livelihood. This is true of anyone with any kind of skill, but int computer-land, the changes come quickly.

    It wouldn't be a problem if people weren't fundamentally lazy. But most people are. And admins are some of the *laziest*, because that laziness translates into an "automate everything" mindset, which is actually a good thing if you are an admin. But the idea of having to RE-automate everything sounds like work. Lots of work.

  • by jedidiah (1196) on Monday August 25, 2014 @02:23PM (#47750493) Homepage

    > Who cares if you have to relearn stuff?

    Anyone that uses something besides Linux. One great thing about Unixen is how they share common interfaces. The more you change that, the less interchangeable the various Unixen become. The more reason their will be to resist moving from one to another.

    This is something that has benefited Linux greatly in the past: the fact that a Solaris user could feel fairly comfortable with picking up Linux and just dive in.

    The anti-dinosaur sentiment should not be an excuse to blindly and gratuitously change things just because of "new shiny shiny".

    All of your substantive complaints seem to be a direct result of ignoring the principle "don't fix what isn't broken".

  • by Charliemopps (1157495) on Monday August 25, 2014 @02:25PM (#47750525)

    At the moment, just about every major distribution except Slackware and Gentoo not only supports systemd, but ships with it on by default.

    So...what "battle" are we talking about? (Or did this post just fall forward five years from the past?)

    Ubuntu is the largest distro I know of and it doesn't support it by default.

    But you're right, all the arguments I've read against it boil down to Linus hating on one of the developers on the project and/or "It's too complicated and unmanageable!" I've yet to read something I'd consider a valid argument against it. A bunch of neck beards yelling "Get off my lawn!" is not and argument I can get any value out of.

  • by Anonymous Coward on Monday August 25, 2014 @02:25PM (#47750529)

    Much like pulseaudio, it will probably become quite good when Lennart stops working on it and hands it over to someone else to maintain.

  • by LVSlushdat (854194) on Monday August 25, 2014 @02:26PM (#47750539)

    Who really needs systemd?

    I've been working with Linux since 1995, where I started with Slackware, moved over to Redhat until it went all "enterprise-y", at which time I moved to Fedora.. Stayed there till a friend turned me on to Ubuntu in 2007, where I stayed pretty much till the recent Unity shitfest over there, where I then moved to Debian.. I cut my teeth on /etc/init.d and a stock standard init() process.. I could do pretty anything I needed to do in troubleshooting/starting/stopping daemons from memory.. Can't remember the last time I consulted a man page regarding anything having to with init() or logging.. Now with this $#@$%%$#@ systemd, I have manpages up ALL the time just to do simple shit that I could do with init() and standard logging in my sleep before systemd. It also seems like this crap is spreading like sewage over pretty much of the standard distros.. Debian/Fedora/CentOS.. The only one I'm somewhat familiar with (haven't used it recently) is Slackware and from what I've heard Patrick and the devs over there feel the same way I do about systemd.... Maybe its time to revisit an old friend.....

  • by 0123456 (636235) on Monday August 25, 2014 @02:32PM (#47750605)

    Everyone hates X, so lets compare this thing I don't like to X. Even thought its obviously very different from X.

    A few loud-mouths hate X. Most people who use X don't even know it exists. Those who use X the way it was designed (i.e. network transparency) can't understand why the loudmouths want to throw that away to build something like Windows, when Windows is dying.

  • by rubycodez (864176) on Monday August 25, 2014 @02:34PM (#47750623)

    A complex startup system that logs to a database rather than a text log, is just poor engineering.

    And to answer any systemd apologist who will mention that it can configured to log to syslog, that won't help if there is a problem in the vast complexity of systemd that prevents it from ever getting started to that point.

    Just the requirement for dbus proves systemd far too complex and bloated a thing, it is against the Unix way of doing things. Failures and problems in a needlessly complicated black box may well be too difficult to even troubleshoot

  • Re:Display server (Score:3, Insightful)

    by 0123456 (636235) on Monday August 25, 2014 @02:35PM (#47750637)

    Do you see any disadvantages of wayland?

    Uh, let's see. Right now I'm running two copies of Eclipse from a VM, displaying on the host machine's desktop using X-forwarding. Under Wayland, that'll require either pushing megabytes of pixels every time I scroll a window, or using some god-awful VNC crap.

    Oh, but the desktop is dead, etc, etc and we'll all be doing software development on phones in future.

  • by Anonymous Coward on Monday August 25, 2014 @02:36PM (#47750649)

    What's broken is that some people would rather change Linux into something else fundamentally, rather than wait for the rest of the world to catch up. The result is going to be the same kind of pain that's happening in the browser arena. There, you have reasonable standards bodies who move "too slowly" for a few, who wish to replace the web with a new version that's obviously even more flawed, all in the name of progress. Sometimes the old guard aren't just holding back progress, but don't tell that to inexperienced youths and bitter old men who want to make a name for themselves.

  • by RabidReindeer (2625839) on Monday August 25, 2014 @02:40PM (#47750699)

    This is the problem with systemd, Gnome 3 and a lot of other recent stuff.

    Unix was originally designed rather like a tinkertoy set. The individual parts might not be very smart, but you could glue them together however you wanted. A "RISC" architecture, if you will.

    Recent "improvements" to Linux have attempted to be all-in-one solutions. By making them one-size-fits-all, you lose useful, important, sometimes critical functionality. Because no one system can be all things to all people. It's a "CISC" solution, and what you are left with is what the designed wanted you to have, not what you wanted to have.

    So that's the Great Divide. Turn into another Apple, where you can have any solution you want as long as it's the one the providers want to give you or retain the original spirt of the system, and allow it to be powerful at the expense of the presumed masses who'd gladly chuck Windows if only Linux was more friendly to the casual user.

  • by dosius (230542) <bridget@buric.co> on Monday August 25, 2014 @02:43PM (#47750729) Journal

    "What's broken exactly?" - PRECISELY.

    You got a bunch of "upstarts" who don't know, or don't care, about Linux's roots and want to turn it into something it just never was meant to be, something other than, well, a *x. And I'll fight that derailment like a tiger if need be.

  • Better question (Score:2, Insightful)

    by Dcnjoe60 (682885) on Monday August 25, 2014 @02:45PM (#47750751)

    Who really needs systemd?

    It may provide some features not previously existing, but it also breaks a lot of stuff that people "knew" were there.

    A better question is why does it matter. Nobody is forcing systemd on distros. They are free to use whatever init system them want. The only reason this is an issue is because debian change to it and all of the derivatives, including the *buntus are now changing because of debian's change. However, nobody is forcing anybody downstream to change.

    Distros are free to use whatever init system they want. Now, if they don't want to expend the effort and use the upstream init system, well, that is a design decision on their part. But, they aren't being forced into it.

  • by CajunArson (465943) on Monday August 25, 2014 @02:47PM (#47750769) Journal

    1. Not that often for my desktop systems, but quite a bit for all those mobile devices out there. P.S. --> anybody who brags about ** years of uptime on a server deserves to be shot for failing to apply updates.

    2. I don't care if I only save 1 second: time savings are important.

  • by RabidReindeer (2625839) on Monday August 25, 2014 @02:47PM (#47750771)

    I think, for a lot of people, they don't have the challanges that systemd solves.

    Conversely, systemd daily inserts problems that never existed before.

    Actually they did. I dealt with binary log formats in Windows, OS/2, and IBM's mainframes. IBM has a really bad habit of creating a different binary format logfile for every app, complete with special binary utilities to be able to read them in any way you like - as long as it's a way IBM supports.

    The old text logfiles might not be as tidy, but I constantly string together strange concatenations of the text utilities to garner critical information from them. Something that's nowhere near as easy when the logs are in binary form.

    What systemd reminds me of is the Windows Registry. A fine concept that turned out to be a nightmare in practice.

  • by TheCarp (96830) <sjc AT carpanet DOT net> on Monday August 25, 2014 @02:48PM (#47750785) Homepage

    That, I must say, is one of the arguments that turns me off to it. I really could not possibly care less how long it takes any system other than my laptop to boot. My laptop does run a distro with systemd, and I do like that it boots fast....I would not hesistate for a second to give that speed up if I needed to for something I do once a day usually and twice a day at most.

    The majority of systems I deal with are servers. They mostly have plenty of CPU and memory available and typically run very few services..... they boot plenty fast without systemd.

    Really the most annoying thing about it for me isn't going to be learning it, its going to be training other people to deal with it and supporting them when they find the software they are installing isn't setup for it properly and they need to troubleshoot and fix it.

    If there was some real benefit, I am all for it but....boot speed? Talk about not worth it if that is the "benefit"

  • by Anonymous Coward on Monday August 25, 2014 @02:50PM (#47750805)

    This is something that has benefited Linux greatly in the past: the fact that a Solaris user could feel fairly comfortable with picking up Linux and just dive in.

    http://en.wikipedia.org/wiki/S... [wikipedia.org]

  • by msobkow (48369) on Monday August 25, 2014 @02:55PM (#47750845) Homepage Journal

    System admins both old and new that are worth anything don't want things changing just for the sake of change.

    It boils down to the old adage: "If it ain't broke, don't fix it."

    Which further boils down to something admins care very much about: stability and reliability. Changing something that's been in production for 5, 10, or more years just because someone decided to roll out the new "shiny, shiny" is not an effective use of the admin's time.

    Last but not least, admins are often responsible for systems from multiple vendors. Having a unique configuration model for each system goes against the whole point of things like POSIX APIs and standardized startup processing.

    Sure on a desktop or developer system, the difference is probably irrelevant. But when your main job is configuring and maintaining services on servers instead of just using a box, the arguments and priorities change for damned good reasons.

  • by raymorris (2726007) on Monday August 25, 2014 @02:57PM (#47750859)
    I notice that of the top 500 fastest computers in the world, 97% run Linux. http://www.top500.org/statisti... [top500.org] That would include the $390 million Tianhe-2. Oak Ridge National Laboratory spent $60 million to upgrade the $104 million Jaguar to become Titan, both running Linux. So yeah, if you're definition of "cheap" includes "the most expensive and powerful in the world", I guess you're right.
  • by beelsebob (529313) on Monday August 25, 2014 @02:57PM (#47750871)

    Anyone that uses something besides Linux. One great thing about Unixen is how they share common interfaces. The more you change that, the less interchangeable the various Unixen become. The more reason their will be to resist moving from one to another.

    Except that's actually false. Unixen really don't share common interfaces. Mac OS uses launchd, FreeBSD uses init.d, many Linuxes use systemd.

    On Linux you'll find devices named /dev/hda(n) and sda(n), while on OS X you'll find /dev/disk(n)s(m), and on solaris you'll find /dev/dsk/c(n)t(m)d(l)s(o).

    All unixes differ. Trying to claim that the way it happens to have been done in Linux for a while is the "one true unix way" is frankly bullshit.

  • by Etcetera (14711) on Monday August 25, 2014 @02:58PM (#47750885) Homepage

    You can see this in Development vs Operations, Bay Area Startup Hipster Programmers vs System Administrators Who Have To Carry The Pager, Big Data vs Simpler Analysis, and a lot of other places in the industry right now....

    There's an influx of talent that doesn't seem to understand the fundamentals of system architecture, or assumes they have all the answers and can/should hard-code them into the design, preventing "the Unix Philosophy" from being applied by the operator who's trying to deal with the crisis at 3 in the morning. "whatcouldpossiblygowrong", ergo I shall design this in C, and if you need more flexibility than I'm offering then You're Doing It Wrong.

    What they don't understand is that they don't have all the answers... Nobody does. The only solution is to leave as much flexibility available as far down the stack as possible to allow the folks who have to deal with this (eg, system administrators) the ability to do their jobs. Replacing shell scripts with C code and the unix toolkit with monolithic binary blobs does not help the situation.

    systemd does a few things right (cgroup management, for one), and promotes the state of the art in a few areas that probably only could be dealt with at the PID1 level... Also, as the original article admits, there's nothing inherently wrong with working to speed up boot times across the board. All of these things are irrelevant and outweighed by enforcing declarative styles on system configuration, and the sheer philosophical hazard of taking all these disparate functions and putting them into a program.

    It makes absolute sense for Android, and perhaps an embedded system that just needs systemd and busybox. For a regular Linux userland, it takes us in the wrong direction.

  • by blue9steel (2758287) on Monday August 25, 2014 @03:03PM (#47750927)

    I've yet to read something I'd consider a valid argument against it.

    It violates basic *nix design philosophy, which basically has two pieces: 1) Everything is a text file 2) Lots of small tools that can be chained together to do big things

    Boot time is essentially irrelevant, I don't see why everyone gets so excited about it.

  • by davek (18465) on Monday August 25, 2014 @03:05PM (#47750939) Homepage Journal

    At the moment, just about every major distribution except Slackware and Gentoo not only supports systemd, but ships with it on by default.

    So...what "battle" are we talking about? (Or did this post just fall forward five years from the past?)

    Ubuntu is the largest distro I know of and it doesn't support it by default.

    But you're right, all the arguments I've read against it boil down to Linus hating on one of the developers on the project and/or "It's too complicated and unmanageable!" I've yet to read something I'd consider a valid argument against it. A bunch of neck beards yelling "Get off my lawn!" is not and argument I can get any value out of.

    When the neck beards speak, it's often prudent to at least listen.

    I'm reminded of a myth, of when the Ancients were sitting down to design Unix, someone said "Why would we ever need a special file, that never contains any data, and always throws away everything written to it?" The Ancient replied, "Trust me, you'll need it." And thus, /dev/null was born.

  • Re:Display server (Score:3, Insightful)

    by CajunArson (465943) on Monday August 25, 2014 @03:06PM (#47750949) Journal

    [quote]Right now I'm running two copies of Eclipse from a VM, displaying on the host machine's desktop using X-forwarding. Under Wayland, that'll require either pushing megabytes of pixels every time I scroll a window, or using some god-awful VNC crap.[/quote]

    Let me fix that for you:

    Using X-forwarding *right freaking now* you are pushing megabytes of pixels every time you scroll a window because every single modern toolkit operates that way and you have obviously got problems distinguishing between a simple tutorial on the 1985 version of xterm vs. how real applications that are forwarded over sockets in the real world actually behave.

  • by gweihir (88907) on Monday August 25, 2014 @03:06PM (#47750951)

    Nothing is broken with Linux. But by now I believe something very fundamental is broken in a highly dangerous fashion with the systemd developers. They hardly seem to qualify as UNIX folks at all with their mind-set....

  • by mrchaotica (681592) * on Monday August 25, 2014 @03:10PM (#47750985)

    That sounds like a good way to create an infinite loop of crashing and restarting services.

  • by gweihir (88907) on Monday August 25, 2014 @03:12PM (#47751005)

    KISS is not a "religious idea" or a "sacred cow". KISS is the very foundation of all working engineering. Systemd throws KISS out the window.

  • by Freultwah (739055) on Monday August 25, 2014 @03:18PM (#47751051) Homepage
    From what I read, I think the point was that if such changes *are* met with such fervent opposition, it is high time to step on the brakes and reevaluate the situation, and perhaps revert the changes.
  • by evilviper (135110) on Monday August 25, 2014 @03:21PM (#47751089) Journal

    - Useless on a server - where you only reboot 4 times a year or so and never have to hot-plug anything or change wireless networks.

    Bull. Lots of servers currently run daemontools or similar, or else they use some other hack, because the SysVinit doesn't have any way to restart services (like crond) the one time they exit after running fine for months...

    Alternatively, somebody has to take the time to set-up exhaustive monitoring, including ALL the trivial services running on the servers, and some dummy has to watch it around the clock, and manually perform this extremely simple and menial task. Or else maybe you're the dummy who gets paged at 3AM to do a trivial service restart, due to some simple and transitory event.

    I would have been just as happy with upstart or anything else, but it was a dammed nuisance lacking that 30 year-old feature, and downright embarrassing that Linux still lacked it, while it's been working well in the base of Windows since the first version of NT.

  • by Mordok-DestroyerOfWo (1000167) on Monday August 25, 2014 @03:22PM (#47751107)
    Hell, most of my servers spend so much time in their boot process initializing RAID controllers, mem testing, etc. that the performance gain with systemd vs init is really not going to make that much of a difference. Add to that the fact that most of us have servers whose uptimes are measured in years, boot performance is pretty much the last thing I give a damn about.
  • Re:Choosing Sides (Score:5, Insightful)

    by Anaerin (905998) on Monday August 25, 2014 @03:29PM (#47751173)

    You're posting a lot on the drawbacks of SystemD, but you're not including any of the drawbacks for SystemV.

    • SysV starts every task and service one at a time, waiting for the previous one to finish before it starts the next. This is fine for single-core single-threaded workloads, but most systems these days are multi-core. It also means that startup is slow. SystemD, on the other hand, can (and does) start up services in parallel, making sure that dependencies are resolved before starting the next item. This makes SystemD MUCH faster at booting.
    • SysV only handles the initial bringing up, and the final tearing down, of services. Any service failures are not noticed, any errors are not dealt with. SystemD monitors services even while they're running, and can re-start them if they fail, handle crash reporting and log rotation. This makes SystemD more error resilient and stable.
    • SysV only runs the services, and doesn't care about their configuration, so basic configuration and dependencies have to be handled in a myriad of ways, different for every service. SystemD attempts to be a central repository for ports (and handling the necessary firewall rules for them), configuration files, logging locations, and the rest. While this does make startup a touch more difficult to configure, it makes the system as a whole a lot simpler to deal with.
  • by Savage-Rabbit (308260) on Monday August 25, 2014 @03:39PM (#47751281)

    Everyone hates X, so lets compare this thing I don't like to X. Even thought its obviously very different from X.

    A few loud-mouths hate X. Most people who use X don't even know it exists. Those who use X the way it was designed (i.e. network transparency) can't understand why the loudmouths want to throw that away to build something like Windows, when Windows is dying.

    I mostly hate X11 because I have to program for it... It's like eating a cactus and washing it down with a whole bottle of Carolina Reaper Chili Sauce.

  • by Anonymous Coward on Monday August 25, 2014 @03:47PM (#47751361)

    What's funny is it actually has the ability, and nobody uses it except for gettys.

  • by whoever57 (658626) on Monday August 25, 2014 @03:51PM (#47751421) Journal

    and I've lost count of the amount of times when I simply wanted to just find a way to make the init system restart a service automatically when it crashes

    I cannot understand what your problem is. I have systems that run continuously for years without processes dying. I have systems where the OOM killer inadvertantly kills some system task, in which case, simply re-starting that task isn't likely to be a helpful response.

    From the perspective of re-starting system tasks, systemd is a solution to a non-problem.

  • by blue9steel (2758287) on Monday August 25, 2014 @04:04PM (#47751549)
    Wait, why would I would the system init function to be monitoring and restarting services? That's an unwarranted scope expansion. Yes, I may want that capability, but there is no reason for the init function do be doing it.
  • by Cyberax (705495) on Monday August 25, 2014 @04:11PM (#47751617)
    What's broken? ARE YOU FUCKING JOKING????

    The whole fucking Unix SysV init mess is a sticking pile of shit. It has never worked correctly. Not once. It's just _lucky_ to work most of the time.

    Personally, I had tons of problems. How about visiting a datacenter at 4am because BIND9 shutdown scripts can hang indefinitely? Or maybe having a subtle race when a device appears 5-10 too late once in 10-20 reboots? Or maybe having to run ejabberd as root, because it simply wants to bind to a 1024 port?
  • by Anonymous Coward on Monday August 25, 2014 @04:14PM (#47751647)

    I was involved in another discussion in one distro where the idea was floated to replace all of /etc XML files. A number of people even proposed replacing /etc with a mysql database that could be stored on or off the local system. Of course the idea was shot full of holes but having said that, the Next Generation (TM) thinking is that of replacing the UNIX paradigm of chaining simple tools together with larger monolithic tools. One of the arguments against was that if any of this broke the only recourse would be to re-image the box (reminds me of Windows). As a "dinosaur" myself I'm not enamoured with the idea that Linux (and Solaris and *BSD to a lesser degree) are becoming more Windows-like, Personally, I'd rather be in control and I don't like it when software "thinks" it's smarter than I am.

  • by Peter H.S. (38077) on Monday August 25, 2014 @04:23PM (#47751725) Homepage

    Re 1: Developers uncooperative?
    Looking at the mailing list this doesn't appear to be the case. +500 developers have contributed to systemd, that points to excellent leadership where even small contributions are welcomed.

    Re 2: Emacs syndrome.
    It is popular but totally wrong meme that systemd just pile on features. Its scope have been quite narrow for years. Yes, it have gained new features, but almost all new systemd features are related to the original scope of stateless booting and light weight containers.
    So people who hasn't bothered following systemd gets totally surprised when a new version of systemd has new features, but that is just because they don't really know systemd.

    Re 5: Total disregard for everything outside of Linux,
    All daemons made when sysvinit was king will work with systemd. It is backward compatible, even with sysvinit scripts (there are some few documented corner cases)

    So daemon authors don't have to change a single line of code if they don't want to. The distribution managers can just add a service file instead of the sysvinit script. (probably remove some bugs that way too)

    No other certified UNIX uses sysvinit scripts, they all have init systems more less like systemd. Does that mean they have a total disregard for anything e.g. not Solaris? (SMF).

    I find the idea that all progress on Linux should be stopped if there is a danger that it progressed faster than other Unix'es (read BSD) a rather silly idea. Especially because those other Unix'es generally hate and despise Linux because it is a successful competitor.

    systemd is the greatest thing happening to Linux for a decade, and probably the biggest shake up ever.

  • by Attila Dimedici (1036002) on Monday August 25, 2014 @05:06PM (#47752021)

    Bottom line is, when it comes to technology progress, roots are pretty much irrelevant.

    Translation: "Why should I learn from the mistakes made in the past? I'll just make them all over again. All in the name of progress."

  • OpenRC (Score:4, Insightful)

    by jbolden (176878) on Monday August 25, 2014 @05:23PM (#47752121) Homepage

    OpenRC is a really good replacement for SysV init. A serious enhancement that keeps with the spirit, an upgrade rather than a rip out and replace. OpenRC doen't keep daemons alive but that would be easy to add. Ultimately then there is only one hard problem what to do about hardware that changes. OpenRC doesn't architecturally have any good way for handing that while systemd does.

    Certainly if the argument were OpenRC vs. systemd instead of SysV init vs. systemd I suspect the advantages of systemd wouldn't have outweighed the huge shift. I hope distributions like Slackware which don't have systemd move to OpenRC so that it gets tested in environments other than Gentoo.

  • by DamnOregonian (963763) on Monday August 25, 2014 @05:45PM (#47752273)
    Humorously, back in my IOS hacking days, (original iPhone), where we were altering kernel pagetables to map hardware into userspace processes and dump bootroms, trying to fix startup inconsistencies related to our limited ability for changes, and the fucking disgusting web of unnecessary cross-dependencies that the boot process practically begged be used, launchd was the second-stupidest feature of that operating system I noted. It's not a real surprise that a lot of people have jumped on the "Apple's way is the best way!" bandwagon, really. Half the people maintaining distros these days see Apple as some kind of thing to look up to, in spite of all available market evidence. I can only surmise that it has something to do with upbringing/education.
  • by DamnOregonian (963763) on Monday August 25, 2014 @06:23PM (#47752529)
    One could call it a limitation, but it's also manifestation of the UNIX security model.

    Any random Joe Schmuck can also make a required change to the blinkenlightsd init script to programmatically alter its startup characteristics to fit his unique system startup requirements. He can't do that with systemd. I call that a limitation. So what we're really arguing is whether or not the status quo limitations are less important than the new limitations you want to introduce.
  • by Smallpond (221300) on Monday August 25, 2014 @07:16PM (#47752861) Homepage Journal

    Embedded systems are exactly the ones that don't want a bloated init system that requires dbus for communication.

  • by Smallpond (221300) on Monday August 25, 2014 @07:26PM (#47752939) Homepage Journal

    What's broken exactly?

    Software has bugs and occationally they crash. I'm not an expert GNU/Linux system administrator by any means, and I've lost count of the amount of times when I simply wanted to just find a way to make the init system restart a service automatically when it crashes. This is trivial with Systemd, you just set Restart=on-failure in the service file and it's done. No need to write error-prone shell scripts or fiddle with run levels. It just works and it's well documented.

    Straight out of Windows. Write buggy software. It's ok if it crashes once in a while because we can just restart it.

    Also straight out of Windows. Make everything into one big integrated binary instead of something that you can see into or hack on.

  • by Electricity Likes Me (1098643) on Monday August 25, 2014 @08:10PM (#47753235)

    Run blah every X seconds is just about the dumbest way we can be doing things on a computer. It's a closed system. It can know exactly when a process dies, and handle the event then. The inability to do this is a huge flaw.

  • by LordMyren (15499) on Monday August 25, 2014 @08:12PM (#47753247) Homepage

    Launchd is the young whippersnapper on the block. Solaris has had daemon administration for years.

    The old guard is a huge fan of PID1 doing it's thing then going away: it's up to everyone else to manage the world after PID1 kicks everything off. The new world- the people who like systemd- are enthusiastic beyond belief to have a PID1 which serves as a master control point where the system can continue to be managed. Every systemd subsystem has a DBUS API we can program and talk to, we can schedule coordinate and manage processes over systemd's core DBUs endpoint- this speaks of the new dawn where we might not be able to hack our shell scripts to do whatever, but we can write higher level code to effectively manage their operation. Which is something that royally sucked egg in the old guard's world.

    Sure some of this could sort of be dealt with by continuing to add more shell scripts. But the init script world is mess. Individual daemons have radically different ideas of what kind of responsibility they need to handle in their init scripts and even though for the most part the skeleton is visible across all, it's a hack job that outsiders have to wrack their brain to understand. Conversely, systemd gives us uniform control over the system: the master control program PID1 that is systemd will let us start/stop things, AND will tell us the status of things (over either shell interfaces or DBus).

    I look at this more like the innovation of steering- which permitted four wheel vehicles- than I do a particular engine configuration (different muscle, same end). Sure you could get there with the old two wheel drive cart, but as it turns out you have a lot more flexibility when the platform has consistent stability that permits being added to. Where the cam goes is an argument that affirms the lie that systemd is just a really complex initscript: it's not, it's a resident system control daemon.

  • by GigaplexNZ (1233886) on Monday August 25, 2014 @08:24PM (#47753309)

    There is no "fundamental change" to Linux with systemd

    I'd call moving DBUS into the kernel, assimilating udev, and making the init system a large complex system that does lots of things rather than the old school ideology of doing one thing and doing it well, some pretty big, somewhat fundamental changes to GNU/Linux.

  • Re:The init system (Score:3, Insightful)

    by Anonymous Coward on Monday August 25, 2014 @09:12PM (#47753523)

    1) systemd cannot be ported to other unices because it depends on a feature, cgroups, that not even the Linux kernel maintainers like. No way will cgroups ever make it onto another Unix. It's a stupid design, but Linux is stuck with it because of Linus' ABI guarantee.

    2) Software not written by idiots will continue to be portable. Network software which relies on systmd, kdbus, or glib is fundamentally a piece of trash. Desktop/application software doesn't typically have a direct dependency on systemd, and regular, user-space DBUS is portable and already runs everything. And while glib is trash, it's acceptable for desktop software.

    3) The problem with systemd isn't that it's a new init system. If that's all it did people wouldn't care nearly as much. What's happening is that systemd is slowly becoming a replacement for all kinds of other things, such as NSS, PAM, etc. Basically, when Red Hat can't get their way with an upstream maintainer (including Linus and the kernel!), Lennart says, "hey, we can just add that feature into systemd and then we don't have to care about compatibility or working with those maintainers".

    I write portable server software. All of my stuff currently compiles and runs on Linux, FreeBSD, NetBSD, OpenBSD, Solaris, and AIX (in other words, all the extent, server-grade Unix platforms). It's much more trivial than people believe, thanks to continually improving POSIX support by all vendors. Most of the portability horror stories are from the 1990s. I don't even bother with autotools, since it's trivial to build and install dynamic libraries on all those platforms.

    I'm sad to see systemd evolve the way it has because it heralds the fact that a large part of the FOSS community has decided to give up on portability. Any software that directly depends on systemd's geometrically growing feature set will always be completely and utterly unportable. It'll also be largely crappy software. One reason I focus on portability is because compiling and running software on different environments tends to bring more bugs to the surface, and do so more quickly. I've found compile-time and run-time errors on OS X or Solaris that actually uncovered bugs which would have effected behavior on Linux, but which would have been much more difficult to discover on Linux because of the different types and slightly different run-time behavior.

Physician: One upon whom we set our hopes when ill and our dogs when well. -- Ambrose Bierce

Working...