On Sunday 23 Feb 2014 23:54:32 Canek Peláez Valdés wrote: > 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.
I think your point is not valid, unless you view Linux as an operating system intended for and inviting comments only from an inspired l33t who can code and it is *only* their user requirements that count. I understand though that it is their/their employer's choice as to how they spend their coding time and what they spend it on. I am not ungrateful for their generosity whether I agree with their approach or not. > 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. You seem to have a lot of faith in their approach and choice-limiting decisions. They have made arbitrary decisions in developing their software in ways contrary to their predecessors. I don't know if this is because they are cleverer than their predecessors, or more ignorant/arrogant/wrong. > > 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. I agree. This is not a religion, but a statement of design principles based on some observations of what seemed to work (at the time) that were made after the event. > 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. We agree again, except that some of these opposing ideas are limiting future development choices and current user options. > 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. KDE took a wrong turn the moment it started emulating Gnome by hardcoding redland a whole host of components in its pursuit of a semantic desktop, removing choice from users who would be otherwise very happy with the KDE3 functionality. Many users have voted with their feet - not because they can code better or code at all, but because they still have a choice as plain users. At least KDE has not hardcoded a requirement for systemd as Gnome now has. > >> 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. Well, "someone willing and able implemented the different options", but did so by following the paradigm of modular development. > > 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. I think we have a fundamental disagreement here. The Unix design principles inc. modularisation and extensibility make good sense when seen from the perspective of many contributors adding to and improving code in a piece meal fashion. X11 did not follow this approach and ended up with convoluted unmaintainable code that had to be broken up. Having developers able and willing to write code is of course a precondition, but not just any code. It has to be code which others can pick up, improve and extend. In other words, they have to write code which is versatile, being respectful of and keeping in mind future development effort. > > 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. On the contrary, I think it says something quite specific: Lennart and other contributors have decided to not follow a modular approach and have hard wired components into a growing monolith. In doing so they have remove choice from users. You want Gnome? You *must* user systemd. At least for this reason alone his and other contributors design approach is deficient and criticised by many as inappropriate for Linux. I expect that ultimately, this hard wiring will meet its timely end because it is by its nature self-limiting and a new development effort will start again. -- Regards, Mick
signature.asc
Description: This is a digitally signed message part.
