Re: [arch-general] [Bulk] Re: RFC: OpenRC as init system for Arch
On 04/29/12 23:22, Tom Gundersen wrote: > On Sun, Apr 29, 2012 at 6:51 AM, Patrick Lauer 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 :) > >>> 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? 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. And you should ask people that had to debug threaded INTERCAL why it's not as awesome as it sounds at first glance ... > >> 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? Yes, I have read a good chunk of systemd (and upstart). My liver doesn't appreciate that much. And "should be hacking on" - yeah, that's the theory. But I usually hit that point once or twice a year where the given structure is either buggy or incomplete and I *need* to mangle such internals. "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?) > >> 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). > 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? Would be useful to define it well enough so we can evaluate how OpenRC (or the current init) doesn't do what you want, and maybe fix it until next week. Have a nice day, Patrick
Re: [arch-general] [Bulk] Re: RFC: OpenRC as init system for Arch
On Mon, Apr 30, 2012 at 5:12 PM, Kevin Chadwick 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
Re: [arch-general] [Bulk] Re: RFC: OpenRC as init system for Arch
On Mon, Apr 30, 2012 at 11:12 PM, Kevin Chadwick wrote: > 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??? > and don't forget to mention some stupid binary configuration system, like gconf, that incapable of removing erroneous entries created by a typo.
Re: [arch-general] [Bulk] Re: RFC: OpenRC as init system for Arch
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!!
Re: [arch-general] [Bulk] Re: RFC: OpenRC as init system for Arch
On Monday 30 Apr 2012 11:30:23 Gour wrote: > On Mon, 30 Apr 2012 09:51:42 +0100 > > Kevin Chadwick 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 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. -- Jayesh Badwaik stop html mail | always bottom-post www.asciiribbon.org | www.netmeister.org/news/learn2quote.html
Re: [arch-general] [Bulk] Re: RFC: OpenRC as init system for Arch
On Mon, 30 Apr 2012 09:51:42 +0100 Kevin Chadwick 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 signature.asc Description: PGP signature
Re: [arch-general] [Bulk] Re: RFC: OpenRC as init system for Arch
On Sun, 29 Apr 2012 01:12:15 -0500 C Anthony Risinger wrote: > 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? Unix philosophy is many small tools that do a single job well. These tools can do MORE than they're constituent parts when used with other tools. Init does have spawn abilities too. There's also supervise, monit. Binary files have nothing to do with systemd sorry, just one of my bones of contention from various recent conf tools. I love text in . files, they're easy to find and can even be recovered from disk by grepping sectors, almost no matter what and with ease. 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.
Re: [arch-general] [Bulk] Re: RFC: OpenRC as init system for Arch
On Sun, Apr 29, 2012 at 6:51 AM, Patrick Lauer 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
Re: [arch-general] [Bulk] Re: RFC: OpenRC as init system for Arch
On Sun, 29 Apr 2012 12:51:11 +0800 Patrick Lauer wrote: > No need for systemd at all :) As someone that has used Linux exclusively since the very early days kernel version 0.99-a i have to say +1 to no need for systemd at allit is just another un-needed uncalled for over complication of a process that works well as it is . Pete . -- Linux 7-of-9 3.3.3-1-ARCH #1 SMP PREEMPT Mon Apr 23 09:41:07 CEST 2012 x86_64 AMD Phenom(tm) 9600B Quad-Core Processor AuthenticAMD GNU/Linux
Re: [arch-general] [Bulk] Re: RFC: OpenRC as init system for Arch
On Sat, Apr 28, 2012 at 11:51 PM, Patrick Lauer 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
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
fo
Re: [arch-general] [Bulk] Re: RFC: OpenRC as init system for Arch
On 04/29/12 11:10, C Anthony Risinger wrote: > On Sat, Apr 28, 2012 at 7:16 PM, Kevin Chadwick 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. 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 ... > > 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 ... > > 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. [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 :) > 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. > 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 :) > >>> 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
Re: [arch-general] [Bulk] Re: RFC: OpenRC as init system for Arch
On Sat, Apr 28, 2012 at 7:16 PM, Kevin Chadwick 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
Re: [arch-general] [Bulk] Re: RFC: OpenRC as init system for Arch
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). 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. 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 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?
Re: [arch-general] [Bulk] Re: RFC: OpenRC as init system for Arch
On Fri, Apr 27, 2012 at 12:08 PM, Jan Steffens wrote: > On Fri, Apr 27, 2012 at 10:53 AM, Kevin Chadwick > 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
Re: [arch-general] [Bulk] Re: RFC: OpenRC as init system for Arch
On Sat, Apr 28, 2012 at 8:12 PM, Kevin Chadwick wrote: > I presume you will be able to get to this journal information even if > you switch off and access the drive in another machine? You can configure the journal to be saved to disk and process it on a different machine later on. -t
Re: [arch-general] [Bulk] Re: RFC: OpenRC as init system for Arch
On Fri, Apr 27, 2012 at 10:53 AM, Kevin Chadwick 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
Re: [arch-general] [Bulk] Re: RFC: OpenRC as init system for Arch
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?
Re: [arch-general] [Bulk] Re: RFC: OpenRC as init system for Arch
On Fri, 27 Apr 2012 19:08:34 +0200 Jan Steffens 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. Hmmm, interesting, but if it just hangs without a panic then there may be no kernel message and working out what it was doing by looking at what it had just done before it hung, would be extremely difficult, wouldn't it?
Re: [arch-general] [Bulk] Re: RFC: OpenRC as init system for Arch
On Fri, Apr 27, 2012 at 10:53 AM, Kevin Chadwick 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.
Re: [arch-general] [Bulk] Re: RFC: OpenRC as init system for Arch
On Thu, 26 Apr 2012 10:49:26 +0200 Nicolas Sebrecht wrote: > 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_. > > This is why I think that switching to OpenRC *now* would be wrong. I doubt it would get onto Hardened Gentoo. So in order to gain a slight speed increase in booting, which can be done in other ways (Alpine boots faster than any systemd enabled system). Please give me examples of any other valuable benefits. 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. p.s. I'm sure many will disagree on this seperate point but whilst I like the pretty startup and colors of arch, I have been annoyed in the past whilst being used to OpenBSD that I have to look at many files for pacman and functions.sh etc.. If there's a bug I need to fix, I prefer not to have to dig around and prefer to know it's somewhere right in front of my eyeballs without thinking about what tab in my editor I'm on, the sames true to me of overuse of inline functions. Code location sporadity and use of binary files seems annoyingly on the increase (not Arches fault). OpenBSD has several files and recently a directory as part of init. They have tried to keep this to as few as possible in case the user wants to lock it down, it has other great benefits. This simplicity surely fits with Arch.
