On Wed, Apr 25, 2012 at 11:54 AM, Rashif Ray Rahman <schiv@archlinux.org>wrote:

On 25 April 2012 23:25, Tom Gundersen <teg@jklm.no> wrote:

...

I strongly believe that should we move away from intscripts it needs to be to an event-driven system (such as systemd or upstart) and it was not clear from the webpage that OpenRC provides this.

I concur.

Although the current init works for me and won't encourage me to shift to things like systemd anytime soon, efforts towards introducing alternatives would have to be justified by how much more they're able to bring to the table. Simply being different or offering a few bonuses won't be enough, IMO. Systemd is something dynamic and is what fits that ideal model, a model which satisfies the needs of the present and hopefully the future.

Otherwise, I like my init as simple as it currently is. Dependency is never a problem as it's very little work to manually ensure they're met.

-- GPG/PGP ID: C0711BF1

The problem I have with a systemd like init system is that it's way too much overkill for a server. I like our current situation as we have an extremely simple init system and users can drop in systemd if they so choose. --Kaiting. -- Kiwis and Limes: http://kaitocracy.blogspot.com/

The 25/04/12, Calvin Morrison wrote:

...

I like our current situation as we have an extremely simple init system and users can drop in systemd if they so choose.

I like our current situation as we have an extremely simple init system and users can drop in //OpenRC// if they so choose.

+1

Arch follows the nice KISS principle and a bit of DIY. We should have default a simple and sane system that works, and if anyone feels the need to install some crazy new fangled type, they can go ahead.

OpenRC works well in Gentoo, i don't see why it would not work well here.

So, OpenRC could be proposed as an alternative init system in AUR. -- Nicolas Sebrecht

On 25 April 2012 23:25, Tom Gundersen <teg@jklm.no> wrote:

...

I strongly believe that should we move away from intscripts it needs to be to an event-driven system (such as systemd or upstart) and it was not clear from the webpage that OpenRC provides this.

I concur.

Although the current init works for me and won't encourage me to shift to things like systemd anytime soon, efforts towards introducing alternatives would have to be justified by how much more they're able to bring to the table. And how many antifeatures they have ;) For me the feature list of systemd is kinda nice, it's obviously more comprehensive than the "old" init systems, but it goes against the unix spirit of having one tool for a job, and do this job well. Having all

Simply being different or offering a few bonuses won't be enough, IMO. Systemd is something dynamic and is what fits that ideal model, a model which satisfies the needs of the present and hopefully the future. "dynamic" how? People have thrown "event based" and such words around, but no one has dared to clarify or properly define what they mean by it. Thus I can't understand if there's anything missing in OpenRC or people are just

On 04/25/12 23:54, Rashif Ray Rahman wrote: the features and being able to not have the antifeatures is what makes OpenRC extra nice ... throwing words around because it feels good.

Otherwise, I like my init as simple as it currently is. Dependency is never a problem as it's very little work to manually ensure they're met.

You only realize what you're missing when you've lost it ;) For me not having dependencies is very frustrating, it makes restarting things so random and assumes that I know or care about who depends on what (hint: that's the job of the init system, not mine)

On Mon, 07 May 2012 22:40:01 +0800 XeCycle wrote:

Violations of this philosophy can be easily found. The Linux kernel is such one. It is already big, with many misfeatures, or "anitfeature"s; but we all use it, right? Linus said such a design simplifies the intercommunication between kernel modules.

I disagree, your obviously clutching at straws, OpenBSD, no modules but monolithic yes. Many argue for and against monolithic or kernels such as QNX where drivers can't hang the kernel (atleast in theory). This is irrelevent. Simple tools do become more than they're parts. grep, cut, tr, cat and do they're particular job well and with less bugs. Init is a simple job. The main case you didn't bring up is perhaps where speed is paramount. I can't think of any others of the top of my head and certainly none that apply to whether the ultimate dependency, init, should be complex. Imagine a system where the kernel had been stripped down to kilobytes yet init was megabytes. p.s. I wouldn't mind knowing more about event driven too. I believe I was given an impression of what it was when systemd first hit ubuntu but I can't remember finding out exactly. A quick google just now turned up nothing.

On Mon, 7 May 2012 17:19:58 +0100 Kevin Chadwick <ma1l1ists@yahoo.co.uk> wrote:

p.s. I wouldn't mind knowing more about event driven too. I believe I was given an impression of what it was when systemd first hit ubuntu but I can't remember finding out exactly. A quick google just now turned up nothing.

Ubuntu is unlikely to provide an official support for systemd in the mid-term (i.e. in the next 2+ years): http://www.markshuttleworth.com/archives/1121. My reading between the lines: "We have an enterprise branch (LTS) so can't afford to come up with new things every 6 months (especially if upstart does everything we want), while Fedora is designed exactly for this goal.". I think that's a reasonable decision, especially now when they are picking up consolekit. -- Leonid Isaev GnuPG key: 0x164B5A6D Fingerprint: C0DF 20D0 C075 C3F1 E1BE 775A A7AE F6CB 164B 5A6D

Hi Patrick, On Mon, May 7, 2012 at 3:30 PM, Patrick Lauer <patrick@gentoo.org> wrote:

People have thrown "event based" and such words around, but no one has dared to clarify or properly define what they mean by it. Thus I can't understand if there's anything missing in OpenRC or people are just throwing words around because it feels good.

I assumed anyone working with init systems had a firm grasp of the main selling-points of the competition, but let me try to explain what I have in mind (by no means take this as authorative, there is plenty of writing on this both by the upstart guys and the systemd guys who know it better than me). I guess it is best explained in terms of an example, let's take storage: Traditionally we would wait for all the storage devices to be enumerated, then fsck all of them, then mount all of them, then start the daemons which might require something from say /var. This no longer works well with modern hardware and a modern kernel. The reason is that we don't know when the kernel has finished enumerating all the devices (sometimes we do, but not always, it depends on the device), and we certainly don't know in case the user has not yet plugged in all the devices at boot, or some of them are network devices that may or may not appear depending on what network we are currently connecting to. An event-driven init system would turn this on its head, and never wait for "all the things to be ready", rather start things on-demand and whenever their dependencies are satisfied. This leads to a much simpler system (from the admin/system daemon developers point of view), but it requires the init system to keep closer control over the state of the system, listen to events, etc. This means that there is no difference between "boot time" and any other time. If you plug in your network cable, or your external hard drive a week after switching on your computer they will be mounted (if that's what you configured in your /etc/fstab) in exactly the same way as if they were connected when you started your computer.

...

On Thu, Apr 26, 2012 at 1:27 AM, Patrick Lauer <patrick@gentoo.org> wrote:

...

About modules and bloat - for systemd you're going from a few hundred lines of shell to a few hundred thousand lines of mandatory dependencies. I have no idea where you get these numbers from, or why they should matter. These numbers come from comparing the code that is involved in system startup. If you get really fancy you use something like "sloccount", or if you're lazy like me you just use wc -l.

