On Wed, Jan 19, 2011 at 5:06 PM, Laurent Carlier wrote:

Le mercredi 19 janvier 2011 16:02:52, C Anthony Risinger a écrit :

...

On Wed, Jan 19, 2011 at 3:59 PM, C Anthony Risinger wrote:

...

Any ideas when will Arch switch to systemd based booting system ?

oh, and the last couple pages in the forum sound promising in regards to arch specific unit files, though i'd have to look closer as i haven't had a chance to try systemd myself for some time.

any comments from someone out there currently using systemd and the arch unit files from AUR?

C Anthony

Let me resume:

Currently there is no plan and no date.

++

I'm not convinced systemd is better than the current initscripts in its current state. I've seen problems from people using systemd in the forums and in other sources. You should work on improving systemd on arch and getting everything documented if you really do like it.

On Jan 19, 2011 7:13 PM, "Ng Oon-Ee" wrote:

On Wed, 2011-01-19 at 17:22 -0600, Thomas Dziedzic wrote:

...

On Wed, Jan 19, 2011 at 5:06 PM, Laurent Carlier

wrote:

...

...

Le mercredi 19 janvier 2011 16:02:52, C Anthony Risinger a écrit :

...

On Wed, Jan 19, 2011 at 3:59 PM, C Anthony Risinger

...

...

wrote:

...

...

Any ideas when will Arch switch to systemd based booting system ?

oh, and the last couple pages in the forum sound promising in regards to arch specific unit files, though i'd have to look closer as i haven't had a chance to try systemd myself for some time.

any comments from someone out there currently using systemd and the arch unit files from AUR?

C Anthony

Let me resume:

Currently there is no plan and no date.

++

I'm not convinced systemd is better than the current initscripts in its current state. I've seen problems from people using systemd in the forums and in other sources. You should work on improving systemd on arch and getting everything documented if you really do like it.

+1

I've been observing the systemd thread, seems really interesting (conceptually and practically). Will have to try it someday, when I've graduated and the cost of an unbootable system becomes less heavy =)

I will likely put time into this when possible, but that's not very soon; I have another Arch related project with btrfs that I've delayed too long. As for being better... I think the links provided to Lennart's blog explain that fairly well. 200 line bash scripts become 15 line service files. I was hoping to hear from someone currently using/trying the systemd related AUR packages, because some of the posts in the forum are very positive, and allude to good Arch specific support/experiences. ... so, anyone out there to support or refute this observation (with actual experience ...) C Anthony [mobile]

On Wed, Jan 19, 2011 at 9:12 PM, Cody Maloney wrote:

On Wed, Jan 19, 2011 at 6:22 PM, C Anthony Risinger wrote:

...

... so, anyone out there to support or refute this observation (with actual experience ...)

Better is a matter of opinion. From what I've gathered about systemd it makes a lot of things a lot better/simpler/cleaner, and seems to be fairly sensibly put together.

don't forget things that were previously not possible! like verifiable boot, reliable kill/term/reload (WITHOUT cooperation from the child process), and resource limiting for example... all of which are rather important for servers :-)

Systemd definitely gets a lot right, and I do use it some on my desktops which already have a strong dependency on D-Bus.

arch desktops? could you elaborate more here; how is the experience?

I could see possibly trying to build a non-bash/sysv init system for Arch to provide much of what systemd provides

i don't understand what you mean here... reinvent an application that currently gaining much traction/backing? why?

but I don't like bringing in D-Bus as a core system dependency to do so. I like KISS, and D-Bus (at least in its current state), just doesn't fit into my interpretation of KISS on any machine.

i just did a quick check on dbus-core. minus all the man pages, headers, etc. you are left with a single dynamic library, and 5 binaries. these combined weigh in at a whopping half a MB (yes, that's 0.5MB :-). what's not kiss about that? i guess i think dbus is pretty awesome. quite frankly, i love linux but i'm tired of editing 1000s of different kinds of config files with different syntax, and disparate methods for doing every little thing. it's a high speed bus that lets me use language <insert here> to speak to many different running applications, independent of the application's language, reliably and effectively. things like libvirt/policykit are very important to my personal/professional uses of linux, at home and company. i don't see dbus going away anytime soon, and honestly i hope it becomes integrated into everything and becomes integral to the linux experience, because from a development point of view it adds a lot of flexibility to grow and introspect, with little if any drawbacks (though i could very well be missing something).

D-Bus has directly reduced both the predictability and stability of my machines, ... for the time being, it has caused me nothing but problems.

how so? if you mean applications changing their interface, this really isn't dbus's fault. could you elaborate more? i have many systems and custom scripts that rely on it in one way or another and i haven't experienced any issues. thanks for your response; it's well appreciated. C Anthony

On Thu, 2011-01-20 at 14:11 +0100, Tom Gundersen wrote:

Hi everyone,

I have been working on integration of Arch and Systemd.

Very much appreciated, thank you!

Regarding people who are worried about getting an unbootable system: systemd and sysvinit can (and should) be installed in parallel, so you can switch between them by adding "init=/bin/systemd" to your kernel line in GRUB (so if it does break your boot, you can just reboot back into sysvinit).

That would be me. This above only holds if we don't utilize the initscripts, right? I understood from the forum thread that using those there'd be 'no turning back'. Never took the time to understand WHY, but that's the impression I took away.

On Thu, 2011-01-20 at 14:34 +0100, Tom Gundersen wrote:

2011/1/20 Ng Oon-Ee :

...

That would be me. This above only holds if we don't utilize the initscripts, right? I understood from the forum thread that using those there'd be 'no turning back'. Never took the time to understand WHY, but that's the impression I took away.

No, we completely refactored the packages over the last couple of months, so that is no longer the case.

You are encouraged to install systemd-git, systemd-arch-units-git and initscripts-systemd-git. It will not conflict with the standard initscripts package, and you can switch back and forth by making the change in GRUB during boot.

I'm trying to keep the wiki page up-to-date, so please use that rather than the forum thread to find information, as the forum thread will quickly get outdated (as soon as a problem crops up in the forum we try to fix it ;-) ).

Cheers,

Tom

Sorely tempted =). Maybe on Sunday. Thanks again, since the forum thread started I've been keeping tabs, and you're doing good work.

On Fri, Jan 21, 2011 at 13:43, Ray Rashif wrote:

On 20 January 2011 21:34, Tom Gundersen wrote:

...

You are encouraged to install systemd-git, systemd-arch-units-git and initscripts-systemd-git. It will not conflict with the standard initscripts package, and you can switch back and forth by making the change in GRUB during boot.

There is no systemd-arch-units-git.

http://aur.archlinux.org/packages.php?O=0&K=systemd&do_Search=Go

...

http://aur.archlinux.org/packages.php?O=0&K=systemd&do_Search=Go

http://aur.archlinux.org/packages.php?O=0&K=systemd-arch-units-git&do_Search=Go

http://aur.archlinux.org/packages.php?ID=40419 They just didn't put "-git" on the end, but it is a git package JKP -- The University of Edinburgh is a charitable body, registered in Scotland, with registration number SC005336.

On Fri, Jan 21, 2011 at 4:45 PM, Ray Rashif wrote:

On 21 January 2011 16:43, John K Pate wrote:

...

...

...

http://aur.archlinux.org/packages.php?O=0&K=systemd&do_Search=Go

http://aur.archlinux.org/packages.php?O=0&K=systemd-arch-units-git&do_Search=Go

http://aur.archlinux.org/packages.php?ID=40419

They just didn't put "-git" on the end, but it is a git package

That doesn't make one bit difference. The fact is that the package does not exist. It was just an FYI for the rest, I was not asking for any answers or links.

you do understand that you can edit the wiki page yourself to correct this mistake, right?

On Thu, Jan 20, 2011 at 7:11 AM, Tom Gundersen wrote:

Hi everyone,

I have been working on integration of Arch and Systemd.

