Agreed that it's not in the summary, but as you correctly note, it's just a "summary". Anyone who reads the underlying blog post will read this among the facts on which the court based its opinion: "The public was allowed to search by keyword. The search results showed only the page numbers for the search term and the number of times it appeared; none of the text was visible."

So those readers who RTFA will be in the know.

Don't I wish.

A cynic might argue that the key difference in this case was that, for a change, the ISP's, and not merely defendants, were challenging the subpoenas; but of course we all know that justice is 'blind'.

An ingrate might bemoan the Court's failure to address the key underlying fallacy in the "John Doe" cases, that because someone pays the bill for an internet account that automatically makes them a copyright infringer; but who's complaining over that slight omission?

A malcontent like myself might be a little unhappy that it took the courts ten (10) years to finally come to grips with the personal jurisdiction issue, which would have been obvious to 9 out of 10 second year law students from the get go, and I personally have been pointing it out and writing about it since 2005; but at least they finally did get there.

And a philosopher might wonder how much suffering might have been spared had the courts followed the law back in 2004 when the John Doe madness started; but of course I'm a lawyer, not a philosopher. :)

Bottom line, though: this is a good thing, a very good thing. Ten (10) years late in coming, but good nonetheless. - R.B. )

Considering that reparenting processes that double fork is tried and true unix philosophy: It would be somewhat surprising to see apachectl properly clean up after itself in your so called cleaner system. Maybe you just fail to properly recreate the problems in your trimmed down universe?

None of the init systems currently in use is conceptually very complex. In the end sysv init is actually one of the more complex ones. The others are of course different, but I would not actually call them conceptually more complex.

In fact setting up a service and then starting it is significantly simpler with systemd (and upstart and openrc) than it is with sysv init. Give it a try before complaining about it.

Hmmm... why would you? Maybe because these are fundamental issues with how sysv init works?

I am not talking about structured application data, I am talking about facts that go with the actual log message like the timestamp, the PID that the message originated from, the capabilities the process has that originated the message, the full filename of the process running, which cgroup the message originated from, which boot id this message belongs to (really nice if you want to see one boot/run/shutdown cycle only), that kind of data.

Having that information in the journal is really nice. Not having to parse it out of some textfile where some application put it in a more or less randomly selected format is even nicer. Correlating data from different log files written by different applications is a huge pain that is completely gone with journald.

Yeap, it does. It makes full use of all the extra data it adds to the log entries and thus allows for way more reliable and powerful filtering, slicing and dicing:-)

So the GNOME project making a technical decision that makes their live easier is forcing something down your throat. You are being a bit egocentric, aren't you?

Do you have prove for any of those claims? Where are the army of developers that do something about the decisions and flock to projects that are not falling for the propaganda? Or are you the only one that understands what is being played here?

This statement does not become true by repeating it.

FLOSS always had a strong "who does the work is right" approach. What the users say has always been secondary.

There are loud voices speaking out against systemd. Do not mistake that for many voices. In Debian the systemd oponents failed to find five people required to call for a vote to overturn the decision made by the technical committee! And that after all the fuss taht was raised during the discussion process.

Why bother to write something that is as good as what was there before? Systemd tries to do more than init ever did, right. But much of that actually makes sense if you take the time to read up and think about it.

I have seen very few reasonable argument levered against systemd in this thread. But then what can you expect from a thread that has an april fools joke listed as a fact?

I mostly see misinformed or uninformed posts. What can you tell people that form a strong opinion on something without bothering to learn about it first? "You're holding it wrong" is actually a rather polite way to put it IMHO:-)

There are several. https://tim.siosm.fr/blog/2014... is the first one that come up googling for the headline of the ewontfix article.

No it one of systemd's goals to manage a system reliably.

Processes that double fork end up with the init process as its parent in the process tree: That is unix-philosophy at work and apache is not to blame here.

That makes it really hard to manage things like apache without additional concepts like cgroups. Those are actually not complex nor do they require lots of code to be implemented, but they need to be managed in a central place to be useful. So systemd does that right in the init process so that you get maximum benefit from the concept.

Most packages do not depend on systemd being PID1, they depend on other things that found a home in the systemd repository. One big thing is of course udev for things that are close to the hardware. The other big thing is user session management. Basically systemd can replace all the custom start-up-the-desktop-environment code that all the desktops implement to make sure all their services get started and keep running. Then there is logind which manages who is logged in where and who has access to which keyboard/graphics card/mouse/etc. That is pretty essential for any modern desktop environment, too.

Note that all these interesting things are interfaces that can be implemented for other init systems as well. Unfortunately nobody stepped forward to do so yet. The implementations found in systemd are tied to systemd being PID1 (more or less badly), since they e.g. use the systemd interfaces to manipulate cgroups.

