On Sat, Feb 22, 2014 at 6:40 AM, Canek Peláez Valdés <can...@gmail.com> wrote: > On Fri, Feb 21, 2014 at 2:14 PM, J. Roeleveld <jo...@antarean.org> wrote: >> On Thu, February 20, 2014 06:34, Canek Peláez Valdés wrote: >>> On Wed, Feb 19, 2014 at 3:00 AM, J. Roeleveld <jo...@antarean.org> wrote: >>>> On Tue, February 18, 2014 18:12, Canek Peláez Valdés wrote: >>> >>> [ snip ] >>> >>>>> Of course the larger a project is the *potential* number of bugs >>>>> increases, but so what? With enough developers, users and testers, all >>>>> bugs are *potentially* squashed. >>>> >>>> Agreed, but I know of enough large projects with large development teams >>>> and even more users that don't get the most basic bugs fixed. >>>> Quantity is not equivalent to Quality. >>> >>> I also agree with that. My point is that the systemd project has >>> enough numbers of *talented* developers to do it. >>> >>> You can disagree, of course. >> >> Talented developer, maybe. >> But not talented designers. > > That's subjective. For me (and many others), the design of systemd is sound. > >>>>> And systemd has a *much* wider community than any other init system. >>>>> So it can handle a larger code base. >>>> >>>> Incorrect. How many people use systemd as opposed to SysV Init? >>> >>> Users? Like five thousand godzillions more. >> >> I tend to disagree. > > I meant that SysV has like five thousand godzillions more that > systemd. Sorry for the confussion. > >> Systemd is ONLY on Linux. >> SysV init can be found on alot of other platforms used in the world. Think >> Solaris, AIX, HPuX and Linux machines that have not had their init-systems >> changed. >> >>> Developers? It would not surprise me that systemd has several times >>> more developers that SysV ever had. >> >> Maybe, but the developers back then still followed the unix-way: Have a >> tool do one job and do it well. > > Again, for many of us that doesn't matter, and we don't take it like > an article of faith. > >> From what I see from systemd, it tries to do too much and the single jobs >> suffer from feature-bloat. > > Many of us believe they solve real problems, and they make our life easier. > >>> What's more, I think those developers are talented enough, to say the >>> least. >> >> I miss talented designers. > > Wonder why? > >>>>>>> > SysVinit code size is about 10 000 lines of code, OpenRC contains >>>>>>> > about 13 000 lines, systemd  about 200 000 lines. >>>>>>> >>>>>>> If you take into account the thousands of shell code that SysV and >>>>>>> OpenRC need to fill the functionality of systemd, they use even more. >>>> >>>> The shell-code is proven to work though and provided with most of the >>>> software. Where it isn't provided, it can be easily created. >>>> I have seen (and used) complex start-up scripts for large software >>>> implementations which complex dependencies. >>>> Fortunately, later versions of those software packages have fixed that >>>> mess to a large extend, but I wonder how well systemd unit-files can >>>> work >>>> in such an environment. >>> >>> You can read [1]. I think it provides a fair and impartial account of >>> how to use systemd to start a complex service (NFS, by its author). >> >> I would not class NFS as a complex service. >> I am talking about a dozen different services that need to be started in a >> specific order where the next one is not allowed to start before the >> previous one actually responds to TCP/IP connections. > > If you had read the link, you would have learned that NFS has 14 unit > files, form a lot of daemons that have to run in concurrent form (and > some of them only when others are not, etc.) It *IS* a complex > service. > >> How would I configure that in systemd unit-files? > > Read the link
Canek, you're too polite. This deserves a /usr/src/linux/Documentation/ManagementStyle, chapter 5 reply. At my risk entirely, here is one: You ignorant nitwit. Read the fine link. Read the fine docs. Read the fine manual. Read the fine publicly posted rationales. Read the fine publicly held distro and package manager discussions. And know what a fine socket is before you start spouting your diarrhea crap about spawning sockets in advance. And if you don't, here's the thing, maybe you're not really familiar with the "Unix way" that you're so proud about. Because you don't get to skip all that and make ridiculous sweeping generalizations and assertions that the docs DO answer. The so-called Unix way that many of you peeps are waxing priest-like about is in reality just one aspect, one part of the Unix way, meant to apply to a particular class of applications. It doesn't apply to everything. Especially, text filter design does not apply to applications that are meant for solving genuinely complex problems - the kernel itself is a glaring violation of the one small thing doing one thing well rule. And why? One, because it uses that complexity to solve things that would be harder to do in the minikernel approach, and two, even as the complex beast it has become it's still simpler (read: Unixier) than the alternative solution of interacting servers. Even as the complex beast it has become systemd is still simpler than the alternative of having abominations of unreliable shell scripts checking to see which version of grep and sed is used to split the command line, or whether the system uses tempfile or mktemp, or depending on perl. ergo libreoffice. desktop environments. firefox. databases. Heck much of what's being said about systemd applies to postfix - there's no general case reason for me to grab some random postfix component and use it for everyday work, therefore postfix is just some closed-source monolithic virus, right? -- This email is: [ ] actionable [ ] fyi [x] social Response needed: [ ] yes [x] up to you [ ] no Time-sensitive: [ ] immediate [ ] soon [x] none