At the moment I think the support is complete, and for me it has been 100% stable for some time. That said, much more widespread testing is required before it can really be said to be stable (so any testing and bug reporting would be highly appreciated, especially if you use lvm/raid/encryption).

bingo. this is the response i was looking for :-)

We would also like to improve the documentation, so if anyone has any questions that are not answered by the wiki page, please let me know.

Regarding people who are worried about getting an unbootable system: systemd and sysvinit can (and should) be installed in parallel, so you can switch between them by adding "init=/bin/systemd" to your kernel line in GRUB (so if it does break your boot, you can just reboot back into sysvinit).

Any questions can be posed on this mailinglist, on the systemd thread in the forum or in #archlinux or #systemd on IRC, where myself ("tomegun") and "falconindy" can sometimes be found.

that is excellent information and an encouragement to try it out; likely this weekend if it indeed works that well :-D i shot of a couple emails to drum up some comments regarding this proposal. to recap, here are some observations/pros/cons, feel free to add/remove/review/dispute because try as i might, i'm biased; let me be the first to say it :-) sysvinit [ PROS ] ) familiarity ) zero dependencies ) already works ) bash (is this even a pro?) ) ... i'm having a hard time here .... sysvinit [ CONS ] ) provides no information about boot ) relies on mountains of external bash scripts ) zero reliability or control over process once they start ) no real functionality at all tbh (is this biased? ... no :-) systemd [PROS] ) lightweight dependencies (DBUS) ) internal/fast handling of menial startup/teardown duties ) handling of complexities like RAID and LVM consistently? (verify?) ) will soon (or already) unify automatic process launch in general (cron/etc) ) verifiable boot (systemadm) ) introspective via DBUS ) accurate and precise kill/reload/restart (first time ever on linux!) ) resource limiting and monitoring of whole process groups! (via the cgroups, another first!) ) service rules for how to handle OOM and other nasties ) socket/bus/FS activation (implicit dependencies) ) boot tracing/stepping (interactive boot, once service at a time) ) significant peerstream (fedora/etc) support and force behind the project ) very complete Arch integrations! yay! sysvinit [ CONS ] ) non-zero dependencies ) newer, less production experience ) some missing unit/service files (which?) ) rc.conf either needs to go, or we find a way to update systemd when it changes... C Anthony

On 21 January 2011 01:48, C Anthony Risinger wrote:

On Thu, Jan 20, 2011 at 11:45 AM, C Anthony Risinger wrote:

...

systemd [PROS]

There needs to be a real alternative to rc.conf. I do not want something that will need rc.conf to "go" anywhere. One central configuration file.

C Anthony Risinger (2011-01-20 11:45):

i shot of a couple emails to drum up some comments regarding this proposal. to recap, here are some observations/pros/cons, feel free to add/remove/review/dispute because try as i might, i'm biased; let me be the first to say it :-)

sysvinit [ PROS ] ) familiarity ) zero dependencies ) already works ) bash (is this even a pro?) ) ... i'm having a hard time here ....

sysvinit [ CONS ] ) provides no information about boot ) relies on mountains of external bash scripts ) zero reliability or control over process once they start ) no real functionality at all tbh (is this biased? ... no :-)

systemd [PROS] ) lightweight dependencies (DBUS) ) internal/fast handling of menial startup/teardown duties ) handling of complexities like RAID and LVM consistently? (verify?) ) will soon (or already) unify automatic process launch in general (cron/etc) ) verifiable boot (systemadm) ) introspective via DBUS ) accurate and precise kill/reload/restart (first time ever on linux!) ) resource limiting and monitoring of whole process groups! (via the cgroups, another first!) ) service rules for how to handle OOM and other nasties ) socket/bus/FS activation (implicit dependencies) ) boot tracing/stepping (interactive boot, once service at a time) ) significant peerstream (fedora/etc) support and force behind the project ) very complete Arch integrations! yay!

sysvinit [ CONS ] ) non-zero dependencies ) newer, less production experience ) some missing unit/service files (which?) ) rc.conf either needs to go, or we find a way to update systemd when it changes...

systemd requires newest releases of Linux kernel, dbus, udev and util-linux-ng. An optional GUI (the systemadm you mentioned) even requires GTK-3. Hopefully this will not be a problem by the time it gets stable. Otherwise you will have to forget about servers. One more CON: systemd uses ~25 small binaries instead of a couple of shell scripts like /etc/rc.sysinit. The source of these binaries is lacking comments. Consequently, you have to be very good with C to improve anything. Read: the boot process becomes opaque. Enterprise scale administration becomes easier at the cost of system simplicity. There can be no KISS in an environment running systemd, dbus, policykit etc. -- -- Rogutės Sparnuotos

On Thu, Jan 20, 2011 at 2:34 PM, wrote:

So here's my question: will a system using systemd still allow this, *without* requiring source modifications to each and every application (to join a specific cgroup), and *whitout* every application requiring real-time or memory locks to be 'registered' somewhere ?

i don't believe it would have any ill effect, but would need some testing. i'm not 100% how it all ties into systemd, but a process being in a cgroup does not need permission/acceptance/patch from the process; it's just in it. cgroups are also hierarchical, so you can have groups of groups. there are several cgroup types (cpu/mem/etc) and each process can be in exactly one of each. one thing to keep in mind is cgroups are not always about _limiting_. you can also use them to ensure that certain groups get the resources or priority they need, ie. your audio apps. by default, nothing is restricted/limited, they are only grouped. C Anthony

On Thu, Jan 20, 2011 at 3:10 PM, wrote:

On Thu, Jan 20, 2011 at 02:54:24PM -0600, C Anthony Risinger wrote:

...

On Thu, Jan 20, 2011 at 2:34 PM,   wrote:

...

So here's my question: will a system using systemd still allow this, *without* requiring source modifications to each and every application (to join a specific cgroup), and *whitout* every application requiring real-time or memory locks to be 'registered' somewhere ?

i don't believe it would have any ill effect, but would need some testing.

i'm not 100% how it all ties into systemd, but a process being in a cgroup does not need permission/acceptance/patch from the process; it's just in it.  cgroups are also hierarchical, so you can have groups of groups.  there are several cgroup types (cpu/mem/etc) and each process can be in exactly one of each.

All correct. But a system using systemd (and hence cgroups) will put an application either into some default cgroup (which will very probably not have the required privileges, and hence needs code in the application to move to another cgroup), or it will require some 'registry' of applications that require a specific cgroup to run in. Both are a real PITA compared to what whe have today.

