Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 



Forgot your password?
typodupeerror
Check out the new SourceForge HTML5 internet speed test! No Flash necessary and runs on all devices. ×
Debian Open Source Linux

Debian Votes Against Mandating Non-systemd Compatibility 581

paskie writes: Voting on a Debian General Resolution that would require packagers to maintain support even for systems not running systemd ended tonight with the resolution failing to gather enough support.

This means that some Debian packages could require users to run systemd on their systems in theory — however, in practice Debian still works fine without systemd (even with e.g. GNOME) and this will certainly stay the case at least for the next stable release Jessie.

However, the controversial general resolution proposed late in the development cycle opened many wounds in the community, prompting some prominent developers to resign or leave altogether, stirring strong emotions — not due to adoption of systemd per se, but because of the emotional burn-out and shortcomings in the decision processes apparent in the wake of the systemd controversy.

Nevertheless, work on the next stable release is well underway and some developers are already trying to mend the community and soothe the wounds.
This discussion has been archived. No new comments can be posted.

Debian Votes Against Mandating Non-systemd Compatibility

Comments Filter:
  • by Anonymous Coward on Wednesday November 19, 2014 @09:32AM (#48416729)

    Go back 5 years and imagine yourself trying to explain systemd to all the Linux developers. One massive program running at PID 0 doing 100 different jobs from startup scripts to DNS resolution complete with binary log files and a completely different (but the same) set of tools o manage them (grep less awk tail). You would be laughed at and run out of town. Nobody would ever take you seriously again.

    Can't wait for all of /etc to disappear and be merged into a single binary file like the Windows registry. I first ran into this nonsense when playing with a BeagleBone Black board. Go ahead and see if you can figure out how to change the ip address. In case you can't here is how you do it:

    http://derekmolloy.ie/set-ip-address-to-be-static-on-the-beaglebone-black/

    Tell me why any of that is necessary? It's exactly like how Windows manages network interfaces.

    • by ledow ( 319597 ) on Wednesday November 19, 2014 @09:36AM (#48416757) Homepage

      Agreed. I don't get systemd. If people want to use it, fine. But, like Windows 8 taught Microsoft, giving people a one-click way of going back to the old-and-tested interface is always a) possible and b) sensible.

      If systemd was really that good, I wouldn't need it foisted upon me forcibly, I'd be voluntarily choosing it rather than the default init on every distro I boot.

      I think worse than pushing it on your users is this - saying you won't support the old way of doing for those that don't want to change.

      All we need is one remote-root in systemd and people might start to think again.

      • I think the way forward will be a lot of systemd forks that strip away functionality, and implement other functionality. That which will bring about the need for a common, standardized interface. And then, choice in init systems will be an option again (but timezoned, hostnamed, logind will be required).

        • Re: (Score:3, Insightful)

          by Anonymous Coward
          The sane choice is migrating to FreeBSD
          • by Anrego ( 830717 ) *

            How practical is this for the desktop?

            This is actually a serious question. I'm not overly familiar with BSD but have been thinking about giving it a shot on the desktop. I've been a Gentoo user for many years and am reasonably comfortable diving into stuff, so I don't anticipate user friendliness being a show stopper, more likely something I can currently do on Linux won't be available or will have poor support in BSD.

            The main things I'm concerned with are Minecraft/FTB, mplayer, flash, VirtualBox, OpenRA,

            • by unixisc ( 2429386 ) on Wednesday November 19, 2014 @06:35PM (#48421625)

              How practical is this for the desktop?

              This is actually a serious question. I'm not overly familiar with BSD but have been thinking about giving it a shot on the desktop. I've been a Gentoo user for many years and am reasonably comfortable diving into stuff, so I don't anticipate user friendliness being a show stopper, more likely something I can currently do on Linux won't be available or will have poor support in BSD.

              The main things I'm concerned with are Minecraft/FTB, mplayer, flash, VirtualBox, OpenRA, and jack/rakarrack. I'm open to alternatives as long as they actually work.

              Flash I could probably live without, but much as I hate it, browsing the web sans-flash does still pose the occasional problem. jack/rakarrack I could also probably live without. I currently use my desktop as a quick-n-dirty guitar amp/effects stack. OpenRA is the thing I anticipate having the most problems with, but I play it somewhat obsessively so very much desired.

              At some point I'll probably just try it and see, but I'm curious if any other slashdotter has gone this route and has anything interesting to say about it.

              I installed PC-BSD after a couple of weeks w/ Windows 8, & by & large, it's been good, for the things I do. Unfortunately, my Wi-Fi wasn't recognized, so I have to run an ethernet cable to my laptop. Other than that, the experience was generally okay, but could have been better.

              The first time I tried installing it, it took a few guesses for me to go into BIOS, disable UEFI (at that time, I was installing 9; now, under 10.1, UEFI is supposedly supported, if you're installing from scratch), and then go into install. I had a few hiccups in getting the system not to go into a loop while installing, but once I got around it, the installation was a breeze - except of course, for the non-support of the Centrino

              Once I logged into the first account created, I had some glitches in creating more user accounts from the GUI - had to do an adduser from the CLI (that bug has since been fixed, since more recently, I can). I created different accounts for different roles - one primary one to do all my day to day work like banking, making payments to various cards, personal emails, et al. And others for different things that I do, such as job exploring, or posting to /. here. Each of them, I try different DEs, such as Lumina, LXDE, KDE and GNOME.

              This week, I upgraded the system to 10.1, and a lot of the bugs I had went away. I still haven't enabled UEFI, since that would require backing up all the data and then doing a fresh install, and there is no single utility in PC-BSD to do all that, and this is not a hot issue w/ me. So, right now, I'm happy w/ my system.

              On the things you were asking, there is Virtual Box, but I haven't tried the other things. For sound players, there is VLC and a whole host of other such utilities. Talking about Flash, I've installed it in FireFox, but not in Chromium (Chrome itself is not there in FreeBSD). But I have no issues watching YouTube videos, if that's what your need for Flash is, w/o Flash and under Chromium, in HTML5. Not tried Minecraft, for me, the favorite game is FreeCiv.

              One thing that PC-BSD does great is integrating things, so that any utility will work in any DE. For instance, GTK apps work great under Qt based environments like KDE, Lumina and LXDE, while Qt apps like Calligra work great under GNOME 3.14. One thing - the PC-BSD control panel is quite advanced, and does a better job of system management than trying to edit files in /etc. I tried that last week when I had to replace a router and change the default gateway address - it refused to save my changes to /etc/resolv.conf, but when I went into PC-BSD control panel's network and changed it there, it worked like a charm.

              As usual, YMMV

        • by jbolden ( 176878 )

          Stripping away functionality is going to be hard to do. For example if standard hostnamed is not going to able to support all the features of the systemd version. Which means either:

          a) System admins are going to be directly exposed to complex use case reverse engineering when they can or cannot use the less powerful daemon
          b) The daemons are going to need to keep up with systemd's feature set and interfaces which means for all practical purposes being part of systemd.

      • by jbolden ( 176878 )

        If systemd was really that good, I wouldn't need it foisted upon me forcibly, I'd be voluntarily choosing it rather than the default init on every distro I boot.
         

        There are long term non-systemd distributions. Crux and Alpine for example. The mainstream distributions are having it foisted on them by upstream because open source developers do think it is that good. This isn't about system admins.

        • This isn't about system admins.

          Of course not, that would suggest that the primary users actually have influence on the development process. It's just unthinkable.

        • by arth1 ( 260657 ) on Wednesday November 19, 2014 @12:37PM (#48418283) Homepage Journal

          There are long term non-systemd distributions. Crux and Alpine for example. The mainstream distributions are having it foisted on them by upstream because open source developers do think it is that good. This isn't about system admins.

          The sysadmins are the meal ticket of developers. For years now, we've been saying we don't want systemd unless it can be made compatible and standalone. Now Red Hat calls me and wonders why I choose to install RHEL 6 on new systems, given that RHEL 7 is out. Why? Because we told you in advance what we wanted, and you chose not to listen.

          Sysadmins are in a position to choose their operating systems. The developers are not in a position to choose their customers.

          • by jbolden ( 176878 )

            RedHat has clearly picked their direction with IaaS and PaaS. Just as they moved from desktop to server they are moving from small server deployment to large server deployment, moving up market. Mostly I suspect traditionalist sysadmins were running CentOS anyway.

          • My platform, and the 130 developers that code for it, are moving to Slackware when Jessie comes out. Fuck'em.

          • I'm interested in the next year of quarterly earnings reports. If sysadmins successfully communicate that they would rather not purchase support for systemd distros, then the market has spoken.

            A thousand angry nerds on the internet mean little compared with one lost contract.

            The financial impact will be slow to show, and the response will probably be immediate, but again slow to slow. Then things should move rather quickly.

            Whether there are responsible people in the role as CTO of large businesses will so

    • by Trepidity ( 597 ) <`delirium-slashdot' `at' `hackish.org'> on Wednesday November 19, 2014 @09:40AM (#48416781)

      I don't see why your BeagleBone black example is systemd's fault. It has a convoluted way of managing network interfaces because it uses connman [01.org], a network-management daemon from Intel that is not part of systemd.

      • I don't think he is saying that it is Systemd's fault. He is using it as an example of what he expects Systemd to become.

        • by MrHanky ( 141717 ) on Wednesday November 19, 2014 @10:29AM (#48417079) Homepage Journal

          And that's why no criticism of systemd is to be taken seriously: it's always about how terrible it will become in the future, never about actual problems it might have today.

          • by sjames ( 1099 ) on Wednesday November 19, 2014 @10:41AM (#48417177) Homepage Journal

            Don't worry, there will be plenty of those. Here's one:

            I am testing Jessie with systemd and find that systemd absolutely refuses to mount a btrfs filesystem in degraded mode even though I explicitly set the option in fstab.

            Can anyone tell me how to either force it to at least attempt mounting or to have it leave fstab alone and call my script to do the mounting?

            No, dropping to an emergency shell so I can mount it manually over IPMI is not an acceptable alternative.

            • My favorite was when I apt-get upgraded my (headless) machine, which would then refuse to boot. No SSH access, just an emergency shell (very annoying for a headless machine). The problem? I didn't have my external USB hard disk -- which had an /etc/fstab entry -- plugged in.
          • There have been plenty of those: legitimate, technical complaints about design flaws, suitability, and downright broken shit. Yet, somehow, that all seems to fall under the "Lul Change-hating luddite uniz nekbeard" response. So I really don't think we can take any proponents of systemd seriously, either.

            Since Debian's not going to protect me from this svchost-cum-kitchen-sink abortion after all, looks like we're going to FreeBSD!

            • Since Debian's not going to protect me from this svchost-cum-kitchen-sink abortion after all, looks like we're going to FreeBSD!

              See how that works? Then you'll be able to feel as superior about your OS to other linux distros, as you do about Windows.

          • Systemd pain now (Score:3, Informative)

            by ansak ( 80421 )
            I'm running arch. Arch moved to systemd before I understood the issues at stake. I feel the systemd pain every day. I'm trying to get multi-head with nouveau working (a different set of pain, that I'll probably just switch to nvidia blobs to get around -- unless someone can point me where I want to be -- but I digress)

            ...and I don't understand why "systemctl isolate multi-user.target" vs. "systemctl isolate graphical.target" [try explaining THAT pair of command lines to start with] can't be expected to b
      • I'm not sure if there if Angstrom ships with a better network manager, but Arch Linux Arm on the Beaglebone uses the netctl [archlinux.org] by default, which makes this process quite simple. Just copy and edit the ethernet-static config and systemctl start netctl@enp2s0.

        CONNECTION='ethernet'
        INTERFACE='enp2s0'
        IP='static'
        ADDR='192.168.0.200'
        GATEWAY='192.168.0.1'
        DNS=('192.168.0.1')

      • in the old days if you wanted to set your DNS servers on Linux you edit /etc/resolv.conf and change them.. Done. no reboot or ifdown/ifup necessary. Nowadays? on Debian and Ubuntu at least with the resolvconf package you have to edit /etc/network/interfaces then ifdown/ifup your interface and if the interface is the only one and you are connnected via ssh you are screwed. or you have to reboot the server to get the changes to take effect. Or you have to type a fucking convoluted command eg:

        echo "namese

    • by arth1 ( 260657 ) on Wednesday November 19, 2014 @09:43AM (#48416789) Homepage Journal

      Tell me why any of that is necessary? It's exactly like how Windows manages network interfaces.

      Don't worry - systemd will handle that for you, and bring your interfaces up whether you want them up or not, using hundreds of sensible MSDOS .ini files. And if you run into problems, you can always check the systemd-journald binary logs through a suitable systemd secret decoder program. Unless, of course, the system went down before the non-transactional logging went to disk.

    • by Anonymous Coward on Wednesday November 19, 2014 @09:45AM (#48416799)

      One massive program running at PID 0

      I don't know what trolling with massively inaccurate information gets you. It's not a massive program, it's a collection of small daemons implementing basic OS services needed by modern desktop and server deployments, one of which is PID 1.

    • by Anonymous Coward

      You are aware that most of the systemd daemons do NOT run on PID 1 (and none of them on PID 0), right?

      • Re: (Score:3, Interesting)

        by Anonymous Coward
        It is expected. Most systemd whiners have not explored systemd. They don't know how it works nor have they administered it. If they would have done that, they would have found that systemd is just fine. Actually systemd is much more professional than sysvinit and the hacky collection of hobbyist scripts surrounding it.
    • Re: (Score:3, Informative)

      by Anonymous Coward

      To be fair, you'd be laughed out of town for saying that today, too, partly because the init daemon runs at PID 1 (not zero), and partly because not all of the systemd daemons run at PID 1. There are quite a few of them and only the first has PID 1. If you'd like to learn more about systemd, or at least mask your obvious unfamiliarity with init systems, you may want to start with Wikipedia [wikipedia.org].

    • by jbolden ( 176878 ) on Wednesday November 19, 2014 @10:21AM (#48417033) Homepage

      Go back 5 years and imagine yourself trying to explain systemd to all the Linux developers. One massive program running at PID 0 doing 100 different jobs from startup scripts to DNS resolution complete with binary log files and a completely different (but the same) set of tools o manage them (grep less awk tail). You would be laughed at and run out of town. Nobody would ever take you seriously again.

      BS. During the early 2000s the discussion of complex scheduling like existed in Solaris came up again and again. There was general agreement that while Linux was fine for simple Linux servers and workstations that the lack of advanced features made it unsuitable to replace big box Unix. Linux induced a financial collapse in big box Unixes now it needs to replace their complexity and functionality.

      • by arth1 ( 260657 )

        BS. During the early 2000s the discussion of complex scheduling like existed in Solaris came up again and again. There was general agreement that while Linux was fine for simple Linux servers and workstations that the lack of advanced features made it unsuitable to replace big box Unix. Linux induced a financial collapse in big box Unixes now it needs to replace their complexity and functionality.

        What you say doesn't hang on a pitchfork.
        If the big commercial unix versions (Solaris, AIX, HPUX, IRIX) failed due to their complexity, the solution for the winner, Linux, is not to increase complexity. It's because of the toolbox approach where you can always upgrade one component without touching others that Linux won. Going back to smit-like administration abstracted five ways from hell and with tentacles into everything and its godmother isn't going to make people flock to Linux.

        Splitting sysv init in

    • You have that absolutely correct! One of the prime motivators for me to move away from Windows and into say Ubuntu was the fact that Ubuntu which is based on Debian had extreme flexibility that the Windows systems lack.

      Case in point, Dell's NetExtender software - on Windows it won't let me connect to a VPN because the cert is self signed. On Ubuntu the NetExtender client presents a dialog to the effect that, and I'm paraphrasing "The cert is self signed, do you want to continue?" the first few times and
    • by the_B0fh ( 208483 ) on Wednesday November 19, 2014 @11:43AM (#48417733) Homepage

      Soon, all linux distros will contain 3 files: /boot/image-blah /vmlinuz /sbin/systemd

      You won't need anything else!

    • Go back 5 years and imagine yourself trying to explain systemd to all the Linux developers.

      That depends on how you do it. If you were to use the massive disinformation campaign you're perpetuating, and those who know better didn't speak up, then systemd would die on the vine. However, if you accurately describe what systemd does, then Linux would be five years ahead of where it is now.

      Having actually read what systemd does, I'm looking forward to seeing it on my machines. It seems to solve several important problems, and seems to be well architected.

      So far, every argument against systemd I've

  • by TheReaperD ( 937405 ) on Wednesday November 19, 2014 @09:34AM (#48416741)

    This is the same community that you can still start a street fight, or at least a troll war, by asking "Which is better: emacs or vi?" I'm not sure they're ever going to get over this. But, like the above question, the world will move on and leave them behind.

    • And the street fight always ends with a dozen more forks. ;-)

    • by morgauxo ( 974071 ) on Wednesday November 19, 2014 @10:01AM (#48416885)

      Yes, you are right. It is always better to not fight. If something inferior is becoming the new standard then oh well. It is better to just let it happen than to show the outside world an ounce of disagreement. As soon as a community does that they might get some internet person posting snarky comments about leaving them behind. The horror!

    • by jbolden ( 176878 )

      , or at least a troll war, by asking "Which is better: emacs or vi?

      Funny enough... after 2 decades of hearing that argument.. I don't hear anyone care anymore. They both have found niches and GUI oriented IDEs have mostly replaced both as developer's day to day choices. This one was finally settled by going from 2 main options to 50 options.

    • Yes, there are emacs/vi fights, but in truth these are in fun. There is not a single vi user who would say that they should build a distribution where emacs did not work. There is not a single emacs user who would say it is OK to build a distribution where vi did not work. Everyone in this community would really say, even though you may be stupid for making your choice, our distribution should work under whichever you choose.
      This General Resolution was about making certain that the distribution still wor

  • Kum-ba-yah (Score:4, Insightful)

    by arth1 ( 260657 ) on Wednesday November 19, 2014 @09:35AM (#48416749) Homepage Journal

    some developers are already trying to mend the community and soothe the wounds.

    I'm not sure that giving people warm fuzzies should take priority over steering the ship in a direction that has proven successful for more than a generation, and which has allowed diversity to flourish.

  • Insight (Score:4, Informative)

    by think_nix ( 1467471 ) on Wednesday November 19, 2014 @09:37AM (#48416763)
    more insightfult news and posts from lwn. Regarding burnout and voicing concerns over systemd. lwn.net [lwn.net] lwn.net [lwn.net]
  • It's a bit more of a meta-outcome. The option that won the vote said, more or less: the General Resolution (GR) process in Debian is not the right way to resolve this dispute.

    There was a proposed option which would actually have explicitly said: packages are not required to maintain non-systemd compatibility. But that option did not win.

  • by nimbius ( 983462 ) on Wednesday November 19, 2014 @09:39AM (#48416773) Homepage
    Im not sure who at debian proposed this idea, that packagers be required to maintain support for non-systemd applications, but its untenable at best. It would mean a redesign of gnome, KDE, and a dearth of other code that in many cases makes no sense (how does networkManager get this treatment outside the scope of systemd?) this particular vote also smacks of an attempt at debian character assassination. the fact is that Debian, and Ubuntu, need to sit down and recognize is that open source software means If i, or users, want rc-init support in Debian for a package we can code it.. If the package doesnt do what we want we can either commit, fork, change packages, or change operating systems. Bureaucratic red tape seems to be an Ubuntu specialty thats strong-armed its way into debian from the start of Systemd. pointless electoral procedures avoid the cusp of the communities argument. SystemD is controversial enough that Debian should give the user the choice to decide whether they want systemd.
    • SystemD is controversial enough that Debian should give the user the choice to decide whether they want systemd.

      This is exactly what some other distros are doing, gentoo for e.g. Leaving parallel openrc with eudev as base or one can move onto a systemd implementation. Recent install handbook reflects both methods. Why can't Debian do something similar ? Manpower purposes? Too much of a split or too confusing for the user base ? I fail to understand the reasoning for choice as well.

      • I haven't used some of the distros you listed but, I know distros such as gentoo are a build your own linux kit wheres Redhat and Ubuntu are intended to "work out of the box" with Debian somewhere in the middle. That makes a major difference in how the maintainers set things up and what level of alternatives they wish to supply. Each method has their advantages which is why each type exists. Most 3rd party products for linux prefer the Redhat and Ubuntu approach because they have a much better idea of w

      • by bill_mcgonigle ( 4333 ) * on Wednesday November 19, 2014 @10:45AM (#48417207) Homepage Journal

        I fail to understand the reasoning for choice as well.

        I think I get this.

        One example: I have a handful of shell and perl scripts that I use to manage virtual machine interdependencies at startup time - this vm needs to be listening on this port before I can think about starting this other vm, etc. and I express that in a JSON tree for configuration.

        I've recently been noticing that the dependency "engine" is a bit buggy and also duplicates much of what systemd already provides (pre-dating it by some years), so I'm going to look at making it work with systemd instead and cutting out a bunch of the code. That also gets me pretty easy dependency tracking on various filesystem mounts, network status, etc., so it could be better than 'sleep 20' in some spots.

        Now, if I wanted to offer that up to the community, somebody could choose to package that into Debian. Assuming my experiment works, systemd would be a hard requirement to use this particular system.

        Somebody in the Debian community proposed that for this package to be accepted I would also have to [re]write another dependency engine and support that. I can't see doing that if the systemd approach works.

        Does it make sense that people who don't want to run systemd (which is fine) also can't impose additional work on developers who do want to use systemd?

    • by morgauxo ( 974071 ) on Wednesday November 19, 2014 @10:13AM (#48416977)

      Why do KDE and Gnome require Systemd as designed? Can someone explain that to me? I really don't get it. They are Desktop managers. They put decorations on windows and shortcuts plus widgets on the desktop. Systemd is an init replacement. It manages the starting of daemons. What the h377 does one have to do with the other? I think Systemd is not the only bloated, over-reaching project if this is a problem.

      • by Anonymous Coward on Wednesday November 19, 2014 @10:49AM (#48417247)

        They want a process to handle things like shutdown, reboot and hibernate via a UI dialog. Previously, Consolekit was that process. But Consolekit was scuttled in favor of Logind. And Logind is dependent on Systemd running as pid1.

        Btw, the guy that had the reins of Consolekit at the time of its closure was Poettering...

      • by fnj ( 64210 )

        For one thing, they are using systemd to query and make changes to the system config, since they have GUIs that need to do this. IMO they should be written to fall back to the old way of doing this directly if systemd is not present, but the tradeoff is extra programming and maintenance work.

      • They could just call /sbin/shutdown. I used KDE for years BEFORE there was such a thing as consolekit and it worked this way just fine!

  • by popoutman ( 189497 ) * on Wednesday November 19, 2014 @09:56AM (#48416843) Journal
    My feelings on this matter? :(
    I intensely dislike systemd and all of its methodology - it's not the Unix way, and I really dislike the systemd developer's attitudes towards bugfixes and other problems with their processes. Systemd is a solution looking for a problem.
    As an admin in a company with something like 50,000 *nix machines, of which I have root on about 10,000 of them, systemd will not be making an appearance on any of these systems and the vendors have been appraised of this fact. Any vendor that cannot provide an alternative to systemd will not be in the running for the next phase of server rebuilds.
    Personally, I think I'll be migrating all my own personal servers and the servers of my University's computer society to something a lot more useful and not requiring systemd to boot. Going to be a fun time.
  • As the tentacles of systemd reach out and penetrate more areas of the system, more applications will inevitably require systemd which means that a Linux installation without systemd will only be able to run a small subset of Linux apps. Even though there are alternatives currently in the works for the init portion of systemd, applications are beginning to depend on the tightly-coupled processes that systemd requires which means that the only viable replacement for the entirety of systemd is another impleme
    • From what I gather, it's not *that* bad - most apps depending on systemd do so for the cgroups support. If one could extract the cgroups functionality into a separate library and get projects to use that instead, the need for systemd would be a lot less.

      Systemd is eating up everything low-level though. Before systemd, a Linux system would look like this:

      Kernel -> (collection of init/syslog/pam/udev/whatever) -> Bash -> GUI

      Now it's

      Kernel -> systemd -> Bash -> GUI

      And to be quite honest, I'm

      • From what I gather, it's not *that* bad - most apps depending on systemd do so for the cgroups support.

        That's the case now but soon desktop environments will start using logind and applications may start using journald. As systemd continues to offer more tightly-coupled modules, applications will likely start relying more on these modules until the point that systemd will likely be a requirement for almost all applications and desktop environments.

    • As the tentacles of systemd reach out and penetrate more areas of the system, more applications will inevitably require systemd which means that a Linux installation without systemd will only be able to run a small subset of Linux apps. Even though there are alternatives currently in the works for the init portion of systemd, applications are beginning to depend on the tightly-coupled processes that systemd requires which means that the only viable replacement for the entirety of systemd is another implementation of tightly-coupled procs which defeats the purpose of writing an alternative in the first place.

      This isn't how it should have to be.

      One of the major faults with init scripts was that when you had inter-dependent systems you had to modify scripts to allow for the mandatory and optional pre-requisite processes and resources. What systemd could have been was an Inversion of Control framework where the initscripts morphed into wireable components so that the system administrator could define whatever network of dependencies he/she required.

      Instead, the components are limited in functions compared to init

    • You can use a different architecture for replacement components, it shouldn't be the same thing
  • by CFBMoo1 ( 157453 ) on Wednesday November 19, 2014 @10:17AM (#48417007) Homepage

    That SystemD is bad for Linux not because of the technical merits but the political BS drama it's spawning. Technical wise I can see why server admins want to have the fine grain control of their start up through individual scripts. It makes sense to me even though I don't do administration. KISS is the order of the day and flat text files beat out binaries any day. Now for desktops SystemD seems fine to me for people who run out of the box systems.

    Honestly the whole thing sounds to be a fix that works better for some things but is getting shoved in to other areas where it isn't needed, wanted, and maybe even detrimental to the operation of other systems. Kinda like when Ubuntu/Gnome went with more touchy modern interfaces on desktops when really it was tablets and phones their interfaces made the most positive impact while negatively effecting others on the desktop.

    I think it's time for some people to get over the one size fits all mentality in the Linux community. Obviously other people have problems with it and it's going to end up tearing you apart in the long run while scaring off others who sit on the sides playing with the toys you folks made up to this point. That's going to leave companies like Microsoft grinning like a Cheshire Cat.

  • Systemd appears to me like the Dolphin of init. Dolphin had the clear mission: To be simple to use. They were willing to ditch the superiour Konqueror for it. OK, if for them one mission statement weighs enough to justify that, go right ahead. I think I'd still prefer Konqueror allthough I couldn't say if I'd be bothered to install it if presented with Dolphin as a default. Same with Systemd vs. init.

    I personally am not sure if this thing turns out well. It all comes down to how good the systemd camp is at

  • I expect things to happen just like GNOME3:
    STEP 1: Big change, didn't really think that one out...
    STEP 2: Community outrage, people whining, people migrating away
    STEP 3: Some development versions away, things actually starts to work, requested features are being added
    STEP 4: We get to a pretty nice project in itself, it has identity, it has what was intended, it has far less users (ungrateful bastards!!!)
    PROFIT?
    Should we get involved into the design of systemd and make it take on our own problems I'm
  • IMHO it was good that it ended up with the outcome it did. You'll notice that the option "we should not have a GR about this" won. What it means is that Debian elected NOT to try to force any particular solution through, but let things settle themselves through consensus decisions by individual package maintainers.

    If enough people care about sysvinit, it will survive and thrive - if not, it will die in Debian, just like other things that have been abandoned. Whether project X is your pet project or not, thi

"Irrigation of the land with sewater desalinated by fusion power is ancient. It's called 'rain'." -- Michael McClary, in alt.fusion

Working...