Archlinux is moving to systemd

jasonwryan · 2012-10-17 23:31:39

Lone_Wolf wrote:

tomegun wrote:
If you want to be taken seriously I suggest you don't make highly controversial/implausible claims without being able to provide the references...
Added a disclaimer to my post 344

Disclaiming those statements doesn't make them any less inflammatory. Trolling of any sort is not tolerated; in a thread like this, the tolerance is much lower. Consider this your first, and last, warning.
https://wiki.archlinux.org/index.php/Fo … o_Trolling

yaffare · 2012-10-17 23:40:31

Just saw this AUR package provides a simple way for Static network configuration for systemd.
Without netcfg or NetworkManager, only iproute2.
Should definitely move in the main-package.
(sorry for interrupting your little war here)

Last edited by yaffare (2012-10-17 23:59:44)

ElderSnake · 2012-10-18 02:05:48

I switched my C-50 APU powered AMD Netbook over to pure systemd the other day, after doing a system update.

Now, much to my pleasant surprise, this thing actually wakes from suspend with the Catalyst drivers!

However unfortunately due to my process of doing the updates and then immediately performing the switch I don't know whether it was a kernel update, some other power management related library or systemd itself which somehow fixed my suspend issues. The Catalyst drivers were not updated IIRC.

Either way, I'm not complaining and the process described in the wiki for switching to systemd is simple and works great.

Last edited by ElderSnake (2012-10-18 02:06:37)

ConnorBehan · 2012-10-18 02:58:25

jasonwryan wrote:

Lone_Wolf wrote:
tomegun wrote:
If you want to be taken seriously I suggest you don't make highly controversial/implausible claims without being able to provide the references...
Added a disclaimer to my post 344

Disclaiming those statements doesn't make them any less inflammatory. Trolling of any sort is not tolerated; in a thread like this, the tolerance is much lower. Consider this your first, and last, warning.
https://wiki.archlinux.org/index.php/Fo … o_Trolling

There's a difference between trolling and not having enough free time to track down your sources. Lone_Wolf's comment about Poettering not wanting to develop udev unless it benefits systemd is quote correct. However, I'm not sure about the goal of replacing polkit and desktop managers.

jasonwryan · 2012-10-18 03:08:03

ConnorBehan wrote:

jasonwryan wrote:
Lone_Wolf wrote:
Added a disclaimer to my post 344

Disclaiming those statements doesn't make them any less inflammatory. Trolling of any sort is not tolerated; in a thread like this, the tolerance is much lower. Consider this your first, and last, warning.
https://wiki.archlinux.org/index.php/Fo … o_Trolling
There's a difference between trolling and not having enough free time to track down your sources. Lone_Wolf's comment about Poettering not wanting to develop udev unless it benefits systemd is quote correct. However, I'm not sure about the goal of replacing polkit and desktop managers.

Posting "attributed" comments in a thread like this without bothering to provide sources is as good as trolling. I also didn't see anything in that email that could even be remotely parsed as "force more people to use systemd."

headkase · 2012-10-18 03:21:17

*gets popcorn* http://i.imgur.com/I6GSf.gif

On-Topic:

My personal opinion on systemd is that it is perfectly fine. It took me all of 30 minutes to switch over to it and now that I'm getting more proficient with it it is really nice, like how easy it is to enable and disable functions - so easy.

Last edited by headkase (2012-10-18 03:22:24)

thestinger · 2012-10-18 03:52:48

ConnorBehan wrote:

jasonwryan wrote:
Lone_Wolf wrote:
Added a disclaimer to my post 344

Disclaiming those statements doesn't make them any less inflammatory. Trolling of any sort is not tolerated; in a thread like this, the tolerance is much lower. Consider this your first, and last, warning.
https://wiki.archlinux.org/index.php/Fo … o_Trolling
There's a difference between trolling and not having enough free time to track down your sources. Lone_Wolf's comment about Poettering not wanting to develop udev unless it benefits systemd is quote correct. However, I'm not sure about the goal of replacing polkit and desktop managers.

He stated that it was taking over from udev, which is untrue as udev was simply moved into the same code repository to share code between the projects (without making a library that would have to expose an external API).