I know how to measure the number of lines of code, and I do acknowledge that if you can do the same job with less code that's nice. My question was: what are you counting as "mandatory dependencies" for systemd. I know of libdbus (the daemon is not mandatory) and, contrary to what it says on the openrc website, glib2 is not a mandatory dependency. What do I do when things don't work? Use the awesome debugging tools that systemd provides. Makes my life a hell of a lot easier compared to when debugging initscripts. On Mon, May 7, 2012 at 3:54 PM, Patrick Lauer <patrick@gentoo.org> wrote:

Already udev lost features and got wrongly renamed, and we haven't even had a proper release yet.

Udev got slimmed down a bit, but this was the right thing to do even without systemd. One tool for one job, right? It no longer creates device nodes, instead it says that that is the job of the kernel (mostly) or (for the few exceptions the kernel can't deal with) some separate user-space tool that is called during boot. systemd ships one such tool, which you could easily copy, or you could make your own. It would be about three lines of bash ;-)

...

What's wrong with WantedBy? You don't like the term, or do you have a technical problem with it? It's very difficult to handle properly - you have to check all init scripts / unit files / znargfruzzles every time to see if their dependencies changes, and if they have any WantedBys.

I'm struggling to follow your line of thought... "every time" what? WantedBy are simply used when you enable a service. Typically you'll either have WantedBy=multi-user.target or WantedBy=graphical.target, to tell systemd which "runlevel" the service should start in, I don't see why this, of all things, would cause such huge problems.

And you should ask people that had to debug threaded INTERCAL why it's not as awesome as it sounds at first glance ...

I didn't know what INTERCAL was: "INTERCAL is an esoteric programming language that was created as a parody by [...] two Princeton University students, in 1972. It satirizes aspects of the various programming languages at the time, as well as the proliferation of proposed language constructs and notations in the 1960s." Doesn't seem very relevant to the current discussion...

"Not possible" is not a valid response to my problem-removal-needs. SystemD is too big and too undocumented for me to trust my skills, I wouldn't want to have to rely on a system that I mutilated like that just to fix a rare corner case that "shouldn't be there" (yeah, great, thanks, it *is* there. Do you want to make it go away?)

I think some of the point of systemd is that once you find a weird corner-case that does not work you can bring it to the attention of the dozens of talented hackers from all distros/formfactor/architectures/... and someone will be able to fix it (hopefully without any unwanted side-effects).

You have no idea how much it bothers me to have to repeat myself, again, for the last time I hope ... but ... What do people actually *mean* by event driven?

If you had given people a chance to reply to your first email, you would not have needed to ask twice ;-) On Mon, May 7, 2012 at 4:25 PM, Patrick Lauer <patrick@gentoo.org> wrote (in reply to Nicolas Sebrecht):

So all in all you just managed to upset some greybeards and turned a technical discussion into random ad hominems. Nice :)

No he didn't. He was quite right in pointing out that distribution maintainers are not necessarily great developers, which probably has lead to lots of bad shell scripts over the years spread around in different distributions. You are the only one attacking people (in particular one of the systemd maintainers, who is not even involved in this discussion). It is really making the OpenRC community look bad. On a somewhat related note, I was reminded to check your website again to see if you corrected your table of features. I thought I might let you know of the errors I found (making these kind of blunders makes it look like you don't really know the competition): * systemd is portable to non-x86 (as far as I know, it is tested on a wide range of architectures and aims to work on anything that works with the Linux kernel) * systemd definitely separates code and config, as far as the admin/user is concerned s/he only has to deal with /etc/systemd/ which contain declarative .desktop-style configuration files. No code. * systemd is very extensible, you can easily add in your own .service files to do whatever you want (I imagine you could even use systemd as your init and only run openrc as your only service file and it should just work). * friendly upstream: no comment. * complex init scripts: don't know what you mean, but you can use whatever initsrcipts you want in systemd * i'd be interested in reading more about how you automatically calculate dependencies to a greater extent than systemd. do you have a link, or could you elaborate? * systemd integrates into virtualization (more so in the next release) * the architecture is definitely modular, just look at the sourctree, most of those subfolders correspond to separate tools that can be disabled or exchanged for something else. * lots and lots and lots of verbose debugging available if you chose to enable it. Both from systemd itself and from whatever your daemons spits out to stderr. Cheers, Tom

On Mon, May 7, 2012 at 6:54 PM, Kevin Chadwick <ma1l1ists@yahoo.co.uk> wrote:

On Mon, 7 May 2012 17:39:35 +0200 Tom Gundersen wrote:

...

An event-driven init system would turn this on its head, and never wait for "all the things to be ready", rather start things on-demand and whenever their dependencies are satisfied. This leads to a much simpler system (from the admin/system daemon developers point of view), but it requires the init system to keep closer control over the state of the system, listen to events, etc.

But a much more complicated one from the admin/system user in terms of troubleshooting. Also in terms of auditing. Rather than seeing what ports are listening by default, we have to investigate (hopefully in one location) to know what will be listened to upon any future possible event. I hope efforts made to make that very clear.

Daemons that are ported to work with the new systemd socket activation (see dbus and udev for examples, there are also plenty others) will allow this very easily. The way it works is that the sockets will be listened to at all times, even before the daemons are running. So starting a daemon would not, if it uses pure socket activation, open any new sockets. Once your daemon does eventually start, the socket will be passed to it so it can handle any connections that came in while it was not yet ready to accept them.

Thanks for the explanation, are there some examples of what this means we can do that couldn't be done in any way outside of init before.

I guess anything is always possible (bash is Turing complete, right ;-) ). That said, we'll get lots of simplifications and can drop old workarounds: We can remove arbitrary timeouts or retry-loops. Especially when it comes to usb storage we often have issues with booting too fast, so that the device is not yet ready when we try to mount it. That would no longer be a problem. Currently, we support a relatively limited number of storage configurations (combinations of lvm/md/dm/encryption). With systemd we now deal with encrypted devices in a nice way, but there is still some way to go before the whole storage stack is event-driven. Once this is the case there will no longer be any restrictions on how you combine storage devices, on top of that the code to do this will be much simpler than the current code. Also, by the fact that things are more finegrained we can deal with some dependencies which were not possible (without a refactor) before. One example could be that we want to first mount /var, then read our random-seed from /var so we can use it as a random encryption key for /tmp. If we mount /tmp and /var at the same time that's not going to work :-) Obviously we can sort this out by refactoring our initscripts a bit, but we could think of more complicated scenarios, where you do not want to have a rigid a system as what our current initscripts are. Btw, I don't know how any of this compares to OpenRC as I have not looked at it at all (I was not impressed by the PR campaign...). -t

On 04/25/2012 10:25 AM, Tom Gundersen wrote:

While dependencies (done in the right way) might have been nice to have, I don't see this as a major shortcoming of our current system, and if we are to change away from initscripts the replacement would have to provide significantly better benefits than that, in my humble opinion.

