Linux Mint Will Continue To Provide Both Systemd and Upstart

jones_supa writes: After Debian adopted systemd, many other Linux distributions based on that operating system made the switch as well. Ubuntu has already rolled out systemd in 15.04, but Linux Mint is providing dual options for users. The Ubuntu transition was surprisingly painless, and no one really put up a fight, but the Linux Mint team chose the middle ground. The Mint developers consider that the project needs to still wait for systemd to become more stable and mature, before it will be the default and only option.

Comments

Re:Are the "GNU" and "Linux" parts still needed?

[Anonymous Coward]

Take note modern shitposters. This is what a good troll looks like.

If everyone who wants to derail a discussion would put in as much effort as this the Internet would be saved.

I like how this got marked troll

[drinkypoo]

It's a fact that the fix for corrupt logs, which systemd will often corrupt if you power-cycle your system, is to delete them and throw them away. https://lwn.net/Articles/621453/ https://lists.fedoraproject.org/pipermail/devel/2013-July/185702.html It's a fact that systemd will only sometimes recover any part of its bullshit binary logs, and only any part after any error. So if journald truncates a file because it shits itself, which it has been known to do, then you lose the whole log.

Moderators, you might want to familiarize yourself with the festering pile of shit which is Lennart Poettering, as well as the pile of crap which is systemd, before you moderate any systemd discussions. Because you clearly have no idea what you're doing.

Re:I like how this got marked troll

[Peter H.S.]

The issue is not with systemd corrupting the binary logs, or with the filesystem corrupting the binary logs, but with the fact that they are -binary- logs. A log file should be an ordinary text file. Nothing more, nothing less.

The glaring problems with flat file, unstructured text logs have been discussed for decades now. Plain text log files, like the original syslog(3) interface was simply bad ideas that Linux inherited. The main commercial selling point with any syslog implementation today is exactly that you can avoid several of these problems by using a DB.

An overhaul of the creaking legacy Linux logging system have been needed for a decade at least. Remember, the Rsyslog project was started exactly to fix such problems. They failed partly because distros and developers don't care about working together for a common goal and because there was no other central developer hub who would take the initiative.

systemd have finally fixed so many of the classic syslog problems. I don't care if you think syslog is perfect and never can be improved, and Rsyslog should be avoided for providing binary DB storing option, but please don't think that other people agree to this postulate.

And systemd's journald is designed to be 100% backwards compatible with syslog, so if your setup have legacy need, it is trivial to get a systemd distro to use legacy syslog text logs.

Re:The pain isn't in the switch

[squiggleslash]

IIRC these "binary" logs you speak of are simply text files with indexing information attached. They're not encrypted or compressed, you can, at worst, use the "strings" command to pull the information, and if you're doing raw sector dumps from a hard drive then you'll be able to read them there too.

Of course, if the log files are zero'd out, like the bug report you quote, then it doesn't matter whether they're "binary" or text, you're screwed. That has nothing to do with systemd.

Logs via network

[bouldin]

SysD's binary logs have another, serious flaw: they are not designed to be sent over a network. This has been an intrinsic part of syslog for a looong time.

There are a few tools to send journald logs remotely, but they rely on tailing the binary log, then reformatting it and transmitting it over HTTPS to another tool on the destination system.

I found a feature request for journald/sysd/whatever to enable network logging, and the solution they are adding is to... tail the binary logs with basically the same tools.

Putting the disk in the middle and depending on file tailing is such a bad solution. Many things can cause this to fail; it's a total kludge.

I discovered this when investigating how to send journald logs to Splunk. The solution there is to... tail the binary logs with journald to a text file and have Splunk monitor the text file.

Now, this is not a fatal flaw. Journald could (I assume) be enhanced to natively send logs over a network. But, this shows that systemd is not enterprise-grade or production-grade, and was not designed with that kind of reliability in mind.