afaik it's not possible for a process to switch groups once it's started, by any means but dying and being restarted, but things may have changed on this front. i wouldn't think systemd does any limiting unless it's specified in the service files (again i'm not 100%) soooo.... what i think you'd do is create a high level target pointing to all the apps you need grouped together. if systemd config supports it, you would define the things you need in that. if it doesn't, you simply `echo` the values you want directly into the appropriate group in /sys/fs/cgroup. i don't see where you'd need to `register` applications or anything convoluted like that; it seems to me like you'd only need to create a single file. C Anthony

On Thu, 2011-01-20 at 15:52 -0600, Yaro Kasear wrote:

I was ALMOST behind a switch to systemd until I found out the guy behind it is Lennart Poettering. Now we can expect a half-broken init system that'll be in perpetual beta, and more passing off the buck on bug reports to distributions/drivers/whatever.

I can see you already responded again to this thread, but my immediate reaction to this mail was o.0!

2011/1/20 Yaro Kasear :

On Thursday, January 20, 2011 06:27:04 pm Ng Oon-Ee wrote:

...

On Thu, 2011-01-20 at 15:52 -0600, Yaro Kasear wrote:

...

I was ALMOST behind a switch to systemd until I found out the guy behind it is Lennart Poettering. Now we can expect a half-broken init system that'll be in perpetual beta, and more passing off the buck on bug reports to distributions/drivers/whatever.

I can see you already responded again to this thread, but my immediate reaction to this mail was o.0!

Lennart is the same person behind Pulse Audio, a known problematic sound daemon. What worries me is that systemd is much closer to the system, which might be potential for general all-around system breakage if systemd gets as bad as PA.

NOTE: I don't want to start a flame war here about PA or anything. I'm just concerned.

Yet you're pretty good at starting one. Do you have anything else to contribute except for it cannot possible be any good because this person wrote it.

On 01/20/2011 05:44 PM, Yaro Kasear wrote:

Maybe I would like to see systemd in action. My concerns are that this one person has a track record (With PA and Avahi) of making subpar daemons that fix non-existant problems in Linux. Yeah PulseAudio sucks so bad that just about everyone uses it now. Do you really think that the people behind nearly every major distro are stupid enough to use it as the default if it didn't do anything?

A lot of PA's issues came from using parts of drivers that weren't being used before, and speed differences between PA, ALSA, and OSS are completely unimportant on any modern computer. And yeah, you might not need it, but that doesn't mean it's useless and sucks.

It does not work for ice1712 based audio cards while ALSA works perfectly with those cards.

Heiko So the ALSA drivers don't do what they're supposed to and that PA's

On 01/21/2011 03:28 AM, Heiko Baums wrote: problem? If it doesn't work on your card, don't use it. It's why I don't use OSS on my laptop. And remember, what I was replying to was:

...

Lennart is the same person behind Pulse Audio, a known problematic sound daemon.

If your ALSA drivers are broken and don't support the feature PA uses, then don't use it. It doesn't make it bad software.

On Wed, Jan 26, 2011 at 07:31:37PM +0100, Heiko Baums wrote:

They are not comparable to usual sound cards like SoundBlaster, because they don't have Stereo or Surround sound. They just have several single input and output channels which can be mixed however you want. And this is just not supported by PA. But it is fully supported by ALSA and envy24control.

Yes. PA doesn't know what to do with the 8 or more identical channels because ALSA doesn't provide any info on how they are supposed to be used, and ALSA is right in doing this as there simply is no such information. The user decides how to wire up the channels. If he wants to use channels 7 and 3 for stereo, and 8,1,6,2,4,5 for 5.1 surround that's entirely possible, as it should be for any pro or semi-pro card. So this could probably be solved if PA would accept some manual configuration in such cases. Maybe it does, but so far apparently no-one knows how to do it. I guess it's just not possible as manual configuration sort of goes against the grain of Lennart's work. One practical solution could be to run PA as a Jack client. Most people using this type of card would be running Jack anyway. Ciao, -- FA There are three of them, and Alleline.

<various ALSA and PA dialog> "When will Arch switch to s_____d"... yes? ALSA != alsa-lib... yes? terminology is important. PA was created to provide business solutions. it does this; refer to widespread acceptance as a good approach. automation and intelligent decisions by computers are a Good Thing when coupled with transparency; refer to the history of computation and technology at large. as a new contact wisely quoted me recently: "I despise the idea of a human doing a computer's job" break away from this thread if you guys want to discuss sound politics :-) C Anthony btw, since i'm technically the "OP"... systemd w3rks. awesome. looking forward to doing what i can to make it a great solution for Arch.

On Thu, Jan 20, 2011 at 9:34 PM, wrote:

After years of problems and frustration,for the last two or three years we (the people using such audio apps on Linux) have finally got a system that allows normal users to do this (using ulimits and just two lines in /etc/security/limits.conf giving members of the 'audio' group the required privileges).

So here's my question: will a system using systemd still allow this, *without* requiring source modifications to each and every application (to join a specific cgroup), and *whitout* every application requiring real-time or memory locks to be 'registered' somewhere ? As far as I've understood it would not. Which would make systemd an absolute no-go for users requiring this.

Note that grouping processes using cgroups does not imply having to use the group scheduler . IIRC systemd uses a debugging hierarchy by default which does not affect program resources.

On Thursday, January 20, 2011 05:45:46 pm Tom Gundersen wrote: (snip)

@Yaro:

1) In my experience Lennart has been a pleasure to work with.

I, personally, have never worked with him. I have seen enough criticism of Pulse Audio, for example, getting handwaved and pinned on someone else's project. I think about it logically: If it works fine with ALSA, why did it inexplicably stop working fine with Pulse Audio running? Why, when he claims that PA not working is the fault of some distribution doing it wrong that it's busted no matter what system I try it on? Lennart has never, in his explanations of how PA actually screws up, actually explained to my satisfaction. And with PA being as flawed as it seems to me, systemd really worries me. From my perspective he couldn't get a sound daemon written that couldn't get sound working right on my system, why am I to believe systemd would fare any better. Let me put it another way, it seems like Lennart's great on new ideas on how to do things, poor on execution. From where I am sitting, anyway This is getting off-topic, and I don't mean to start a "Lennart sucks" flame war.

2) Regarding systemd and "The Arch Way", I guess this is a matter of opinion, but the way I see it, systemd fits perfecttly. For two reasons (off the top of my head, there might be more):

Firstly, while systemd is more complex (due to more features) than sysvinit, the arch-specific parts of systemd are much simpler than the arch-specific parts of sysvinit (since systemd does most of what rc.sysinit and rc.shutdown do for sysvinit).

Isn't the fact that systemd is more complex already makes it more or less against Arch's KISS principles? Or am I confused?

In fact, by pushing as much as our boot process "upstream" and sharing it with other distributions, we simplify our lives significantly due to the "free" testing and development effort we receive (especially the integration of the init system and related packages like udev and util-linux).

I certainly can't fault that part. That's probably open source's greatest strength. ESR called it "Linus' Law" and he explained it succinctly in the CatB paper. My concern is about how cooperative and willing to fix known issues upstream will have. You can write patches, but only one person (Or possibly, a group of people.) can approve it for an official inclusion with upstream. How many patches has Lennart rejected on systemd? How many has he accepted? Of those has he rejected has he given a verifiable reason?

Secondly, in a world where devices might come and go and their dependencies might be arbitrarily complex, the sysvinit architecture cannot work in a clean way. SysVinit was created when all setups could be assumed to be static, and this is simply no longer the case (this can best be seen in a setup with lots of raid/lvm/encrypted devices).

I admit to never using RAID/LVM/ENCRYPTION. But last I checked init had nothing whatsoever to do with how /dev is populated or managed. We have udev for that, and udev doesn't care what init system we use. All inits do is call udev when their scripts tell them to. I don't see how this makes systemd more viable than SysV when udev is what controls this instead, as udev works the same no matter if its SysV, Upstart, or systemd. Perhaps you can clarify init's role in device population besides running udev when appropriate, as SysV is already capable of that?

Cheers,

Tom

On Thursday, January 20, 2011 07:03:23 pm Ng Oon-Ee wrote: (snip)

This talk is probably a year or so out of date however. Try pulseaudio now, I think you'll be pleasantly surprised. You'd also have noticed that actual bug reports on our forums/ML etc. concerning pulseaudio have dropped to close to nil.

I am currently using OSSv4. I don't know how accurate a reading of PA I'd get while using it. Maybe I might temporarily switch to ALSA to give it a whirl. At any rate, lets not go too far off topic here.

On Fri, 2011-01-21 at 03:07 +0100, Heiko Baums wrote:

I'm quite satisfied with the current sysv init. It does everything which is needed to be done at boottime. And the init process simply is only for booting the system and for nothing else.

Btw., Ubuntu with its upstart or systemd is not starting faster for me than Arch Linux with its sysv init, at least not in Virtualbox and QEMU.

Specifically on this topic, I've noticed that the latest Ubuntu (which I setup on an old laptop for someone else) boots up REALLY fast, faster than Arch on this newer, more capable machine. I've not really put much effort into streamlining boot, but just to mention that whatever they've done with Upstart, it does bring boot times down.

