Re: Archlinux is moving to systemd

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)

Re: Archlinux is moving to systemd

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.

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.

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

Re: Archlinux is moving to systemd

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.

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

Re: Archlinux is moving to systemd

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.

Re: Archlinux is moving to systemd

But whether the Constitution really be one thing, or another, this much is certain - that it has either authorized such a government as we have had, or has been powerless to prevent it. In either case, it is unfit to exist.-Lysander Spooner

Re: Archlinux is moving to systemd

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 youhaven't noticed it yet. I am looking forward to the day when we can dropthat 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.

Re: Archlinux is moving to systemd

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.

Re: Archlinux is moving to systemd

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.

Re: Archlinux is moving to systemd

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.

But whether the Constitution really be one thing, or another, this much is certain - that it has either authorized such a government as we have had, or has been powerless to prevent it. In either case, it is unfit to exist.-Lysander Spooner

Re: Archlinux is moving to systemd

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 udevAnd 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

Re: Archlinux is moving to systemd

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.

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.

Re: Archlinux is moving to systemd

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.

Re: Archlinux is moving to systemd

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.

Re: Archlinux is moving to systemd

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 itSystemd is a part of itSoon 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.

There shouldn't be any reason to learn more editor types than emacs or vi -- mg (1)[You learn that sarcasm does not often work well in international forums. That is why we avoid it. -- ewaller (arch linux forum moderator)