On Mon, Feb 24, 2014 at 2:54 PM, Mick <michaelkintz...@gmail.com> wrote: > 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.
Of course comments can come from anyone. But it stands to reason that, in the first place, the people *writing* the code would primarily listen to people that actually know what they are talking about. In the second place, even if they *listen*, that doesn't mean they will *implement* whatever a random set of users ask for. > 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. Glad to hear that. >> 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. I have nothing even remotely close to "faith". I can read code, I can read design documents, and I follow the discussions in the different forums where systemd is the topic. It's my educated and reasonable conclusion that their approach is correct (in general terms; of course I don't agree with everything). > They have made arbitrary decisions in developing their software in > ways contrary to their predecessors. Excuse me, but where do you get the idea to call their decisions "arbitrary". Again, read the code (if you are able to), read the design documents, read the discussions. You can disagree with their decisions (I do with some of them); but I don't think there is a single one that can be called "arbitrary". > I don't know if this is because they are > cleverer than their predecessors, or more ignorant/arrogant/wrong. Not necessarily "cleverer"; they just have more software history available to determine what it works and what it doesn't. >> > 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. Glad to hear that. > 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. You said it: "at the time". Hardware is highly dynamic now; hard drives, sound cards, network cards, memory and even CPUs can come and go while the systems is running. SysV (and therefore, OpenRC) was *never* intended to work like that, so what it does it does badly, if at all. >> 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. No they are not; THE CODE IS OUT THERE. Anyone can take the code at any point in time before systemd, and start a new path if this one turns out to be failing. There is no "limiting" no one and nothing; while there are people willing and able to, any design path can be explored. >> 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. That's your analysis; I really don't like KDE, but I love my GNOME 3 desktop. That's subjective and has nothing to do with the topic at hand; I was talking about how different (and sometimes opposite) ways to solve a problem doesn't mean (necessarily) that one of them is wrong. > At least KDE has not hardcoded a requirement for systemd as Gnome now has. GNOME has no hardcoded requirement for systemd; do your homework. >> >> 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. Not true; not always anyway. And that's my point; if the "rule" is only applied sometimes THERE IS NO RULE. >> > 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. In some cases, yes, they did. In others (like systemd), they didn't; do your homework and study that cases. Just like systemd Why? Because this is not a religion, and there is no hard rule. There are rules of thumb that you can ignore if you think your design works better without them. Like systemd (in general). > X11 did not follow this approach and ended up with convoluted > unmaintainable code that had to be broken up. And the declared crap by the same X11 developers, and now they are focusing in Wayland. > 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. I agree; that's why systemd has recruited dozens of developers from basically all distributions under the sun, and they are able to pick up, improve and extend the code. Like networkd; that's new. Or like watchdog support. Or like SMACK labels. You name it. > In other words, they have to write code which is versatile, being > respectful of and keeping in mind future development effort. And that's the case of systemd's code, which if you took the effort to learn how to program, you will be able to see by yourself. Even if it doesn't follow all the "unix principles" to the rule, it is versatile and keeping in mind future development effort. That's why GNOME, KDE and Xfce would depend (optionally) on it; that's why the author of NFS was happy to finally create a set of unit files that would work on any distro; that's why embedded guys like Tizen or Jolla are using it. >> > 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. It's modular enough, where it has reasons to be. > In doing so they have remove choice from users. Why? You can keep using the same stuff as before. > You want Gnome? You *must* user systemd. This is simply not true; GNOME 3.10 *runs in OpenBSD* [1]. Do. Your. Homework. In Gentoo you need systemd, but that's a decision from the Gentoo maintainers. They do the job, they make the choices. > At least for this > reason alone his and other contributors design approach is deficient and > criticised by many as inappropriate for Linux. Do your homework before saying things that are not true. > 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. Wanna bet a beer that doesn't happen in the next 20 years? I'll bet a beer. (I don't drink beer). Regards. [1] http://undeadly.org/cgi?action=article&sid=20140219085851 -- Canek Peláez Valdés Posgrado en Ciencia e Ingeniería de la Computación Universidad Nacional Autónoma de México