KISS - If it "ain't" broke, don't fix it.... I'm sure some may have needs that exceed what the current initscripts can provide, the simple efficient Arch way has done, and continues to do, quite well. -- David C. Rankin, J.D.,P.E.

On 04/27/12 00:01, Kwpolska wrote:

When I first saw the topic, I thought "yet another systemd-like piece of crap?" Then I read that this is from Gentoo and the rest of the original post and I think it could be nice and I could even switch to it one day. But do you actually need to bother with runlevels or is it like arch (everything in $DAEMONS goes to 3 and 5, and 5 can be set for X through inittab)?

Well, you get named runlevels which you can call from inittab: l0:0:wait:/sbin/rc shutdown l0s:0:wait:/sbin/halt -dhp l1:1:wait:/sbin/rc single l2:2:wait:/sbin/rc nonetwork l3:3:wait:/sbin/rc default etc. etc. So if you want to split things like that, yes that's possible. The advantage is that the runlevels are named, so you have "default", and you could have "desktop" if you wanted. And if you are really crazy you could write an acpid rule that switches to "powersave" runlevel if AC power is removed, etc. etc. The sky is the limit :) Take care, Patrick

On 04/26/12 01:57, Leonid Isaev wrote:

On Wed, 25 Apr 2012 22:03:19 +0800 Patrick Lauer <patrick@gentoo.org> wrote:

...

Greetings,

in the last months there have been many discussions about init systems, especially systemd. The current state seems to make no one really happy - the current Arch Linux init system is a bit minimal and gets the job done, but it's not superawesome. There's things like init script dependencies that would be nice to have, but then it's about the smallest of all init systems around.

[...]

Patrick Lauer

Gentoo Developer, OpenRC co-maintainer

Thanks for your explanation. However, I sense a confusion regarding an init system and a boot process. AFAIU openrc still uses /sbin/init Yes and no, we only use sysvinit to trigger the "we are booting" and "we are changing runlevel" events. To quote /etc/inittab:

l1:1:wait:/sbin/rc single l2:2:wait:/sbin/rc nonetwork l3:3:wait:/sbin/rc default

-- the daemons/services are handled through a set of (ba)sh scripts. most of the logic is posix sh, the dependency resolution and some other bits are C.

From what I learn from systemd documentation, all services are handled by one daemon -- dependencies, tracking, etc. are a natural bonus, so to say. ... why should that be a daemon? (And what happens in the unlikely event that the supercomplexified PID #1 self-terminates? I think there's a very good set of reasons why sysvinit's "init" is very small and simple ...)

Although I also dislike the idea of systemd-{journald,logind,...}, as long as those things are implemented via modules, I don't think they are "bloat". So IMO the only negative thing in arch's adoption of systemd is that rc.conf will have to go away :) Yes. It's redundant ;) In the end our runlevels are just symlinks to the init scripts in /etc/init.d and managed with the rc-update / rc-config / rc-status tools. "rc-update add squid default; rc" is such a boring way to add a service to the default runlevel and start it ... and once you get hooked on rc-status you'll be wondering why you didn't have it before.

About modules and bloat - for systemd you're going from a few hundred lines of shell to a few hundred thousand lines of mandatory dependencies. There's so many exciting ways you could accidentally trigger a bug in that, it goes against my philosophy that computers should be boring and doesn't let me be lazy. It does have a few decent ideas (like CGroups - which ended up taking me an afternoon to get initially patched into OpenRC) but at the cost of a rather hostile upstream that likes writing code more than anything and goes in a direction that makes some of us very much not happy, especially as it now corrupts other unrelated projects like udev (oh, systemd-udevd) and syslog-ng (haha, you get journald now!) and so on. Oh well. Take care, Patrick

On 04/26/12 17:08, Tom Gundersen wrote:

On Thu, Apr 26, 2012 at 1:27 AM, Patrick Lauer <patrick@gentoo.org> wrote:

...

About modules and bloat - for systemd you're going from a few hundred lines of shell to a few hundred thousand lines of mandatory dependencies. I have no idea where you get these numbers from, or why they should matter. These numbers come from comparing the code that is involved in system startup. If you get really fancy you use something like "sloccount", or if you're lazy like me you just use wc -l.

It matters because more complexity means more bugs and things are harder to debug, and that's something where I just can't justify spending more time on things when they could be kept boringly simple. If you don't understand that I wonder what you do when something doesn't work (and please don't answer reinstall)

...

but at the cost of a rather hostile upstream I do not have this impression at all. systemd devs certainly have been very open to all the suggestions I have made to make it work better on Arch.

If you agree with them they are kinda ok. My ideas tend to conflict with their vision, so I usually see that others who verbalized the same idea get shot down on the mailinglists with comments that make me wonder if I'm really confused or reality just got very bizzare.

...

that likes writing code more than anything and goes in a direction that makes some of us very much not happy, especially as it now corrupts other unrelated projects like udev (oh, systemd-udevd) and syslog-ng (haha, you get journald now!) and so on This does not make sense. udev still works the same on systemd-less systems and syslog-ng works just fine with (or without) systemd.

Wanna bet? ;) Already udev lost features and got wrongly renamed, and we haven't even had a proper release yet. At this rate we will have to switch to alternatives before the three next systemd releases are done.

I am very happy that you are trying to educate us about OpenRC, but if you are going to attack systemd please get your facts straight and refrain from spreading unsubstantiated FUD.

Lenny started the FUD. I'm slightly annoyed with that, but I'm relying on facts (see code size, easy to verify) and don't just call other people stupid, ignorant or call their product obsolete crap. Although I could do that, but how does that help me to keep things boring and predictable for me? Take care and stop being such a grumpy teddybear, Patrick

On Fri, Apr 27, 2012 at 10:53 AM, Kevin Chadwick <ma1l1ists@yahoo.co.uk> wrote:

We are going to sacrifice, simplicity, amount of code to look for bugs and most importantly, ease of troubleshooting. One of the beauties of Unix is the error information. Aren't they all going to be mixed together on systemd. Imagine if all drivers loaded at once. Ughh Would many resort to Windows style trial and error more often.

One of the features of systemd is the large amount of metadata the journal colllects. This allows filtering on the message source, for example. Right now that's just the process (and service) that generated them, but with the coming udev integration and kernel logging improvements, you will also be able to view kernel messages by device or module.

On Sat, 28 Apr 2012 18:58:01 +0100 Kevin Chadwick wrote:

but if it just hangs without a panic

I still like KISS for init but thinking about it, The chances of that are I'd guess next to none, once the drivers are loaded? I presume you will be able to get to this journal information even if you switch off and access the drive in another machine?

On Fri, Apr 27, 2012 at 12:08 PM, Jan Steffens <jan.steffens@gmail.com> wrote:

On Fri, Apr 27, 2012 at 10:53 AM, Kevin Chadwick <ma1l1ists@yahoo.co.uk> wrote:

...

