On Mon, Feb 24, 2014 at 9:07 AM, Alan McKinnon <alan.mckin...@gmail.com> wrote: > On 24/02/2014 01:12, Mick wrote: >> On Sunday 23 Feb 2014 22:32:32 Alan McKinnon wrote: >>> On 23/02/2014 20:18, Canek Peláez Valdés wrote: >>>> I don't think forking would attract much developers. Writing something >>>> new trying to follow "the*nix design principles", but being modern and >>>> with the same features (all of them optional, of course) of systemd >>>> will have more chances; although I think it will fail because most of >>>> the people that can code "better" actually like the systemd design, >>>> and would prefer to contribute to it. >>>> >>>> And if you found enough of this mythical good-coders, good luck >>>> defining what it means "the*nix design principles". >>> >>> I've been wondering about this concept of "the*nix design principles"... >> >> Well, I'm no authority on this since I can't code, but here's a starter for >> 10: >> >> http://www.faqs.org/docs/artu/ch01s06.html >> >> http://people.fas.harvard.edu/~lib113/reference/unix/co-unix4.html > > I really like documents like this, all airy-fairy and giving the > impression that the whole design was worked out nicely in advance. It > wasn't. the doc even quotes this fellow who had nothing to do with the > doc itself: > > "Those who don't understand UNIX are doomed to reinvent it, poorly." > --Henry Spencer > > Let me tell you how Unix was designed, how the whole thing took shape > once K&R had gotten C pretty much stabilized. It is most apparent in IO > error handling in early designs and it goes like this: > > We don't do error handling. We don't even try and deal with it at the > point it occurred, we just chuck it back up the stack, essentially > giving them message "stuff it, I'm not dealing with this. You called me, > you fix it." > > Doesn't sound like good design does it? Sounds more like do whatever you > think you can get away with. Good design in this area gives you > something conceptually along the lines of try...catch...finally (with > possibly some work done to avoid throwing another exception in the > finally). Unix error "design" does this: > > exit <some arb number> > and an error message is in $@ if you feel like looking for it > > Strangely, this approach is exactly why Unix took off and got such > widespread adoption throughout the 70s. An engineer will understand that > a well-thought out design that is theoretically correct requires an > underlying design that is consistent. In the 70s, hardware consistency > was a joke - every installation was different. Consistent error handling > would severely limit the arches this new OS could run on. By taking a > "Stuff it, you deal with it coz I'm not!" approach, the handling was > fobbed off to a higher layer that was a) not really able to deal with it > and b) at least in a position to try *something*. > > By ripping out the theoretical correctness aspects, devs were left with > something that actually could compile and run. You had to bolt on your > own fancy bits to make it reliable but eventually over time these things > too stabilized into a consistent pattern (mostly by hardware vendors > going bankrupt and their stuff leaving the playing field) > > And so we come to what "Unix design" probably really is: > > "You do what you have to to get the job done, the simpler the better, > but I'm not *really* gonna hold you to that." >
*slow clap* -- This email is: [ ] actionable [ ] fyi [x] social Response needed: [ ] yes [ ] up to you [x] no Time-sensitive: [ ] immediate [ ] soon [x] none