On Fri, 2011-01-21 at 03:18 +0100, Heiko Baums wrote:

Am Fri, 21 Jan 2011 10:11:40 +0800 schrieb Ng Oon-Ee :

...

Specifically on this topic, I've noticed that the latest Ubuntu (which I setup on an old laptop for someone else) boots up REALLY fast, faster than Arch on this newer, more capable machine.

I've not really put much effort into streamlining boot, but just to mention that whatever they've done with Upstart, it does bring boot times down.

Probably just because the daemons aren't started at boottime but sometime at runtime when upstart or systemd thinks they are needed?

I'll test the latest Ubuntu in the next few days.

Heiko

I've always dismissed it as simply that, but I recall just commenting out all my daemons for one boot in Arch, and it didn't really help much. The MAIN problem seems to be that I'm using gnome =). As I said, never bothered much to check it out. The latest Ubuntu does leave a good impression on the start though (boot time and initial viewing, the themes are good). That said - I remember the mountains of ppas and self-compiled software I used to have. No thanks =)

Am Fri, 21 Jan 2011 03:16:34 +0100 schrieb Jan Steffens :

Parallel *is* faster because the kernel can put all those reads into an optimal order. Also, the obvious multiprocessing.

Is this done by the kernel? Means, does systemd use this kernel feature? Arch's and Gentoo's sysv init don't do it. In my experience - I have tested this on Gentoo and on Arch - these parallelizations make booting a lot slower particularly on older and slower systems.

Arch's init system is completely ignorant of dependencies.

Is this really an issue? I mean, Gentoo's init system is aware of dependencies. But I really haven't missed this on Arch. I usually know by myself, that apache first needs a network being set up. And I have the impression that this makes Arch's init system slightly faster and more KISS like.

This does not happen. This particular feature of systemd requires a patched apache, so systemd can hand the port over to the newly started server.

This would make it even worse, if apache needs to be patched. And if apache is patched can this behaviour of systemd be turned off? Heiko

On Fri, 21 Jan 2011 03:16:34 +0100 Jan Steffens wrote:

Arch's init system is completely ignorant of dependencies.

Depends on how you look at it, I guess. I see the explicit ordering and backgrounding of daemons (done by the user) in rc.conf as a (very crude) form of "dependency/parallelisation optimisation". Dieter

Am Fri, 21 Jan 2011 10:30:53 +0100 schrieb Philipp Überbacher :

Now I know what avahi and PA does, and I don't have a user for either, yet they are there. I don't have the slightest idea what CK and PK does, they don't have any tangible benefit for me, yet they are there. I'm not sure whether systemd will fall into the former or later category, but I'd be really surprised if it had any real benefit for me Yet I'm sure to have it on my machine within a year or so.

Me, too. I know that I have one or two entries in my Xfce menu for some avahi stuff, but I really don't know what this is for. It was just there as a dependency for another package. The only thing which has changed since I'm forced to using CK and PK is that I had to edit my .xinitrc and add a ck-launch-session, and that I now have again another daemon running on my system for features I had before, too, without these unnecessary, additional, resource eating stuff, which makes in the best case my system slower. But something doesn't work anymore without this CK and PK stuff. I currently can't remember what that was. The same with all those vfs daemons, which I really don't need and don't know what they are for. Or udisks-daemon. Some time it was just running on my system. I don't know why. I didn't start it by myself. I could access all my disks and devices without it before. Those developments are not always the best. And I'm really worried about them. I know, this is getting a bit off-topic. But it has to be said. Heiko

On Thu, Jan 20, 2011 at 8:07 PM, Heiko Baums wrote:

Am Fri, 21 Jan 2011 09:03:23 +0800 schrieb Ng Oon-Ee :

...

This talk is probably a year or so out of date however. Try pulseaudio now, I think you'll be pleasantly surprised. You'd also have noticed that actual bug reports on our forums/ML etc. concerning pulseaudio have dropped to close to nil.

5. In the same article I read that systemd binds itself to port 80 instead of starting apache at boottime and starts apache only if a request to port 80 comes in. This is not the task of an init system, and I have slight security concerns about that. If I tell the init system that I want apache being started then I want to have apache started at boottime or when I say so and not when systemd thinks it is needed. And this way systemd first needs to unbind itself from port 80 and then start apache and bind it to port 80. So if I open port 80 in my firewall this port is open without a software being bound to it, even if it's only a millisecond.

The same article also mentions this is hardly a new concept. inetd has been capable and doing this for years. And guess what, you can actually configure the desired behaviour. For example there are currently two different unit files for sshd. One that just starts the daemon, while the other one will only start if there's a incoming connection. https://github.com/falconindy/systemd-arch-units/blob/master/service/sshd.se... vs https://github.com/falconindy/systemd-arch-units/blob/master/service/sshd%40... Cheers, Sander

On Thu, Jan 20, 2011 at 4:17 PM, Jan Steffens wrote:

On Thu, Jan 20, 2011 at 9:34 PM,   wrote:

...

After years of problems and frustration,for the last two or three years we (the people using such audio apps on Linux) have finally got a system that allows normal users to do this (using ulimits and just two lines in /etc/security/limits.conf giving members of the 'audio' group the required privileges).

So here's my question: will a system using systemd still allow this, *without* requiring source modifications to each and every application (to join a specific cgroup), and *whitout* every application requiring real-time or memory locks to be 'registered' somewhere ? As far as I've understood it would not. Which would make systemd an absolute no-go for users requiring this.

Note that grouping processes using cgroups does not imply having to use the group scheduler . IIRC systemd uses a debugging hierarchy by default which does not affect program resources.

hmmm, i know that it used to used the `debug` group for lack of a better group. i believe a `noop` subsystem is also available now... i can't find any evidence on the systemd code of it using `debug` anymore. it seems to only use `name=systemd` which causes no other subsystems to be mounted unless they are explicitly included (which they don't seem to be...). i could be wrong but it appears that it's no longer using `debug`, and is using `none` or `noop` somehow instead; which would mean that it's not doing anything other than pure grouping. however glimpses like this: http://0pointer.de/public/systemd-man/systemd.exec.html show you just how powerful service files can be. in the example case of audio apps, it appears trivial to tweak resources to any degree if need be, with infinitely more precision than previous solutions. on a side note, there is also a PAM module that puts user sessions into groups as well, apparently providing the same flexibilities. C Anthony

On Thursday, January 20, 2011 06:48:14 pm Sander Jansen wrote: (snip)

- It's nice you can install it next to sysv-init. This makes it really easy to test without breaking the system.

You can do this? I might try it out. If it works as expected in its stage of development, I'll quick being a jerk about it. Also, how does that work? Do you choose an init at some point?

- If you installed vala 0.10, systemd-git won't build, even though gtk is disabled. This is a bug in the configure script of systemd. Solution would be either to install vala-0.11 or remove vala from your system.

I'm confused by this. Do you mean that vala's conflicting something out of the system or just causing a breakage in some way?

- I guess the initscripts-systemd is listed as an optional dependency of systemd, but I'm not sure how usefull systemd is without it...?

Though I don't 100% know how systemd is, don't all init systems need scripts to be useful? I would think that installing systemd's initscripts would be important for it to do its work.

- The login console seems to be slightly messed up. I can login, but error/log messages keep being send to the terminal as well.

What are the messages? Is there a bug in the bug tracker about this or is this purely an upstream concern?

- I know how I can change the default target on the boot line, but can I set it anywhere else?

Is that how you would run one init system over another?

- sshd has listed network.service as a dependency, but what if you use NetworkManager instead?

Would this be cause for a seperate set of daemon scripts just for systemd or are there plans to make it work with rc.conf in much the same way SysV does?

Cheers,

Sander

On Thursday, January 20, 2011 07:05:23 pm Ng Oon-Ee wrote:

On Thu, 2011-01-20 at 18:55 -0600, Yaro Kasear wrote:

...

