Devuan Jessie beta released

Posted May 2, 2016 8:06 UTC (Mon) by Cyberax (✭ supporter ✭, #52523)
In reply to: Devuan Jessie beta released by jaromil
Parent article: Devuan Jessie beta released

> your comments are offensive and contain false information about Devuan.
Really?

> We don't intend to keep everything the same, this is also stated on the website regarding ongoing research on init systems. I'll be looking at nosh, while being a fan of GNU DMD.
Yeah, sure. I predict that it'll end up with a huge "best init system" bikeshed thread. And since half of those "veteran unix adminstrators" have superstitions against cgroups ("It can steal your soul!"), nothing really interesting will come out.

> You seem to imply Devuan is an init system project. Its not: we are developing a new base distribution, which to us mostly means binaries and a very minimal, non obtrusive layer to handle their execution.
So far I see pointless crusades against libsystemd and pretty much nothing else.

to post comments

Devuan Jessie beta released

Posted May 2, 2016 8:36 UTC (Mon) by jaromil (guest, #97970) [Link] (12 responses)

>> your comments are offensive and contain false information about Devuan.
>Really?

yes.

> "veteran unix adminstrators" have superstitions against cgroups ("It can steal your soul!")

false information. is this a literal quote? if not, why quotes?
FYI what we call VUA is an informal group of IT professionals counting more than 1000 subscribers.

> So far I see pointless crusades against libsystemd and pretty much nothing else.

False information.

Devuan is not waging any crusade against libsystemd. There is nothing religious in what we do. Believe it or not, some of us have nothing against systemd per-se.
Referring to your statement here: libsystemd is a package still found in Devuan's beta release.

Devuan Jessie beta released

Posted May 2, 2016 8:45 UTC (Mon) by Cyberax (✭ supporter ✭, #52523) [Link] (10 responses)

> false information. is this a literal quote? if not, why quotes?
Just read _this_ article. Lots of systemd haters simply have no idea what cgroups do and why they are needed.

> Devuan is not waging any crusade against libsystemd.
Yes, it does.

Other readers, sorry for the quote:
> Since I'm running Debian testing on my desktop, I decided to look at the
> packages, and there it was, systemd was installed automatically somehow
> when upgrading my packages! I've installed Debian once, 10 years ago,
> and was just upgrading the packages occasionally ever since then, so
> package upgrades was the only way systemd was able to sneak into my
> computer. It feels like my computer was infected by a bad virus. I
> quickly removed the systemd package and all packages that depended on it
> without issues. However, I noticed libsystemd0 was still installed and
> doing a reverse dependency check showed that there are lots of important
> packages that indirectly depended on it because of dbus depending on it.
> That is clearly a bug, and I hope Debian can fix this issue. Normally,
> I wouldn't object to having some library installed, but from what I read
> about systemd from the links on your site, it's so awful that I don't
> even want its library installed on my computer.

> Referring to your statement here: libsystemd is a package still found in Devuan's beta release.
That's because this crusade is abandoned because of too much work. As ultimately other stuff is going to be abandoned.

But please, do continue to provide entertainment.

Devuan Jessie beta released

Posted May 2, 2016 8:51 UTC (Mon) by jaromil (guest, #97970) [Link] (9 responses)

We should try to stick to technical arguments. While we do, nothing prevent people from coming here or on our mailinglist or on our IRC channel to posting text which basically amount to rants without technical merit.

You are one of those people, as your interaction here is manipulative, offensive and does not contain any factual evidence for your assertions.

Devuan Jessie beta released

Posted May 2, 2016 8:59 UTC (Mon) by Cyberax (✭ supporter ✭, #52523) [Link] (8 responses)

Technical arguments? Who cares about technical arguments?! SystemD is the Great Satan of software and must be destroyed.

You asked for evidence about libsystemd crusade - I provided a quote from a previous version of the Devuan website. And this very thread has uninformed rants against control groups.

Others might try to read the Devuan mailing list and confirm it for themselves. It's helpfully archived by gmane: http://news.gmane.org/gmane.linux.devuan.devel

Devuan Jessie beta released

Posted May 2, 2016 9:55 UTC (Mon) by jrigg (guest, #30848) [Link]

> Technical arguments? Who cares about technical arguments?!

Most of the readers here, I imagine. Is it too much to ask to keep the discussion on a polite and rational level?

Devuan Jessie beta released

Posted May 2, 2016 14:50 UTC (Mon) by mgb (guest, #3226) [Link] (4 responses)

> Technical arguments? Who cares about technical arguments?! SystemD is the Great Satan of software and must be destroyed.

Great Satan? No. Harmful monolithic hack? Yes.

Hacking is creative and wonderful. Much that is good in computer science started as hacks. But init systems are not new. Dependency-based init systems are not new. Gnu/Linux needs an engineered init solution, not a hack backed by a tawdry political movement. I don't know who V.R. is but this is half of the sort of document that the Debian Tech Committee should have produced instead of the hand-waving we saw from both sides: http://blog.darknedgy.net/technology/2015/10/11/0/ Anyone who has to use systemd would do well to read V.R.'s document for a much better understanding than systemd's own documentation offers.

Nevertheless, despite ignoring decades of software engineering, the systemd hack would still be a valuable experiment if it were truly modular. It is not. It has a vast and untidy surface over a convoluted and unstable interior. There are arguments to the contrary by those who look at the nitty gritty of makefiles and build options while ignoring the big picture but the fact is that distros are splitting into with-systemd and without-systemd flavors because by intent and by poor design systemD is in practice monolithic.

Systemd succeeded because Gnu/Linux is modular - truly modular in practice. But SystemdD itself is monolithic. It blocks the way forward for Gnu/Linux. This is why I have always opposed systemd and why the route forward from Wheezy is Devuan. Not because systemd was an undesigned hack that just grew and metastasized, not because systemd is a bad implementation of a good idea, but because systemd seriously impedes the future development of F/LOSS.

Devuan Jessie beta released

Posted May 2, 2016 15:16 UTC (Mon) by peter-b (guest, #66996) [Link]

I'm looking forward to your forthcoming good implementation of systemd's "good idea". If it successfully addresses the problems that systemd solves, then I'm sure it will be adopted very enthusiastically.

I don't mean this sarcastically or dismissively -- I genuinely believe that there is space for multiple implementations of a good dependency-based, race-free init system for Linux. Even better if it exposes an implementation of the public systemd API so that people can try it out with their existing tools more easily.

Devuan Jessie beta released

Posted May 2, 2016 15:21 UTC (Mon) by anselm (subscriber, #2796) [Link] (1 responses)

… but because systemd seriously impedes the future development of F/LOSS.

Considering that the cobbled-together suckage that is the traditional setup (System-V init, init scripts, inetd, cron, at, syslogd, …) apparently hasn't managed to seriously impede the future development of F/LOSS for the last 25 years or so, I wouldn't worry unduly about systemd. People have obviously dealt with much worse stuff than systemd (and by all indications don't mind planning on still dealing with it going forward, see Devuan), or we wouldn't be here now.

Devuan Jessie beta released

Posted May 2, 2016 15:59 UTC (Mon) by johannbg (guest, #65743) [Link]

Well there are cases where you still "cobbled-together" components with systemd like for example it's a common misconception that type timer units replace a cron based solution that stems from people filled with the bright idea of migrate "everything" to native systemd type units which ends up like a work of bunch of idiots re-implementing cron in the form of timer units but now with the double the administrative overhead to it's end users and no technical benefits.

When I went through the whole components that ship cron scripts in Fedora ( ca 100 components ) only half of that was applicable to be migrated to timer units and once I had gone through those ca 50 components that ship those cron scripts and filtered out the unused, obsoleted scripted trash which seem to be shipped and exist only to waste peoples space on hardrives or serve as an example to the terminal world how not to write a script, I ended up with roughly 30 components which would have been migrated.

In the above example these two solution complement each other short comings and should be implemented as such where applicable in the distribution and elsewhere not re-implemented in the form of type timer units instead of cron scripts because they "can" or systemd is "hot" for the moment.

Devuan Jessie beta released

Posted May 2, 2016 18:19 UTC (Mon) by Cyberax (✭ supporter ✭, #52523) [Link]

> Gnu/Linux needs an engineered init solution
Then provide one.

> I don't know who V.R. is but this is half of the sort of document that the Debian Tech Committee should have produced instead of the hand-waving we saw from both sides: http://blog.darknedgy.net/technology/2015/10/11/0/ Anyone who has to use systemd would do well to read V.R.'s document for a much better understanding than systemd's own documentation offers.
I read this document. I don't see any real technical points against systemd design in principle. And no, "inelegant" does not count. Real-life systems are almost always "inelegant" from theoretical standpoint.

There are also lots of inaccuracies in details (like the statement that cgroups v2 requires the single writer).

And really, statements like:
> It should be noted that dynamic tracing is another potential way to achieve deferred execution conditional upon resource availability.
Are a _huge_ warning sign for anybody maintaining real-life systems.

Devuan Jessie beta released

Posted May 2, 2016 18:55 UTC (Mon) by flussence (guest, #85566) [Link] (1 responses)

>Technical arguments? Who cares about technical arguments?! SystemD is the Great Satan of software and must be destroyed.

I thought GPL was. Changed your mind already? ;)

Devuan Jessie beta released

Posted May 2, 2016 19:30 UTC (Mon) by Cyberax (✭ supporter ✭, #52523) [Link]

GPL is the Greater Great Satan. Duh.

Devuan Jessie beta released

Posted May 2, 2016 13:19 UTC (Mon) by smcv (subscriber, #53363) [Link]

> Devuan is not waging any crusade against libsystemd

From the outside, its long list of forked packages certainly gives the impression that it is. I maintain dbus upstream and in Debian, so I was curious what the debdiff for that source package would look like.

It appears that the changes are as follows:

* Remove the libsystemd build-dependency and don't pass --enable-systemd to configure. This is the "don't link libsystemd" change.

* Don't pass --with-systemdsystemunitdir to configure. Together with the previous, this results in the systemd metadata (a few hundred bytes of text) not being installed.

* Merge the version of dbus 1.8.20 that used to be packaged in stretch before it was superseded by 1.10 (1.8.20-1), not the version that is in jessie (1.8.20-0+deb8u1, which has the new upstream version but not the packaging changes). This does not fill me with confidence about Devuan's change-management: if I had intended those packaging changes to be in a jessie stable-update, I would have put them there. I suspect this was accidental. However, it's nice to know that I'm more conservative about what I'll include in a stable update than Devuan developers are...

Why are you bothering to patch this package for those, if the answer isn't "removing libsystemd for political reasons"? Even if we take it as axiomatic that systemd will not be used, the only positive technical effect of diverging from Debian here is to save a few K of disk space (a library and metadata that would not have been used if init wasn't systemd). This seems a deeply inefficient use of developer time; you could save much more space than that, if that's your goal, by compressing /usr/share/doc/*/copyright.

If you do want to remove libsystemd for political reasons, something like https://anonscm.debian.org/cgit/users/md/libsystemd-dummy... [1] would involve an order of magnitude less forking than what you seem to have done. Every package you fork consumes developer time and is an opportunity to introduce bugs and/or delay security fixes; if it has taken this long to get a beta-quality fork of Debian 8, it seems that developer time is a resource that should be used wisely.

I should perhaps mention here that in addition to libsystemd, dbus-daemon in Debian links two libraries that can never be in active use at the same time[2]: libapparmor and libselinux. This nicely illustrates how, if your goal is to minimize unused library dependencies, Debian is unlikely to be the best place to start. Fedora, for example, has a much closer focus on providing only the things that are actively supported, with SELinux and no AppArmor in their dbus-daemon. The flip side of that is that they only support their chosen init system, which happens to be systemd.

Once again, I work on Debian, not Fedora; I don't think minimizing unused library dependencies is actually a particularly useful goal, so I ship a dbus-daemon in Debian that can be used to its full potential with any or no LSM, and with or without systemd.

[1] provided by a Debian systemd maintainer out of frustration with how some anti-systemd efforts were approaching their chosen task
[2] assuming the corresponding "big LSMs" don't become stackable at kernel level, which seems unlikely