
Uselessd - muyuu
http://uselessd.darknedgy.net
======
pgl
This is such an excellent example of how to actually approach what you don't
like about another project. It also has the potential of actually being really
useful (despite the name): there are lots of _good_ bits in systemd which are
out of reach for people who disagree with so much else in it.

I really hope this takes off.

------
joelberman
I do not want to spend the time to learn new things unless they are directly
related to my work. So systemd was a PITA for me, but now I am fine with it
(BTW, I have used UNIX since the late 60's so have seen a lot). This project
looks great, but I do not have the energy to care, I will just deal with
whatever comes with my distro. By the way, pick a better name. I suspect many
OSS and home grown projects fail for the simple reason that the name, while
clever, makes people either think the project is a joke, or some geeky thing,
or unprofessional. Either pick an obvious descriptive name, or be prepared to
spend a boatload of money building name recognition.

~~~
uselessdguy
The name is perfect and I do not see myself changing it. The fact that so many
people misunderstand makes it better. The Linux Action Show thought we were
calling systemd "useless" and went on a hilarious rant, there's people on
LinuxQuestions.org who _really_ insist that it's pronounced "use _less_ dee"
(I call it "uselessdee", as in it's of no use, personally).

~~~
brazzy
So basically you're doing all this for the lulz of confusing and pissing off
people and don't really want anyone to actually _use_ the software?

~~~
nknighthb
An existing alternative to systemd is called upstart. Three of the most
popular VCSs are called git, mercurial, and subversion. A major open-source
image manipulation program is known as The GIMP. A popular email client among
a certain crowd is mutt. less is more, we snort our networks, and manage our
VMs with a vagrant. We compile our mission-critical code with a gnat, use
browsers written by organizations named after radioactive lizards and an
infant noise, write menu-driven applications with curses, and Uglify our
JavaScript.

And you're worried about somebody calling their own project "uselessd"?

------
silon3
"like" (it happened to me)

No journald. Consequently, this also means no libqrencode and libmicrohttpd
integration, nor hooking coredumps to the journal. The default log target for
auxiliaries is now LOG_TARGET_SYSLOG_OR_KMSG.

The main case against binary logs is their corruptibility. This happens more
often than you’d think, due to not having any transaction consistency, as an
RDBMS would. The advice of the systemd developers on handling this? Ignore it.

~~~
Uberphallus
Not related to all binary logging, but journalctl is incredibly sluggish.

Some combinations of slow (rotating) media, certain filesystems, and
underpowered CPUs (ARM in my experience) and you get a barely usable logging
system that makes you want to punch your box.

~~~
rakoo
I don't even have an esoteric setup and every time I want to read logs I'll
have to wait 30 secs. Even though there is absolutely no activity.

~~~
toupeira
Try "journalctl -e" or "journalctl --since today", it seems like by default it
will load _all_ available logs which leads to this slugishness.

~~~
perlpimp
it is slow because log is read written in a block binary format but pager
accepts byte granular fseek feature to go forward without loading everything
into $PAGER's buffers.

------
JoshTriplett
Because systemd was entirely too consistent across environments, so it needed
some inconsistency introduced.

The documentation reminds me a lot of Emacs's "ANTINEWS", listing all the
functionality you lose by downgrading to the previous version of Emacs. Except
in this case, it's actually a "NEWS" file, showing all the functionality you
lose by downgrading from systemd to uselessd.

> Certain superfluous unit types removed, namely devices, timers, swaps,
> mounts and automounts.

So under uselessd a service or socket file cannot depend on the presence of
certain mounts, for instance (RequiresMountsFor=). Nor can a service run
maintenance tasks periodically with supervision on the maintenance task, and
with all the privilege-dropping, isolation, and security features easily
accomplished with a systemd service. (And even if a cron implementation
implemented such features, they'd work gratuitously differently from systemd
services.) Nor can the availability of a device trigger the reliable,
monitored launch of a service with all those same systemd features.

> Setup routines for various MAC/ACL systems, including SMACK, IMA and
> SELinux, are gone. We want to stick to a more clearly defined purpose, one
> that is agnostic of such elements. Nonetheless, we have retained SELinux
> access routines in D-Bus APIs and unit options for SMACK attributes in
> socket unit files to respect existing configurations.

So anyone who actually wants to use such security systems is screwed, then.
Good thing Linux isn't about choice.

> systemd-fsck has been replaced with a service file that starts /sbin/fsck to
> fsck devices. In essence, this isn’t much different from what systemd-fsck
> already did, but with the overhead of a middle man executable interfacing
> with /sbin/fsck cut out. This also means that the systemd-defined sysctl
> parameters for its fsck are gone, and you should use the old ones
> (/forcefsck, etc.) instead.

So now, in order to force a check of a filesystem on reboot, you must write to
that filesystem, potentially doing further damage to it.

~~~
uselessdguy
ANTINEWS is the best kind of NEWS. And you don't just lose things, come on.
Our recent support for running a system instance of systemd/uselessd without
taking over init (as early and rudimentary as it still may be) is a good
thing. Cross-libc is another. A couple of things from main.c were refactored
into independent tools.

This is still a giant WIP and it's quite experimental. We make this perfectly
clear in the wiki that it's not ready for system integration or daily use, and
there's still a long way to go (including some more radical ideas) before we
ever think of making a stable release.

uselessd is about sticking to processes. Did we not make that clear? If you
want a dedicated supervisor, you can use something _explicitly designed_ for
such a purpose, like monit or supervisord, instead of using systemd's mixed
functionality. Device activation can still be accomplished through (e)udev.
We're device node manager-agnostic. We made this clear.

No, you're not screwed. I think you completely ignored the fact that we intend
on being _portable_. This is still early, again, but nonetheless we do compile
on FreeBSD and Debian GNU/Hurd and some of the tools (like systemd-delta)
actually run properly.

To be honest, we haven't tested the systemd-fsck unit. We mostly removed the
binary due to being something that used libudev and looked like it belonged to
a shell script more than anything. You can still force fscks through other
means (tune2fs for ext2/3/4, etc.) We'll be sorting this out.

It sounds like this project offends your personal ideological sensibilities,
as you totally misunderstand its purpose and fail to realize it's a WIP and
unstable.

By the way, I liked the jab about choice. I wish we all voted for the same
political party, too.

~~~
vidarh
> If you want a dedicated supervisor, you can use something explicitly
> designed for such a purpose, like monit or supervisord, instead of using
> systemd's mixed functionality.

Without being pid 1, that dedicated supervisor needs supervision. Now you have
duplicated functionality.

At the same time, said supervisor runs into all kinds of extra problems to
ensure proper cleanup of misbehaving services. Supervisord for example is a
perfect example of a process monitor is easy to make lose track of the
services it's supposed to monitor (I'm not trusting it again). Systemd's use
of cgroups for this is for good reason: it's a _hard_ problem to sort out.

You may end up with something usable, but a lot of the Systemd decisions are
the ways they are because the alternatives were severely broken. And yes, that
includes supervisord and monit.

E.g. here's an example from the Monit website:

    
    
          check process apache with pidfile /var/run/httpd.pid
              start program = "/etc/init.d/apache2 start"
              stop  program = "/etc/init.d/apache2 stop"
    

This seems innocent enough. Certainly it's better than "just" plain old SysV
init. But it is still fundamentally broken.

I've lost count of the number of times the Apache init scripts fails to bring
Apache reliably up or down, for a variety of reasons, and the assumption that
the pid-file will _actually_ contain the pid of Apache or an invalid pid is
fundamentally broken (the number of times I've found the pid-space has rolled
over quickly enough to cause problems? Not huge, but far from zero), as is the
assumption that there won't be _other_ Apache processes in various unpleasant
states whose pid is not in the pid file, but which will prevent a restart.

The problem is that Monit is fairly representative for process managers in
this respect, most of which makes the (broken) assumption that the init
scripts start, stop and restart actions will work reliably, and/or that the
pid file contains sane content, and/or that you have a reliable way to kill a
process based on holding onto a pid. I've yet to encounter a system where
_any_ of those assumptions are true, though you may need to scale up a bit
before you start seeing enough of those failures to care.

So the suggestion of using something like monit or supervisord without
addressing the amount of functionality you lose if you do makes me question if
you understand the purpose of the pieces you are tearing out and/or whether
you have put any thought into how users can regain that functionality without
ending up making the same tradeoffs systemd does after all.

I'm all for getting something more modular than systemd, but ultimately I
think few people will be well served by giving up on the substantial
improvements systemd is bringing.

~~~
uselessdguy
You can run uselessd with or without being PID1. The two modes have different
implications, obviously. The latter choice will mean a separation of system
manager and service manager. cgroupfs monitoring works properly in both cases.

PID files and SysV initscripts are broken. We're well aware and this has been
common knowledge for a long time. What I meant was that you can still get more
potential from a dedicated program that tries to focus and solve cases in one
specific areas. Making a distinction between the init part and the
manager/supervisor part is one of our longer term goals with uselessd,
beginning with version 5. It's a trade-off.

We understand what we're doing, and we do not deny the presence of warts. When
we announce that we're stable and ready for system integration, then we can
really talk. As it stands now, this is all preliminary pondering.

------
muyuu
Top of /r/linux right now:

[http://www.reddit.com/r/linux/comments/2k5b7e/the_concern_is...](http://www.reddit.com/r/linux/comments/2k5b7e/the_concern_isnt_that_systemd_itself_isnt/)

"The concern isn’t that systemd itself isn’t following the UNIX philosophy.
What’s troubling is that the systemd team is dragging in other projects or
functionality, and aggressively integrating them."

------
otterley
Original discussion, about a month ago:
[https://news.ycombinator.com/item?id=8348025](https://news.ycombinator.com/item?id=8348025)

------
gnud
This is a very good initiative. But linking "GNUisms" to the communist party
website is just dumb.

~~~
currysausage
It might be unprofessional in this context, but it did make me smile. The GNU
project's political dedication is vital to the OSS world, but quality of code,
documentation and usability often do feel like an afterthought. The minimalism
of the BSDs, for example, always is a refreshing contrast.

(Don't get me wrong, I don't want to flame, I use GNU tools on a daily basis.
Just when you know what they mean, the rather unexpected link is pretty
funny.)

~~~
fafner
GNU tools are rather well documented and well usable. I really don't
understand the claims you are making.

~~~
currysausage
It starts with this:

    
    
      The full documentation for XY is maintained as a Texinfo  manual. If
      the info and XY programs are properly installed at your site, the command
      
              info coreutils 'XY invocation'
      
      should give you access to the complete manual.
    

No, I don't want to spend days learning how to use yet another obscure
hypertext browser. That's not the Unix way anyway. _GNU 's Not Unix_, and
that's fine - but annoying at times.

------
dantillberg
Grammar nit: I believe that "complementary kitchen sink" would mean that the
kitchen sink goes really well with it, while "complimentary kitchen sink"
would mean that the kitchen sink is included at no additional charge.

~~~
agumonkey
I believe it's the opposite. Compliment : positive quality. Complement :
making a whole.

ps: not native english speaker.

~~~
shawabawa3
While your definitions are technically correct - GP is right.

Complimentary means "free", complementary means "goes well with"

~~~
agumonkey
Okay, thanks

------
taeric
Ok, this has to have been one of the more interesting reads on what the
complaints against systemd are. Ridiculously entertaining, to boot.

~~~
cwyers
Honestly, I feel the opposite -- I feel like this project acts as a far better
rebuttal to some common misconceptions about systemd than Lennart's blog post
about systemd myths. Why isn't systemd portable? You could read Lennart's
explanation, or you could just look at all the things these guys had to rip
out in order to get systemd to compile (and then not work) on non-Linux
kernels.

~~~
taeric
I think we are mainly in agreement. This was a _very_ informative project.

Now, in my case, I happen to have furthered my distrust of systemd in the
process. But that is secondary to just having learned more about what exactly
is involved by looking at this.

------
muyuu
Thread on their latest release:
[https://forums.darknedgy.net/viewtopic.php?id=4659](https://forums.darknedgy.net/viewtopic.php?id=4659)

Still very early days though.

------
muyuu
Modded out of the FP. Guess the mods know best heh.

------
n0body
do not care.

i've lost interest in systemd stuff now. use it. don't use it. whatever

------
spitcode
[http://boycottsystemd.org/](http://boycottsystemd.org/)