Lennart and Kay (the udev developer) are both Red Hat employers, and they themselves aren't going to support udev outside of systemd. Red Hat can't be expected to pay for the development of software they aren't going to use. They're still putting in the extra work to maintain it for now, but unless someone steps up to maintain it (which they don't seem to think will happen), it isn't going to stick around forever.

systemd also doesn't take over from polkit or display managers - although polkit has moved to systemd support itself, replacing the consolekit support. Since logind handles sessions and seats, consolekit is no longer needed - but logind implements a different featureset than consolekit ($XDG_RUNTIME_DIR, inhibitor locks, true multiseat, etc.).

Last edited by thestinger (2012-10-18 03:56:24)

Lone_Wolf · 2012-10-18 12:32:55

It seems i have let my personal opinions cloud my judgement to much in this thread.
Although i'm the thread starter and have influenced the direction of this thread a few times, i won't post in it anymore.

zb3 · 2012-10-18 13:28:51

Some quotes:

- "Note that it is not possible to boot up a machine withotu udev though."
http://www.spinics.net/lists/fedora-dev … 71927.html

- "(Yes, udev on non-systemd systems is in our eyes a dead end, in case you
haven't noticed it yet. I am looking forward to the day when we can drop
that support entirely.)"

tomk · 2012-10-18 14:15:44

This is getting ridiculous....

zb3, reference for the second quote PLEASE.

karol · 2012-10-18 14:18:26

tomk wrote:

This is getting ridiculous....
zb3, reference for the second quote PLEASE.

Here: http://lists.freedesktop.org/archives/s … 06066.html

marvn · 2012-10-18 14:18:54

zb3 wrote:

Some quotes:
- "Note that it is not possible to boot up a machine withotu udev though."
http://www.spinics.net/lists/fedora-dev … 71927.html
- "(Yes, udev on non-systemd systems is in our eyes a dead end, in case you
haven't noticed it yet. I am looking forward to the day when we can drop
that support entirely.)"

not support =! forbid (I know, it seems obvious, but some ppl still don't get it)

alphaniner · 2012-10-18 14:25:07

tomk wrote:

This is getting ridiculous....
zb3, reference for the second quote PLEASE.

http://lists.freedesktop.org/archives/s … 06066.html

tomegun · 2012-10-18 14:29:34

zb3 wrote:

- "Note that it is not possible to boot up a machine withotu udev though."
http://www.spinics.net/lists/fedora-dev … 71927.html

Context: it is not possible to boot a systemd machine (the discussion you quote is about Fedora, which uses systemd) without udev (not the other way around). It is perfectly possible to boot a non-systemd system without udev, or to use udev without systemd.

- "(Yes, udev on non-systemd systems is in our eyes a dead end, in case you
haven't noticed it yet. I am looking forward to the day when we can drop
that support entirely.)"

This has been discussed and explained a million times. Summary: Lennart (and the other systemd guys) personally believe that udev on non-systemd systems are a dead end and will not be working specifically on that themselves, that does not mean that they will make this impossible (quite the opposite, it is explicitly supported). Moreover, they do accept bug-fixes for non-systemd setups, and they accept features that benefit either systemd-only systems, or systemd and non-systemd systems.

They do look forward to the day when no one is using udev on non-systemd systems, but that does not mean that they will "force" this to happen by making it hard to do. Just that they think systemd is so superior that they are hoping/expecting everyone to switch eventually.

Last edited by tomegun (2012-10-18 14:30:43)

ConnorBehan · 2012-10-18 19:11:09

Right, people have read too much into that Lennart quotation and put words in his mouth. However, these people still have a right to be angry if udev (a program that so many people use and depend on) refuses to accept features that benefit non-systemd systems and are *neutral* to systemd.

Many people want non-Redhat software (including init systems) to work well without having to go back to devfs. Perhaps it's naive of me to think that two Redhat employees would be driven by some benevolent stewardship over this community but there are examples that Lennart and Kay can learn from. Look at Dave Airlie. He works for Redhat but he collaborates with so many others that I used to think he worked for AMD.

tomegun · 2012-10-18 19:32:18

ConnorBehan wrote:

However, these people still have a right to be angry if udev (a program that so many people use and depend on) refuses to accept features that benefit non-systemd systems and are *neutral* to systemd.

If that happened, then I would understand that it would be annoying. The people involved are (contrary to popular opinion) eminently reasonable, so let's wait for such a situation to occur before we panic.

