On Wed, 1 Jul 2015 19:36:07 +0100 João Miguel wrote:

Nonetheless, respecting the quoted principle, I could easily replace systemd by OpenRC when I chose to. Note that just last month, over 3 years had passed after systemd was adopted, and I could still use OpenRC. Now, for whatever reason, the principle was broken without notice. I'd expect news or an email in this mailing list, to which I've been paying close attention (though I knew less than the authors about most problems...).

Feels like this post[1] by Adam Jackson fits perfectly. Calling for freedom or choice is not going to help anyone. [1] https://www.redhat.com/archives/rhl-devel-list/2008-January/msg00861.html Maintaining a distro is hard, takes a lot of time and effort and nobody here is payed for their work on Arch. If you have problems please talk about those problems, not about workarounds that break. We might be able to resolve actual issues, but to do that we need to know what is broken, not how you work around that breakage.

...

Upstreams are integrating support for systemd features and Arch is going to be enabling them, whether it's sd_notify support or something else. Upstream? Then why is it that for the same versions of the same packages, say, in Gentoo they are not dependencies? Example, compare these two:

https://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/x11-drivers/xf86-in... https://www.archlinux.org/packages/extra/x86_64/xf86-input-evdev/

If you believe this dependency is wrong create a bug report or talk to the maintainer and find out why they think it is necessary. If it turns out it's incorrect I'm sure it will be removed.

On 01-07-15 21:12, David Kaylor wrote:

...

I rest my case. Again, any reply is welcome.

You are wasting your keystrokes and your time.

Arch devs have long since decided to make systemd an integral part of Arch Linux. And I didn't like it any more than you do, at first. Actually there are 2 actively maintained implementations of openrc for arch : Apg way (uses udev from systemd but everything else is openrc) and artoo way (can be used with eudev) .

Users of both variants communicate through this forum thread : https://bbs.archlinux.org/viewtopic.php?id=152606 LVV

On 01/07/15 02:36 PM, João Miguel wrote:

First of all, thank you for such a quick reply.

Now, I don't want to preach. But I will not pretend I chose Arch Linux at random. I chose it for many reasons, an important one of them being that I liked the Arch Way, it made sense to me, and it seemed you were following it. Now it seems to belong to a forgotten past.

On Wed, Jul 01, 2015 at 10:34:01AM -0400, Daniel Micay wrote:

...

Arch is as much a systemd-based distribution as it is a Pacman-based distribution at this point. (...) Is it now? https://wiki.archlinux.org/index.php/The_Arch_Way

That's an unprotected page on the wiki, not an authoritative source on anything to do with the distribution. Arch has always been a simple distribution in terms of the developer perspective, not the user one. Using systemd made it simpler than ever in that regard because much more work is taken care of by both the systemd developers and all of the projects shipping unit files. It has never been a minimalist distribution. Splitting packages is rare compared to other distributions, and dependencies aren't made optional whenever possible. It has also never been a distribution offering much user freedom / choice compared to Gentoo and even Debian. There are very few cases where there are multiple packages offering different configurations of the same project. There's no equivalent to update-alternatives or the comparable uses of USE flags. Changing /bin/sh from Bash will be broken, as will changing the python symlink to point to python2 instead of python3 even though this works on some other distributions. It doesn't strive to offer choices like this, and never has. It would mean a *lot* more complexity on the development side of things along with major deviations from upstream. Arch is the *opposite* of a user-centric freedom. The opinion of users has no weight here. Only the developers have an opinion, and there aren't voting systems as there are in Debian. Technical decisions are made based on merit via consensus among the developers, not popularity.

it is not simple, not minimalist, and not user-centric.

Certainly not minimalist, but those other two claims are questionable. Arch has *never* been minimalist... a Linux kernel with every module available and every feature enabled at least when there's no non-bloat related cost, feature-packed/complex GNU tools, nearly all optional features enabled across all the packages, etc.

