Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Systemd Sucks, Long Live Systemd

naftuli.wtf

Post reply on HN
Print view View original

241–250 of 272 posts

Re: Systemd Sucks, Long Live Systemd

#241

Post by Too »

quickben wrote: post #25
xenadu02 wrote: post #13

Earlier quoted context omitted.

Who said the unit philosophy was the be-all, end-all? Unix doesn't even believe it's own philosophy because it's too damn painful. Why does ls do sorting? Why does grep do -R recursive searching? How is that "Do one thing and do it well"? Unix is just a collection of random decisions made by various people over the years. The Unix philosophy is really more like "I've always done it that way so don't you dare change i…

"The C compilation model of separate header files is not a good design" This is probably just your lack of experience not having worked on 50+ million LOC compiling for 12 hours and not having anything else as a better option. There is a reason these things exist.

??? Header files is the problem, not the solution.

Re: Systemd Sucks, Long Live Systemd

#242

Post by merb »

marios wrote: post #163
microcolonel wrote: post #84

Earlier quoted context omitted.

For what it's worth, I don't think Lennart is against non-Linux systems; he just doesn't care. And as an avid OpenBSD user, as well as an avid Linux user, I can't blame him. Linux has great APIs like cgroups, inotify (in my opinion considerably more useful than the equivalent use of kqueue), and others. OpenBSD is the other unixy system which I think offers something valuable and unique, and it has its own APIs to of…

I think inotify is broken. If 'broken' is too strong a word, then it's at the very least misnamed. It stands for inode notify, except there are edge cases where it doesn't actually report inode events. Consider this scenario: cd /tmp mkdir test touch test/somefile ln test/somefile linktothefile inotifywait -m test Basically, you're monitoring a directory that contains a single file. There's also a hard link to the fi…

OT: well that problem is outlined in some articles about inotify. Probably most people don't care. Since they only want to watch a directory and their subdirectories and not edits from hard links.

Re: Systemd Sucks, Long Live Systemd

#243

Post by beagle3 »

otabdeveloper wrote: post #94
FeepingCreature wrote: post #14

I'd probably respect SystemD a lot more if it measured itself against a modern init system like Gentoo's OpenRC instead of pretending it's invented dependency handling. https://wiki.gentoo.org/wiki/Comparison_of_init_systems > OpenRC provides a number of features touted as innovative by recent init systems like systemd ...

Systemd isn't an init system, it's a service (a.k.a daemon) management daemon. Its primary purpose is to restart and diagnose failing daemons cleanly. Systemd won for one simple reason: it's the only tool that accomplishes this task without bugs. We've been running daemontools for almost a decade in production, and it's a nightmare of bugs. Very glad to be finally switching to systemd.

What bugs are you seeing with daemontools? I've been running it in production for 15 years now (shortly after djb released it) and it's been rock solid the entire time.

Re: Systemd Sucks, Long Live Systemd

#244

Post by gens »

pif wrote: post #173
gens wrote: post #156

Earlier quoted context omitted.

