So the people that build the system do not care about it. *plonk*

Why should it be replaceable? It is internal. You are fine as long as you can attach everything you need as some kind of backend to that interface.

Yes, some of the gcc extensions in the kernel are getting removed. On the other hand the clang compiler is getting extended to handle more gcc extensions. It already does quite a few.

Once clang builds the kernel it will most likely also build systemd:-)

Oh, come on... *ALL* init systems do IPC. That might just be a simple pipe somewhere, but that is still IPC. How do you think telinit works?

KWin (the KDE window manager) will depend on logind at the very least for wayland. ConsoleKit is dead, so anything currently using that will need to look for an replacement soon. That includes basically every DE out there.

Some might come up with a different solution, some may function without logind, some will just require logind like gnome does now. Let's wait and see how that will work out.

You are aware that logind, journald and networkd are all stand-alone daemons that just happen to integrate well with systemd-PID1 and that live in the same source code repository? You do not want them? Just disable them.

Journald is a bit of an exception here: It basically provides the logging infrastructure for the other parts of the project. So all you can do there is to have it forward the logs to syslog.

I entirely fail to see why binary logs are such a big argument, considering that syslog is fully supported. Push your stuff there, RHEL7 apparently even does that by default. You still get more information into your logs that way than you used to. So you win, independent of whether you use journalctl or cat on the files syslog creates to read them.

No, but then FreeBSD is of course free to have several init systems if they care. Traditionally they do seem to prefer a more consistent user-space developed by one team.

I do not get what you are going at with this point.

Yeap, it is getting more and more common, even on embedded hardware. There is so much software out there that is basically untested on anything but glibc that it makes sense to use that libc if you do not write everything in-house.

I used "we" exactly once and I am pretty sure there will be very few people indeed that defend the crontab syntax.

I am in no way talking about features of any replacement init. I am talking about interfaces other applications are depending on.

This may be udev, or the hostname/data/time configuration or logind or whatever else. Fact is that gnome is depending on some of these interfaces. KDE announced that they will do the same -- at the very least for wayland. I doubt that the other DEs will be far behind, especially now that ubuntu wants to move to systemd, too. These interfaces are apparently not all bad, so developers want to use them.

So if you want to run any of these applications, then you need to provide these interfaces in one way or another. This can be by either using systemd, or systemd-shim or systembsd or whatever implementation. There are quite a few to choose from at this point:-) For a new project to remove all that code and claim it is not needed is naive at best.

The features provided by the init system itself or how those are implemented is irrelevant to my point.

It is a feature to some, a misfeature for others. It definitely does not make this uselessd a viable alternative to systemd for mainstream distros.

Not at all. It is just sound development: Come up with a interface you use in your code for the functionality you are using from others. That way you can have different implementations. In this case: Push logs to /dev/null, use journald or push it to syslog. Actually it is exactly what makes this flexible and modular.

This project is indeed useless:-)

First it implements the PID1 part of systemd, cutting out things like hostname, date and time management and logind. So this does *not* ship the things that are needed to run Gnome (or soon any other desktop environment). So you need systemd anyway... or a systemd shim or systembsd or whatever to provide the functionality that is missing.

It removes journald... and with it really nice features like systemctl status whatever showing the last bit of output from that unit. That is a huge step back, especially since much of the journald code still needs to stick around: It is the "internal" logging interface used in systemd. It just feeds it on to syslog now instead of writing it to disk, something you could do with one line of configuration.

Removal of udev? You need that functionality, so again you will need to install "real" systemd or some other piece of code replacing that. Again you could just reconfigure the "real" systemd to use any alternative implementation in place of its own.

Then it advertises that it is portable. The developer apparently spend time to make this run on FreeBSD, which is nice, but has anybody in that came ever asked for that? AFAIK they are working on something like Apples launchd. Any other of the BSDs that want systemd? Not that I am aware of.

Then it is portable to other compilers but gcc. Systemd uses gcc extensions that make for more robust code (e.g. destructors for variables). Ripping that out will just lead to more bugs, especially in the error-paths. Not sure that is worth the trouble.

Finally it is portable to other libcs. That is actually somewhat nice... even though glibc is the dominant libc implementation on linux systems (that are not android:-).

Then it removes some really convenient functionality like the timer units. Do we really want to go back to the cryptic crontab syntax? If the job there is somewhat complex it will most likely start a systemd unit anyway (for the security features, resource management, the way better logging or just the better job control). PID1-systemd needs to know the time anyway, and it needs to start jobs, so why not have it start jobs based on the current time? That is definitely less code -- and probably better tested, too -- than running an extra daemon for that rather trivial job.

It also removes the support for the security frameworks... "to stick to a more clearly defined purpose, one that is agnostic of such elements". Wow, that is just plain stupid. If you want to use these frameworks, then you want to have them in use *everywhere*. That is the whole purpose of those frameworks.

I should say that Tesla's offerrings are nowhere near what my pocketbook could accomodate. Having said that, I wish nothing but good luck to them.

Dealerships are useless, blood-sucking parasites, and I won't shed a tear for them, if those massive wasters of useful oxygen will disappear from the face of the earth. Even though I've gotten the art of buying a car down pat, keeping my actual interaction with those vermin to an absolute minimum, and even if, by my own estimates, I reasonably avoid having to deal with maybe 90% of the bottom feeders a typical car buyer would be subject to, I'd still wish them to burn in flaming pits of hell.

I have to laugh at their PR spin, when they claim how dealerships are the best way to buy cars. Blah, blah, blah. I can safely safe that, having bought 3 cars in the last ten years, dealerships are always just a waste of my nerves, they add absolutely nothing of value, and only inflate the price of a car through their markups. I wouldn't actually even mind if all that having these dealerships around do would add a modest markup to the price of a car, in exchange for a little bit of service. If that was all to it, then I don't think I'd mind it at all. But that's just a small part of the problem, and I'm sure it's quite clear what I'm talking about, so enough said...

Let's just say that I'm rooting for Tesla, even though if they win it would do absolutely nothing for me directly. Indirectly, yes: not having to deal with those parasites, the next time around, would be a big plus.

Not 2^16 (Unicode already has way over 2^16 codepoints assigned). The maximum Unicode codepoint value is 1114111, which is somewhat over 2^20 (and happens to be the highest codepoint encodable in UTF-16).

$Dayjob$ hires talented interns from local scrools of higher learning, every summer. Many of them come back for a few years, as they finish up their bachelors.

Your university most likely has a few beaureaucrats in some kind of a career placement office, of sorts, that are likely have leads to local companies who have open summer internships.

A few of the best $dayjob$'s interns get a job offer, after they graduate. And all of them earn some beer money during the summer, and have something to go on their resume.

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