On Sun, Feb 23, 2014 at 5:12 PM, Mick <michaelkintz...@gmail.com> wrote:
[ snip ] > Well, I'm no authority on this since I can't code, My point exactly. > but here's a starter for 10: > > http://www.faqs.org/docs/artu/ch01s06.html Funny you mention this; the second definition is by Robert Pike, who later said: "Not only is UNIX dead, it's starting to smell really bad." > http://people.fas.harvard.edu/~lib113/reference/unix/co-unix4.html You can hear in [2] the best response to the famous quote by Henry Spencer ("Those who don't understand UNIX are doomed to reinvent it, poorly."): "Those who don't understand UNIX are condemned to quote Henry Spencer." And that's the point; the people doing this changes *obviously understand Unix*. They understand it so well that they are able to look at it honestly, beyond dogma or articles of faith, and see its downsides, so they can try to fix them. > http://en.wikipedia.org/wiki/Unix_philosophy This reminds me of the people that quote from religious books to argue about anything non theological. The "rules" and "sound bites" in the links you provide are there to summarize rules of thumb; they are NOT scripture, and they are certainly NOT the only way to get a technically good program that is easily maintainable. In other words, you can ignore most of them, or just following them to a point, and anyway end up with a sound design and a technically great program that is easy to maintain and extend. The people with coding experience (or most of them anyway) understand this; we are not a religion, we don't have prophets that speak the undeniably truth. We have highly skilled developers who can have opposing views on how to design and implement many different ideas, and that doesn't (necessarily) means that any of them are wrong. There are many ways to solve a problem of sets of problems. Having Emacs doesn't mean vi is "wrong", nor having GNOME means KDE is "wrong", nor the other way around. >> I've now concluded it's a myth, much like invisible pink unicorns. >> >> Is it like the kernel? A huge monolithic chunk of code with support for >> modules? > > I would think that although the kernel has grown over the years, it has not > done so like systemd. You can still *not* build modules you don't need in > your kernel. This has nothing to do with "Unix principles"; it's just that someone willing and able implemented the different options. >> Is it like X11? A huge monolithic chunk of code that has a bizarre build >> system for years, and took something like 5 years of hard work to get it >> modular? And is 20 years behind the times? And *still* requires devs to >> jump through hoops to get a rendered image through a compositor and back >> up the the GPU? > > The X11 devs saw the error of their ways and ended up breaking up the big > monolithic Xorg code and releasing it as a modular package since X11 7.0, if I > recall right. The X11 devs decided that X11 is crap, and therefore they are working now in Wayland. Yes, Wayland is basically written by the same people who maintains X.org. Again, see [2], it's pretty awesome. >> Is it like perl? Support every possible way to do something if it >> remotely makes sense to do it, no matter how bizarre the syntax? >> Is it like python? Pick ONE way to do it and stick with it dammit! >> Is it like php? Do whatever you feel like? >> Is it like command line text processing tools that only do one narrow >> thing well? [1] >> Is it like bash? I can't find a decent description of how bash came to >> be except it's like Vogons - wasn't designed and didn't evolve, it just >> sort of ... congealed > > Designing a programming language is not exactly parallel with designing an OS, > although similarities exist (e.g. re-use code where you can and don't re- > invent the wheel). I'm pretty sure there are lots of people who vehemently believe that the "Unix principles" can apply to everything, even programming languages. You would be cataloged as an heretic for saying that is not exactly parallel. >> Not to rain on anyone's parade, but there's a prize of 40 internets up >> for the first person who can clearly and unambiguously define "Unix >> design principles" with specificity so that it is globally applicable. > > The Unix design philosophy may not be globally applicable, but has served > Linux well over the years. No; what has served Linux is to have developers willing and able to write the necessary code, following whatever design they decide is the correct one. > Lennart has de facto introduced a different way of > developing his Linux code, which to others and me seems more restrictive. First of all, it's not only Lennart; the systemd repo has (literally) dozens of contributors with write access. Second of all, calling "restrictive" the tightly integrated approach, is exactly as constructive as calling "anarchic" the loosely integrated one. Like "Unix principles", it means nothing and it says nothing. > I am not saying that his coding is poor (I'm not qualified to judge), or that > systemd is wholesale bad. But, is this a whole new design paradigm in the > development of Linux that we should applaud and follow, or just a mistake > borne out of ignorance/arrogance/expedience? Or people willing and able to try new ideas that they believe are awesome? > Time will tell. Indeed; although, as I see, time is already telling us. Regards. [1] http://proness.kix.in/talks/foss.in07-plan9.pdf [2] http://www.youtube.com/watch?v=F6PFjoYuml0&t=28m27s -- Canek Peláez Valdés Posgrado en Ciencia e Ingeniería de la Computación Universidad Nacional Autónoma de México
