Like sysd, discussion about it should really be able to be (more) modular, and in theory is, but in practice isn't; hence the long-ish post ... .
> Date: Fri, 25 Apr 2014 17:49:22 -0500 > From: Bruce Dubbs <[email protected]> > To: BLFS Development List <[email protected]> > Subject: Re: [blfs-dev] blfs bootscripts (-dev) > > akhiezer wrote: > >> Date: Fri, 25 Apr 2014 17:08:10 -0500 > >> From: Bruce Dubbs <[email protected]> > >> To: BLFS Development List <[email protected]> > >> Subject: Re: [blfs-dev] blfs bootscripts (-dev) > >> > >> akhiezer wrote: > >> > >>> Btw, what was it decided you to 'get more involved' on the sysd side - > >>> e.g. demand for teaching courses on the stuff? > >> > >> No, it was a combination of things. There were comments in the lists as > >> well as irc that people wanted systemd. Were they made aware of the lfs-syd book. Were they - if asked - expressing a preference for a 'mixed' book. Armin was maint lfs-sysd already. Why not 'promote' that to the 'official' lfs-sysd branch, you/a.n.other head-up the lfs-non-sysd(aka *nix) branch, and you (e.g.) head-up the lfs-combined branch. It seems that lfs-sysd branch got 'clobbered' or had the carpet pulled out from under it. Forgive the direct question - such matters shouldn't really be left unaddressed or just whispered about: but were you wary of Armin gaining 'too much' influence if head of lfs-sysd branch? Or did Armin say that he didn't want to do such a role? > >> My judgement is that there are > >> about an equal number of people on both sides of the issue. > >> > >> Additionally, most of the mainstream distros have gone to systemd. If > >> we want to maintain one of our fundamental goals of being an > >> instructional resource, we really need to address this. > >> Is it good education to have students read two intertwined texts, and not flag up to them which stream is which. Although, yes I guess it may be argued that folks doing lfs for the first time or two, might be not too concerned about what is strictly needed or not: and that folks who've done lfs for a while will know by then (at least) which parts belong to which stream. Although it's the front-facing book that's the main educational goal, is it good education in the use of rcs to do what has been done to lfs and now mooted for blfs (i.e. layer everything on single main branch), rather than keep the two books - sysd/non-sysd(aka *nix) - as separate branches, and have a third combined branch. The single-branch approach would hardly be considered best, or even good, practice; and certainly wouldn't be taught in most reputable environments. People get 'moved-sideways "&c"' for that type of thing (all-on-single-branch), in many environments. Again: why not use the three-branch approach. I know you said that with single-branch, changes can just be reverted if wanted: but that becomes increasingly easier-said-than-done; and anyhow, a 3-branch approach would always be much simpler to do any such reverts with - *and* is much easier to see how to get clean merges onto the 'mixed-book' branch. > > > > > > Yes, I agree about addressing it: but the two streams in b/lfs should > > still be separable fairly readily; and that has been getting lessened, > > and unnecessarily; and it raises doubts about why. > > There is a lot more in common than not. Adding a few systemd > prerequisites shouldn't be a problem. About the only differences are > systemd/eudev. Additionally systemd doesn't need syslog, but those are > about the only package differences. I admit that d-bus isn't needed on > most servers, but it is for most desktops. > By the same tokens, a 3-branch approach would even more be very clear and straightforward. Besides, systemd hasn't finished yet in its rearrangements of the landscape: and that can be accommodated far better with the 3-branch approach than with single-branch. > The big differences are in Chapter 7. Scripts and configuration files > are completely different. However that shouldn't be an issue for > someone to do one or the other. Ditto for 3-branch, and further, much more: it's far easier to simply pick which book - lfs-sysd, lfs-*nix, lfs-mixed - does the user want to use. > > >> I personally don't like the amount of systemd components mutual > >> interconnections. IMO, that's not really necessary from a design > >> standpoint. However, I don't have any input into that. Well you've made an unnecessary admixture in lfs and are touting similar for blfs: and you have 100% input access into both of those. > > > As noted before and elsewhere (& increasingly), as the 'community' gets > > its hands on sysd, it'll (the former) knock it into (at _least_ better) > > shape. > > I'm interested if you have any personal hands on experience with > systemd? Other than the admittedly different configuration files and > learning curve, what's your objection? 'objection' to ... ? b/lfs-mix, or sysd per se, or both? Assuming the wider, here's a very-summary part-outline - incl of some earlier summary part-outlines - that relates to the areas your questions address: ==== * 'objection's not the right word - too much connotation of _re_action and defensiveness; too passive. * The config files are pretty much straightforward. * Learning curve has been easy perhaps because have looked at sysd on/off for a few years now. * Yes, have used sysd from-compile and in distros, at various points; and tracked dev on main mailing lists &c. * Main appraisal is that it's just not very good; poor implementations of several of the better ideas (incl of early-adopted 3rd-party ideas); plus pretty poor design decisions. That's partly why the interest in seeing what the wider community does with it in due course. (A related aside: have you been following what the openbsd folks are doing with/to openssl - incl what they're uncovering and doing (more-)properly.) * Overall, find that sysd is just not a very interesting instance of addressing of some mildly/reasonably interesting ideas (again, incl from 3rd-party). * Not too bothered about 'monolithic' per se: cf. e.g. linux kernel; but the latter can be essentially modularised quite a bit, and readily so. * I think too that sysd really just moves complexity around, re-casting it, rather than solving for it; and that notions otherwise - e.g. re startup/process dep-tree, removing the 'need' for knowing shell scripting, etc - are substantially illusory. * It's open-source but a semi- closed-system, with much potential for some vendor-lockin: in those latter two respects I kindof bracket it with say windows, mac, oracle, ibm, cisco, &c&c&c; working with sysd is in many respects just like working with those, in that there's a 'particular' way of doing things, within a variously-rigid vendor-defined framework. That's just an observation, not a value judgement: they are what they are, it's part of the landscape; and if linux-userland wants to head down that route then, well, these things happen; likewise for linux-kernel. Somethings will step into the places they've left behind. * Think it's reasonable to say that there's a lot of untrustworthiness attached to the players behind sysd. They seem to have had enough of what they see as the bazaar and they think that they're replacing it with what they see as a cathedral. As for the 'politics', machinations and manoeuvrings: in part it's 'just' types of stereotypically-negative corporatised behaviour - e.g. some of the attitudes to *nix userland have been like a hostile takeover (and they're 'noising-up' players in the linux kernel that are not their people). Their arguments change to suit whatever stage in their overall programme that they are at: but overlaying that there's the attitude that if you want to fool enough people, pick a big-enough (package of) lie(s) and repeat it often enough until enough people believe it; and when one stage is done & consolidated, move on to the next. * We here have got the happy 'luxury' of not _needing_ to use sysd, whether by choice or by force or by manoeuvrings, for any long-foreseeable period. We're quite sure to e.g. be able to build our/others' own os's - whether linux, bsd, or for more-exptl stuff, or indeed sysd-based - as we wish: and for the/any further encounters with sysd-based stuff, then pretty sure that intellectually it can be handled readily; as noted, it's kindof just like interfacing with e.g. windows servers or oracle or cisco (IOS) stuff; they've got a particular (corporatised) way of doing things, that can be dealt with. * So, overall, am interested in seeing sysd and linux's journey over the next 2-5 years :) . We here won't be impacted negatively by it - at least, at most only in very very indirect ways, and not e.g. via os/sw components that we use - irrespective of what happens. * Worth bearing in mind also that of course there's far more to life than computers and linux and systemd. Howver, computers of course permeate life more and more: and it's very useful, to say the least, to have a good control and grasp of at least your own computing environments. Sure, understand others, and how you might be interfacing with them: but at least try to at least substantially control your own; I'd say that in these respects, the sysd product and its pushers are still too far over the line, and still heading too much in the wrong direction. ==== > > Mine is lack of flexibility as to what runs. However that's more of a > theoretical issue as I've not really had a practical problem that wasn't > solved fairly easily with a little research. > The latter part seems a bit of a non-sequitir to the first half. You could say the same about windows, mac, or only being able to run a 'huge' all-compiled-in kernel, or a consumer router that you only have click-click-click gui access to, or driving a car whose bonnet/hood is sealed down, or other relatively-closed system: but what's the point that's being made? Anyway, enough time-spend for now on closed-system computing. rgds, akh > -- Bruce > > -- -- http://lists.linuxfromscratch.org/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