So you want to have a tiny init process that spawns a bigger init process that does all the actual work? If the "big init" fails, then your system is hosed. If your "small init" fails, then the system is also hosed. Your proposal gets more code into the critical path, not less.

But then your problem is that other projects start to depend on systemd. What exactly are you objecting to here? That Systemd finally solves real world problems that developers face when implementing their software? Or that developers go ahead and fix the issues that they were unable to fix before? In the end you claim we should keep bugs open because some people on the internet are feeling uneasy.

Yes, there are bugs in systemd, just like there are bugs in sysv init -- even after decades of use. Yes, there will be some exploit sooner or later targetting systemd, just like there will be some for every other piece of software. But that should not stop people from improving the status quo.

Lennert and some other guys wrote a bit of code and went out to talk about it. They got feedback, and improved their code based on that feedback. At some point more people started to care about the code and so they contribute. Much later some other people sit down together and agree that this piece of software addresses problems they have, so they depend on that software -- either as something providing a service to their own software or as a basis for their distribution. At which point in the story does somebody grab you and forces a USB stick down your throat?

That kill apache, not the crap it started and that forked itself away.

Systemd can set up filesystems without racing, something that is not possible with sysv init. No more races makes for a more robust boot. In fact systemd does address most of the race issues found in the debian init system. Go and check their bug tracker if you do not believe me.

That you were unable to configure your system to make it boot with systemd is anecdotal evidence at best. I bet it did not boot right away when you installed your first sysv-init based Linux ever either;-)

I never measured the boot up times, so I am not sure whether systemd is faster or not. I frankly do not care one way or the other.

At least here systemd has no open ports. Why does it matter whether systemd, upstart, sysv init or openrc started the sshd under attack?

With the options to limit the process that systemd offers I can even severely limit what an attacker can do on my system once a daemon is compromised. Those countermeasures are of course also possible with init-scripts, but they are *way* harder to implement securely. I have not seen many distributions that bothered to add any additional security measures to their init scripts.

A local user is something different, true, but considering that you are referring to sshd that does not seem to be your argument.

Read a couple of man-pages and see for yourself.

You can wire up syslog to the journal. Why would you want to convert rich information into a string and shove it down a pipe before you make use of it? Let's start with a useful format and use lossy conversion methods on that when needed, not the other way around.

You are not ripping your CDs to mp3s either so that you can burn other CDs by converting those mp3 files to WAVs either, do you?

So please enlighten me: How do you kill apache with all the php/ruby/whatnot crap it directly or indirectly spawned? With systemd it is just one convenient systemctl stop apache

Please do not assume that I am too young or too stupid to know the good old ways. I have been around for a while, even though I still have not managed to learn not to get into discussions at slashdot that are bound to end up in namecalling.

I was more thinking about starting postgres before the server that uses that DB to store its stuff. Grep for "sleep" in the init scripts of the sysv-init distribution of your choice: You will be surprised.

Check out http://www.freedesktop.org/sof... , especially all the options starting with "Private" there.

Convenient for everybody. Just try the things that come with systemd. Most are a real improvement over the existing tools to manage hostname/date/time/timezone/locale/service/network/efi boot loader/virtual machine/whatnot. At the very least they are way more consistent in how they work and they work on all modern Linux distros in the same way. That was never possible before.

Yes, I know: Just suggesting to look into systemd is sacrelegious:-) Sorry, I won't do that again.

Let's just wait a year or two. By then all the hotheads that are running for the BSDs now will be back, everybody will be using systemd (including gentoo and slackware) since it clearly is the best approach available right now. When somebody finally comes along in 10 or 15 years with a good idea to replace systemd she will be yelled at for breaking away from the tried and true systemd that has been good enough for everybody this past decade.

The problem is: A *tiny* init process won't be able to offer the *exactly same* functionality. The functionality has to come from somewhere, it does not fall from the sky: Some code needs to implement it.

If you want to keep PID 1 tiny then you can implement the actual functionality in separate processes. You now have two or more process and now you need code in the tiny init process that makes sure the controlling processes are getting started (and restarted). Remember: Those daemons provide the actual functionality, so PID1 can not depend on that to start those daemons in the first place.

You need code that facilitates a communication channel between the processes. You need code to lock out processes that are not meant to talk to your tiny init process. You need a protocol that the init process speaks and that allows it to be remote-controlled. All of sudden that tiny process is no longer tiny and your architecture is much more complex than it would be otherwise.

That complexity requires you to add more code to mitigate communication failures, to synchronize data structures between all the different processes that need access to them, you need to be careful not to introduce race conditions between those processes. In the end you end up with a pretty big init process and a bunch of big and nearly equally critical daemons surrounding it. I do understand where the systemd guys come from: Keep the architecture simple, and put absolute minimum amount of code into PID1 to provide the functionality they want. That makes the overall system less complex and easier to reason about, which is good for security and robustness.

Read the code, it is actually pretty ok.