New Group Calls For Boycotting Systemd

[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

[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.

[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?

[finalzone]

An attempt to read this gets a redirect to their login page if JS is enabled, and an almost blank page if JS is disabled-at least in Torbrowser.
I don't trust social networking sites, and as a user of systemd on a sensitive system I do need to know if any of this relates to potential
for back doors. Could someone post a summary of arguments made in this?

Here is the full text

I've been watching the systemd drama with a skeptical eye, from a distance. But tonight I read something that crystallized it all for me, so now I'm compelled to point out why Lennart Poettering and systemd cannot be trusted.

The gory story begins with their journald discussion, here http://thread.gmane.org/gmane.comp.s...922/focus=6950 where they rationalize why they created their own data structure rather than using an existing embedded DB. Aside from their claim that nothing suitable existed being wrong (LMDB belies those claims) the fact is the solution they developed is inherently unreliable https://bugs.freedesktop.org/show_bug.cgi?id=64116 which utterly invalidates their claimed attention to robustness.

Going thru the rationale point by point
- small, embeddable, in pure C - LMDB is the smallest transactional DB engine in the world, written in pure C.
- stable API, sanely managed, free software - the LMDB API is modeled after the BDB API so it was mature from day 1 and has had no incompatible changes since LMDB's introduction. It is professionally managed by software veterans and released under the OpenLDAP Public license - totally free.
- 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.
- typeless - LMDB is typeless, as a key/value store it doesn't care what types of values you store.
- efficient with large and binary data - LMDB is particularly efficient with large data, nothing else comes anywhere close. http://symas.com/mdb/microbench/#sec4
- does not require file locks; readers don't block writers, and writers don't block readers.
- robust against failures - LMDB is crash-proof by design, and proven in the real world. https://symas.com/carrier-grade-stab...d-performance/
- needed in-line compression - this is a red herring. LMDB uses 1/3rd as much space as DBs that offer compression. Compressors need to average 3-4x compression ratios to match LMDB's space efficiency, but few can guarantee more than 2x compression on average. http://symas.com/mdb/inmem/scaling.html (By the way, I've got nothing against compression in general. In fact I was one of the pioneers of open source lossless data compression, nearly 30 years ago. https://sourceforge.net/p/arc/ It serves a purpose and I know, better than most, where it's useful and appropriate.)

Leaving aside the blatant ignorance and NIH-ism, this thread shines a bright light on the whole hazy question of "Unix design philosophy" that has shrouded the systemd debate. The Unix philosophy is to write small, single-purpose tools that can be composed together (in pipelines, via scripts, etc.) to build larger solutions. The systemd folks are quick to point out that systemd is not monolithic; it in fact currently is comprised of 69 individual binaries. http://0pointer.de/blog/projects/the-biggest-myths.html

This rebuttal from the systemd camp utterly misses the point though. Having 69 binaries that are all intimately tied together, interdependent, and written by the same person is just playing a shell game. The point in writing dedicated tools is to have dedicated authors, subject-matter experts, responsible for each tool. Unless you're an extremely gifted and brilliant individual, you cannot acquire and maintain expertise in all of the subject areas that a complex system requires for its operation. The systemd team has clearly demonstrated that they're incompetent at designing robust multi-process data storage systems. What else in their all-in-one kitchen sink project have they also failed to design competently, leaving implementation issues aside? Which other viable technologies have they ignored, in their quest for in-house homegrown purity?

[highlandsun]

So in other words, a developer is greatly offended that they chose to use their own solution rather than the solution he developed and that his company offers paid support for. I am sure he is a totally unbiased source on that.

Way to utterly miss the point.

[highlandsun]

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.

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.

[droste]

Could someone post a summary of arguments made in this?

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.

[Luke]

This story cannot be read by those of us who don't want LinkedIn Accounts

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

An attempt to read this gets a redirect to their login page if JS is enabled, and an almost blank page if JS is disabled-at least in Torbrowser.
I don't trust social networking sites, and as a user of systemd on a sensitive system I do need to know if any of this relates to potential
for back doors. Could someone post a summary of arguments made in this?

My own examination of the systemd "cryptsetup" module's source hasn't found anything obvious, but this kind of discussion
should take place in the open and not in locked forums.

We need to keep many eyes on the kernel, on crypto libraries, on browsers, and on systemd. In all cases this is so nobody is tempted to try
a little "underhanded C" and so that accidently introduced security bugs are found by us before they are found by the NSA or other hostile
exploiters. There must never be another "heartbleed," at least with FOSS software it's possible to audit this stuff.

[TheBlackCat]

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

So in other words, a developer is greatly offended that they chose to use their own solution rather than the solution he developed and that his company offers paid support for. I am sure he is a totally unbiased source on that.

[highlandsun]

Why you cannot trust Lennart Poettering / systemd

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/article/20140924071300-170035-why-you-cannot-trust-lennart-poettering-systemd