However, making so many packages depend on it so that any basic desktop usage (in the case of the util-linux dependency, even non-graphical usage) does break one principle listed in the aforementioned page: freedom. In fact, I ought to quote it:

Arch is the opposite of a distribution with lots of user freedom. Users will come and go based on whether they like the technical decisions made by the developers. The popularily of those decisions has no impact on how things are done, regardless of how vocal users are about it.

Nonetheless, respecting the quoted principle, I could easily replace systemd by OpenRC when I chose to. Note that just last month, over 3 years had passed after systemd was adopted, and I could still use OpenRC. Now, for whatever reason, the principle was broken without notice. I'd expect news or an email in this mailing list, to which I've been paying close attention (though I knew less than the authors about most problems...).

You can still use it, it's just becoming increasing more difficult at a pretty steady pace. Those packages didn't suddenly pick up systemd dependencies in the past few weeks / months anyway. The version control logs disprove the claim that there are many recent changes.

...

Upstreams are integrating support for systemd features and Arch is going to be enabling them, whether it's sd_notify support or something else. Upstream? Then why is it that for the same versions of the same packages, say, in Gentoo they are not dependencies? Example, compare these two:

Gentoo has USE flags so features can be optional at compile-time. Many of the packages with dependencies on systemd in Arch link against libsystemd, and we don't split up the package as is the norm here. If there's a package with an *unnecessary* dependency on systemd, you can and should file a bug. I don't think there are many that depend on it and don't use it.

That doesn't mean I want to compile everything. Or that you should have packages for, say, OpenRC. The packages in the repos are not my choice, I'm not asking to choose which ones should be on the official repos, that's what the unofficial repos and the AUR are for. It just means you shouldn't suppose people have these or those packages installed, but that instead, and as you did before, even years after systemd being default, you should provide whatever you want, open the doors you want, not closing any others. Minimalism means minimal dependencies too.

If I wanted systemd bloat and a dash of hypocrisy

What hypocrisy? When have you seen the developers state that they care about user freedom, or that the distribution is based on minimalism? Community memes don't define the distribution, technical choices by the developers do. It's clearly not based on what you say it is, and *never* has been. It has always used significantly more disk space and a measurable amount of additional memory than Debian and especially Gentoo as a consequence of keeping things simple (again, from a development perspective). I'd stay in Windows

installing Internet Explorer... I worry the suggestions to change distro The point is not one of telling what the devs should or shouldn't do

That's what you're doing.

but of remembering the principles upon which the community is based.

You can claim that the community is based on a set of principles, but it has nothing to do with technical decisions by the developers. Memes about minimalism and user freedom != actual distribution policy / principles / history.

On Thu, 2 Jul 2015 09:24:42 -0400, Daniel Micay wrote:

Arch is the *opposite* of a user-centric freedom.

I disagree.

...

it is not simple, not minimalist, and not user-centric.

Certainly not minimalist, but those other two claims are questionable.

I agree. Reasoning: With everything Arch provides regarding it's policy, it's following the KISS principle. Since software from upstream usually is not split into tons of packages, it might be not minimalist, but even this could be handled, since pacman.conf provides the NoExtract option. Assumed a package comes with an unneeded dependency, it's easy to provide an empty dummy package to resolve this unneeded dependency. There's no need to compile it from ABS with special configure options, assumed the dependency is really unneeded. The user centric-freedom still is, that we users could make our individual installs, the way we like it, without much pain, by e.g. providing outdated libs and resolving unneeded dependencies. I'm not in favour of systemd, but for me the drawbacks caused by systemd are still big nothing compared to the advantages provided by Arch Linux, IOW I like the KISS principle policy and the user-centric policy. The fight against systemd was lost a long time ago. We can live with systemd or use another distro, period. If we are using Arch with systemd and run into issues, we are free to send requests to this list or a forum. IMO we shouldn't continue another Arch systemd policy thread, since we finished this discussion a long, long time ago. Regards, Ralf

On Thu, 2015-07-02 at 09:24 -0400, Daniel Micay wrote:

On 01/07/15 02:36 PM, João Miguel wrote:

...

First of all, thank you for such a quick reply.

Now, I don't want to preach. But I will not pretend I chose Arch Linux at random. I chose it for many reasons, an important one of them being that I liked the Arch Way, it made sense to me, and it seemed you were following it. Now it seems to belong to a forgotten past.

On Wed, Jul 01, 2015 at 10:34:01AM -0400, Daniel Micay wrote:

...

Arch is as much a systemd-based distribution as it is a Pacman -based distribution at this point. (...) Is it now? https://wiki.archlinux.org/index.php/The_Arch_Way

That's an unprotected page on the wiki, not an authoritative source on anything to do with the distribution.

Arch has always been a simple distribution in terms of the developer perspective, not the user one. Using systemd made it simpler than ever in that regard because much more work is taken care of by both the systemd developers and all of the projects shipping unit files.

It has never been a minimalist distribution. Splitting packages is rare compared to other distributions, and dependencies aren't made optional whenever possible.

It seems these types of discussion pops out once in a while. Personally, I think that systemd has a lot qualities. The only thing that I do not like about it it is that does not follow the UNIX philosophy. Philosophy that has made UNIX/Linux so successful for so many years. Read The Art of UNIX Programming from Eric Raymond to know what that philosophy really is. That being said, no one can really complain given that you receive what you have paid for. I understand that very influent people among the Arch dev community are also major contributors of systemd so it is quite natural that ArchLinux is a systemd based dist. Red Hat has interests in systemd success. Who can blame an organisation trying to dominate and success? It is the nature of the beast... As a user, despite not having easy alternatives if I wanted to switch to a different init system, ArchLinux still provide the best Linux experience that I ever had!

On 02/07/15 02:34 PM, Neven Sajko wrote:

Daniel Micay dixit:

...

The package isn't going to be split so it doesn't make much sense to refer to libsystemd.

It is split: https://www.archlinux.org/packages/core/x86_64/libsystemd/

I know it's split into systemd, libsystemd and systemd-sysvcompat. The split is there to break a cyclic dependency, and doesn't provide the flexibility offered by Debian's systemd split including breaking up libsystemd. They have it set up so you can run things like systemd-logind without systemd as init (or installed at all).

I am a bit disappointed to hear that there appears to be such a large disconnect between the developer philosophy and the user philosophy in the community. Even the website itself (which granted in many cases simply points to various wiki sections), tends to give the impression the Arch Way and philosophy are user centric. In fact. It even has an entire "user centric" point in it. To hear that this "Arch Way" is not an official stance but something the community came up with is news to me. I'm completely fine with the focus being entirely on simplicity and minimalism from a dev standpoint. There is something to be appreciated there. However, I feel that perhaps the community image may need some clarity for that. Looking at everything in The Arch Way wiki page (except the user centric portion), as well as most other things I can easily see it being taken either way. And most of us may not be concerned with that dev central focus being the philosophy applied as the developer's desires line up with our use cases. I believe though one of the biggest strengths of the free/open software community is being able to make the decision to deal with something or not after gathering the necessary information. In this case, the presentation of that information may require some clarity. Heck, it's entirely possible it is perfectly clear somewhere but just being missed by users. On Thu, Jul 2, 2015 at 2:33 PM, Eduardo Machado wrote:

2015-07-02 10:24 GMT-03:00 Daniel Micay :

...

...

First of all, thank you for such a quick reply.

Now, I don't want to preach. But I will not pretend I chose Arch Linux at random. I chose it for many reasons, an important one of them being

On 01/07/15 02:36 PM, João Miguel wrote: that

...

I liked the Arch Way, it made sense to me, and it seemed you were following it. Now it seems to belong to a forgotten past.

On Wed, Jul 01, 2015 at 10:34:01AM -0400, Daniel Micay wrote:

...

Arch is as much a systemd-based distribution as it is a Pacman-based distribution at this point. (...) Is it now? https://wiki.archlinux.org/index.php/The_Arch_Way