We are going to sacrifice, simplicity, amount of code to look for bugs and most importantly, ease of troubleshooting. One of the beauties of Unix is the error information. Aren't they all going to be mixed together on systemd. Imagine if all drivers loaded at once. Ughh Would many resort to Windows style trial and error more often.

One of the features of systemd is the large amount of metadata the journal colllects. This allows filtering on the message source, for example. Right now that's just the process (and service) that generated them, but with the coming udev integration and kernel logging improvements, you will also be able to view kernel messages by device or module.

yes this is nice :-) by far and large, systemd is the init system as i imagined it *should* be, when i first started using linux ... i can't count the number of times i thought "/sbin/init doesn't do a damn thing, and is utterly useless" "bloat" is not measured by LOC, but rather by degrees of uselessness. i have converted several desktops -- and servers -- to use systemd *exclusively*. by this i mean i subsequently "pacman -R initscripts sysvinit". haven't looked back, and not a single issue that wasn't my own doing. after a small amount of learning you can bang out unit files with EASE ... just the other day, i wrote a fwknop.service in probably 5 minutes or less. now i get to do this ... ----------------------------------- # systemctl status fwknopd.service fwknopd.service - firewall knock operator daemon Loaded: loaded (/etc/systemd/system/fwknopd.service; enabled) Active: active (running) since Sat, 28 Apr 2012 16:06:08 -0400; 37min ago Main PID: 18452 (fwknopd) CGroup: name=systemd:/system/fwknopd.service └ 18452 /usr/sbin/fwknopd --config-file /etc/fwknop/fwknopd.conf.local --foreground Apr 28 16:06:08 some-server.xtfx.net fwknopd[18452]: Starting fwknopd Apr 28 16:06:08 some-server.xtfx.net fwknopd[18452]: Added jump rule from chain: INPUT to chain: FWKNOP_INPUT Apr 28 16:06:09 some-server.xtfx.net fwknopd[18452]: PCAP filter is: udp port 62201 Apr 28 16:06:09 some-server.xtfx.net fwknopd[18452]: Starting fwknopd main event loop. Apr 28 16:06:19 some-server.xtfx.net fwknopd[18452]: (stanza #1) SPA Packet from IP: 1.2.3.4 received with access source match Apr 28 16:06:19 some-server.xtfx.net fwknopd[18452]: Added Rule to FWKNOP_INPUT for 1.2.3.4, tcp/22 expires at 1335643609 Apr 28 16:06:49 some-server.xtfx.net fwknopd[18452]: Removed rule 1 from FWKNOP_INPUT with expire time of 1335643609. ----------------------------------- ... (root needed to see journal) see all that extra info after the status? that's the systemd journal capturing the stdout of the foreground process it monitors. the syslog-like timestamps are added by systemd. i have custom units managing daemons like this, timers syncing archlinux mirrors, units modifying /sys/ tunables (there is no `sysctl` for sysfs!), some that run/reboot XBMC on my HTPC ... ... and on servers especially, i even have units bound to ethernet devices, automatically managing the interface, and/or starting dhcp! ----------------------------------- # systemctl status net-dyn-phys@eth0.service Password: net-dyn-phys@eth0.service - dynamic inet interface [phys:eth0] Loaded: loaded (/etc/systemd/system/sys-subsystem-net-devices-eth0.device.wants/../net-dyn-phys@.service; enabled) Active: active (running) since Thu, 26 Apr 2012 23:38:40 -0400; 1 day and 17h ago Main PID: 175 (dhcpcd) CGroup: name=systemd:/system/net-dyn-phys@.service/eth0 └ 175 /usr/sbin/dhcpcd --config /etc/dhcpcd.conf.local eth0 Apr 26 23:38:45 some-server.xtfx.net dhcpcd[175]: eth0: leased 5.6.7.8 for 86400 seconds Apr 27 11:37:57 some-server.xtfx.net dhcpcd[175]: eth0: renewing lease of 5.6.7.8 Apr 27 11:37:57 some-server.xtfx.net dhcpcd[175]: eth0: acknowledged 5.6.7.8 from 74.207.239.122 Apr 27 11:37:57 some-server.xtfx.net dhcpcd[175]: eth0: leased 5.6.7.8 for 86400 seconds ----------------------------------- ... and i plan to make this even more automatic/intelligent in the future. i also use a handful of other units developed by Exherbo (git-daemon) that required no changes whatsoever to work for Archlinux. how's that for cross-platform? in summary: systemd is fanta-bulous ... and IMO, anything less is just as useless as that which preceded it. i have no reservations for-or-against OpenRC, but systemd is the new precedent for how-to-build-an-init-system-for-modern-systems. -- C Anthony

On Sat, Apr 28, 2012 at 7:16 PM, Kevin Chadwick <ma1l1ists@yahoo.co.uk> wrote:

On Sat, 28 Apr 2012 16:05:54 -0500 C Anthony Risinger wrote:

...

"bloat" is not measured by LOC, but rather by degrees of uselessness.

I disagree here. If many don't use/need those features aside from an init system initialising things then it is bloat and will have bugs that will even affect simple firewall systems. Of course I'd use OpenBSD for a firewall but I know some build a highly stripped down Linux (kernel).

perhaps it is a matter of taste, but i don't think the init system's purpose is to simply "initialize" things. it is a state manager, esp. considering it has abilities no other process has. i wish i could find the link now, but i read an excerpt regarding the original design philosophy of the init program ... and while it wasn't 100% straight forward, the original goals heavily alluded that init was a intelligent supervisor, and not nearly as dumb as we now know it. for LXC systems, i previously wrote an "init" in bash, that could parse inittab, and respond to SIGPWR and SIGINT (powerfail and crtlaltdelete in inittab), i probably 100 LOC of bash. basic functionality was implemented in far less ... what's the point? now i have to write everything in shell scripts for stuff that could perfectly well be handled by the supervisor. i write a lot of shell code, and have literally read the bash man page enough times to be able to jump to any point for reference ... shell code is anything but secure and rather fragile. it's just not meant to do as much as we make it. you are probably right about the firewall case, maybe it wouldn't be needed. but my guess is that you could actually make the firewall much more fault tolerant and intelligent by using such a powerful supervisor as systemd. for the most part though, most systems *do* require intricate and complex relationships between services, and systemd fills that need splendidly, *because* it does more that "fire and forget" [initialize] processes.

I hope there's no, well this is cool, and this bits wrong fundamentally but we and others have done so much work, lets just carry on. Windows registry springs to mind. Recent events like binary and random config file locations keep me wondering if the support companies so heavily involved in Linux have motives to make Linux harder to fix and customise. I like sed and diff, thankyou very much, I don't want to learn a thousand different config tools and formats ironically in the name of 'ease' or 'speed/compatibility' to shut many complainers up.

