New Group Calls For Boycotting Systemd

[finalzone]

More importantly, their NIH led them to create a solution (journald) that is broken by design - it is inherently vulnerable to crash corruption, and as the linked bug report shows, the corruptions are well known by the developers and they have no idea how to fix them. The key point is that no single team can possibly have expertise in every aspect of a complex system, and the systemd developers' all-in-one philosophy will inevitably lead them to make more such unfixable design mistakes.

What is your suggestion?

[highlandsun]

What is your suggestion?

Stick to your strengths? If they actually have any. So far all I've read is that they're incompetent at everything they've ever done. http://igurublog.wordpress.com/2014/...ainst-systemd/

Maybe "a better init" is a good idea at its core. But this crew are not the right people to deliver it.

[js3915]

Never understood the hate towards systemd, however they need to grow up and actually make something better. There are so many advantages to systemd that outweigh the negatives, that I dont even understand why people are trying to make an argument unless there was a viable alternative. It was sad to see upstart die off gave systemd some competition hopefully something else will come along. With cloud based server now an droplet type services, you need something like systemd this is something the older way cannot do on a mass scale... Really I cant even see a distro like slackware going too much longer without implementing some elements of systemd. Alot of software is becoming dependent on systemd. They might have to migrate even

[erendorn]

The key point is that no single team can possibly have expertise in every aspect of a complex system, and the systemd developers' all-in-one philosophy will inevitably lead them to make more such unfixable design mistakes.

There are 300+ contributors to systemd, and commit access for people from different companies. It's neither single developer nor single team.

[erendorn]

More importantly, their NIH led them to create a solution (journald) that is broken by design - it is inherently vulnerable to crash corruption, and as the linked bug report shows, the corruptions are well known by the developers and they have no idea how to fix them. The key point is that no single team can possibly have expertise in every aspect of a complex system, and the systemd developers' all-in-one philosophy will inevitably lead them to make more such unfixable design mistakes.

I don't think you understand their point on corruption. The journal is append based, so if a file is corrupted, generally all previous entries are readable, and all further entries are made on a different file, so readable as well. The entries lost due to the crash are lost, which can not really be prevented.
They don't say they don't know how to fix it, they say there's nothing to fix anyway.

[discordian]

Here is the full text