That's an unprotected page on the wiki, not an authoritative source on anything to do with the distribution.

Arch has always been a simple distribution in terms of the developer perspective, not the user one. Using systemd made it simpler than ever in that regard because much more work is taken care of by both the systemd developers and all of the projects shipping unit files.

It has never been a minimalist distribution. Splitting packages is rare compared to other distributions, and dependencies aren't made optional whenever possible.

I disagree, it is indeed a minimalist, i only install what i want. ok, it can be not the most minimalist, but it is, in a good deal.

...

It has also never been a distribution offering much user freedom / choice compared to Gentoo and even Debian. There are very few cases where there are multiple packages offering different configurations of the same project. There's no equivalent to update-alternatives or the comparable uses of USE flags. Changing /bin/sh from Bash will be broken, as will changing the python symlink to point to python2 instead of python3 even though this works on some other distributions. It doesn't strive to offer choices like this, and never has. It would mean a *lot* more complexity on the development side of things along with major deviations from upstream.

Arch is the *opposite* of a user-centric freedom. The opinion of users has no weight here. Only the developers have an opinion, and there aren't voting systems as there are in Debian. Technical decisions are made based on merit via consensus among the developers, not popularity.

WHAT? The opinion of users has no weight here ?!?!?! I came to Arch because th way it is built and "marketed" looked like a real community and user centric, user centric not to be as easy as pushing a button, but in the way that i can install, configure, and use it the way i want to. Is that real?

If Arch is becoming a personal distribution to attend the developers, so let it clrealy in the website, so we consider choosing a new way. But to realize such an affirmation is a little bit dismotivating at minimum.

Although this subject, i wanna thanks the devs; because everyone knows it a hard work and Arch devs always did a great work.

The real POINT here is that, ANY decision made (not only systemd) have its pros and cons, but when someone ask for something different or question that, it is wise to listen, think, and answer in an polite way. Recently i am seeing much rage in talks, i think i will be better, and constructive, to filter better the words so that we can have a kind of a talk.

...

...

it is not simple, not minimalist, and not user-centric.

Certainly not minimalist, but those other two claims are questionable.

Arch has *never* been minimalist... a Linux kernel with every module available and every feature enabled at least when there's no non-bloat related cost, feature-packed/complex GNU tools, nearly all optional features enabled across all the packages, etc.

...

However, making so many packages depend on it so that any basic desktop usage (in the case of the util-linux dependency, even non-graphical usage) does break one principle listed in the aforementioned page: freedom. In fact, I ought to quote it:

Arch is the opposite of a distribution with lots of user freedom. Users will come and go based on whether they like the technical decisions made by the developers. The popularily of those decisions has no impact on how things are done, regardless of how vocal users are about it.

...

Nonetheless, respecting the quoted principle, I could easily replace systemd by OpenRC when I chose to. Note that just last month, over 3 years had passed after systemd was adopted, and I could still use OpenRC. Now, for whatever reason, the principle was broken without notice. I'd expect news or an email in this mailing list, to which I've been paying close attention (though I knew less than the authors about most problems...).

You can still use it, it's just becoming increasing more difficult at a pretty steady pace. Those packages didn't suddenly pick up systemd dependencies in the past few weeks / months anyway. The version control logs disprove the claim that there are many recent changes.

...

...

Upstreams are integrating support for systemd features and Arch is going to be enabling them, whether it's sd_notify support or something else. Upstream? Then why is it that for the same versions of the same packages, say, in Gentoo they are not dependencies? Example, compare these two:

Gentoo has USE flags so features can be optional at compile-time. Many of the packages with dependencies on systemd in Arch link against libsystemd, and we don't split up the package as is the norm here. If there's a package with an *unnecessary* dependency on systemd, you can and should file a bug. I don't think there are many that depend on it and don't use it.

...