what binary configs? are you referencing? in systemd's case anyway, the unit files all look like simple key/value environment files, and are easily parseable by anything. my favorite in this arena is augeas, because it takes any config file and makes it reliably editable ... sed is nice and all, and i use it rather heavily for daily tasks, but it's not suitable for editing other peoples stuff in an automatic and predictable way. personally, i'd like to see a configfs of sorts so i could edit all configs from a single hierarchy (python + augeas + FUSE ... *hint hint* ... someday :-)

OpenBSD - hotplugd, sudo - nice and simple.

Linux - udev, polkit and friends - what a mess, where shall I start. Oh the beginning, right I'll read this book and then I'll know where the beginning is, of course if somethings configured this then actually there's a new beginning.

Sorry didn't mean to rant just saying what I see from over complex newness disregarding strong unix heritage like cross-distro things such as dconf and gconf bring.

Rather than some conspiracy I'd hope/expect it's simply that having many many coders bring wanted features but also unstoppable misdirected trains as there aren't enough top notch respected eyes to notice before it's too late. Elephantitis.

i think systemd offers a nice way to not only start your processes, but also maintian their relationship to the rest of the system. traditional init systems work fine ... so long as everything works correctly on first try. if you want to have any kind of faul tolerance, or even recovering from minor outages/hiccups, you suddenly need all this extra infrastructure to watch pid files, watch directories, watch watch watch ... while meanwhile, your init system is standing in the corner picking it's nose, because it "did it's job already" and all it needed to do was "start some stuff in the first 5 seconds".

...

i have custom units managing daemons like this, timers syncing archlinux mirrors, units modifying /sys/ tunables (there is no `sysctl` for sysfs!), some that run/reboot XBMC on my HTPC ...

... and on servers especially, i even have units bound to ethernet devices, automatically managing the interface, and/or starting dhcp!

Could you be explicit in what you've gained. Maybe I'm ignorrant of the details but I see perhaps this functionality being more universal and that's it?

i just want things to happen at the right moments without worry, reuse as much as possible, and not need to introduce additional requirements ... in the end i'm quite sure we have the same goals :-) i know this isn't the final way i'll do it, but i currently use this unit file on ~3 servers: ----------------------------------- # Bindings to physical interfaces [Unit] Description=dynamic inet interface [phys:%I] Wants=network.target Before=network.target BindTo=sys-subsystem-net-devices-%i.device After=sys-subsystem-net-devices-%i.device After=systemd-user-sessions.service rc-local.service [Service] Type=simple TimeoutSec=0 Restart=always RestartSec=10 EnvironmentFile=/etc/conf.d/dhcpcd PIDFile=/run/dhcpcd-%I.pid ExecStart=-/usr/sbin/dhcpcd $DHCPCD_ARGS %I ExecStop=-/usr/sbin/dhcpcd --exit %I [Install] Alias=sys-subsystem-net-devices-eth0.device.wants/net-dyn-phys@eth0.service ----------------------------------- ... with just what you see above, and no modifications between systems, i can run a dhcp service on any interface, whether it exists or not, by only making a single symlink for each interface needed. when a particular interface comes into being, dhcp will be started. when the interface disappears, dhcp will be killed and the unit "shutdown". if dhcp dies but the interface still exists, it will be restarted. this unit activates the network.target, but guarantees that all units depending on the network will wait until it's finished before being started themselves. ... doing to same with an init script requires a much more work, a lot more boilerplate code, and probably another process or two+. -- C Anthony

On Sat, Apr 28, 2012 at 11:51 PM, Patrick Lauer <patrick@gentoo.org> wrote:

On 04/29/12 11:10, C Anthony Risinger wrote:

...

perhaps it is a matter of taste, but i don't think the init system's purpose is to simply "initialize" things.  it is a state manager, esp. considering it has abilities no other process has.  i wish i could find the link now, but i read an excerpt regarding the original design philosophy of the init program ... and while it wasn't 100% straight forward, the original goals heavily alluded that init was a intelligent supervisor, and not nearly as dumb as we now know it.

well, the sysvinit /sbin/init is very good at being PID 1 ... the state manager gets started and/or kept alive by it - and there's so little code involved that there are no surprises. The sysvinit code is so "boring" that there are still typos in the comments because not enough people even look at it to notice ...

yeah ... i'm a C novice, and i'm pretty sure i can write a stable init ... that's kinda the point. init is so incredibly dumb that it requires no code. is that really what "unix philosophy" is meant to convey? so little code and functionality? #include <stdio.h> int main() { printf( "Hello Unix!\n" ); return 0; } ... done! and rock-solid stable! :-)

...

for LXC systems, i previously wrote an "init" in bash, that could parse inittab, and respond to SIGPWR and SIGINT (powerfail and crtlaltdelete in inittab), i probably 100 LOC of bash.  basic functionality was implemented in far less ... what's the point?  now i have to write everything in shell scripts for stuff that could perfectly well be handled by the supervisor.

acpid for SIGPWR, ca:12345:ctrlaltdel:/sbin/shutdown -r now for SIGINT, oh wait, my defaults already do that

And I didn't have to write any code for that ...

traditional init will lock up the container because it thinks it must reboot/shutdown the system. there is absolutely no way to make it kill itself, and end the container "normally". it has to be kill -9'ed from the outside. ... systemd on the other had, realizes it's running in a container, and simply exit()'s.

...

i write a lot of shell code, and have literally read the bash man page enough times to be able to jump to any point for reference ... shell code is anything but secure and rather fragile.  it's just not meant to do as much as we make it.  you are probably right about the firewall case, maybe it wouldn't be needed.  but my guess is that you could actually make the firewall much more fault tolerant and intelligent by using such a powerful supervisor as systemd.  for the most part though, most systems *do* require intricate and complex relationships between services, and systemd fills that need splendidly, *because* it does more that "fire and forget" [initialize] processes.

Worse than OpenRC, especially as it has insane nuggets like "WantedBy" (hello threaded Intercal!)

In my opinion,  if I have to start hacking random C to add or adapt features (which happens as soon as the builtins do the wrong things - that's about twice a year for me) it'll be a lot more crashy than a simple shell script where I add one line of code.

well, i've used systemd for quite some time, and have never needed to hack any C. you can always ruin shellscripts from unit files if you like, no one is preventing that. the introspective and investigation tools in systemd are excellent and unmatched by any other "alternative" i've encountered ... have you actually tried it yet? if i want to know what my systems is doing as a whole, who better to ask that the ONE process capable of telling me? pid 1 can do stuff no other can ... why squander such powers?

[snip]

...

Rather than some conspiracy I'd hope/expect it's simply that having many many coders bring wanted features but also unstoppable misdirected trains as there aren't enough top notch respected eyes to notice before it's too late. Elephantitis. i think systemd offers a nice way to not only start your processes, but also maintian their relationship to the rest of the system.

So the only weak argument in favour of systemd is dependency handling, which has been around for a decade. Oh, and if you have stateful init scripts (yeah, radical, I know) you can just check if all services you wanted to start are started and still alive. (running "rc-status" and "rc" with openrc does exactly that)

No need for systemd at all :)