On Thursday, January 20, 2011 06:48:14 pm Sander Jansen wrote: (snip)

...

- It's nice you can install it next to sysv-init. This makes it really easy to test without breaking the system.

You can do this? I might try it out. If it works as expected in its stage of development, I'll quick being a jerk about it.

I think you meant 'quit' =p. Freudian slip?

Actually, not sure how that typo got in there. Thanks for catching it. Yes, I did mean 'quit.'

...

Also, how does that work? Do you choose an init at some point?

I believe its been mentioned that you'd just alter the boot parameters in grub (or lilo if you use that).

Is this in the wiki?

On Thu, Jan 20, 2011 at 6:55 PM, Yaro Kasear wrote:

On Thursday, January 20, 2011 06:48:14 pm Sander Jansen wrote: (snip)

...

- It's nice you can install it next to sysv-init. This makes it really easy to test without breaking the system.

You can do this? I might try it out. If it works as expected in its stage of development, I'll quick being a jerk about it.

Also, how does that work? Do you choose an init at some point?

See the wiki, it's a kernel boot parameter.

...

- If you installed vala 0.10, systemd-git won't build, even though gtk is disabled. This is a bug in the configure script of systemd. Solution would be either to install vala-0.11 or remove vala from your system.

I'm confused by this. Do you mean that vala's conflicting something out of the system or just causing a breakage in some way?

There's a bug in configure script. It works fine if you don't have vala installed, but if you do have it installed it will bark at you if you have the wrong version.

...

- I guess the initscripts-systemd is listed as an optional dependency of systemd, but I'm not sure how usefull systemd is without it...?

Though I don't 100% know how systemd is, don't all init systems need scripts to be useful? I would think that installing systemd's initscripts would be important for it to do its work.

Yeah, this is more a packaging issue.

...

- The login console seems to be slightly messed up. I can login, but error/log messages keep being send to the terminal as well.

What are the messages? Is there a bug in the bug tracker about this or is this purely an upstream concern?

Just stderr output from the various daemons running. I'm guessing it goes to the wrong terminal.

...

- I know how I can change the default target on the boot line, but can I set it anywhere else?

Is that how you would run one init system over another?

systemd has a concept of runlevels, but calls them targets. You can override the default on the kernel boot line.

...

- sshd has listed network.service as a dependency, but what if you use NetworkManager instead?

Would this be cause for a seperate set of daemon scripts just for systemd or are there plans to make it work with rc.conf in much the same way SysV does?

systemd has "unit" files that replace the traditional sysv daemon scripts. They're much shorter and sweeter. The question was related to whether sshd should list "network" which is arch's /etc/rc.d/network script as a dependency. Cheers, Sander

On Thu, 2011-01-20 at 19:23 -0600, Yaro Kasear wrote:

On Thursday, January 20, 2011 07:09:43 pm Sander Jansen wrote:

...

On Thu, Jan 20, 2011 at 6:55 PM, Yaro Kasear wrote:

...

On Thursday, January 20, 2011 06:48:14 pm Sander Jansen wrote: (snip)

...

- It's nice you can install it next to sysv-init. This makes it really easy to test without breaking the system.

You can do this? I might try it out. If it works as expected in its stage of development, I'll quick being a jerk about it.

Also, how does that work? Do you choose an init at some point?

See the wiki, it's a kernel boot parameter.

...

...

- If you installed vala 0.10, systemd-git won't build, even though gtk is disabled. This is a bug in the configure script of systemd. Solution would be either to install vala-0.11 or remove vala from your system.

I'm confused by this. Do you mean that vala's conflicting something out of the system or just causing a breakage in some way?

There's a bug in configure script. It works fine if you don't have vala installed, but if you do have it installed it will bark at you if you have the wrong version.

...

...

- I guess the initscripts-systemd is listed as an optional dependency of systemd, but I'm not sure how usefull systemd is without it...?

Though I don't 100% know how systemd is, don't all init systems need scripts to be useful? I would think that installing systemd's initscripts would be important for it to do its work.

Yeah, this is more a packaging issue.

...

...

- The login console seems to be slightly messed up. I can login, but error/log messages keep being send to the terminal as well.

What are the messages? Is there a bug in the bug tracker about this or is this purely an upstream concern?

Just stderr output from the various daemons running. I'm guessing it goes to the wrong terminal.

...

...

- I know how I can change the default target on the boot line, but can I set it anywhere else?

Is that how you would run one init system over another?

systemd has a concept of runlevels, but calls them targets. You can override the default on the kernel boot line.

...

...

- sshd has listed network.service as a dependency, but what if you use NetworkManager instead?

Would this be cause for a seperate set of daemon scripts just for systemd or are there plans to make it work with rc.conf in much the same way SysV does?

systemd has "unit" files that replace the traditional sysv daemon scripts. They're much shorter and sweeter. The question was related to whether sshd should list "network" which is arch's /etc/rc.d/network script as a dependency.

Cheers,

Sander

I think I'll try this out. I'll be sure to file bug reports as necessary.

Can we move this discussion to the forums, if there is a a real ready systemd replacement for archlinux, make the devs interested. Secondly on the forums probably the trolls won't reply ;) -- Jelle van der Waa

On Sat, 2011-01-22 at 13:43 +0100, Dieter Plaetinck wrote:

On Sat, 22 Jan 2011 13:36:45 +0100 Jelle van der Waa wrote:

...

Secondly on the forums probably the trolls won't reply ;)

afaik forums contains more trolls then mailing list.

Probably in number, but I'd wager that replies are faster here than on the forums =)

Sander Jansen (2011-01-20 19:09):

On Thu, Jan 20, 2011 at 6:55 PM, Yaro Kasear wrote:

...

On Thursday, January 20, 2011 06:48:14 pm Sander Jansen wrote: (snip)

...

- It's nice you can install it next to sysv-init. This makes it really easy to test without breaking the system.

You can do this? I might try it out. If it works as expected in its stage of development, I'll quick being a jerk about it.

Also, how does that work? Do you choose an init at some point?

See the wiki, it's a kernel boot parameter.

By default, Linux kernel runs /sbin/init as PID 1 (the first user level process). This can be changed by adding init=/binary/to/run to the kernel command line. The command line can be changed in the kernel config, in the boot loader config or during boot in grub, lilo, syslinux, etc. For example, in grub one sees "kernel /boot/vmlinuz26 root=/dev/sda5 ro". One can append this to change what the kernel starts: init=/sbin/init init=/bin/systemd init=/bin/bash

...

...

- I guess the initscripts-systemd is listed as an optional dependency of systemd, but I'm not sure how usefull systemd is without it...?

Though I don't 100% know how systemd is, don't all init systems need scripts to be useful? I would think that installing systemd's initscripts would be important for it to do its work.

Yeah, this is more a packaging issue.

If you compile and install the upstream systemd source, you can reboot into a working system (it comes with a bunch of streamlined unit files needed for early boot). In fact, systemd is pretty good at not requiring any unit files: you can launch it with only one unit file for getty and have a working system. These initscripts-systemd are used as a bridge between systemd and some of the early boot scripts in Arch.

...

...

- The login console seems to be slightly messed up. I can login, but error/log messages keep being send to the terminal as well.

What are the messages? Is there a bug in the bug tracker about this or is this purely an upstream concern?

Just stderr output from the various daemons running. I'm guessing it goes to the wrong terminal.

This probably means that systemd was unable to start syslogd or doesn't know about it. Which one do you use? Is it running?

...

...

- I know how I can change the default target on the boot line, but can I set it anywhere else?

/lib/systemd/system/ has a symlink: default.target -> graphical.target You can create /etc/systemd/system/default.target to override it.

...

...

- sshd has listed network.service as a dependency, but what if you use NetworkManager instead?

Would this be cause for a seperate set of daemon scripts just for systemd or are there plans to make it work with rc.conf in much the same way SysV does?