The way I understand this stuff is that the systemd people are not making these sorts of statement out of hostility. It is not their aim to make udev work poorly on non systemd systems. All they want (iiuc) is to avoid giving the impression that they promise to add hacks/workarounds to udev for things that should be fixed elsewhere (i.e. in the init system). There is currently functionality in udev which is only there to accommodate non-systemd init daemons (the behaviour is arguably wrong, but on non-systemd systems that's the best we can do), and that will stay. However, we don't want to add more special cases like that.

alphaniner · 2012-10-18 19:40:47

ConnorBehan wrote:

However, these people still have a right to be angry if udev (a program that so many people use and depend on) refuses to accept features that benefit non-systemd systems and are *neutral* to systemd.

It seems to me that accepting such features would seem to go against the "Unixness" and "simplicity" arguments so frequently leveled against systemd.

zb3 · 2012-10-19 06:12:44

marvn wrote:

not support =! forbid (I know, it seems obvious, but some ppl still don't get it)

"!= forbid" because it is open source software. As long as someone will manage the fork it's okay, because I guess non-developers are not wishing to spend their time patching udev
And this will only require more time. By saying "not support" it means they will no longer care, and integrate it as deeply as they can even if it makes it practically impossible to fork

So to run udev you will have to emulate more and more API's

Not really quotes but the whole concept:
https://www.gpul.org/indico/materialDis … s&confId=0

Knowing the quotes + concept, I understand people saying "systemd will take over everything", even though It's not yet true

Awebb · 2012-10-19 09:45:29

alphaniner wrote:

It seems to me that accepting such features would seem to go against the "Unixness" and "simplicity" arguments so frequently leveled against systemd.

After reading a lot of systemd related posts on reddit, I am now convinced, that the moment you play the "Unix philosophy" card, you automatically disqualify from all discussions about the "Unix philosophy". The usual line they refer to is: "Write programs that do one thing and do it well.". There are a few things I dislike about that simplification:

1. There is no single true "Unix philosophy". See this article for a hint on how much there is to say about the topic.

2. I don't see how systemd is a single program. It is a set of tools, a collection of programs, a software suite, if you want. While there indeed is a /bin/systemd, it is not the fancy allrounder, that should need to face the "Unix philosophy" question.

systemd --help
systemd [OPTIONS...]

Starts up and maintains the system or user services.

  -h --help                      Show this help
     --test                      Determine startup sequence, dump it and exit
     --dump-configuration-items  Dump understood unit configuration items
     --introspect[=INTERFACE]    Extract D-Bus interface data
     --unit=UNIT                 Set default unit
     --system                    Run a system instance, even if PID != 1
     --user                      Run a user instance
     --dump-core[=0|1]           Dump core on crash
     --crash-shell[=0|1]         Run shell on crash
     --confirm-spawn[=0|1]       Ask for confirmation when spawning processes
     --show-status[=0|1]         Show status updates on the console during bootup
     --log-target=TARGET         Set log target (console, journal, syslog, kmsg, journal-or-kmsg, syslog-or-kmsg, null)
     --log-level=LEVEL           Set log level (debug, info, notice, warning, err, crit, alert, emerg)
     --log-color[=0|1]           Highlight important log messages
     --log-location[=0|1]        Include code location in log messages
     --default-standard-output=  Set default standard output for services
     --default-standard-error=   Set default standard error output for services

Starting up and maintaining system/user services pretty much looks like a single task to me. It can be compared to a desktop environment. While I usually don't like those code beasts, because they bundle features I don't need or want, they all consist of multiple tools doing single jobs (more or less) well. They could also be referred to as "desktop distributions", like texlive is often called a "TeX distribution", instead of a "TeX environment". In that respect, systemd (the collection, not the binary) is a "init system distribution/environment", but nobody wants to append the words "distribution" or "environment" to everything they say.

3. Rule of Generation: Avoid hand-hacking; write programs to write programs when you can.
I'd say writing an init script is hand hacking, while writing a service file for systemd is not. While I am not sure, whether I will be comfortable with giving up those versatile daemon scripts in the long run, I would agree, that everything besides "start/stop/restart/reload config" should be handled by a client, rather than the init system. See Rule of Representation: Fold knowledge into data so program logic can be stupid and robust

However, there are a few "Unix rules" broken by systemd, but those are not the one mentioned above:

1. Rule of Silence: When a program has nothing surprising to say, it should say nothing.
The first thing I learned about systemd is, that it is very chatty. It even tells me what exact command it uses to create it's symlinks. While I don't think it is a bad thing, it breaks this rule.

2. Choose portability over efficiency.
It is currently unknown, if it will ever be possible to use systemd on something other than Linux. It is also not clear, how systemd will change the Linux ecosystem. Many tools will now be written with systemd in mind, maybe we will even see disgusting dependency chains, like we have to deal with thanks to the big DE's. As an example, the "best" pdf viewers in my opinion are tied very closely to either Gnome or KDE, installing them would pull in dependency after dependency. This is not a problem with systemd itself, though.

3. Avoid captive user interfaces.
I know, I'm being picky here, but since when do I need to give a swich to a program in order to NOT have it pipe it's output to a pager? Yes, I just linked a personal preference to a holy rule. You'll be fine.

brain0 · 2012-10-19 12:54:01

Awebb wrote:

2. Choose portability over efficiency.
It is currently unknown, if it will ever be possible to use systemd on something other than Linux.

I think it is well-known that it never will.

Awebb wrote:

maybe we will even see disgusting dependency chains, like we have to deal with thanks to the big DE's. As an example, the "best" pdf viewers in my opinion are tied very closely to either Gnome or KDE, installing them would pull in dependency after dependency. This is not a problem with systemd itself, though

Now think why those viewers are the best: Because they rely on well-written libraries to do lots of their work: Display a user interface, decode graphics, render fonts - all they need to do is take a PDF parser (poppler) to parse the data, have libraries render the fonts and graphics and call the DE's library functions to present it in a way the user expects. A viewer that does not depend on a DE will either have reduced functionality, or reimplement more functions that have already been written - but the new code has more bugs.

To me, this looks like an extension of your argument for units vs. rc.d scripts.

thestinger · 2012-10-19 14:14:11

Awebb wrote:

2. Choose portability over efficiency.
It is currently unknown, if it will ever be possible to use systemd on something other than Linux. It is also not clear, how systemd will change the Linux ecosystem. Many tools will now be written with systemd in mind, maybe we will even see disgusting dependency chains, like we have to deal with thanks to the big DE's. As an example, the "best" pdf viewers in my opinion are tied very closely to either Gnome or KDE, installing them would pull in dependency after dependency. This is not a problem with systemd itself, though.

There is no equivalent to cgroups and some of the other interfaces used by systemd on other operating systems. You would first have to port those features to other kernels, it's hardly about efficiency.

Janarto · 2012-10-20 08:19:12

I get the point that software is increasingly "linux compatible" rather than "posix compatible" (see the critics of Tanenbaum about the lack of posix compatibily and the fact that this issue is not well known nor understood by developers)

But it's not a new phenomenon, as most software are somewhat undertested for other POSIX systems.
Furthermore, as ggc remains the compiler on most distributions, and with the push of the GPLv3, I see the gap growing between linux and other systems.

Drivers are one part of it
Systemd is a part of it
Soon wayland will be a part of it (as it relies on KMS)

But the positive aspect is the growing convergence among various linux distribution. We now have a critical mass of actors supporting systemd, we'll see how it will impact debian in the linux world, and the bsd's in the future.

Last edited by Janarto (2012-10-20 08:20:07)

scar · 2012-10-20 10:37:16

OK, maybe it looks stupid, but after all it is ARCH...
You have surely noticed, that as systemd processes at boot, some green dots/markers appear.
COULD YOU PLEASE MAKE THEM BLUE???

dolby · 2012-10-20 11:11:30

scar wrote:

OK, maybe it looks stupid, but after all it is ARCH...
You have surely noticed, that as systemd processes at boot, some green dots/markers appear.
COULD YOU PLEASE MAKE THEM BLUE???

Yeah, its stupid but there are other stupid people like you
https://bbs.archlinux.org/viewtopic.php?id=145019

Teho · 2012-10-20 13:06:49

Now that all systemd-arch-units have moved to their corresponding packages and only zram.service remains, wouldn't it make sense to rename it to something like "zramctrl"?

Arch Linux

#351 2012-10-17 23:31:39

Re: Archlinux is moving to systemd

#352 2012-10-17 23:40:31

Re: Archlinux is moving to systemd

#353 2012-10-18 02:05:48

Re: Archlinux is moving to systemd

#354 2012-10-18 02:58:25

Re: Archlinux is moving to systemd

#355 2012-10-18 03:08:03

Re: Archlinux is moving to systemd

#356 2012-10-18 03:21:17

Re: Archlinux is moving to systemd

#357 2012-10-18 03:52:48

Re: Archlinux is moving to systemd

#358 2012-10-18 12:32:55

Re: Archlinux is moving to systemd

#359 2012-10-18 13:28:51

Re: Archlinux is moving to systemd

#360 2012-10-18 14:15:44

Re: Archlinux is moving to systemd

#361 2012-10-18 14:18:26

Re: Archlinux is moving to systemd

#362 2012-10-18 14:18:54

Re: Archlinux is moving to systemd

#363 2012-10-18 14:25:07

Re: Archlinux is moving to systemd

#364 2012-10-18 14:29:34

Re: Archlinux is moving to systemd

#365 2012-10-18 19:11:09

Re: Archlinux is moving to systemd

#366 2012-10-18 19:32:18

Re: Archlinux is moving to systemd

#367 2012-10-18 19:40:47

Re: Archlinux is moving to systemd

#368 2012-10-19 06:12:44

Re: Archlinux is moving to systemd

#369 2012-10-19 09:45:29

Re: Archlinux is moving to systemd

#370 2012-10-19 12:54:01

Re: Archlinux is moving to systemd

#371 2012-10-19 14:14:11

Re: Archlinux is moving to systemd

#372 2012-10-20 08:19:12

Re: Archlinux is moving to systemd

#373 2012-10-20 10:37:16

Re: Archlinux is moving to systemd

#374 2012-10-20 11:11:30

Re: Archlinux is moving to systemd

#375 2012-10-20 13:06:49

Re: Archlinux is moving to systemd

Board footer