That doesn't mean I want to compile everything. Or that you should have packages for, say, OpenRC. The packages in the repos are not my choice, I'm not asking to choose which ones should be on the official repos, that's what the unofficial repos and the AUR are for. It just means you shouldn't suppose people have these or those packages installed, but that instead, and as you did before, even years after systemd being default, you should provide whatever you want, open the doors you want, not closing any others. Minimalism means minimal dependencies too.

...

If I wanted systemd bloat and a dash of hypocrisy

What hypocrisy? When have you seen the developers state that they care about user freedom, or that the distribution is based on minimalism?

Community memes don't define the distribution, technical choices by the developers do. It's clearly not based on what you say it is, and *never* has been. It has always used significantly more disk space and a measurable amount of additional memory than Debian and especially Gentoo as a consequence of keeping things simple (again, from a development perspective).

I'd stay in Windows

...

installing Internet Explorer... I worry the suggestions to change distro The point is not one of telling what the devs should or shouldn't do

That's what you're doing.

...

but of remembering the principles upon which the community is based.

You can claim that the community is based on a set of principles, but it has nothing to do with technical decisions by the developers. Memes about minimalism and user freedom != actual distribution policy / principles / history.

-- The irony is that Bill Gates claims to be making a stable operating system and Linus Torvalds claims to be trying to take over the world. -- seen on the net

Now, it would be technically possible to replace *systemd* in base with a generic "init-system" which could be provided by both *systemd* and *openrc*, but that would make things much more complicated and *much* more effort to maintain.

Packages don't have a dependency on systemd because they need an init system. They have a dependency on systemd IPC interfaces and/or libraries not provided by openrc. If they depend on systemd without needing something like this, it's a (very minor) bug to report. Supporting alternative implementations of those interfaces (like Debian's systemd-shim) would mean a lot of extra work across the distribution. Arch supports one specific /bin/sh implementation, one standard C library, one standard C++ library, one C++ exception model, one toolchain for building the system, etc. It also tends to only support one specific implementation of a command-line utility as the main tool and others have to be namespaced. Packages like util-linux/coreutils aren't split into little pieces and there's no equivalent to update-alternatives. Sure, packages like musl, libc++, libc++abi and busybox are in the repositories but not in a way that can actually replace anything in the base system, it just lives alongside it without being used by any other packages. Arch only ever supported one init system until the transition period to systemd where it supported two. The old initscripts adopted systemd utilities like systemd-tmpfiles before going away anyway, and the old scripts were still supported. It was convergence to a single supported init system rather than two choices for the base system living alongside each other. Making technical decisions and then going through with them with proper integration into other packages is the only way that things are going to be polished. The alternative is a *lot* of extra complexity, development effort and bugs.

While technical debate can be productive when it's not simply rehasing the same things over and over again, simply voicing opinions is not. I don't think it would be a good idea to develop any distribution based upon the opinions of whoever shouts the loudest. Decisions are made based on consensus among the people doing the work whether they are Arch developers, trusted users or other contributors in the community without those fancy titles. Arch isn't striving for popularity so the popularity of the decisions among the users isn't important. It's developed for the people doing the work. I interpreted this thread as a bug report with 'The Arch Way' page on the wiki so it hasn't been for naught. That page has been rewritten to better reflect what has always been the development philosophy instead of being a vague advertisement for the distribution with questionable claims. https://wiki.archlinux.org/index.php/The_Arch_Way It's not perfect, but it's a lot more grounded in reality now.

WHAT? The opinion of users has no weight here ?!?!?!

Popular opinion has no weight. Zero. Technical arguments have weight but most of them have already been debated for ages. There's a strong consensus among the developers (and trusted users / other people who contribute, but that's less important) in support of the status quo. Additionally, if by 'here' you mean arch-general... most developers probably don't subscribe to this list at all. It's used for requesting help and flame wars. I'm quite sure that nothing said in this thread is going to have any impact on Arch's development. There's little else to be said about these topics. It's just a repeat of the same things over and over again and that's exactly why it's not on the radar in terms of development.