systemd has "unit" files that replace the traditional sysv daemon scripts. They're much shorter and sweeter. The question was related to whether sshd should list "network" which is arch's /etc/rc.d/network script as a dependency.

Some of them are not so sweet. In fact, most of the advanced functions (e.g. on demand service startup, fine tuning dependencies) are difficult to grasp and the help is scattered over a handful of man pages. All of the advertised features of systemd bring a lot of complexity with them. -- -- Rogutės Sparnuotos

I think systemd is too much complicated and thus error prone. And so does SysV init. In terms of reliability it should be as simple as possible. What I really like is the the idea of runsv [1] – the init itself does almost nothing. Even the simple things like respawning of the processes are handled by external daemons. This is what I call unix way and what I think is the most future proof (what if D-Bus become obsolete etc etc). And as other people said – I'm afraid of systemd even more because it was written by the same person as Pulse Audio was. PA didn't work very well for quite a long time. I'm not going to argue about that (it's just my personal opinion and none of you will change it), but I just don't believe someone who wrote a piece of crap which took several years to become generally usable will suddenly write something so delightful so it can be used as a replacement of one of the most tested and most established things in Unix/Linux world. [1] http://busybox.net/~vda/init_vs_runsv.html

oh... my. there is too much <expletive deleted> to respond properly so i'll try touch a couple [several] things ... ... why the resistance at all? let me reiterate this niiiice and slow: SYSVINIT HAS NO POWER, NO FUNCTIONALITY, AND ABSOLUTELY ZERO USEFULNESS ON IT'S OWN. the "unix philosophy" (debatable in itself...) of doing one thing doesn't usually translate to LITERALLY DOING ONE THING. please please please, please, read that several times until it sinks in nice and deep; every single argument about sysvinit's "simplicity", "maturity", blah blah, woka woka, etc etc, and anything else related to it's stability is complete nonsense because ... YOUR BOOT PROCESS IS A MEGAMATRON SHELL SCRIPT, AND HAS PEANUTS TO DO WITH INIT; IN FACT, INIT IS NOT EVEN NEEDED. capisce? good. now we can move on and give up this pointless cling to something that provides us nothing WHATSOEVER. systemd is superior in every single way imaginable. that is the pure and simple truth; it's not even an arguable point. many of the "concerns" here are already answered/clarified higher up in the thread, or are nothing more than FUD and personal grudges against a guy who seems to SIMPLY WANTS TO IMPROVE THINGS AND DOESN'T CARE IF YOU WANT TO USE SYSVINIT FOR 60 MORE YEARS. systemd solves real user/business problems, and whether or not you/me/us make personal use of every single possible feature is irrelevant. these sentiments are echoed throughout most of community. systemd has <whatever number> binaries?? yeah, and? so what? take a hard look at the precious sysvinit "suite"; you'll find 1700 external calls to grep, sed, awk, cut, ..., ... even if it mattered one tiny little bit, i'm pretty sure you'll exceed systemd's count in the first file or two. i've been thru the init scripts several times and ramfs init; i know. just believe me. why should init do "do almost nothing"?? how many other applications do we slick developers write where the goal is to do a whole 'lotta nothing? come on. systemd doesn't step out of scope one bit; it's job is to reliably start, stop, and babysit processes with the parameters, environment, and constraints WE DEFINE. that's it; feels pretty dang simple/kiss to me. actually take a look at your boot process someday... then come back and drone on about how slick systemd is. so what if systemd requires the latest <insert here>? that's what we run around here. nobody cares about a server running <insert deity> knows whatever version; just use sysvinit like usual... wait, what's the argument again? ... really, drop everything about pulseaudio. there are many many people involved with both projects. this has to be the single dumbest argument imaginable. i'd link to a list of fallacies again but it's already been; do a search, then come back with real concerns. nobody cares about how complex systemd might look to a user who has neither read/understood the code nor even looked at the VERY COMPLETE man pages. this quite possibly rings in as the second dumbest argument. take a look at your kernel, what are we at, like 12 million SLOC? look at any decent software your using RIGHT NOW... what do you find? yup, code. *gasp* CK/PK are (AFAIK) advancements that let various CLI/GUI/UI/automated tools perform dangerous tasks with high levels of control; fine grained permissions. very few business problems are solved by coarse unix permissions on the FS. btw, introducing arguments with "i don't know what X is, understand why it exists, nor have i even attempted to realize why it might be useful, but it's total garbage because ... " effectively destroys yourself before you've started. developers write software to solve problems, not chase pixies. well it's time for a recess. i'm am at a serious loss of words for most of this; i fail to understand how one can competently arrive to the conclusion that sysvinit is even close to the same skillset as systemd... sysvinit is a fckn bench-warming waterboy whose only on the team because he never graduated and his dad invented the sport 40 years ago. so, look beyond the "boot", and read about systemd and the incredible flexibility it provides before looking for the nearest rock to throw. i suggest here again: http://0pointer.de/public/systemd-man/systemd.exec.html http://0pointer.de/public/systemd-man/systemd.unit.html http://0pointer.de/public/systemd-man/systemd.service.html http://0pointer.de/public/systemd-man/systemd.socket.html http://0pointer.de/public/systemd-man/systemd.mount.html now, tell me how sysvinit provides even 5% of that functionality? some of that i don't even know how to accomplish MANUALLY, and others i don't even know WTF they do. holy frustration batman. C Anthony

bravo, sir. i'll throw you one last bone, because your track record in this conversation is one of severe inability to comprehend any information presented. On Fri, Jan 21, 2011 at 12:15 PM, Yaro Kasear wrote:

On Friday, January 21, 2011 11:53:22 am C Anthony Risinger wrote:

...

oh... my.  there is too much <expletive deleted> to respond properly so i'll try touch a couple [several] things ...

... why the resistance at all? let me reiterate this niiiice and slow:

Because it's completely unnecessary.

of course; i don't know why anyone would want the only process capable of babysitting to actually babysit. hmmmmm......

...

SYSVINIT HAS NO POWER, NO FUNCTIONALITY, AND ABSOLUTELY ZERO USEFULNESS ON IT'S OWN.

the "unix philosophy" (debatable in itself...) of doing one thing doesn't usually translate to LITERALLY DOING ONE THING.

please please please, please, read that several times until it sinks in nice and deep; every single argument about sysvinit's "simplicity", "maturity", blah blah, woka woka, etc etc, and anything else related to it's stability is complete nonsense because ...

YOUR BOOT PROCESS IS A MEGAMATRON SHELL SCRIPT, AND HAS PEANUTS TO DO WITH INIT; IN FACT, INIT IS NOT EVEN NEEDED.

Some form of init is still needed even if the initscripts are glorified shell scripts. What do you think has to RUN those shell scripts for them to be of any use at all?

ehm... you can just point `init=/some/shell/script` and have that shell script source the normal rc.* files; make it `trap` the INT and PWR signals and.... ZOMFG!!!! you have a complete "sysvinit" in bash in about 15 lines. take a look at how the ramfs boot works, because it does exactly this.

Hell, even without a single initscript, an init system STILL needs to be in place. That's just how UNIX works

the kernel just needs something to run. and it actually pretty much always runs /init... the initramfs later on passes the `init` parameter within /proc/cmdline to switch_root for exec'ing.

SysV Init is simple, which is what Arch is all about.

i'm sorry but your incredibly wrong. again, for the 700th time, sysvinit does nothing. all functionality is in shell scripts. please stop chanting this because i'm about 95% sure that the kinds of people who are capable of actually writing these scripts would agree, if this thread is any indication of that.

...

capisce?  good.  now we can move on and give up this pointless cling to something that provides us nothing WHATSOEVER.

It provides us with a solid reliable way to boot our system and manage what runs at boot time. Anything more than that is luxury and unnecessary.