- OOM safe - LMDB does practically no memory allocations of its own - readers require zero mallocs, writers seldom require more than 1. It can never use enough memory to drive a system into swapping; it can never cause an OOM (out of memory) condition.Its also mmaping the database, which I guess could pose problems on 32bit Target since that space cant be used for anything else... particulary if it should fit in a fraction of the 4Gb Addresspace like some embedded cpus require/favor for kernel/userspace seperation and not to mention other things you`d have to map and reserved ranges.
Further I am not so sure the ACID "semantics" will actually hold in every case if you use the host systems file caching (power loss)

- does not require file locks; readers don't block writers, and writers don't block readers.
Lets see what the doc says:

There is normally no pure read-only mode, since readers need write access to locks and lock file. Exceptions: On read-only filesystems or with the MDB_NOLOCK flag described under mdb_env_open().

And further:

Do not use LMDB databases on remote filesystems, even between processes on the same host. This breaks flock() on some OSes, possibly memory map sync, and certainly sync between programs on different hosts.

When you compare this to their rationale, it doesnt seems out of place to search for alternatives:

It should not require file locks or communication between multiple
readers or between readers and the writer. This is primarily a
question of security (we cannot allow users to lock out root or the
writer from acessing the logs by taking a lock) and network
transparency (file locks on network FS are very very flaky), but also
performance.

Seems like listing a unreasonable best-case scenario for LMDB without looking at the big picture of the actual requirements. And missing the point, since the thing about systemd is excatly trying to get the overall system right, if part of it suck then noone prevents a replacement. Those quite possibly will happen.

[Luke]

Thank you

Here is the full text

This settles my concerns, as nothing in that indicates any malicious behavior or any intention to drop in back doors/spyware. If the Linkedin story had been something about having a contract with the NSA or with GCHQ (other than, of course to get their own machines booted!), that would have been entirely another mattter.

From where I stand "trust" means being able to rely on someone not to engage in intentionally malicious behavior. Intentional malice towards the user normally means intentional bugs, back doors, or spyware from where I stand., Intentional malice towards the user of a system can also mean an attempt to make it impossible for a user to migrate their data to another OS, such as a proprietary format for user data (not system logs). If journald was say, a spreadsheet program, and the backend was something odd this would qualify, but system log portability is far less important. At any rate, journald can be told to echo all output to syslog as it goes if this is an issue.

Malicious behavior in journald would be something like a code that would prevent mounting a special forensic volume from making journal entries, or echoing the contents to a hidden file either stashed somewhere on disk (for recovery by law enforcement) or emailed out to either the programmer (phone home) or to law enforcement upon special activation. If systemd does not do something like this, I deem it trustworthy enough for my uses.

"Malicious behavior" towards BSD does not affect me as I am a Linux user, and as my heavily customized OS is almost a private distro (with about a dozen users) I have noticed nothing that would force me to use it unless I want to include GNOME or rely on upstream packages compiled against it. Converting my Ubuntu based but heavily modified main OS to it was a matter of choice, so I could get my customized boot-time stuff ported over long before I would have to pin Upstart or something else. If most systems in use end up on systemd, that's actually a benefit for programmers of anything that starts at boot time, as just like back in the sysvinit days only one init system would need to be supported. Maybe that would allow finally putting an end to wholesale use of sysvinit scripts now used simply for universal compatability.

As for package manager indicated dependencies, I am well enough versed in those that if I had a valid need to use some other init system, I'd make a dummy package providing the missing dependencies-or put the "provides" directly into the replacement packages. Hell, just to get a modern version of Dracut installed to use systemd in the initramfs I had to remove the conflicts with initramfs-tools from the dracut DEBIAN file, plus make some other modifications. I left initramfs-tools installed so I can create a non-systemd initramfs to boot to upstart if an update breaks systemd. Yes, I've had that happen, as expected on a hacked alpha distro.

[Luke]

"Unix Philosopy" has no bearing on user security or usability

I've no problem reading it without an account even with noscript on, so:
Lennart said he can't use existing DBMS for journald because of his requirements and the post says that he wasn't/isn't right and LMDB meets all the requirements he had.
The post then argues, that this is clearly NIH and in the last paragraph that systemd is not in the sense of "the unix philosophy" therefore Lennart and the systemd team can not be trusted.

Note that this is a summery of the post, not my view on this subject.

The "philosophy" I am concerned with is code distributed without requirement of monetary payment, with source code available that can be compiled into the exact binaries being distributed on some known toolchain. I could argue that any code I didn't write myself is "NIH" in my own machines, thus making anyone else's arguments over that irrelevent. I only develop one piece of boot-time code (a multi disk unlocker for cryptsetup), so I am a systemd user, not a systemd developer.

[highlandsun]

- OOM safe - LMDB does practically no memory allocations of its own - readers require zero mallocs, writers seldom require more than 1. It can never use enough memory to drive a system into swapping; it can never cause an OOM (out of memory) condition.Its also mmaping the database, which I guess could pose problems on 32bit Target since that space cant be used for anything else... particulary if it should fit in a fraction of the 4Gb Addresspace like some embedded cpus require/favor for kernel/userspace seperation and not to mention other things you`d have to map and reserved ranges.

On 32 bit systems it can do dynamic mmap'ing of relevant data pages. Your concern here is a non-issue.

Further I am not so sure the ACID "semantics" will actually hold in every case if you use the host systems file caching (power loss)

Already tested and proven by various 3rd parties.

http://wisdom.cs.wisc.edu/workshops/spring-14/talks/Thanu.pdf

Their preliminary results indicate they found 1 crash vulnerability in LMDB, but after I contacted them for clarification it turned out they were mistaken. LMDB has zero crash vulnerabilities. They will be presenting their corrected/final results at OSDI confirming this https://www.usenix.org/conference/osdi14

When you compare this to their rationale, it doesnt seems out of place to search for alternatives:


Seems like listing a unreasonable best-case scenario for LMDB without looking at the big picture of the actual requirements. And missing the point, since the thing about systemd is excatly trying to get the overall system right, if part of it suck then noone prevents a replacement. Those quite possibly will happen.

Searching for or creating alternatives is fine, if you actually come up with something better. journald is inherently vulnerable to crash corruptions, by design. journald's fundamental flaw is that It is not a pure append-only design; after appending log entries it must rewrite index pointers at the head of the file. Any crash that occurs while the index pointers are being updated can render the entire journal file corrupted and unusable. It is neither reliable nor performant. LMDB is both. "Trying to get the overall system right" is a laudable goal but they've proven conclusively, repeatedly, that they aren't good enough programmers to get it right.

[prodigy_]

I stayed out of the debate before, but now I've stumbled across a concrete reason to avoid all of this stuff.
https://www.linkedin.com/pulse/artic...tering-systemd

Spot on. People are mistaking Lennart's manic hyperactivity for brilliance and his obsession with writing crapware for competence. The guy is a mediocre software designer and programmer at best. He has A LOT of energy but this doesn't necessarily mean he would be able to use it in the best interests of the community even if he wanted to.