I came to Arch because th way it is built and "marketed" looked like a real community and user centric, user centric not to be as easy as pushing a button, but in the way that i can install, configure, and use it the way i want to. Is that real?

It's a community distribution in the sense that the developers aren't paid employees and there's no backing corporation. You can install, configure and use it however you want but the developers are only going to support the use cases they care about. In the base system, there's usually *one* supported option for that component (glibc, libstdc++, libsupc++, coreutils/util-linux, systemd, binutils/gcc, etc.). As a binary distribution, it *has* to make many of these decisions, and others like choosing one init system need to be made to have a polished, maintainable distribution.

If Arch is becoming a personal distribution to attend the developers, so let it clrealy in the website, so we consider choosing a new way. But to realize such an affirmation is a little bit dismotivating at minimum.

It has always been a distribution built around the technical views of the developers. Unlike many other distributions, it doesn't try to appeal to a broad audience. That's what makes it Arch rather than say a distribution like OpenSUSE. There's always room for more contributors, and they'll quickly become trusted users / developers if they're talented and get along with the other developers. The people doing the work are the ones making the decisions, as things usually are in open source projects.

The real POINT here is that, ANY decision made (not only systemd) have its pros and cons, but when someone ask for something different or question that, it is wise to listen, think, and answer in an polite way. Recently i am seeing much rage in talks, i think i will be better, and constructive, to filter better the words so that we can have a kind of a talk.

It's not like this is a technical discussion providing anything positive for the distribution's development. It would be a lot more constructive for everyone to avoid wasting time like this. The constructive thing to do is accepting that Arch isn't a meta distribution like Gentoo. It only supports choice *above* the layer of the base system. You don't get to replace glibc, the toolchain, the core utilities, the init system / core services (i.e. systemd), etc. without venturing into extremely painful unsupported territory. There are *lots* of other distributions, and most settle on either using systemd or not supporting it *at all*, up to the point that unit files are stripped out of packages (as Alpine does).

I personally prefer systemd over the alternatives. I grant there's considerable feature creep, but the people who complain a lot either don't offer an alternative, or the one alternative they offer is the frankly broken system Linux had been using since the dawn of time. I wouldn't mind some spiritual successor to systemd where its entire purpose is to be init, without sacrificing some of the more useful/powerful features like cgroups, concurrency, and the like. Systemd went wrong when it started going into stuff that init itself really doesn't need to manage on its own. SysV Init needs to die, let's move on. OpenRC is not enough to save it. On Thu, Jul 2, 2015 at 10:49 PM, Bardur Arantsson wrote:

On 07/03/2015 12:19 AM, Daniel Micay wrote:

...

...

WHAT? The opinion of users has no weight here ?!?!?!

[--snip--]

Just to add a little bit to what Daniel said: Can we please calm down a bit here?

It's not like there's no overlap between what developers want and what ordinary users want -- in fact there seems to be rather a lot of overlap given the number of users Arch has. Remember that developers are users too!