there is nothing solid or incredibly reliable about bash; read a comprehensive doc detailing all the things that affect it's execution. and... uhm.... manage?? at what point does init do this again? ooooh, you mean rc.d scripts? did i just say scripts? yes, scripts. so, not init. bash. custom. share-nothing.

...

systemd is superior in every single way imaginable.

This is a matter of opinion. Not fact.

right, if your braindead. like sysvinit :-)

...

that is the pure and simple truth; it's not even an arguable point.

I am arguing it, therefore it is arguable.

well that's circular reasoning if i dun ever saw'ed it. nice.

...

many of the "concerns" here are already answered/clarified higher up in the thread, or are nothing more than FUD and personal grudges against a guy who seems to SIMPLY WANTS TO IMPROVE THINGS AND DOESN'T CARE IF YOU WANT TO USE SYSVINIT FOR 60 MORE YEARS.

I doubt that. Again, to use Pulse Audio as an exabmple, he's stated he wanted it to take ALSA's place many times. He may not have said it about systemd, but there's no reason, none, to believe he doesn't expect it to replace SysV init on most Linux distributions.

as it should. sysvinit is next to worthless. recognize this. computers should do more for us as time goes on; it's not exactly a novel idea.

...

systemd solves real user/business problems, and whether or not you/me/us make personal use of every single possible feature is irrelevant.

And those problems are...? So far even those further up in this thread haven't described any real problems aside from certain inconvient things about the Arch Initscripts, which are fixable without introduce a needlessly complex init replacement.

@#$@#$!!!!.... please see the numerous links in the first post that you most certainly have not visited.

...

these sentiments are echoed throughout most of community.

Are they? Please back up this assertion with facts instead of unsubstantiated rants.

read: consistency/reliability/transparency/control this is what the community wants. sysvinit does not provide. see the many good posts by Tom.

...

systemd has <whatever number> binaries?? yeah, and?  so what?  take a hard look at the precious sysvinit "suite"; you'll find 1700 external calls to grep, sed, awk, cut, ..., ...

Those are core utilities, not the sysvinit suite. They're gonna be there whether or not we use SysV Init. And I bet even systemd would end up using them too in its units.

ya, so what? does that mean a good process manager should be parsing unpredictable text and making decisions on that? let me think about that, no. i apologize, but have you ever wrote a real application?

...

even if it mattered one tiny little bit, i'm pretty sure you'll exceed systemd's count in the first file or two.

Again, they're core utilities you'll find in ANY POSIX system. Just because SysV Init's scripts uses them is misleading and irrelevant and pointing this out is a blatant red herring.

whether these "core" apps already exist is what's irrelevant. i am referring to the need to use umpteen external; processes just to do trivial things like string manipulation. if you really think making 1700 calls to external processes adds stability then your really ... ... :-) read the links; you will learn several good things, i promise!

...

i've been thru the init scripts several times and ramfs init; i know.  just believe me.

So am I. Your point has absolutely no value at all, as those utilities are not there for init's sake, but to make scripting at all useful. Switching to systemd wouldn't fix that one bit.

you are missing the point by ~100 lightyears.

...

why should init do "do almost nothing"??

Init decides what is run in what circumstances. That's ALL it needs to be. This is not a problem that needs to be fixed. Your argument is invalid.

no, it doesn't. it does ONE thing, ONE time. it can respond to SIGINT and SIGPWR, that's all. soooo.... try again next time.

...

how many other applications do we slick developers write where the goal is to do a whole 'lotta nothing?  come on.  systemd doesn't step out of scope one bit;

Yes it does. Almost every one of systemd's features are completely unneeded for a fully functional boot process.

sure, if you don't actually care about your system after boot, or enjoy wasting time setting up the same "features" in more fragile ways. i, for one, have better things to do, and systemd is on a great path to helping me manage all the servers in my data centers. init has SUPERVISORY POWERS GRANTED BY THE KERNEL. use it.

Nothing systemd offers isn't already done with SysV Init and simple bootscripts.

ah hahahahahahaha. ah man that's rich. thanks for that.

...

it's job is to reliably start, stop, and babysit processes with the parameters, environment, and constraints WE DEFINE.

SysV Init does that too. Or have you not noticed the existence of /etc/inittab, /etc/rc.conf, or /etc.rc.local. Those three files alone already grant a finer amount of control over how Arch's boot process than systemd does. Let's not even touch on the "magical" things you can do with mkinitcpio.

same. nice try though.

Your rant stinks of someone who doesn't understand the first thing of how the Arch boot process actually works.

kk :-) 'cept i've read it line by line several times and have implemented multiple mkinitcpio hooks. do you have anything of value to add yet? because you've submitted 10+ msgs now and i cant find anything of worth.

...

that's it; feels pretty dang simple/kiss to me.  actually take a look at your boot process someday... then come back and drone on about how slick systemd is.

It's not KISS at all. It does things an init system plain doesn't need to.

please see the first post.

...

so what if systemd requires the latest <insert here>?  that's what we run around here.  nobody cares about a server running <insert deity> knows whatever version; just use sysvinit like usual... wait, what's the argument again?

That systed fixes no problems and it only looks like its being looked at for "newness" sake? That it introduces completely unneseccary complexity to the boot process?

you just don't get it chief. READ. THE. LINKS. :-)

...

... really, drop everything about pulseaudio.  there are many many people involved with both projects.  this has to be the single dumbest argument imaginable.  i'd link to a list of fallacies again but it's already been; do a search, then come back with real concerns.

Your entire argument here was riddled with fallacies of its own. Whereas arguing about a developer's track record is not a logical failing, but completely relevant to the issue at hand.

except for the fact that code speaks for itself, and it's very much a collaborative effort at this point. what do you do for a living that endows you with such valuable insights as to the competence of others?

...

nobody cares about how complex systemd might look to a user who has neither read/understood the code nor even looked at the VERY COMPLETE man pages.

Plenty of Arch users care. Otherwise this thread wouldn't be going the way it has. Systemd is pretty much against the Arch Way, and the KISS principles of UNIX. Trying to claim the average arch user doesn't care is incorrect.

im sorry, but im not sure the average arch user matters. if you look at the thread closely, you will see that the more prominent members of the community are usually in agreeance with what Tom, myself, and others who don't mind learning something new, have outlined and suggested. why you ask? because it's less work for those doing the work. "Simplicity of implementation, code-elegance, and minimalism shall always remain the reigning priorities of Arch development." hmmm, where does systemd NOT fit into that, and oodles of bash scripts fit better? "Complexity without complication." and how are adhoc rc.d scripts simpler than clearly defined unit/service/socket/target files? "Code-correctness over convenience." bash is one giant convenience. and dont forget this: " 'Simple' is defined from a technical standpoint, not a usability standpoint. It is better to be technically elegant with a higher learning curve, than to be easy to use and technically [inferior]." need i say more? because in this context, sysvinit is the pinnacle of inferior.

...

this quite possibly rings in as the second dumbest argument.  take a look at your kernel, what are we at, like 12 million SLOC?  look at any decent software your using RIGHT NOW... what do you find?  yup, code.  *gasp*

That's not even close to the argument I or others are arguing and you know it. Enough with the red herrings already.

ok... peeeerhaps; but don't pretend to evaluate systemd, then proceed to make wild assumptions, when you clearly have no real understanding of it at any level whatsoever. it doesn't help those who are truly interested.

...

CK/PK are (AFAIK) advancements that let various CLI/GUI/UI/automated tools perform dangerous tasks with high levels of control;  fine grained permissions.

Made possible in no small part through things like hal and udev, who by themselves can actually fulfill that role with CK or PK.

i'm starting to think you don't know how udev works or what it is.

...

very few business problems are solved by coarse unix permissions on the FS.  btw, introducing arguments with "i don't know what X is, understand why it exists, nor have i even attempted to realize why it might be useful, but it's total garbage because ... " effectively destroys yourself before you've started.  developers write software to solve problems, not chase pixies.

