Systemd Works On PPPoE Support

[slojam]

Scarily enough I can see both landing in systemd someday.

Print server is an obvious one. Every windows machine can function as one, and so it's clearly good for systemd as well.

As to torrent client -- think about offloading package distribution from mirror servers..

Nothing is too crazy, clearly.

NOno, I want systemd-officesuite first please. And fold in systemd-arduino. Why not?

[CTown]

NOno, I want systemd-officesuite first please. And fold in systemd-arduino. Why not?

Request accepted!

This comment on that same page still gets me:

+Yevgney Sliosarenko well, we were still missing a good text editor in the systemd suite. Thankfully, with LibreOffice Writer we now have a really good editor for editing all those systemd unit files!

Also, did you guys here about the new Lennarts that just came in?

[Nobu]

I don't see why you can't, at the same time, have something that "Just Works"(tm) and something that you can customize however you like it. Am I missing something?

If you want that much control, build your own distribution (or help with one which does what you want). Otherwise, help build the tools that could allow your favorite distro to do what you want, and try to get them included in that distro. Else, raise(SIGABRT)!

[nasyt]

From: Rob Pike <robpike@gma...>
Subject: Q: moving directories? hard links?
Date: Sat, 16 Apr 2011 11:56:46 -0700

On Sat, Apr 16, 2011 at 11:17 AM, Skip Tavakkolian wrote:
> Linux has slowly become Windows-lite

Except for the lite part.

-rob

http://harmful.cat-v.org/software/operating-systems/linux/

[sdack]

Just yesterday did I run into an annoying fail case with systemd. A hard disk of a multi-OS computer received a new Windows installation, which also caused its disk to receive a new UUID. This disk got mounted from a Linux installation on the same computer. What happened when I booted the Linux installation was that systemd tried to mount the Windows disk by using its previous UUID. As expected did it fail of course and I only wanted to enter the new UUID into the fstab, but systemd halted the system for 3 minutes until it gave up trying. I could not stop it from trying, I could not get around it (it was all stuck in single-user boot up) and the only way to update the UUID so Linux can find the disk was to wait for systemd to make up its mind.

This is the kind of stuff people have been warning about. In the past would the mount operation have thrown out an error message, but the rest of the system would have booted up as usual without any delay. Now you are stuck waiting on systemd. Lucky for me it decided to give up trying or else would I have had to boot up the machine from a rescue disk just to change a single line in the fstab.

[psychoticmeow]

Just yesterday did I run into an annoying fail case with systemd. A hard disk of a multi-OS computer received a new Windows installation, which also caused its disk to receive a new UUID. This disk got mounted from a Linux installation on the same computer. What happened when I booted the Linux installation was that systemd tried to mount the Windows disk by using its previous UUID. As expected did it fail of course and I only wanted to enter the new UUID into the fstab, but systemd halted the system for 3 minutes until it gave up trying. I could not stop it from trying, I could not get around it (it was all stuck in single-user boot up) and the only way to update the UUID so Linux can find the disk was to wait for systemd to make up its mind.

This is the kind of stuff people have been warning about. In the past would the mount operation have thrown out an error message, but the rest of the system would have booted up as usual without any delay. Now you are stuck waiting on systemd. Lucky for me it decided to give up trying or else would I have had to boot up the machine from a rescue disk just to change a single line in the fstab.

It sounds like it worked as designed, but not as you expected, and you had to find out the hard way that you should add the option nofail to non-critical mounts. So really the problem here is a lack of communication from systemd to our distros (maybe?) to us that the behaviour has changed, not that systemd is buggy.

I don't recall reading about this change in the coverage here, or on the arch website, so unless I'm reading every single release note I'm not going to find out about it until something bad happens to me (or to you in this case).

That sucks.

[sdack]

It sounds like it worked as designed, but not as you expected, and you had to find out the hard way that you should add the option nofail to non-critical mounts. So really the problem here is a lack of communication from systemd to our distros (maybe?) to us that the behaviour has changed, not that systemd is buggy.

I don't recall reading about this change in the coverage here, or on the arch website, so unless I'm reading every single release note I'm not going to find out about it until something bad happens to me (or to you in this case).

That sucks.

Stalling the boot process for 3 minutes and not doing anything in that time is definitely bad. Someone was hoping for the problem to disappear or to fix itself if only enough time passes. What it should have done is to give an error message and to continue as far as possible to the single-user prompt so that the issue can be fixed by an administrator. It was the whole point of booting into single-user mode in the first place. I sure will not put "nofail" behind every mount point now. Hardware always fails at some point in its life and such issues need to be addressed, but stalling does not fix anything. Frankly, I am surprised to see systemd to fall back to stalling the boot process when the whole idea of it was to make everything faster.

[finalzone]

Stalling the boot process for 3 minutes and not doing anything in that time is definitely bad. Someone was hoping for the problem to disappear or to fix itself if only enough time passes. What it should have done is to give an error message and to continue as far as possible to the single-user prompt so that the issue can be fixed by an administrator. It was the whole point of booting into single-user mode in the first place. I sure will not put "nofail" behind every mount point now. Hardware always fails at some point in its life and such issues need to be addressed, but stalling does not fix anything. Frankly, I am surprised to see systemd to fall back to stalling the boot process when the whole idea of it was to make everything faster.

That behaviour is a part of "UNIX philosophy" under Rule of Repair. See http://www.phoronix.com/forums/showt...367#post451367
and http://www.phoronix.com/forums/showt...659#post451659

[psychoticmeow]

Stalling the boot process for 3 minutes and not doing anything in that time is definitely bad. Someone was hoping for the problem to disappear or to fix itself if only enough time passes. What it should have done is to give an error message and to continue as far as possible to the single-user prompt so that the issue can be fixed by an administrator. It was the whole point of booting into single-user mode in the first place. I sure will not put "nofail" behind every mount point now. Hardware always fails at some point in its life and such issues need to be addressed, but stalling does not fix anything. Frankly, I am surprised to see systemd to fall back to stalling the boot process when the whole idea of it was to make everything faster.

I was under the impression that it's so you've got a couple of minutes to plug that USB/hot swappavle device back in? I'm not really sure what the big deal is given you know now that you can disable this behaviour by configuring fstab, maybe what you want to do is ask them for better detection of hot pluggable devices, or at least to make the delay while you wait more configurable.

[sdack]

That behaviour is a part of "UNIX philosophy" under Rule of Repair. See http://www.phoronix.com/forums/showt...367#post451367
and http://www.phoronix.com/forums/showt...659#post451659

Allow me the mockery, but what does systemd have to do with UNIX philosophy?!? If anything does it mark the end of it. Anyhow, we are past the point-of-no-return...

In the past would such mounts have happened in the background while the boot process continued in the foreground. This was done for disks with long spin-up times for example. If a mount could not complete was it forked into the background. This is what I though what systemd was all about - to make use of multi-processing and multi-threading for an increased parallelism already at boot time. So clearly does it not deliver on its promises, all while in the past this has already been solved with background mounts. The systemd developers still have some work to do.