(P.S. I'm not a developer/packager just an ordinary user.)

On 01/07/15 07:14 PM, Jens Adam wrote:

Thu, 2 Jul 2015 00:43:13 +0200 Guus Snijders :

...

...

Why in the world should util-linux require systemd!? Why do all these packages need it when they were fine without it before?

The first question is a relatively simple, technical question. My guess is that the util-linux won't currently run without system installed, hence the dependancy. Arch packages are usually quite 'clean' in that respect. It's probably possible to recompile it without that dependency for this specific case.

A little fiddling with 'pacman -Qql util-linux' and 'ldd' reveals that the only tools linked to (lib)systemd are 'logger', 'lslogins' and 'uuidd'.

So it's a hard runtime dependency for a core tool that's widely used (logger). Making it into an optional dependency would cause runtime crashes and it would be especially bad in this case because other packages depend on util-linux for utilities like logger. Splitting it out into another package would be the Debian solution, but Arch avoids that to avoid complexity. Gentoo handles this with USE flags.

Aside from that: Yes, some packages do have too broad dependencies (e.g. systemd instead of libsystemd) and it certainly didn't help that udev became part of systemd, but in the end the train we're on drove off long ago, so until systemd's successor arrives on the scene it's probably best to accustom yourself to it and test it until all the bugs and edge cases are accounted for.

The package isn't going to be split so it doesn't make much sense to refer to libsystemd. It's considered part of the mandatory base system and the developers aren't going to go out of the way to make it optional by adding this kind of complexity on their end.w

On Fri, Jul 3, 2015 at 1:10 PM, LoneVVolf wrote:

This blog post gives the best description of systemd flaws i am aware of : http://judecnelson.blogspot.fi/2014/09/systemd-biggest-fallacies.html

That is one of the worst descriptions of problems in systemd that I am aware of:-) The author completely misses that systemd is a layered architecture which at its core provides (mostly) a convenient cgroups interface. Other services are layered on top of that core functionality and in turn provide more interfaces, that in turn other services depend upon. None of the other init system can provide similar basic services, so none can even come close to replacing systemd at this time. That is actually a bit sad, a bit of competition has never hurt:-) Best Regards, Tobias

To be fair: There is more to here than "Unix philosophy" and "I hate Lennart". Number 1 is "systemd is a monolithic mess" and reveals a glaring misunderstanding of layered architectures. He is basically claiming that kernel/xorg/browser is one mess since the browser won't start without the kernel and xorg running at the same time. Number 2 about "everybody uses systemd" is barking up the wrong tree: The question is not "Why do distributions adopt systemd?", it is "Why do developers adopt systemd?". Distributions have to tag along for the ride once enough developers use the stuff. He sees that ("A big motivating factor is that other application suites (e.g. GNOME) increasingly depend on it to work."), but does not bother to examine that issue. Number 2 is "systemd is not for every use case" and he is actually right with that. Number 4 is about shell scripting and that you could have shell scripts that are as clean as systemd unit files... if that was true, then at least one distribution would have managed that in the last couple of decades. He is right that systemd does not reduce complexity though, it just moves it into a different place. That in itself is a big achievement though. Number 5 is "you can use Linux specific features without systemd", which is correct, but it is less convenient to do, so nobody bothered. Systemd did make many of those features mainstream. Number 6 is "No other init provides anything of value to userspace (besides starting stuff), so systemd is evil for doing that." Number 7 is "all the claimed benefits of systemd can be archived differently", which is obviously correct. Pretty close to Number 5 though. Number 8 is "but everything does indirectly depend on systemd as init, not just on services provided by things in higher layers", which is just another misunderstanding of a layered architecture. Number 9 boils down to "systemd is too complex for some use cases". He is right there, just as he was in Number 2 before. Number 10 is the boring binary logging again. Nothing new here... but he raises one interesting question: Why have a journal when it can just forward to syslog? Because systemd needs to log stuff, even when syslog is not yet running or was already stopped. So it needs to either throw away the logs (which is what sysv init did) or it needs to have some internal interface that makes sure stuff is not lost and can optionally interface with syslog when that is available. That is pretty much what the journal is. It did grow a bit from there once it became clear that it is useful. Number 11 is "I do not like Lennart", which I actually consider to be a valid point. He is right in claiming that there is a social component to projects and that this does influence the selection of software one is comfortable to run. Number 12 is "the kernel is complex is no excuse for systemd being complex". Mostly another misunderstanding about layered architectures that again result in the claim that systemd is a entangled mess. Number 13 is "most of systemd was written by just a handful of people", which is true for any open source project. IMHO that does not diminish the value of having many contributors at all: Those did read (parts of) the code and they do provide feedback and what not. And that's it... Best Regards, Tobias

On Fri, 3 Jul 2015 16:51:21 +0200 Bardur Arantsson wrote: <snip>

STOP!

Although I find the discussion interesting, I have watched with growing amazement. As I recall, this list became moderated due to the furore when systemd was introduced, and I doubt that Lennart himself could have got a post on the subject through in the aftermath. Geoff