Did anyone make that logical fallacy anywhere in this discussion? I looked into how systemd works, I also looked into who made it and his track record for making overtly complex software that solves problems that don't exist.

try again... this time look "closely-er" :-)

...

well it's time for a recess.  i'm am at a serious loss of words for most of this; i fail to understand how one can competently arrive to the conclusion that sysvinit is even close to the same skillset as systemd... sysvinit is a fckn bench-warming waterboy whose only on the team because he never graduated and his dad invented the sport 40 years ago.

I could reiterate the problems with your argument. But I won't, I already covered it earlier

haha what, no sense of humor either? man, tough crowd tonight.

...

so, look beyond the "boot", and read about systemd and the incredible flexibility it provides before looking for the nearest rock to throw. i suggest here again:

Beyond the boot I don't want the init system to be anything more than the root parent. That's what init is for: Bring the system up/down and parenting itself to other processes. Anything else is just gravy and NOT NECESSARY.

hmm, let it be the root supervisory parent, but do't let it do anything. why didn't we think of that before? it's genius! oh wait... yet. again. sysvinit. doesnt. do. anything. at. all. for. you. bash. scripts. handle. everything. get it right.

...

http://0pointer.de/public/systemd-man/systemd.exec.html http://0pointer.de/public/systemd-man/systemd.unit.html http://0pointer.de/public/systemd-man/systemd.service.html http://0pointer.de/public/systemd-man/systemd.socket.html http://0pointer.de/public/systemd-man/systemd.mount.html

now, tell me how sysvinit provides even 5% of that functionality? some of that i don't even know how to accomplish MANUALLY, and others i don't even know WTF they do.

SysV doesn't need to. We have udev and hal to do those things, and they likely to it in a more clearcut and reliable way than systemd ever would.

now i know you don't understand udev. goto: line 'ahaha...' im sorry man, very rarely am i this abrasive, but you are hopelessly misinformed. please try some of the links provided; Lennart actually does a very good job of laying it out. and to Tom and others who have put in the work, thanks. default or not, it will be a great improvement to Arch. C Anthony

On Fri, Jan 21, 2011 at 9:07 PM, Ray Rashif wrote:

I just tried systemd. And it just failed. I don't want to know anything else, and I don't want to find out why.

To everyone trying out systemd, please keep in mind that the arch integration has not received a lot of testing yet, so don't expect it to "just work". It does for me (and other people working working on systemd and Arch integration, as far as I know), but I guess there are lots of cases that we have not tried yet. Any detailed descriptions of failures would be highly appreciated.

Just looking at its underlying framework without having to make it run successfully is enough to get the point across - it is _not_ KISS.

I think this depends on your point of view. For an administrator, user or arch developer, the simplicity should be no less than with initscripts. Depending on what exactly you are doing, I would argue that usually it is much simpler (in the worst case scenario, you can always just use your old arch configuration files and everything will work the same (fingers crossed...)). The complexity only becomes an issue if you want to do systemd development, but I guess that most people will not do that, and requiring all users to understand the internal workings of all the software they use is a bit ambitious (I certainly don't). What should matter is the simplicity of software's external interfaces (like configuration files, behavior, etc). Thanks to everyone who's taking a look at the systemd packages, apologies to anyone whose babies it eats. Tom

On 22 January 2011 05:30, C Anthony Risinger wrote:

ok, so what went wrong?  your sure you did everything correctly?  more info would be needed to help you.

Thank you, but I can help myself if I want to pursue this, when I have the time to pursue this. The point was to check how far it was in the integration. No more, no less.

ooooh now i see. maybe you meant to post here:

http://ubuntuforums.org/ :-)

... because arch users are encouraged to help solve their own problems; whats your goal exactly?

Are you on a provoking rampage? Because my goal was to simply give you some feedback for this topic you brought up. If that can even be a goal. Looking at Tom's reply was much more worthwhile. You probably thought I was trying to undermine the validity of your points running across this topic - which was not the case at all.

"KISS, #2 in the top ten list of misunderstood/abused/regurgitated concepts."

Sorry, but I think I know KISS when I see KISS.

let me get this straight, you tried once, it didn't work once, so now it's garbage?  you must think the whole AUR is garbage too then?  or what?

No. I tried it for all its hype, to _inspect_ what "systemd" comprises, to get the general idea. No more, no less.

well luckily i don't think they run a democracy around here ;-)

Of course, they don't. Either way I would have nothing to gain or lose. It is just a personal opinion.

indeed, and i'd mostly agree.  however while im not a developer for archlinux, i wouldnt waste time on obsolete systems when a better alternative saves me time; you may end up maintaining the initscripts yourself.  keep that in mind.

the point of systemd is to make ALL of our lives easier, not more difficult.

Right. Anyway, you might want to realise that nobody who "matters" has had - up to this point - anything to say about "switching to systemd". Mostly because none of them have the time (so there is still hope). You can always file an FR in the tracker if you want to gain some progress for your enthusiasm, or even get an ultimatum.

On Fri, Jan 21, 2011 at 9:51 PM, Yaro Kasear wrote:

If it isn't broken, don't fix it. We put grub2 in [extra], not [core], for the same reason we really should put systemd in [extra] and not [core].

Don't get me wrong, but no one is putting anything anywhere. This is not a voting. The decision of bringing any package to the official repos is exclusively on the shoulders of a developer willing to maintain it. So all the discussion about entering or not is moot. On the other hand, I'm enjoying the articles very much. The comments on each blog post are very enlightening. It even shows that Lennart has more patience than I would have... I've seen it being bashed without any reason and yet answer politely. One very inspiring comment by Lennart, that sums up a lot of my own thoughts is: "... you are right, systemd is nothing like traditional Unix. And that is a good thing. Unix has been designed 41 years ago. You honestly believe that its design is perfect and flawless and 41 years after it was designed still should be followed in all detail? No, computers changed, and Unix never was perfect. It probably was a better design than most other operating systems, but this does not mean it is perfect and we should never depart from it." So, maybe we could tackle this discussion with an open mind, instead of being so zealots about what you already know. Remember, you didn't born knowing Linux. You can learn other things too :) I'm happy with the thread, because I'm having a good time reading about systemd. I'll try it in a few moments and see what it gives. Thanks Risinger for the links and Tom for the packages :) -- A: Because it obfuscates the reading. Q: Why is top posting so bad? ------------------------------------------- Denis A. Altoe Falqueto Linux user #524555 -------------------------------------------

On Jan 21, 2011 5:42 PM, "Ray Rashif" wrote:

On 22 January 2011 05:30, C Anthony Risinger wrote:

...

... because arch users are encouraged to help solve their own problems; whats your goal exactly?

Are you on a provoking rampage? Because my goal was to simply give you some feedback for this topic you brought up. If that can even be a goal. Looking at Tom's reply was much more worthwhile. You probably thought I was trying to undermine the validity of your points running across this topic - which was not the case at all.

OK fair enough; I may have misinterpreted a bit. The "I don't want to know" stuff didn't resonate well with me, esp. since you didn't provide any logs/etc. so I got a different impression. My apologies if that's the case... Yeah I guess I may have rampaged a bit. It's frustrating to see ideas trampled on for reasons holding little if any merit; many feel like leaps of faith to hang on? To what? Much work has gone into this from all sides for the improvement of everyone, and warrants some respect. No worries.

...

the point of systemd is to make ALL of our lives easier, not more difficult.

Right. Anyway, you might want to realise that nobody who "matters" has had - up to this point - anything to say about "switching to systemd". Mostly because none of them have the time (so there is still hope). You can always file an FR in the tracker if you want to gain some progress for your enthusiasm, or even get an ultimatum.

I swear there was one in there already, will have to check. Good idea! This thread may have outlived it's usefulness; I hope many have a better understanding at the least (and the thread itself was a play on the upstart thread if its not obvious ;-) because there are many interesting applications to an intelligent init. C Anthony [mobile]