Hacker News new | past | comments | ask | show | jobs | submit login
[dupe] Uselessd (darknedgy.net)
169 points by muyuu on Oct 24, 2014 | hide | past | web | favorite | 59 comments



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.


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.


With apologies to uselessdguy, I have to agree that the name is not an asset. I have NO problem with clever names, but sometimes they are a bit too much. For example, I always though that Lesstif (a clone of Motif) was a silly, off-putting, name. As to the substance of it, I'm not thrilled with systemd and generally agree with the argument that it's taking on too much. So I wish the uselessd project well, if for no other reason than it may encourage systemd to address some of it's shortcomings.


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).


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?


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"?


Humorous names aren't exactly new to free software.


"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.


> 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.

To be honest, if the format is done well there is no reason you cannot still read all the non corrupted records. textfiles corrupt too, you just generally live with them being broken because you can read the unbroken stuff.

Going by the bug tracker the journald approach is to make the reader work with broken files better.


The binary logs are append only. The bug tracker entry says that they got "some corrupted logs" but not how. People get corrupted or truncated text logs all the time, they just ignore it because "oh the log ends midway through a line? eh".

The ridiculous "oh my god my logs will be always ruined thing" is a beat up by those who need to assassinate something about systemd, because it's always been devoid of any technical accuracy or discussion.


A truncated text log can still be informative, and I've never had a corrupted text log hang or crash my text editor.


That's because your text editor has had thousands of hours of work going into catching all of the edge cases.

Things which have caused editors to hang or crash: 1. Binary data outside of the US-ASCII visible range 2. Malformed or creative Unicode combinations 3. Very long lines 4. Very many lines 5. Inconsistent line termination 6. Lines with patterns which trigger syntax highlighting, URL underlining, etc. 7. Embedded terminal escape sequences

It's not unreasonable to imagine that the journald developers might spend the same amount of time on safeguards, something which is easier with a well-defined binary format.


Yeah so let's just redo all those thousands of hours of work... for one specific format that has literally one use.


It's not thousands of hours with a better-defined format than free-form text, which is obviously the case for journald. Doing that for a single format makes sense for something which would be as heavily used as system logs – it's not like people haven't spend crazy amounts of time writing syslog parsers or other hassles which go away with a structured format.


This is like saying.

"I get shot going to work every day. But I bought a bullet proof vest, so life is okay."

Iron bandages don't solve problems, they for a short time work around them. Except because nobody actually like writing systems level code, they stick- forever.


> "I get shot going to work every day. But I bought a bullet proof vest, so life is okay."

You get corruption if the machine shuts down incorrectly. In binary or text files. In that case journald/syslogd act like a black box. Syslogd will give you whatever garbage it has in those text files, journald will give you the surviving records and will tell you which ones are unreadable.

If you want to not get shot, shut down your machine properly. If you cannot shut down your machine properly because it crashed then you have data garbage if you want it or not. Drives work that way.

I'm not sure what you are arguing for.

Journald does not write broken records itself.


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.


I'm not currently using Linux, so I might be wrong, or misunderstanding what you're trying to do, but could you just have journald write to syslog?

ForwardToSyslog=yes in /etc/systemd/journald.conf.


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.


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


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.


See ? People complaining before reading TFM. Thank you !


Sounds like you're running into some bug. I've never run into any perceptible lag.


That sounds odd. Did you try to strace it and see what it actually does?


I found this to be the case as well. Especially on a busy system where there are a lot of events, when you're trying to find the cause of an issue and constantly opening and closing logs, the lag is definitely noticeable.


To be honest: that's kinda to be expected if you run it on a slow machine. However you can configure it to be in-memory only and forward to syslog and you have it as it was before.


I'm highly suspicious that syslog can actually be faster in such a situation. If you can't seek to the disk quickly, then it doesn't matter what you do - logging will be slow if you need to flush frequently.


I googled "libqrencode". Is it really QR code encoding?


Yep. It's because when you kernel panic most people do not feel like typing stuff off a screen. If you have a QR code on your monitor however you can easily scan it and it contains all the info about what is wrong.

That's a pretty good feature if you ask me.


That's a Linux kernel feature, not a systemd feature. It's unrelated: http://www.linux.com/news/featured-blogs/200-libby-clark/773...

systemd has libqrencode integration, in order to, if I recall correctly, display a QR code when you generate FSS keys from journalctl.


That is a useful feature! The way it was written it sounded like QR codes were going into the logs.


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.


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.


> 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.


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.


> So under uselessd a service or socket file cannot depend on the presence of certain mounts, for instance (RequiresMountsFor=).

Of course it can - you just write a script that checks for the mount being there and if not attempts to mount it, with a timeout, then put it in as a dependency.


"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."

Well it isn't called usefuld.


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

You're not screwed. If you need SMACK, IMA, or SELinux, you still have systemd. That's choice.


Top of /r/linux right now:

http://www.reddit.com/r/linux/comments/2k5b7e/the_concern_is...

"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."


Original discussion, about a month ago: https://news.ycombinator.com/item?id=8348025


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


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.)


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


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.


Yeah, I'm not criticising it, but I expected an actual example .


Off the top of my head: __compar_fn_t (just a typedef), strndupa(), parse_printf_format(), canonicalize_file_name(), the GLOB_BRACE flag, implicitly included headers, error.h (also in uClibc)...

We have notes in our Bitbucket source.


you must be a laugh riot at parties


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.


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

ps: not native english speaker.


compliment (n.)

"An act, or expression of civility, usually understood to include some hypocrisy, and to mean less than it declares" [Johnson], 1570s, complement, via French compliment (17c.), from Italian complimento "expression of respect and civility," from Vulgar Latin *complire, for Latin complere "to complete" (see complete (adj.)), via notion of "complete the obligations of politeness." Same word as complement but by a different etymological route; differentiated by spelling after 1650.

complimentary (adj.)

1620s, "conveying a compliment," from compliment (n.) + -ary. In later use loosely meaning "free of charge."

complement (n.)

late 14c., "that which completes," from Old French compliement "accomplishment, fulfillment" (14c., Modern French complément), from Latin complementum "that which fills up or completes," from complere "fill up" (see complete (adj.)). Originally also having senses which were taken up c.1650-1725 by compliment.


While your definitions are technically correct - GP is right.

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


Okay, thanks


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


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.


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.


Thread on their latest release: https://forums.darknedgy.net/viewtopic.php?id=4659

Still very early days though.


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


do not care.

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





Applications are open for YC Winter 2020

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: