Slashdot Mirror

← Back to Stories (view on slashdot.org)

Fork of Systemd Leads To Lightweight Uselessd

Posted by timothy on from the not-big-and-fancy dept.

An anonymous reader writes A boycott of systemd and other backlash around systemd's feature-creep has led to the creation of Uselessd, a new init daemon. Uselessd is a fork of systemd 208 that strips away functionality considered irrelevant to an init system like the systemd journal and udev. Uselessd also adds in functionality not accepted in upstream systemd like support for alternative C libraries (namely uClibc and musl) and it's even being ported to BSD.

12 of 469 comments (clear)

  1. kill -1 by Spazmania · · Score: 5, Insightful

    If it still doesn't adequately support the "kill -1" functionality of initd (which kills and resets all processes init manages, especially the getty processes on the terminals), I still don't want it.

    --
    Moderating "-1, Disagree" is simple censorship. Have the guts to post your opinion.
    1. Re:kill -1 by arth1 · · Score: 5, Insightful

      The compatibility is a main reason. Being able to run and configure all startup/shutdown processes independently of the overseer is nice. As a sysadmin, I get to do easy manual corrections, additions and deletions without giving init a thought.
      i don't have to use the "service" command, and I spend far less time when seting up a new server or adding a service.

      i don't give a crap whether the system boots twice as fast - reboots are years between, and in scheduled windows. I want something that lets me admin my systems without relying on anything more than a dumb terminal - and if need be, not even that.

    2. Re:kill -1 by Anonymous Coward · · Score: 5, Interesting

      you just can't work out how much is complete FUD and whats a genuine gripe

      Once upon a time I used to carefully go over all aspects of my system, and compile custom kernels, fine-tune startup, etc. I haven't bothered in the last decade or so when things work out of the box and I want to concentrate on what I am using the computer for instead of polishing the backend. That said, I've been following some of the systemd news, and responses to it seem to be a real mess and a huge amount of complaints that end up just being strawmen (probably not intentionally). There are legit idealogical complaints I can appreciate, but the vast majority of specific, detailed complaints I come across I later find out are just false. Too many complaints saying "It can't use X" or "It forces you to use Y", when it turns out there is a simple option to change to use X or not use Y... or in many cases where it flat out doesn't do Y or already uses X by default. It makes it rather difficult to take complaints seriously, talking about the "*nix way," when I thought RTFM used to be part of the *nix way.

  2. Finally someone decides to do something by Skarjak · · Score: 5, Insightful

    That's how the free open source community works. If you don't like something, it's pointless to just spend a lot of time bitching about it (like many linux users have done about systemd). Just go out and make your own version. Everyone who's been complaining about systemd better contribute to this thing.

    1. Re:Finally someone decides to do something by Anonymous Coward · · Score: 5, Insightful

      Actually, that's a bad idea. They should go an support another init project that's already underway, like OpenRC. This is just protest software by a single guy.

    2. Re:Finally someone decides to do something by DeHackEd · · Score: 5, Interesting

      Ordinarily I would agree, but systemd's "MCP-like" behaviour (TRON reference, I honestly believe that's a valid simile) means that uselessd has a chance of being a replacement for systemd packages of existing distributions. If I can put this in place of systemd on centos7 and have it boot in an unprivileged container (currnetly impossible with stock) then that's a win in my book.

      You can't just switch systemd for openrc in an existing distribution without some major resistance. Believe me, I wish it could or I would just install openrc or upstart. That's the problem - systemd is claiming distributions and the list of alternatives is unnervingly small.

    3. Re:Finally someone decides to do something by Anrego · · Score: 5, Interesting

      Not just that, but running a non-systemd system even if you use a distro that uses openrc by default is becoming more of a pain as more and more packages hook into it. As a Gentoo user who is trying to hold off for just a little while longer I've found myself doing a lot of package shuffling and using the package blacklist for the first time in the almost decade I've been a gentoo user.

    4. Re:Finally someone decides to do something by chihowa · · Score: 5, Interesting

      I agree and am happy to see this fork. As unpopular as it may make me, I actually like the initd functionality of systemd. I'm fine with using and writing the old init scripts, but systemd unit files are simple, concise, and powerful enough for my needs.

      On the other hand, I find the kitchen-sink feature creep of systemd absolutely repulsive. Cramming all of that functionality into PID 1 as a unwieldy monolith seems like such a deeply flawed exercise. Uselessd seems like a perfect replacement for systemd: all of the benefits and none/less of the cruft.

      --
      If you want a vision of the future, imagine a youtube comments section scrolling - forever.
  3. Re:udev by caseih · · Score: 5, Informative

    FUD again. The udev module of systemd does not run under PID=1! Please take a look at how systemd is organized before you post something like this.

    $ ps axf | grep systemd | grep -v grep
        1 ? Ss 0:47 /usr/lib/systemd/systemd --system --deserialize 16
      247 ? Ss 2:48 /usr/lib/systemd/systemd-journald
      603 ? Ss 2:20 /bin/dbus-daemon --system --address=systemd: --nofork --nopidfile --systemd-activation
    19211 ? Ss 0:00 /usr/lib/systemd/systemd-udevd
    19260 ? Ss 0:18 /usr/lib/systemd/systemd-logind

    systemd encompasses many things that used to be separate, but that doesn't mean they all run in the same process. Functionality is still kept modular, and you can update systemd without requiring a reboot most of the time. systemctl --daemon-reexec will reload the updated modules.

    I'm not a fan of *ctl commands (hard to type, they don't roll off the fingers), but they are okay.

  4. Re:With a name like "use-less-d" by fidelleon · · Score: 5, Interesting

    I thought it would be serious until I visited uselessd' site (http://uselessd.darknedgy.net) and saw such gem: "This has meant eradicating plenty of GNUisms" and GNUisms being a link to... USA's Communist Party (no, seriously: http://www.cpusa.org/).

  5. Re:Not a boycott but a confirmation by dskoll · · Score: 5, Insightful

    systemd does have some very good ideas when it comes to the init system. Socket-based activation and process supervision are Very Good Things.

    But when the systemd developers started trying to embrace, extend and extinguish other things like syslog, core dumps, etc. then systemd jumped the shark.

  6. Re:Err... by ThePhilips · · Score: 5, Interesting

    Yes. No. Wait - yes. No... no. Uh....

    The systemd has modular design.

    But monolithic architecture.

    Literally everything inside systemd is intertwined using the D-Bus.

    So yes, a crash of one of the systemd daemons might cause deadlock/hang or even crash of the rest of the systemd, and consequently affect the processes running under it.

    The systemd's design is pretty bad. This is not an exaggeration, when people call it Windows-like: MSWindows OS has very very similar atructure as the systemd. Windows "Event Log" is really cherry topping.

    On-topic: uselessd doesn't fix this problem. It lessens it, but doesn't fix it.

    --
    All hope abandon ye who enter here.