and doing that from a remote tool? right ... run command XYZ over ssh, parse for ABC, etc etc. what about timed stuff? what about events/services that are not daemons? i'm a developer; i want real interfaces to use, with precise endpoints and clear methods. dbus does this nicely. in time, i can query more and more over dbus. when i have a hundred systems, i very much do not want to babysit them. systemd and the associated thought path really is a great step forward. yes shell is nice. i write uber-tons of shell. but the unit files are clean, simple, consistent, and powerful. read some of the man pages ... tell me how to do all that with shell and/or OpenRC alone, because people *want* this! else systemd would not exist, nor have so much impetus.

...

traditional init systems work fine ... so long as everything works correctly on first try.  if you want to have any kind of faul tolerance, or even recovering from minor outages/hiccups, you suddenly need all this extra infrastructure to watch pid files, watch directories, watch watch watch ...

that's why I offered OpenRC as an alternative - it does all those things while still being boring and manageable.

manageable? any init system that claims to only be /sbin/init is deluding itself. "init" is all the rc scripts, the init app itself, all the daemon rc scripts ... *everything*. systemd will spew out a graphviz chart if i want. or let me start units one by one during boot in an interactive way ... what can OpenRC do above-and-beyond, for ME, the interrogator?

...

 while meanwhile, your init system is standing in the corner picking it's nose, because it "did it's job already" and all it needed to do was "start some stuff in the first 5 seconds".

So fix your init system :)

luckily someone did it for me!

...

... with just what you see above, and no modifications between systems, i can run a dhcp service on any interface, whether it exists or not, by only making a single symlink for each interface needed. when a particular interface comes into being, dhcp will be started. when the interface disappears, dhcp will be killed and the unit "shutdown".  if dhcp dies but the interface still exists, it will be restarted.  this unit activates the network.target, but guarantees that all units depending on the network will wait until it's finished before being started themselves.

ln -s /etc/init.d/net.lo /etc/init.d/net.eth3; /etc/init.d/net.eth3 start <-- there's eth3 running with dhcp

And for the dynamic case where you don't know the device name ahead of time I'd suggest using NetworkManager - it's built to handle all that jazz. Oh, and if you have a sane init system it'll know in what state NM is and thus be able to delay starting services that rely on a network connection.

heyo! networkmanager on a server is going to be an even tougher sell than systemd. in virtualized environments, hardware can be much more dynamic than physical servers would experience ... but this was only an example, and far more interesting examples exist on the inter-tubes.

Or, if you are really kinky, write udev rules to do such things. It's less code than the unit file ... and udev *is* the event handler for such things.

udev is meant to manage symlinks to stuff in dev, and trigger short-lived apps to do similar book-keeping, not manage or kickoff services. in systemd's case, a single udev rule is used to tag devices which are then exported and usable by unit files.

...

... doing to same with an init script requires a much more work, a lot more boilerplate code, and probably another process or two+.

You could do it like that, yes ... but isn't that a bit overengineered?

how so? what if dhcpcd has a bug, and spontaneously blows up? systemd will catch the output, the exit code, and other infos, then restart it for me. when something does exactly what i need, in 10 lines of key/val declarations, that's more like precise engineering in my book. -- C Anthony

On Mon, 30 Apr 2012 09:51:42 +0100 Kevin Chadwick <ma1l1ists@yahoo.co.uk> wrote:

Heck, I save my documents as .txt for secondary backup purposes. I wish I knew that when I was a teenager doing work for school at 3AM and Word lost everything spectacularly well.

Heh...similar lesson when I was workin on OS2 with Lotus Word Pro (or how it was called)...saved one day, was not able to open it next day and since then I said: "No more binaries documents!" and that's have we did embrace LaTeX/LyX etc. Sincerely, Gour -- The intricacies of action are very hard to understand. Therefore one should know properly what action is, what forbidden action is, and what inaction is. http://atmarama.net | Hlapicina (Croatia) | GPG: 52B5C810

2012/4/30 Kevin Chadwick <ma1l1ists@yahoo.co.uk>:

On Mon, 30 Apr 2012 11:30:23 +0200 Gour wrote:

...

we did embrace LaTeX/LyX etc.

To get the benefit of your experience. Do you use Lyx as your editor or something else.

Sorry if I "jump in", but as a LaTeX user I usually suggest to stay away from Lyx. Basically it's an editor that attempt to make LaTeX work like Words, which IMHO it's not the best approach. I suggest to use an editor that doesn't try to hide how LaTeX works, and one of my favourite is TexMaker. Just my opinion. Regards, Lorenzo -- "Imagine an idea that occupies your mind the way an army occupies a city."

On Mon, 30 Apr 2012 13:43:19 +0200 Ralf Mardorf <ralf.mardorf@alice-dsl.net> wrote:

Keep in mind that blind people can't read nice formated documents on braille, they anyway need to read the source code ;).

Whatever...I found that when working on non-technical texts, LaTeX markup takes away focus from writing...and therfore LyX was perfect tool to work on the content and then just do fine tuning using LaTeX. That's why we now consider to use AsciiDoc and produce output using dblatex or LaTeX back-end. Sincerely, Gour -- Bewildered by the modes of material nature, the ignorant fully engage themselves in material activities and become attached. But the wise should not unsettle them, although these duties are inferior due to the performers' lack of knowledge. http://atmarama.net | Hlapicina (Croatia) | GPG: 52B5C810

On 04/30/12 at 09:16pm, Rashif Ray Rahman wrote:

On 30 April 2012 17:35, Lorenzo Bandieri <lorenzo.bandieri@gmail.com> wrote:

...

2012/4/30 Kevin Chadwick <ma1l1ists@yahoo.co.uk>:

...

On Mon, 30 Apr 2012 11:30:23 +0200 Gour wrote:

...

we did embrace LaTeX/LyX etc.

To get the benefit of your experience. Do you use Lyx as your editor or something else.

Sorry if I "jump in", but as a LaTeX user I usually suggest to stay away from Lyx. Basically it's an editor that attempt to make LaTeX work like Words, which IMHO it's not the best approach. I suggest to use an editor that doesn't try to hide how LaTeX works, and one of my favourite is TexMaker.

There is nothing wrong in using LyX. I don't know why you have that perception. It helps when your writing is qualitative rather than quantitative (in which case LaTeX and a more involved process can be adopted).

LyX is the only qt (or gtk) program I use in a regular basis, and the main reason why I type xinit at all -- another reason being that elinks sometimes does not make sense of webpages. Manolo

On Mon, 30 Apr 2012 11:55:48 +0100 Kevin Chadwick <ma1l1ists@yahoo.co.uk> wrote:

To get the benefit of your experience. Do you use Lyx as your editor or something else.

As LaTeX 'front-end'. your servant, Gour-Gadadhara Dasa -- One who is able to withdraw his senses from sense objects, as the tortoise draws its limbs within the shell, is firmly fixed in perfect consciousness. http://atmarama.net | Hlapicina (Croatia) | GPG: 52B5C810