Of course nobody benchmarked. Rarely are there programmers in OSS these days that benchmark anything. (not nearly as common as those who claim "speed") There was a bug though where the journaling was so slow it caused the whole server to crash. (sorry, can't find it right now; something about them using mmaped files and the access pattern was.. or something, interesting stuff:) Binary logs should be faster, in theory…

> Rarely are there programmers in OSS these days that benchmark anything. Please, don't release such a bold statement without any source. Please!

There is the object of this discussion, systemd, that has always been about "starting things in parallel" to make it "boot faster" but there has never been a proper benchmark (the distrowatch guy said, when asked, that he didn't notice any difference; i didn't see a proper benchmark anywhere by anyone). The kdbus proponents that were active on lkml at the time of increased drama (including the devs) also never did a proper performance evaluation. It was Linus who had to actually run perf on dbus to (easily) show the real reason why it is slow... I also remember commenting en passant once or twice about bad and/or biased performance testing. So that is my "source", the relative lack of proper benchmarks on blogs when they talk about performance of a piece of software. At least this is how it seems to me, as i did not email a bunch of programmers to feel around (innuendo not intended, but funny so i'l leave it).

On the other hand some OSS projects (the various databases, for example) do have posts/writings on performance. There are even some really in depth ones.

I'm fine with things being bloated (or just plain cpu slow) as that careless coding lets people make some nice things (a big part of KDE, for example). But i am not fine with people who publicly claim that their code is fast(er) without doing proper benchmarking. Hell if it was hard i wouldn't say anything, but it is not (for C code at least).

Objectively most programs i use (and most people use, even without knowing) can afford to be slow and eat much more memory then they should. Because most programs just sit there doing nothing for the grand majority of their run time (FF and sublime.., why do you send those msgs that use up 1-4% cpu ? i just don't understand). (honestly i'm worried that they are lowering(raising?) the performance baseline. but that's just predictions of future, voodoo, spirit animals showing the flow of chi or something)

PS Sry for the dumb rant. I like the topic of performance.

Re: Systemd Sucks, Long Live Systemd

#245

Post by z3t4 »

yrro wrote: post #238
z3t4 wrote: post #138

My main complain about systemd is that it does not log the stderr stream !!

It does log the standard error stream. The default value of StandardError= is inherit, which will cause stderr to go to the same place that stdout goes, which by defaults to journal. This is documented in systemd.exec(5). If not overriden in an individual service's unit file, perhaps you have set DefaultStandardError= in /etc/systemd/system.conf?

The problem is that it doesn't store "unit" meta-data for stderr, so you can not see stderr logs with journalctl -u nameOfUnit or systemctl status nameOfUnit

Re: Systemd Sucks, Long Live Systemd

#246

Post by johnny22 »

ashark wrote: post #24
FeepingCreature wrote: post #14

I'd probably respect SystemD a lot more if it measured itself against a modern init system like Gentoo's OpenRC instead of pretending it's invented dependency handling. https://wiki.gentoo.org/wiki/Comparison_of_init_systems > OpenRC provides a number of features touted as innovative by recent init systems like systemd ...

OpenRC's the only init system I've actually liked . It's one of the things I really miss from when I used Gentoo, and I don't know why more distros didn't adopt it years ago.

OpenRC was definitely my favorite init system before systemd existed. Definitely beat out the defaults of distributions who were using the debian/redhat style sysvinit.

Re: Systemd Sucks, Long Live Systemd

#247

Post by pessimizer »

scrollaway wrote: post #237
rdslw wrote: post #232

Earlier quoted context omitted.

You're plainly wrong. 1) You write "Most (MOST, not all) of the arguments against systemd are in fact bullshit". 2) And yet you (wrongly) write "there is plenty wrong with systemd" To be in line with your 1) statement you should write 'it is only small things with systemd which are wrong. Because everything - MOST = small, and not 'plenty'. Yet you dont do, and you write 'plenty'. Why? Because you know, the moment yo…

If you're going to try to use "the logic perspective" and be hostile for the sake of being hostile, at least have the decency of running your own post through that filter. "Everything - most = small" is a mathematically nonsensical statement. Of course, you could also tone the hostility down before reading my post. Maybe that'd have helped you catch the fact that a flaw in systemd does not necessarily equal an argume…

The first phrase of the first comment you offered on this thread was about how annoying in their ignorance you thought the comments of the people you were replying to were, so you should probably not lecture people on civility at length.

Re: Systemd Sucks, Long Live Systemd

#248

Post by skissane »

jjnoakes wrote: post #195
skissane wrote: post #63

Earlier quoted context omitted.

I'm not going to defend everything xenadu02 said, but I think there were some points that resonated with me even though I agree they could be expressed more constructively. > Why does ls do sorting? Why does grep do -R recursive searching? How is that "Do one thing and do it well"? I think these are valid examples of how Unix itself fails to follow the "Unix philosophy" of "Do One Thing and Do It Well". > The fork/ex…

Programs have features because they are useful. Some features may not fit your view of what the philosophy should dictate, and that's OK. Having a recursive ls doesn't bother me for example. Fork-and-exec isn't complicated by threads. Only fork-and-keep-executing is. UNIX doesn't have a naming convention using file extensions. Some of your points are valid opinions that are shared by others, but I don't know how much…

> Fork-and-exec isn't complicated by threads. Only fork-and-keep-executing is.

Another issue is that fork-and-exec doesn't work well with languages with complicated runtimes, e.g. multithreaded garbage collection. It forces you to use a lower level language (such as C) to write all the code between fork and exec. An API based on process handles with a separate "start" call to convert a not-yet-started handle into a running process wouldn't have that deficiency.

Another issue is that it is very hard to implement robust error handling without race conditions in the fork-exec model. What if the child process encounters an error between the fork and the exec? How does it notify the parent process of exactly what error it got (e.g. "setsid failed"?) You need some sort of IPC mechanism between the child and the parent. And such an IPC mechanism is prone to race conditions. By contrast, the process handle-based API I suggested doesn't have this problem since it doesn't introduce more concurrency into the system than is absolutely necessary.

> UNIX doesn't have a naming convention using file extensions.

Yes it does. The average Unix system is full of file extensions like .c, .h, .so, .html, etc. Even in Unix V1 file extensions were used as a convention - http://minnie.tuhs.org/cgi-bin/utree.pl?file=V1

> Some of your points are valid opinions that are shared by others, but I don't know how much they have to do with the UNIX philosophy.

Is there a clear definition of what the "UNIX philosophy" is? Is any criticism of Unix systems as actually implemented a valid criticism of the "Unix philosophy"? Or do you want to define the "Unix philosophy" so vaguely as to put it beyond any possibility of criticism?

Re: Systemd Sucks, Long Live Systemd

#250

Post by reflexive »

0xbadcafebee wrote: post #58

The problem with systemd is not that it is "bad". There's a lot worse software out there. Systemd is relatively competently programmed. And it's even useful! The problem with systemd has always been that it forces you to do everything the systemd way, and usually to use its tools. It goes against everything that has helped GNU/Linux become a great system: that it wasn't really one system. It was bits and pieces, and…

> Systemd is the opposite. It is inflexible and clunky, monolithic and proprietary

The other points can be debated, but please don't call it proprietary. It is free software as in "freedom" (LGPL).

Post reply on HN