Hi there,
Not sure whether I should email this mailing list about this problem, but here goes:
I've been using OpenRC in Arch Linux for a long time, and uninstalled systemd, as I don't use anything that requires it.
However, in the latest update it seems an awful lot of packages I use suddenly require systemd. First, I have a conflict between libgudev and eudev-systemdcompat, so the installation stops right there. I don't even remember a libgudev package when I used systemd! The pacman output, 1st refusing to remove eudev, then accepting, is as follows:
$ sudo pacman -Syu :: A sincronizar a base de dados de pacotes... core está actualizado extra está actualizado community está actualizado multilib está actualizado openrc-eudev está actualizado siosm-selinux está actualizado :: A iniciar a actualização do sistema... atenção: libselinux: local (2.4-1) é mais recente que siosm-selinux (2.2-1) atenção: libsepol: local (2.4-1) é mais recente que siosm-selinux (2.2-1) atenção: setools: local (3.3.8-5) é mais recente que siosm-selinux (3.3.8-1) a resolver dependências... a procurar pacotes em conflito... :: libgudev e eudev-systemdcompat estão em conflito (libsystemd). Remover eudev-systemdcompat? [s/N] erro: detectado conflito entre pacotes sem solução erro: falhou ao preparar a transação (dependências em conflito) :: libgudev e eudev-systemdcompat estão em conflito (libsystemd<221)
$ sudo pacman -Syu :: A sincronizar a base de dados de pacotes... core está actualizado extra está actualizado community está actualizado multilib está actualizado openrc-eudev está actualizado siosm-selinux está actualizado :: A iniciar a actualização do sistema... atenção: libselinux: local (2.4-1) é mais recente que siosm-selinux (2.2-1) atenção: libsepol: local (2.4-1) é mais recente que siosm-selinux (2.2-1) atenção: setools: local (3.3.8-5) é mais recente que siosm-selinux (3.3.8-1) a resolver dependências... a procurar pacotes em conflito... :: libgudev e eudev-systemdcompat estão em conflito (libsystemd). Remover eudev-systemdcompat? [s/N] s :: libgudev e eudev estão em conflito (libgudev-1.0.so). Remover eudev? [s/N] s erro: falhou ao preparar a transação (não foi possível cumprir as dependências) :: chromium: exige systemd :: libwacom: exige systemd :: libgudev: exige libsystemd :: libinput: exige systemd :: udisks2: exige systemd :: colord: exige systemd :: device-mapper: exige systemd :: lib32-systemd: exige systemd :: mesa: exige systemd :: lvm2: exige systemd :: subversion: exige systemd :: udisks: exige systemd :: xf86-input-vmmouse: exige libsystemd :: accountsservice: exige systemd :: ceph: exige libsystemd :: eudev-openrc: exige eudev :: kmscon: exige systemd :: libatasmart: exige libsystemd :: libgsystem: exige libsystemd :: libgusb: exige udev :: libpulse: exige systemd :: libusb: exige systemd :: lighttpd: exige systemd :: media-player-info: exige systemd :: mkinitcpio: exige systemd :: openrc-core: exige udev>=186 :: openvpn: exige libsystemd :: pcmciautils: exige systemd :: pkgstats: exige systemd :: procps-ng: exige libsystemd :: qt5-base: exige systemd :: qtwebkit: exige systemd :: rtkit: exige systemd :: syslog-ng: exige systemd :: upower-pm-utils: exige eudev-systemdcompat :: util-linux: exige libsystemd :: xf86-input-evdev: exige systemd :: xf86-video-openchrome: exige systemd
Why in the world should util-linux require systemd!? Why do all these packages need it when they were fine without it before? I wouldn't like to install systemd, but will if necessary. Nonetheless, I don't want it to replace OpenRC. What can I do? I want an updated system, but I'd very much prefer to have one without systemd.
Thank you in advance, João Miguel
On 01/07/15 09:52 AM, jmcf125@openmailbox.org wrote:
Why in the world should util-linux require systemd!? Why do all these packages need it when they were fine without it before? I wouldn't like to install systemd, but will if necessary. Nonetheless, I don't want it to replace OpenRC. What can I do? I want an updated system, but I'd very much prefer to have one without systemd
Arch is as much a systemd-based distribution as it is a Pacman-based distribution at this point. The best options you have available are switching to a distribution with official support for at least one other init system without any of systemd installed (Gentoo, Alpine, Slackware, [...]) or just accepting that Arch is a systemd distribution and switching to it.
There *are* systemd-based distributions like Debian that aren't (yet) fully dropping support for other init systems, but Arch never intended to preserve support for other options when it switched. Debian also splits systemd into many packages and has various stubs for running stuff that depends on it without all of it running / installed. It sounds like you'd be happiest using a distribution where no systemd components are ever going to be required though, and there are plenty.
Upstreams are integrating support for systemd features and Arch is going to be enabling them, whether it's sd_notify support or something else. Packages aren't going to go out of the way to support a niche, unsupported use case. It's only going to get more painful to swim against the current as time goes on. The various dbus client implementations will probably be switched over to using kdbus this year, for one thing. I'm sure there will be more.
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 says different. systemd is the opposite of the Arch Way except for being open-source: it is not simple, not minimalist, and not user-centric.
But that is not really what this problem is about. Although it is a bit mind-boggling that systemd has been chosen as the main init system for Arch, its shortcomings are not necessarily shortcomings of Arch. That is, Arch can still be simple, minimalist, etc. and it is with the conscience of this fact that I chose to install Arch Linux in all my systems. systemd breaks the Arch Way. Having it as a package doesn't.
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:
Another guiding principle of Arch Linux development is freedom. Users are not only permitted to make all decisions concerning system configuration, but also choose what their system will be.
By keeping the system simple, Arch Linux provides the freedom to make any choice about the system.
A freshly installed Arch Linux system contains only basic core components with no automatic configuration performed. Users are able to configure the system as they wish, from the shell. From the start of the installation procedure, every component of the system is 100% transparent and accessible for instant access, removal, or replacement by alternative components.
The large number of packages and build scripts in the various Arch Linux repositories also support freedom of choice, offering free and open source software for those who prefer it, as well as proprietary software packages, for those who embrace functionality over ideology. It is the user who chooses.
As Judd Vinet, the founder of the Arch Linux project said: "[Arch Linux] is what you make it."
I used systemd in Arch for a long time. In fact, when I came, it was already the main init system, and I didn't really mind, or know much 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...).
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/
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, I'd stay in Windows installing Internet Explorer... I worry the suggestions to change distro are going too far. The point is not one of telling what the devs should or shouldn't do, but of remembering the principles upon which the community is based.
I rest my case. Again, any reply is welcome. João Miguel
On Wed, 1 Jul 2015 19:36:07 +0100 João Miguel jmcf125@openmailbox.org 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.
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.
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
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
That's wonderful; but it doesn't invalidate what I stated earlier. Direct your comments to the OP.
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.
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.
I find systemd easier from an user perspective too. Or ok, let say, a sys-admin one. And I'm talking from my >14 years profesional Linux experience. Wow, has it been so long. 18 years since I first installed Linux (Slackware 3, Debian 2.2, RedHat, Mandrake, Slackware, Arch - now using Arch for my laptop/desktop, Debian and Ubuntu on servers, sometimes Centos/RHEL).
And I can hardly wait for distros to standardize on networkd too. Finally some long needed standardization in the basic setup of a Linux system.
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
Arch officially does not support alternative init systems. Therefore, there is no reason to expect that the official repos will go out of their way to help you do so. There is an underlying assumption that any Arch system uses systemd.
Any AUR package is responsible for depending on other AUR packages, if using the main repo packages breaks things.
-- Eli Schwartz
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!
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/
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).
2015-07-02 10:24 GMT-03:00 Daniel Micay danielmicay@gmail.com:
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.
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.
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 eduardo.machado@gmail.com wrote:
2015-07-02 10:24 GMT-03:00 Daniel Micay danielmicay@gmail.com:
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.
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.
It is very simple. The bare minimum Arch install consist of the base https://www.archlinux.org/groups/x86_64/base/ group.
The user *must* install this group. If they don't, they no longer have a minimal Arch install, so developers cannot help them. It is the *base* and everything else builds on it. It would make no sense to replace the *linux*, *filesystem* or *pacman* package with something incompatible and expect everything to keep working.
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.
Regards, Sebastiaan
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.
2015-07-02 18:46 GMT-03:00 Daniel Micay danielmicay@gmail.com:
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.
Hi Daniel,
i wanna apologize if i misspelled something and made more damage than good.
And this post of yours is what i am certain that all the users would like to see, and i have to commed. It was a kind of polite and really technical note.
I know that when we work in projects like this, we work almost for love, it's demanding and sometimes we get frustrating with the feeling that our work are not getting recognized. I'm sure it is not the case for anyone here, but when we see a phrase like "the user opinion has no weight" it generates the same feeling that i tried to describe above.
Note that I am not advocating any solution. but what i would like to hear is that de devs heard the users, technically and non-technically opinions, weighted them with the pros and cons, and them choosed a solution with some benefits.
Didn't you agree that this is a really better statement? ;)
Best regards, and again, sorry, i didn't want to polemize.
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.
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.
I have to say, well done Daniel. Glad something useful finally emerged from this thread.
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).
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.)
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 spam@scientician.net 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.)
2015-07-03 6:45 GMT+02:00 Yaro Kasear yaro@marupa.net:
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.
Well, to be fair, systemd [the process or as a concept] isn't managing it all on its own, there are separate tools for the tasks under the systemd label. The developers saw usefulness in having these tools to keep a better eye on things, and I do think we've gained some benefits over other "pure init"-systems this way. Optimal or not, I don't care. It has at least been a lot easier for me to manage, as a user, compared to parsing tons of different script only to find out what they're trying to do or if any of them even have the same features.
That's just my experience after switching to Arch to try systemd when the transition was made. I'm still around because I think the way Arch integrates software feels "cleaner" compared to many other distros.
Thank you to all the developers and users who have helped me out directly or indirectly. We don't need to agree on everything before a decision is made. As long as a decision is made in either direction and Arch keeps moving, we could always go somewhere else later if need be.
Op 1 jul. 2015 15:52 schreef jmcf125@openmailbox.org:
Hi there,
Not sure whether I should email this mailing list about this problem, but here goes:
I've been using OpenRC in Arch Linux for a long time, and uninstalled systemd, as I don't use anything that requires it.
[snip]
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.
The second question is a bit broad and calls for advocacy and that has it's effect. Too bad, since these kind of threads usually lead to some (pointlessly long) debates without any real outcome...
Next time, try to stick to the technical questions and perhaps the replies are more helpful and less frustrating.
Just my $0,02
Mvg, Guus
Thu, 2 Jul 2015 00:43:13 +0200 Guus Snijders gsnijders@gmail.com:
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'.
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.
--byte
On 01/07/15 07:14 PM, Jens Adam wrote:
Thu, 2 Jul 2015 00:43:13 +0200 Guus Snijders gsnijders@gmail.com:
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 Wed, Jul 1, 2015 at 3:52 PM, jmcf125@openmailbox.org wrote:
However, in the latest update it seems an awful lot of packages I use suddenly require systemd. First, I have a conflict between libgudev and eudev-systemdcompat, so the installation stops right there. I don't even remember a libgudev package when I used systemd! The pacman output, 1st refusing to remove eudev, then accepting, is as follows:
libgudev was split from systemd into its own project. As a result, some packages have picked up a dependency on libgudev. However, libgudev cannot be installed on your system because it conflicts with eudev.
To clear up your dependencies, try having whatever eudev package contains libgudev.so provide libgudev.
Some general comments :
- Openrc is a replacement for sysv init, not an addition.
- openrc has it's own equivalent of .service files, they are simpler then systemd servicefiles
- my personal opinion about openrc is that it's not mature enough yet for majority of linux users to replace systemd The majority of Arch users however should be capable enough to use it efficiently.
- systemd has many good things, but also many flaws.
This blog post gives the best description of systemd flaws i am aware of : http://judecnelson.blogspot.fi/2014/09/systemd-biggest-fallacies.html
LVV
On Jul 3, 2015 6:10 AM, "LoneVVolf" lonewolf@xs4all.nl wrote:
Some general comments :
- Openrc is a replacement for sysv init, not an addition.
OpenRC runs on SysV Init last I checked, as OpenRC is just highly polished initscripts. How is that a replacement instead of an addition?
- openrc has it's own equivalent of .service files, they are simpler then
systemd servicefiles.
I admit I have not looked at OpenRC service files. But systemd units are barely even 6 lines not counting empty lines.
- my personal opinion about openrc is that it's not mature enough yet for
majority of linux users to replace systemd
My opinion is because it stoll relies on things Linux desperately needs to be rid of. Systemd has the advantages of both actually ridding us of SysV Init snd ysing vsrious kernel features OpenRC simply can't do to being initscripts.
The majority of Arch users however should be capable enough to use it
efficiently.
I have no argumemt here. But I still feel systemd is the better option.
- systemd has many good things, but also many flaws.
OpenRC does too. Not the least of which is that it is not actually an init replacement. Make OpenRC an independent init system then it will be a serious contender.
This blog post gives the best description of systemd flaws i am aware of : http://judecnelson.blogspot.fi/2014/09/systemd-biggest-fallacies.html
I will look this over. But I have already seen a bunch of systemd rants over the years snd they always boil down to the same points:
1. Unix philosophy, as if it was some sort of gospel when even most bona fide Unix systems don't even follow it any more. 2. Feature creep, about the only legitimate gripe I have seen. 3. Blaming the decisions of other projects bad decisionmaking on systemd. GNOME 3 is a classic example. 4. Change Is Bad (tm), usually taking the form of the commentator wanting to cling to initscripts.
LVV
On Fri, Jul 3, 2015 at 1:10 PM, LoneVVolf lonewolf@xs4all.nl 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
I can't overtly fault the logic in that blog post for the most part. However he does still basically toe the "Unix philosophy" line (Talking about modularity and such.)
The thing that bothers me most about this document though is how he dismisses systemd's legitimate, if not unique, features as "propaganda." He also tends to talk about flaws in how systemd is written but doesn't seem to explain that, go into rants about Poettering not long after dismissing one of the common statements being "you just hate systemd because Poeterring," etc.
I must be that rare breed of systemd supporter who actually actively DISLIKES Poettering. When he started Pulseaudio and it started breaking everyone's sound, he went into a mantra of "ALSA's broken" instead, despite the fact ALSA, even standalone, worked just fine without PA. That said I now use Pulseaudio, because once it matured it stopped breaking sound as much. I'm not a fan of how it demands to "own" all sound on the system, but I can get over that.
Add point 5, though, to the typical anti-systemd rants when boiled down: 5: I hate Lennart Poeterring.
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 07/03/2015 04:31 PM, Tobias Hunger wrote:
To be fair: There is more to here than "Unix philosophy" and "I hate Lennart".
STOP!
Can we please end this discussion now?
This no longer has anything to do with Arch Linux and is just spam (for this list) at this point.
I'm sure people who are interested can find other places to discuss the merits (or otherwise) of systemd.
Regards,
On Fri, 3 Jul 2015 16:51:21 +0200 Bardur Arantsson spam@scientician.net 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
On Fri, Jul 3, 2015 at 4:10 PM, Geoff capsthorne@yahoo.co.uk wrote:
On Fri, 3 Jul 2015 16:51:21 +0200 Bardur Arantsson spam@scientician.net 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.
The bitter flame wars concerning systemd were rife on several other mailing lists a few years ago and led to no useful outcome other than to severely impact on users who had significant volumes of mail in their inboxes. This led both to some MLs being moderated but also led to some people unsubscribing from lists to get away from the futile claim and counterclaim spew of mail. Please stop this systemd discussion now as the majority of people in this list are subscribed for the purpose of providing and receiving genuine help with issues that can't be answered in the wiki or forums. Also suggestions for positive developments that have not been discussed elsewhere.
Times have moved on since the systemd war - and we have a very functional arch linux operating system. Please move any further systemd rants to some other channel.
Wow, I really didn't expect such a discussion. I mean, I don't like systemd, but what I had was a technical problem (along with a bunch of opinions, I'll give you that). I have solved it, and would have before if I could search the web better... As LoneVVolf lonewolf@xs4all.nl has thankfully pointed out there's a thread about this problem in the forums.
I couldn't get it working right away, but with some tweaking in the AUR PKGBUILDs, now it's all up and running just fine. In fact, it was a bit of a boneheaded problem.
And just so we're clear, and because I cannot hold myself from getting into arguments.
This link someone threw: https://www.redhat.com/archives/rhl-devel-list/2008-January/msg00861.html is not the answer. Last time I checked, Arch wasn't a Redhat puppet yet. Also, check what the OP asked for in that case (https://www.redhat.com/archives/rhl-devel-list/2008-January/msg00845.html) and make a serious comparison to what I asked for, see if you can spot the differences. Fedora doesn't have a page with words like «minimalism» and «freedom» and «user-centric» about a «Fedora Way» either. It's just RHL with a different hat.
Saying Linux is not about choice is false. Cars are not about choice, that analogy is flawed. Linux is made by the community, by developers, people who devote their free time to make something everyone can use. Users use Linux, as cars, for various things, that doesn't really matter here. But while companies make cars to make money, people make Linux for whatever other reason floats their boat.
These problems didn't emerge before because Linux wasn't made for money. Now that it is what matters are the mili-seconds you can save on boot! Or the market share! Oh, more people must use Linux! Not because they will have a better experience, but because money will be made off it.
systemd has advantages, of course. But what it stands for, AFAIC, is the opposite of what FOSS is.
I have more stuff to do. So instead of saying what has been said thousands of times (and I'm afraid I've done that already) have some rants you might not know yet: http://gentooexperimental.org/~patrick/weblog/archives/2013-10.html#e2013-10... https://lkml.org/lkml/2014/8/12/459
Here's Torvalds, mad with systemd devs: https://lkml.org/lkml/2014/4/2/420
Debian dissidents: https://devuan.org/
BTW, I checked (https://www.archlinux.org/people/developers/), none of the people speaking here are devs. Stop acting like you are (for those of you who did, of course).
Thank you for all help and entertainment :-P João Miguel
I have more stuff to do. So instead of saying what has been said thousands of times (and I'm afraid I've done that already) have some rants you might not know yet:
Then please go and do your "other stuff" and stop cluttering up this mailing list with your irrelevant and barely coherent ramblings.
BTW, I checked (https://www.archlinux.org/people/developers/), none of the people speaking here are devs. Stop acting like you are (for those of you who did, of course).
I don't believe anyone ever did imply that. As others have stated many times, this is not a list that developers typical use or pay much attention to.
By all means, ask for help, ask technical questions, etc. But if all you want to do is ramble on about something that has long since been debated and decided, please sod off.
arch-general@lists.archlinux.org