On Mon, 30 Apr 2012 19:59:02 +0530 Jayesh Badwaik wrote:

You are very correct, master documents should always be plain text. The generated documents can be binary however. Also, there should be a fallback system where the plain text documents are used rather than binary documents so that the faults in generator do not affect the bootability of the system.

What's the point. To me that's just adding an extra redundant layer that could have bugs. I see no point using binaries for configuration whatosever. RAM is crazy fast and some SSDs are now as fast as a PIIIs ram. How many nanoseconds does it take to parse config files??? Heck it would be fast on our spectrum ZX. The other argument is cross program similar formatting. To me that just adds difficulty and a usage barrier to possibly very different programs. Qmail, dovecot and sudoers are all very different, it causes no problem. Binaries and xml in odd multiple locations expecting users to use a conf tool with rediculously long and custom non self explanatory terminal lines does!!!!! I installed mint for a friend. It came with gconf. I had to google and install dconf to configure lockscreen, WTF!. Configuring gnome as an admin takes ages because it's custom. A textfile with examples would take seconds!! I'm sure these things wouldn't have happened years ago!!

On Mon, Apr 30, 2012 at 5:12 PM, Kevin Chadwick <ma1l1ists@yahoo.co.uk> wrote:

What's the point. To me that's just adding an extra redundant layer that could have bugs. I see no point using binaries for configuration whatosever. RAM is crazy fast and some SSDs are now as fast as a PIIIs ram. How many nanoseconds does it take to parse config files???

Heck it would be fast on our spectrum ZX.

The other argument is cross program similar formatting. To me that just adds difficulty and a usage barrier to possibly very different programs.

Qmail, dovecot and sudoers are all very different, it causes no problem. Binaries and xml in odd multiple locations expecting users to use a conf tool with rediculously long and custom non self explanatory terminal lines does!!!!!

I installed mint for a friend. It came with gconf. I had to google and install dconf to configure lockscreen, WTF!. Configuring gnome as an admin takes ages because it's custom. A textfile with examples would take seconds!!

