On Fri, Dec 13, 2013 at 3:03 AM, akhiezer <lf...@cruziero.com> wrote: >> Date: Thu, 12 Dec 2013 23:50:45 -0800 >> From: Nathan Coulson <conat...@gmail.com> >> To: LFS Developers Mailinglist <lfs-dev@linuxfromscratch.org> >> Subject: Re: [lfs-dev] sysvinit programs >> > . > . >> >> A thought I was having about systemd vs sysvinit. If the books are >> being developed in parallel, we should probably try to use the same >> programs in each. ex:/ if we use pidof in procps-ng we should also >> use the pidof from procps in systemd. (The above is using the pidof >> from procps, but seemed like a good example to use). >> > > > - and so the (again, entirely predictable) crowbar-ing begins ... > > > Systemd folks are not interested in bidirectional influence: it's their > way or the highway (as they see it, anyhow; it's a bit risible). _When_ > (not 'if') sysd folks make yet another deliberate contrived change such > that 'the sysd way' now uses program 'y' and deprecates - and deliberately > "now cannot use" - the related and formerly-used program 'x'; while > program 'x' and not 'y' has been in use in b/lfs; then you're saying that > b/lfs should switch over to program 'y'.
Not quite that black and white in my head. Programs provided by sysvinit, that are not provided by systemd (but still available in other packages) would be good candidates in my head as an example. Who knows, Other decisions I could be against them *shrug*. I have always been a fan of using upstream as much as possible, minimizing LFS specific patches (Either our changes should go upstream [or in a upcoming release], or if possible we should change what we do and adapt a solution that could go upstream. So I want to view sysvinit LFS as upstream, and systemd as based upon it unified where it makes sense. > Are you seriously suggesting that b/lfs lets itself be led and pushed > around by the nose, by sysd folks, like that? Nice try, but you won't > fool everyone: not everyone will follow you into the darkness. I am suggesting that BLFS is primairly for sysvinit's LFS, and should stay that way unless (a) we change the default lfs book to another init system, or (b) that sysvinit LFS and systemd LFS have equal support from us [so one is no more imporant then the other]. At this time, A and B are not part of my recommendation. With that in mind, I would like to see BLFS to accommodate a systemd LFS where it makes sense (not catered towards it, but able to work when built on such a system). Personally I do not care about systemd itself. I was on the fence on it prior to using it (and switched to it so I could understand it [if I am going to like or hate it, I am going to know what it is]) It's new and shiny (I like new and shiny). I do like how bootscripts are written in it better. I love that packages are including systemd bootscripts. I was not happy that it caches core dumps [for my usecase], and I could only access them with root. And I want to control mounts, instead of having systemd automatically mount some of my partitions. All in all, it's touching more of my linux system then I want it to, and seems to be enforcing it's defaults over the kernel. All in all, I'm willing to stick with it for now on my own personal system. But I would be making the same recommendation if I decided to love or hate it. Armin has done a lot of work, and it is being used by a lot of members. I admit there has been changes I wish would have gone a different direction (sorry Armin, I do try to speak up), but I would like to see this succeed. sysvinit is staying, and I would like systemd to stay as well. -- Nathan Coulson (conathan) ------ Location: British Columbia, Canada Timezone: PST (-8) Webpage: http://www.nathancoulson.com -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