Are you guys still discussing init systems? (I might have lost some context, if so: my appologies, and please change the Subject). None of initscripts, OpenRC, systemd or upstart use binary or XML configuration files. Gnome might, but that seems off-topic. If you wish you could always use KDE instead, which uses .desktop-like files (as does systemd for what that's worth). Cheers, Tom

On Sun, Apr 29, 2012 at 6:51 AM, Patrick Lauer <patrick@gentoo.org> wrote:

The sysvinit code is so "boring" that there are still typos in the comments because not enough people even look at it to notice ...

The lack of maintenance of sysvinit is a bit worrying, isn't it?

...

i write a lot of shell code, and have literally read the bash man page enough times to be able to jump to any point for reference ... shell code is anything but secure and rather fragile.  it's just not meant to do as much as we make it.  you are probably right about the firewall case, maybe it wouldn't be needed.  but my guess is that you could actually make the firewall much more fault tolerant and intelligent by using such a powerful supervisor as systemd.  for the most part though, most systems *do* require intricate and complex relationships between services, and systemd fills that need splendidly, *because* it does more that "fire and forget" [initialize] processes. Worse than OpenRC, especially as it has insane nuggets like "WantedBy" (hello threaded Intercal!)

What's wrong with WantedBy? You don't like the term, or do you have a technical problem with it?

In my opinion,  if I have to start hacking random C to add or adapt features (which happens as soon as the builtins do the wrong things - that's about twice a year for me) it'll be a lot more crashy than a simple shell script where I add one line of code.

By "builtins" do you mean PID1? If so, this is not something an admin should be hacking on (just like an admin would not hack on sysvinit's /sbin/init). Have you actually looked at the code?

So the only weak argument in favour of systemd is dependency handling, which has been around for a decade. Oh, and if you have stateful init scripts (yeah, radical, I know) you can just check if all services you wanted to start are started and still alive. (running "rc-status" and "rc" with openrc does exactly that)

As has been mentioned by several people in this thread, and also on the other lists where you sent your proposal: the main reason people are interested in systemd is due to its event-driven design (similar to upstart, but unlike sysvinit and, as far as I can tell, OpenRC). -t

On Mon, 2012-05-07 at 22:13 +0800, Patrick Lauer wrote:

On 04/29/12 23:22, Tom Gundersen wrote:

...

On Sun, Apr 29, 2012 at 6:51 AM, Patrick Lauer <patrick@gentoo.org> wrote:

...

The sysvinit code is so "boring" that there are still typos in the comments because not enough people even look at it to notice ... The lack of maintenance of sysvinit is a bit worrying, isn't it? Au contraire ... it's so boring-stable that no one *needs* to even look at it. That's how I like my software best, so boring that most people don't even notice it exists :)

With typos where they belong to, to the comments instead of the code :). Speaking for software in general, not especially for the one this thread is about. Software never should be dropped, because it's not maintained, when there's no need to maintain it.

On Mon, 30 Apr 2012 09:22:42 +0200 Nicolas Sebrecht wrote:

...

In my opinion, if I have to start hacking random C to add or adapt features (which happens as soon as the builtins do the wrong things - that's about twice a year for me) it'll be a lot more crashy than a simple shell script where I add one line of code.

Having most of the distribution maintainers playing in with boot critical shell scripts is worse. I've been faced with so many poorly written shell scripts over distributions for decades that I can't believe in your "C is more crashy" statement.

If it makes it easier to find and stop things like avahi then that's one bonus. That's one of the reasons I chose Arch. I wouldn't put it past Ubuntu to build avahi spawning into systemd itself so it can't be stopped, mu wha ha ha.

The 07/05/12, Patrick Lauer wrote:

So anyway. If you complain about bad shell, fix it, or throw some examples at me so I can rewrite them cleanly.

"Patch it yourself" is exactly the opposite of what I would expect. This is not peace of mind to add patches to already too much stressed code in pieces of core tools. I'm not talking about you especially and vanilla OpenRC scripts but those written and tuned by maintainers.

Don't think rewriting in Modula-3 will make it any better, the same people you condemned for not writing good shell won't write good INTERCAL either. Educate them, fix any bug you find, enjoy.

Traking down what maintainers do with stderr and how error code is handled in init shell scripts is most of the time a good example of how educated people can write poor shell code. As you're asking for it, here is a random example of shell code in sysfs (a very core script) taken from official repository(1): if [ ! -d /sys ]; then if ! mkdir -m 0755 /sys; then ewarn "Could not create /sys!" return 1 fi fi This code is exposed to race conditions as the directory creation could happen in a slice between the first condition check and the next mkdir call. Of course, in this particular case we can sanely expect the creation of /sys beeing not concurrency at all, but this way of "checking for conditions and then handle the missing condition after the facts" is almost everywhere in the code. This is RACY and plain WRONG. You should turn them all in things like: mkdir /sys 2> /dev/null 2>&1 cd /sys || { ewarn "<the error message>" return 1 } If this kind of problem was only for creating directories, I wouldn't even mention it. But in real life these shell code scripts make debugging and maintaining init a nightmare. Writing good shell code is MUCH harder than it looks at a first glance, including for educated people. (1) http://git.overlays.gentoo.org/gitweb/?p=proj/openrc.git;a=blob_plain;f=init... -- Nicolas Sebrecht

On Wed, 9 May 2012 12:30:34 +0200 Nicolas Sebrecht wrote:

...

You should turn them all in things like:

mkdir /sys 2> /dev/null 2>&1 cd /sys || { ewarn "<the error message>" return 1 } That's just a little less racy and certainly not atomic, /usr/bin/install would be atomic. As you have said your race point doesn't actually matter. You call it plain wrong and admit there is nothing wrong at the same time? Well, the problem here is -

On 05/09/12 19:35, Kevin Chadwick wrote: that script will be the only one running, and the only one manipulating sysfs, and it's fail-safe - if anyone else creates the directory we still end up in a state where it exists (modulo permissions) So yes, it's technically racy and could fail, but all failure modes are benign (directory already there, directory really already there) or really confusing (we can't create a dir - is / mounted readonly? Why are we being run then?!), so either it's good or something really bad you can't catch anyway.

There's another point, shell is easily editable and understandable and that's a good thing and not a bad one and also one of arches values I believe, hence pacman uses so much shell!

And it's on-the-fly editable. If you just need to disable that check for a minute because ... err ... long story, but you have to do it ... trivial. And sh -x gives you an instant "debugger" that makes finding silly mistakes a lot easier.

On occasions I have had to resort to editing shell init scripts because I don't agree with the distro or devs. People shouldn't be forced to Gentoo and damaging the environment.

Wat :) I presume you got distracted and meant to write something else, otherwise I have to claim that you are a donkey ;) Thanks for the most surreal quote of the day (so far) Take care, Patrick

The 09/05/12, Kevin Chadwick wrote:

On Wed, 9 May 2012 12:30:34 +0200 Nicolas Sebrecht wrote:

...

You should turn them all in things like:

mkdir /sys 2> /dev/null 2>&1 cd /sys || { ewarn "<the error message>" return 1 }

That's just a little less racy and certainly not atomic, /usr/bin/install would be atomic. As you have said your race point doesn't actually matter. You call it plain wrong and admit there is nothing wrong at the same time?

The way used to handle conditions is wrong. And I admit that for /this/ particular case, this is not much relevant.

There's another point, shell is easily editable and understandable and that's a good thing and not a bad one and also one of arches values I believe, hence pacman uses so much shell!

I don't find pacman much editable, sorry. I've given examples of nice features not easy to implement, here in the past. ,-p -- Nicolas Sebrecht

On Fri, Apr 27, 2012 at 10:53 AM, Kevin Chadwick <ma1l1ists@yahoo.co.uk> wrote:

Imagine if all drivers loaded at once.

Just a piece of information: the way kernel modules are loaded is not changed, currently they are (for most intents and purposes) loaded at once. -t

On 04/26/12 16:49, Nicolas Sebrecht wrote:

Hi,

The 25/04/12, Patrick Lauer wrote:

...

As an alternative to the One Process For Everything I'd like to ask you to evalute OpenRC as an init system for Arch Linux. <...>

...

While Gentoo is by far the largest user it's definitely not the only one - there are the direct derivatives (Sabayon, pentoo, funtoo, sysrescuecd, tinhat, ...) and some "foreign" users (Alpine, a debian derivative, uses OpenRC) Alpine is highly dedicated to small systems with few physical resources which makes the reference not much relevant. Well, it's just one example of a non-gentoo-derived user. Shows that it's highly portable and not twisted towards one specific confiuguration.

...

Should you decide to switch (or just evaluate if switching is possible / makes sense) you'll get full support from us in migrating init scripts and figuring out all the nontrivial changes. Just visit us on IRC ( #openrc on irc.freenode.net), send us a mail ( openrc@gentoo.org ) or meet us for a beer or two.

Thanks for your consideration,

Patrick Lauer

Gentoo Developer, OpenRC co-maintainer I wouldn't expect anything else from a OpenRC maintainer to support his tool to be used on other platforms. :-)

But to be fair, you should say that the future of OpenRC is NOT certain in Gentoo at least, and as a consequence in all of the forked projects. Nyet. Future very certain. Most of us will stick with OpenRC, and do whatever is needed to keep it working.

Please all, take a look at: - http://marc.info/?l=gentoo-dev&m=130929913506375&w=4 - https://bugs.gentoo.org/show_bug.cgi?id=373219 - http://marc.info/?l=gentoo-dev&m=132538362810246&w=4

Gentoo might make systemd the default init system in the future.

Nobody can say if and when this could heppen but this is clearly possible for OpenRC to become a Gentoo init system _alternative_. Maybe there will be a Gentoo fork with systemd as default. Maybe systemd will be better supported than it is now. But we've invested too much energy into a surprise-free solution that "Just Works" and isn't 100k LoC with almost no comments to just switch to something that is a lot harder to manage and doesn't even have all the same features. (Sidenote: if anyone ever claims the kernel is bad code - let them read systemd or upstart. It gives a good perspective. Kernel is about the best code you can find for bedside reading) (And another sidenote: we have almost no control over systemd upstream, so ... no thanks. If they decide to integrate syslog into ... oh wait ... uhm, if they decide to integrate consolekit ... eerrrrr, if they ... uhm ... add ... an X server? I hope I didn't give anyone a silly idea now, but that'd be bad. I have some machines that boot with <64MB memory used, I would like for

Nein. That'd be a proper schism that will make the exherbo split look like happy sunshine happy happy. Now that systemd upstream has assimilated udev (which confuses nicely, but their decision in the end) there's even work to get rid of that silly udev, err, systemd-udev, err, systemd dependency. The harder some people try to force their ideas on others the faster we get replacements to route around the damage. things to stay small and efficient)

This is why I think that switching to OpenRC *now* would be wrong.

I think not switching now would be wrong, but in the end it's your loss and not mine ;) Have fun, Patrick

On Wed, 9 May 2012 10:58:01 +0200 Nicolas Sebrecht wrote:

And dbus will be part of the kernel, soon.

So, what you call "silly dependencies" *are the core* of a Linux system.

So is that sentiment, we'll force it upon you. How lovely. You have read all the security papers about dbus, right? Unless your willing to give up lots of your own or machine time compiling of course. I wouldn't run the as admitted by and somewhat out of Linus's control bloated linux kernel on servers, adding dbus would just re-affirm that even if it wasn't used. I wonder and am not suggesting whether the unix/posix world is going to divulge completely due to linux only tech. I wonder when/if a new linux kernel will gather steam. Perhaps called something like genux. Or if techs will eventually flock even more to the BSDs. They're retorical by the way.