5 Does the “typical linux user” have anything to gain over traditional scripts?

This is article 5 from the latest proposed list of topics

Probably the most valuable content this community has produced was condemned by immaturity and lack of organization (on our part) to set the parameters of the procedure within which a productive debate can occur.

One of the reasons people without bosses, authoritarian structures, fail to organize and formulate their own power structures is because they have been conditioned to be vicious aformalists (anti or non formalists in terms of organizational tendency).  Individuals born and raised within this patriarchal system of authority can only behave like spoiled children all their life.  Sorry cynwulf1 and mobinmob, but you used and abused your expertise to block all other possible participants and concentrated on your own duel of expertise competition.

The content of your expert testimonies may be of value, but next time something like this happens fungalnet is not going to be here and be nice, you will be moderated and either respect an open process discussion or you can take your dialogs somewhere else.  Imagine if in a Union meeting two characters, with very accute and experienced authoritative voices,  converted the meeting into a dialog where everyone else was forced to be quiet and listen,  Two people from within an amphitheater, can dominate nad hijack all discussion to what they think the object of the meeting is.  Not here, not again!

Fungalnet failed to set the rules of a debate, it occured in a totally unrelated subject, fungalnet let it go on, you both ignored fungalnet trying to present the case of “the average linux user”, and now the question still remains open.  Neither of you, consumed in your own expert testimony, were able to convince (we believe) for either or.

The question remains,  should we “average linux users” (who may use a workstation for editing text, browsing the net, manipulating images, video, or audio, or who may be an average linux admin hosting a home or small office network of file, mail, firewall, backup, print, and other servers).  Are scripts as found in Antix or Open/Free{BSD}, enough, or are supervision suites such as those of Void, Obarun, Adelie, Spark, Artix, a benefit to users?

If you, the reader can deduce an answer from the debate below, please participate and contribute to the ongoing debate.  We will insure that nobody will speak over you, no dialogs are going to be allowed to continue, anyone addressing another individual and not the entire audience and possible participants, WILL BE MODERATED, blocked, restricted …!

So respect the process of “equal” participants despite of the level of expertise or move your dueling show elsewhere!

  •  

    http://skarnet.org/software/s6/overview.html

    I wonder what a typical desktop Linux user would gain over sysvinit, when using something like s6, or runit or daemontools in fact?

    i.e. do those users wanting to avoid systemd need a process supervision suite over a basic sysvinit setup?

    For me this just seems like paying lip service, even buying into, the typical “sysvinit’s time was up…” line and that alternatives had to be offered, because sysvinit was getting “old” or lacked certain features [one wonders how did they cope with this atrocious situation for so many years]. You will read that “it’s a miracle that sysvinit worked at all”, etc. If you tout sysvinit, you will be mocked and derided, which is why I feel that some have capitulated and “moved the target” as it were.

    This comes from a few quarters – most are simple fanbois, parroting and repeating what they have read elsewhere, others are professional sysadmins, who are involved primarily in the enterprise server market and make their living from Red Hat, Canonical or SUSE “products” and may make use of the “features” systemd offers which apparently never existed before [in a supported off the shelf RHEL installation, all tied up with a nice support contract]… because of this, “everyone” needs to be running it, etc. In many cases, the professionals probably don’t run any kind of Linux as a desktop – for most, Linux is primarily a work tool and a server.

    I think skarnet’s goals are admirable – they even released under a sensible licence – and there is the means to replace init directly or run under sysvinit. It’s cross platform so again, you know this is not by any stretch just some vapour project catering only to the fears of the irrational anti-systemd cult.

    Obarun however seem to be all about offering an Arch Linux without systemd, through offering a process supervision suite instead of systemd or sysvinit? So it’s this odd “compromise” I have referred to above: “don’t want systemd? – install a process supervision suite!”. That I don’t fully comprehend? A process supervision suite is not a drop in replacement for systemd, it does not replicate all of systemd’s functionality – nor does it claim to – this seems like “smoke and mirrors” – and assuming that 95% of Linux distro/respins/derivatives are just hobbies targeting dekstop hobbyists and especially this one seems to have an ideological slant, I have to wonder.

    This illustrates one of the benefits and also one of the failing of the Linux ecosystem – “fragmentation” – a word ironically used by a well known systemd developer. The nature of a typical Linux system as a “collection of bits” also makes that same system susceptible to being steered by those with enough power, money and influence, to pay/pay off develops, to fund projects to get them on the hook – to be in a position to pull that funding, etc. It’s why you have software such as systemd and emulating that and building in shims and compatibility layers or advertising supposed equivalents which are not equivalents, only plays into the hands of that project and its backers.

     

  •  

    I don’t know if I know enough to answer all of those questions you are raising, especially what users need and what users want. I know that users who own a modern computer (something with more than one single core/thread and something that can process more than 32bit instructions) can see their space age (remember Sputnik? It didn’t have chips, it had bulbs in it) machine laboring to run long tedious scripts before a prompt is provided. As PC grew in spectrum, role, and abilities, to use this 32bit linear one coffee grinding wheel process it all, mentality “appeared” to the “user” as a decaying choice. So systemd appeared as the new PC system in comparion to those “old PC” hardcore hardheads.

    To start the same machine with runit the difference appears obvious. To read the runit wiki and how to enable disable services appears to some as becoming an expert in 24hrs. Show me such a sysvinit document that empowers a mediocre user to such an extent. Every other distribution you visit sysvinit is implemented in its own unique way. In my view, sysvinit encourages this mess of variety.

    I have more questions for your questions. How many people do you think have used systemd through ubuntu, mint, or even debian, for years, and never touched the service management setup ever since its installation? They have a gui for this, it is not hard, but they have lxdm, bluez, cups, right next to really essential to the system services. Someone who may not be fully familiar with those things can easily brick their machine (in their eyes being bricked as they see no desktop or DM login on the next boot).

    Is s6 necessary for browsing the net and playing games or writing a poem or editing a video? Yes and no. No, for chatting on instagram I guess not, for playing a game where fps may be of issue, or for available resources to the memory used for film cutting and pasting from reel to reel, it might very well be.

    Just last week I thought of a different way to see if I can break my system, and on the 66 boot tree I added tty1 which is supposed to be handled by a subsequent tree after boot is finished. From bootloader to tty1 login: it seemed like a blink of an eye, while speeding up to enter my user and pw there were still messages popping up of processes that related to booting. So the 66 developer is correct when he is suggesting to wait “a second”.
    One can get tired of waiting scripts in line, behind one another, to be served slow thick soup at the soup kitchen, before their system becomes available. Not with a 21st century machine. Even trying antiX-runit edition seemed as a step into 21st century. Maybe it is all psychological, after 53″ of waiting for sysvinit to finish you get up and make coffee which takes 4′ then sit back down and log-in. So yes, you may be right, it is all in our heads.

    Who is going to explain to me whether I need acpid or not? How do I turn it off on sysvinit. If you do in return I’ll tell you how you can see if it is running and where on Obarun, and how to disable it immediately or after next boot. It is even simpler than runit.

    Did you read my review of Spark (archlinux + sinit + ssm)? I think partially it may answer some of the inquiry you have brought up. If sinit and ssm can do such a great job, how the hell did people live with the huge mess called sysvinit for so many years? You read the entire sinit and the entire ssm …. and you scratch your head? What is this init war all about anyway?

    Then you go back to your virtual multi-cored Obarun installation and try to figure out ways to throw the system off, to derail it, to stop it, to trick it in doing something stupid, and it is sticking its tongue out. No matter what you do it comes back up fresh like it was rebooted. There are two ways, the powercord and the shutdown daemon asked in a nice specific polite way. Otherwise the system is indestructible. I couldn’t say the same for runit. It would be like asking a bicycle to do 0-400m in 9″

    So, yes, I think we do need something better, especially when it is available and free (which I don’t think systemd really is – or elogind for that matter).

     


  • One small additional remark. 66 doesn’t add or subtract anything from s6, it is just a very user friendly way to set up s6 (which is terrible if you are not a graduate student on init/serv.superv. specializing in the subject).

    The very first person who will tell you how terrible s6 is, is the person who wrote it. Even he had a hard time implementing it on Adelie. But after you compile 66 on Adelie an 8 year old can use it.

    Once you set everything up with 66, it vanishes. You may as well delete it and it will not make a difference. The system runs on s6.

     


  • @cynwolf1:

    The questions is what supervision suites (and init systems based on them) offer that they should be preferred to sysvinit, isn’ t it?

    It is a valid one. It also a hard one to answer without looking at why the supervision suites where created and why they were used as init systems.

    daemontools were never intended as a replacement for sysvinit. They were a solution to run cleanly and reliably long running program/daemons in a manner that they can be restarted when they failed and easily run with a carefully modified environment. sysvinit does not offer anything close – /etc/inittab is pretty primitive and severely restricted. Some time after the creation of them somebody realised that in a system with daemontools, sysvinit can be replaced with a simple script and svscanboot could run the whole system (the relevant document is named something like Svscanboot as pid1). That was followed by full blown init systems that offer supervision (minit/cinit/ninit) and supervision suites with init capabilities (runit). They extended the original concept with ordering-dependencies (needs/wants), time-based execution etc…

    Why replace sysvinit? Because these new-fanged systems did more, much more cleanly with less code -especially if you factor in the rc systems). Can that be substantiated with more than claims about the supervision history? Absolutely.

    How does a sysvinit does more that what the programs that comprise it allow? By augmenting them with (complex) rc systems. Gentoo did that, with baselayout that was partly rewritten in C as OpenRC. It ran on sysvinit or bsd init. But… it sprung an init system of its own, because sysvinit did not do much and was not maintained. See a pattern here? Debian went it’ s own way by adding dependencies in special headers in its scripts…

    So do we need more than what what sysvinit provides? Almost every rc system before systemd/upstart extended it substantially. So it follows that many people need more than the basic toolset it provides. You can use modern supervision suites/system managers on top of sysvinit (see what kiss linux does with the busybox-provided tools). But why use sysvinit at all if all the work is already done by the rc-system/supervision suite and the sysvinit programs can be replaced with a few scripts?

    If somebody values sysvinit and wants to use it with arch, obarun and artix provide the necessary systemd-less packages to do so. Why isn’ t anyone doing it?

    Because it not minimal enough to merit consideration against sinit/busybox init and not full-featured enough to stand up to openrc/runit/66/s6-rc.

    “SysV init must die.

    I’m joking. You may happily continue relying on init if you feel yourself comfortable with it.”

    https://busybox.net/~vda/init_vs_runsv.html

     

  •  

    fungal,

    Your argument to me at least, seems to equate to “faster boots”. My questions is about the usefulness of “service supervision” to the average user of a “hobbyist” desktop Linux distribution – especially as touted as a “distribution without systemd” for those particularly interested in avoiding that.

    “Show me such a sysvinit document that empowers a mediocre user to such an extent. Every other distribution you visit sysvinit is implemented in its own unique way. In my view, sysvinit encourages this mess of variety.”

    I expect the systemd developers were of much the same opinion. They used the word “mess” as well as I recall, when bemoaning the “variety” of choice available and the need to end this “fragmentation”. On of the plus points of the simple init process, provided by sysvinit, was that it allowed all kinds of “bolt on” alternatives to form. It’s flexible in that you can implement it as per Debian or Red Hat or have a different take on it altogether as with Slackware’s “BSD style” system.

    For Debian there was rcconf(8), update-rc.d(8), etc and their associated documentation. All relatively simple means of starting/stopping and configuring/changing services and their run levels – but most users did not need to mess with any this. In most cases, on a typical Linux distribution, you would not touch the system provided init scripts anyway. In Debian in particular, installation of a package usually added any needed scripts and set them to start. In some others and the ‘BSD’s, there is the additional need to enable the script manually. In FreeBSD, for example, the daemon is merely set to start in rc.conf.

    I used Linux distributions with sysvinit for probably about 10 years and never saw a problem – I have no doubt that if the need had ever arisen for a service supervision suite, I would have installed any one of the options available at the time – but I can honestly say that my systems would boot correctly, quickly enough and work reliably with sysvinit and whichever distribution’s implementation – hence why I believe most of the slanderous comments about it are myths which have been spewed out and passed on by corporate shills and their willing parrots. I used Slackware and Debian mainly and other distributions before that and can honestly say that I was never much bothered by the init system or anything it supposedly lacked. I don’t much care what the “enterprise” market uses or wants to use, that’s immaterial.

    I remember trying fedora several years ago, probably once or twice and was on both occasions hit with typical systemd problems, which were of course not bugs at all, but entirely my own fault. Similarly with Debian, the last time I used it, it was the first release which defaulted to systemd, and switching over to sysvinit gave me a more dependable system, which was at least more familiar.

    A “mediocre user” can only be “empowered” by learning how to administer their own system to some degree – where there is a reliance on high level tools, automation, graphical windows style configurators, etc, this is straight back down the route of systemd, etc… I fail to see the “empowerment” there.

    “One can get tired of waiting scripts in line, behind one another, to be served slow thick soup at the soup kitchen, before their system becomes available.”

    Boot time, was one of the bullet points for systemd. Again I feel I must be specific – I don’t care about boot time, some users do. In general, if the CPU is fast enough, no level of boot optimisations such as parallelism, etc, makes that much difference on “21st century” hardware, as a typical boot in itself is not strictly processor intensive and never was, e.g. a fast SSD may make more of a difference. This is why most proprietary OS and some Linux are using suspend to disk for faster boots these days (Windows now does this by default). The faster boot argument so lauded by systemd and it’s fans, is just more dubious snake oil to lure the gullible (in the few tests I remember doing, systemd was /slower/ to boot that some comparable sysvinit systems on my hardware at the time…).

    I also don’t need service supervision – and I am also not arguing against service supervision – just as I would not argue against a RAID5 setup, or full disk encryption, or running sshd or using jails or ZFS or whatever else – if you need it, you need it, if you don’t, you don’t…

     

 

  •  

    First let me clear up the mental state of the person you are directing your questioning. I am so fed up and disappointed in managing to disappoint myself of my favorite distro, void, that I am dissociating from the object. At least temporarily. I thought if I start writing about bicycles on the side, top right menu-tab (under bicycling/α-testing).

    I assume you have read the response to you by mobinmob, I think it covers part of the questions here as well, or doesn’t it. Should I wait for your response to mobinmob before I continue my dramatic condemnation? 🙂

    I think part of default behavior in many systems, trying to benefit the user that doesn’t want to touch the system, the main idea behind installing software that is meant to run in the background and provide a service, is that the package installs the software itself, with some default configuration, and a service/run-script that enables it as soon as it is installed, or by next reboot, depending on the kind it is. So because you install cups, this means that cupsd runs eternally when the system is powered up. One is tempted to have many things installed and available, even if they are not used but in very specific occassions. Wifi (I can, but haven’t plugged the dongle for maybe 2 years, or more). Bluez … in the rare occassion of having to download a picture that I took from this very basic cel-phone with camera that appears to be 5-6yo and I have no cable kit to connect it otherwise. Not a smart phone, one I inherited from mom. It has been off much longer than it was ever on. But no, I am not claiming that there is any system you can’t just turn services off.

    Not all criticism of sysvinit by systemd advocates was propaganda and not objective. I don’t think you believe this either. Then again, not all criticism of sysvinit is in support of systemd. I think mobinmob’s detailed presentation is sufficient to what each one did or did not do well.

    I honored your recommendation to try free and open BSD to have a frame of reference, I don’t think you have tried Obarun, even to run it live on a vm. Read the intro-to-66 wiki and play with it a bit. Then we can talk some more 🙂

    PS I think it was wheezy debian 7 that was last that defaulted to sysvinit but systemd had become available, and it was 8 jessie that flipped the two. Now if you were able to “just switch” to sysvinit in Jessie, then you were a better man than the whole Devuan team (it took them years, literally) and antix/mx. I struggled to borrow update packages from Jessie, testing, sid at the time and still maintain integrity in wheezy and it just wasn’t possible or feasible anymore.

    Not only did I not ever pay attention to how sysvinit run, till I left Debian I didn’t understand how linux worked. Unfortunately I was obeying the dev’s suggestions “don’t touch the system”. Now where is the “free” in “don’t touch the system, we know what’s best for you, we decide, you just keep playing solitaire”? Arch logic in a way is great. We provide a very stable minimal base and 5 metric tons of software. Do what you like, read the wiki, but don’t come crying something broke.

    Obarun base no-X image is more than twice as big as Arch. You basically get a shell, a kernel, the filesystem, and pacman. Anything else you have to do on your own. If you install bluez then bluez is up and running when the installation is finished, and it will stay that way till you fight the hydra to shut it off or simply uninstall it.

    PS2 After realizing the autism of Void’s team to keep Gnome running at all costs, in all architectures and even on musl, and shaping the entire distribution to accommodate this need, beyond Obarun I have little hope this battle is worth fighting anymore.

     

  •  

    Hello mobinmob,

    “Because these new-fanged systems did more, much more cleanly with less code -especially if you factor in the rc systems).”

    This is one of those “citation needed” comments because I actually went through a lengthy debate a year or so ago with someone and the end result was that, in a comparison of code, sysvinit was much smaller and much simpler. The “rc system” as you call it, is derived from UNIX System V which is where “sysvinit gets its name. If you visit sysvinit’s project website, you will see that it’s described as “System V like”.

    “Factoring in the RC system” is also somewhat fallacious as packages always provide their own scripts.

    “Less code” is also subjective. Do you consider a simple base init and packages providing their own code to be “more” code over something which uses more binaries?

    You may be somewhat surprised to learn that sysvinit installs at around about just less than 1MB and it’s bundled scripts are for shutting down, rebooting, unmounting, etc 0- and a handful of utilities such as telinit, etc. By comparison OpenRC is about twice the size… it’s an apples and oranges comparison however. s6 + libskarnet is also a larger installed size than sysvinit, but smaller than openRC – again apples and oranges, but it seems to refute your “less code”…

    “How does a sysvinit does more that what the programs that comprise it allow? By augmenting them with (complex) rc systems.”

    The “rc systems” are the init scripts, they are “complex” to those who do not understand them. so I don’t understand your line of argumentation – or are you saying that developers are intentionally writing “complex” code in order to obfuscate and confuse?

    “Debian went it’ s own way by adding dependencies in special headers in its scripts…”

    That “complex” workaround was in implementing dependency based boot around 10 years ago. Really it wasn’t complex, the “complexity”, if you like, was getting it enforced and in migrating systems over to it at upgrade time. This was the transition between lenny and squeeze.

    It may surprise you somewhat that a lot of UNIX has been workarounds and scripting rather than the next great big (usually binary) solution to end all headaches(tm). A lot of UNIX has been about using a series of tools and linking those together and writing scripts around that and the result has been surprisingly fault tolerant and has kept things ticking over for decades. It’s why OS such as FreeBSD, OpenBSD, NetBSD have stuck to their own tried and tested init solutions rather than embracing the next big thing. Interestingly those latter projects tend to filter out the brainfarts and are not so corporate influenced, so a lot of s*** is kept at arms length as a result.

    “Almost every rc system before systemd/upstart extended it substantially.”

    Well no, because you did not get “service supervision” out of the box for example, on Debian’s or fedora’s sysvinit implementations for example. Service supervision was something you added, if you needed it. The “rc system” was just the usual take on the usual SysV style init, with an init process which starts/stops init scripts dependent on runlevel.

    “So it follows that many people need more than the basic toolset it provides.”

    Which is somewhat of a leap of logic. systemd is now providing much of the “plumbing” for desktops, it arguably provides what many users “need”, prior to that there was no dependence on systemd and consolekit, upower, udev, etc were all independently developed. s6 by comparison seems to provide “service supervision”…

    “You can use modern supervision suites/system managers on top of sysvinit (see what kiss linux does with the busybox-provided tools).”

    You can if you have need for them.

    “But why use sysvinit at all if all the work is already done by the rc-system/supervision suite and the sysvinit programs can be replaced with a few scripts?”

    Perhaps because it’s stable, well tested and well matured? Advocating for whole init replacement, puts you back on the slippery slope to feature creep and monstrosities such as systemd.

    Busybox’s site is advocacy and making the case for that solution over any other – hardly surprising and not exactly objective.

    For me at least, some of the runit, OpenRC, s6, etc advocacy is not dissimilar to the systemd projects “propaganda” to support the propagation and adoption of their project – i.e. decide it’s “better”, then build a case for why, retroactively filling in the blanks or cherry picking suitable argument along the way.

     

  •  

    “Not all criticism of sysvinit by systemd advocates was propaganda and not objective.”

    While that’s a valid point, it’s arguable that most of the criticism was from those with an agenda – i.e. to push their own implementation (systemd).

    “Then again, not all criticism of sysvinit is in support of systemd. I think mobinmob’s detailed presentation is sufficient to what each one did or did not do well.”

    With absolutely no disrespect intended to mobinmob, his comment does not constitute a “detailed presentation”. But we are already on a tangent in this init system vs init system back and forth. My original comments were regarding the supposed need for a service supervision suite in a typical Linux distribution, which will probably not be run as a server and will most likely be just a hobbyist’s desktop.

    So while it’s nice to say “I’m running some kewl new init on my hobby Linux box”, that’s about all you can say about it. If you were instead running sysvinit, your boot time might be a bit slower, but what other tangible difference would that make to your desktop?

    “I honored your recommendation to try free and open BSD to have a frame of reference…”

    I made no such recommendation. I make a point of specifically not recommending anything software-wise to anyone. As I’ve said many time, I use what works for me, I don’t get involved in advocacy. Linux users trying out BSDs is almost always a waste of time and effort. Linux users have preconceived ideas and just want those affirmed.

    “PS I think it was wheezy debian 7 that was last that defaulted to sysvinit but systemd had become available, and it was 8 jessie that flipped the two.”

    True, that’s what I said, you just added the correct release code names / versions.

    “Now if you were able to “just switch” to sysvinit in Jessie, then you were a better man than the whole Devuan team (it took them years, literally) and antix/mx.”

    I have no trouble stating here that: I was easily able to run what I wanted to run on Debian 8 with systemd removed and sysvinit installed instead.

    The only vestige was libsystemd0 which even the Devuan people now finally admit was benign… they may have spent “years” chasing that one possibly out of purely ideological (“every… last… one!”) reasoning (or in trying to satiate an ideological user base), before realising that a) they couldn’t easily get rid of it and b) it wasn’t worth removing anyway. Other vestiges were “systemd compatibility”, such as unit files provided by packages, etc – not much can be done with those, nor is it worth it. gnome is probably a big proportion of the problem – avoid that and you can more easily avoid systemd. This is because the Debian gnome maintainers are only interested in a systemd based implementation, full stop.

    The big annoyance of course is that when you attempt to install certain things, systemd may be pulled in as a dependency… but then there is apt pinning, disabling recommended packages and other trickery… you may not realised that I was a Debian (and Ubuntu) user since around 2006 or 2007. I know how to find out what is currently installed / not installed and how to avoid installing specific things, etc.

     


  • Hi cynwolf1!

    I would really like a link to that debate if it is in a public forum. There are of course problems with measuring size in that context, so I think I can clarify by replying almost point by point 🙂

    “The “rc system” as you call it, is derived from UNIX System V which is where “sysvinit gets its name. If you visit sysvinit’s project website, you will see that it’s described as “System V like”.”

    “Factoring in the RC system” is also somewhat fallacious as packages always provide their own scripts.
    “Less code” is also subjective. Do you consider a simple base init and packages providing their own code to be “more” code over something which uses more binaries?”

    That is confusing use of terminology on my part… Ι tend to separate init systems (e.g. binaries/scripts included in the sysvinit tarballs) from the basic initscripts that bring the system up (rc-systems) and are/were pretty different in each distribution and from the individual initscripts for services.

    Not all upstream projects provided sysvinit scripts and they differed between distributions. The fact that they are provided to the “end user” as packages does not mean much. They still have to be written and maintained. They are still code needed to run. So yes, I consider them “more” code 😛
    “It may surprise you somewhat that a lot of UNIX has been workarounds and scripting rather than the next great big (usually binary) solution to end all headaches(tm). A lot of UNIX has been about using a series of tools and linking those together and writing scripts around that and the result has been surprisingly fault tolerant and has kept things ticking over for decades. It’s why OS such as FreeBSD, OpenBSD, NetBSD have stuck to their own tried and tested init solutions rather than embracing the next big thing. Interestingly those latter projects tend to filter out the brainfarts and are not so corporate influenced, so a lot of s*** is kept at arms length as a result.”

    BSDs just have fewer devs and are very conservative because they cannot justify a change if it cannot be maintained by their current developers and/or funding. That attitude creates very stable and well-engineered systems. It also creates systems that cannot progress very fast if someone does not take up the specific task. How do I know that? Because of package managers. Ι spend almost 10 years listening the most inane arguments from my friends that used the BSDs about how their method of using ports and hackish scripts were more stable and generally better than apt. It took (mainly) the efforts of three men to change the situation and suddenly the same friends sung the praises of pkgng and pkgin.

    It is the same situation with initsystems IMHO. They are developers that know they need more than the traditional init scripts. Openbsd went ahead and created rc.d [1], a minimalist rc-system with the features they need. They were also the first to update their packaging tools.

    FreeBSD tried and failed to port and adopt launchd at the behest of iXsystems [2] and TrueBSD tried Openrc. They seem to have also considered nosh.

    So some people are searching for a better solution, that is not just expanding the current init.

    I am using runit and 66, they both use text for their “initscripts” and logging (optional in runit and with external tools in both), and I am not in any way advocating for one “binary” solution to rule them all ™. 😛
    “Which is somewhat of a leap of logic. systemd is now providing much of the “plumbing” for desktops, it arguably provides what many users “need”, prior to that there was no dependence on systemd and consolekit, upower, udev, etc were all independently developed. s6 by comparison seems to provide “service supervision”…”

    Systemd was propelled into adoption for two reasons IMHO: pressure for desktop components that tied into it and genuine better solutions to certain problems than sysvinit. Ι am interested in the latter, if it can be provided by simpler, better engineered tools. I believe that supervision suites are a solution.

    Do not get me wrong! The attitude of having an extremely simple solution that can be extended with other tools is a admirable one, deeply rooted in the unix tradition. It is also the attitude that prevented the adoption of runit/cinit/minit/ninit before systemd and led us indirectly to it. I still remember the conversation in the Arch forum when the adoption of runit was proposed. Sysvinit was enough (64k is enough), KISS etc. We all know what happened to there “principles” when systemd appeared and two people were persistent enough to push it for adoption.

    If you believe that sysvinit is enough and everything else can be implemented above its solid foundation that (again) is a valid technical argument. I want more and I can get it without the complexity of systemd or a mountain of shellscripts.
    ““But why use sysvinit at all if all the work is already done by the rc-system/supervision suite and the sysvinit programs can be replaced with a few scripts?”

    Perhaps because it’s stable, well tested and well matured? Advocating for whole init replacement, puts you back on the slippery slope to feature creep and monstrosities such as systemd.”

    An appeal to tradition is as useless as an appeal to novelty.

    Is runit somehow not stable and well tested? Is s6?

    Do they offer more than sysvinit?

    Do I need what they offer?

    Sw is not whiskey to be matured. It is a tool to solve a problem. The problems the “init” tool solves are evolving. It can either be extended or replaced by a more capable tool. I am firmly on the replace camp helping every way I can 😛

    Runit and s6 have not succumbed in the race for more features outside their scope. Even when s6-rc was created it did not subsume s6 and 66 does not seek to replace them but tie them together and complement them. The slippery slope is not the natural way of progressing, systemd had plenty of external help on order to vastly expand its scope.
    “Busybox’s site is advocacy and making the case for that solution over any other – hardly surprising and not exactly objective.”

    Of course it is advocacy (for the runit tools included in bb). It also spot-on. It focuses on what the solution does better than sysvinit (not any other).

    [1] https://www.bsdfrog.org/pub/events/openbsd-rcd-AsiaBSDCon2016-paper.pdf

    [2] https://www.youtube.com/watch?v=Mri66Uz6-8Y

     


  • As we say in the wild wild west, of guns guts and glory, I’ll take the fifth.

    In the not so far east where I am now, I’ll take my “pasa tiempo” bowl out and enjoy the debate between you two. If this is not the very essence of why I made this blog, the content of the comments right here, I don’t know what is. Definitely not the popular interest on how to install obmenu-generator or the list of unix systems without systemd.
    Meanwhile, before the next episode unfolds, I am examining my antiX installation, the one that is still left with sysvinit on it, from the blob of sysvinit, to the multiple directories called /etc/rc.d# and the enormous body of scripting in /etc/init.d and try to relearn the remnants of wheezy. This is a minimalistic openbox .xinit installation, as most of what I have are, and one that was kept as an ornament of my distant past, before I installed s6/66 on top of antiX 19, and antiX-sid.

    In my birthland, when we want to say let’s play “heads or tails”, we say “corona” or “letters”, from the time some royal figure with a “corona” was on one side of every coin and the other was the promise of the state to return X value in exchange for the coin. So, let’s say sysvinit is corona, and the new alternatives are “letters” (runit, OpenRC, s6, sinit, minit).

    Despite of the 5th amendment to the US constitution, I did not remain silent when I reviewed Spark and sinit/ssm, I admitted guilt, why would a single user of a PC need any more than this. Huge difference between sinit/ssm and svinit though.

     


  • The article I referred to in my first comment is “Running svscan as process 1” by Paul Jarc:

    http://code.dogmap.org/svscan-1/

    It is a pretty nice explanation of the way and the reason to use supervision suites as init systems.

     

  •  

    The comment above is from me. I highly suggest the article mentioned 😉

     

  •  

    @cynwolf1:

    ““Then again, not all criticism of sysvinit is in support of systemd. I think mobinmob’s detailed presentation is sufficient to what each one did or did not do well.”
    With absolutely no disrespect intended to mobinmob, his comment does not constitute a “detailed presentation”. But we are already on a tangent in this init system vs init system back and forth. My original comments were regarding the supposed need for a service supervision suite in a typical Linux distribution, which will probably not be run as a server and will most likely be just a hobbyist’s desktop.

    So while it’s nice to say “I’m running some kewl new init on my hobby Linux box”, that’s about all you can say about it. If you were instead running sysvinit, your boot time might be a bit slower, but what other tangible difference would that make to your desktop?”

    Our host is most generous in describing my answer indeed 😛

    The scripts needed to run my system with runit (void) are simpler and more compact than any sysvinit rc implementation I have encountered (save maybe the slackware one). The frontend files for 66 in my obarun installation are also compact, but it is a more complex system. I attempted to illustrate why a system supervision can be a good fit for a sysvinit replacement by going back to the history of this evolution, from a tool to supervise/cleanly restart/ reliably log daemons to an init system. I see it as a small evolutionary step for supervision suites, not as an terrible affront to the unix way ™.

    What do the supervision suited offer in a desktop is a nice question, but it misses the point -only slightly. The supervision suites offer… supervision. You may decide that is not needed in a desktop system (Ι disagree) but that is ok. What exactly is wrong if I have this additional feature while still having simple scripts to launch my system?

    In a cost-benefit analysis, what is the additional cost of having service supervision capabilities in my init system that outweights the benefit of these capabilities? Since I want them, why should I use sysvinit+runit and not just runit with runit-init for PID1?

     

  •  

    I love it!

    While that’s a valid point, it’s arguable that most of the criticism was from those with an agenda – i.e. to push their own implementation (systemd).

    Possibly true, but the importance is that the remaining criticism was constructive and complementing each system criticizing the other, not within an antagonism for which one should prevail “alone”. A prime example of this is the logs of the skarnet supervision and other lists, where there are advocates of various systems coexisting and cooperating, each defending his choices, but nobody advocates for systemd, nor is anyone wasting time to criticize it. It may be confirming your statistic, nobody there has a direct financial interest to portray one system as superior to another.

    My original comments were regarding the supposed need for a service supervision suite in a typical Linux distribution, which will probably not be run as a server and will most likely be just a hobbyist’s desktop.

    I respect this tendency but with a twist. A family, or a squat of comrades, or some other grouping of people under a common roof (a condominium building possibly), may have a need to run some network of resource sharing. If we were all running Void for example, and each one of us every day run an update and upgrade, the base system files and what we may have in common can be downloaded once in a common cache server. If 8 out of 10 use icepick browser, why download it from the other side of the univers 8 times? Getting the pkgs from the lan is in my experience 10s of times faster than getting them from the nearest mirror. It is also respectful of the mirror’s costs and bandwidth, and should be “unix” culture by now to do such things. Sharing and efficiency is something you “can” do with unix, I don’t think you can share such resources with MSw,MacOS,android. They want their puppets to be in direct connection to the mothership as isolated individuals. It is how authoritarianism works.

    This separates what we may call enterprise and “home” computing by a hair line of sizes. You can have one machine, dedicated to the risks of being exposed to hacking dangers, running torrents through tor, and up/down-loading movies, music, books, etc. Then pass them to a file server for the “commune”, or design office, or whatever you call your living arrangement. … and you will say, for decades mega servers run with sysV scripts without a reboot … and nobody was really sure that after years of change would that server boot if it needed its kernel changed to accommodate this new hw that was incompatible with the old. I think we can agree to disagree on some of the tangents and details without elaborating too much.


    So while it’s nice to say “I’m running some kewl new init on my hobby Linux box”, that’s about all you can say about it. If you were instead running sysvinit, your boot time might be a bit slower, but what other tangible difference would that make to your desktop?

    What desktop? And what sacrifices must one do to run “a desktop” without systemd these days? This devuan, MX, void solution, of running everything by “systemd standards and tools”, by imitating there is a systemd present, just so there is a fancy DM to log into, instead of an ugly console telling you *** welsome to Obarun (or xxxBSD for that matter) *** and only subtracting the “init utility” out of it, to me is part of the systemd problem. Obviously “many” don’t see it that way, and even come from a supervision-suite point of view to tell you “elogind” is pretty good at what it does, and dbus is wonderful, and using systemd-libs is not really the same as running systemd.

    There was some time, years ago, on a debian-users list, that a “professional” doing this for a living, had run into this “odd case” where this service log was filling up his server’s partition, and the hard to read journal, did not reflect much meaningful information. The log was getting huge, because a normal operation of the daemon would log all the login/logout of the service’s functionality. I think it was in the class of 10 identical entries per second. The responses were the usual “Germanic hypocrisy” reproduced by the puppets. It is a feature, a security feature and you should be thankful that this good system is logging all this. Another was, “it is your fault, you should have configured journal-d to cut the excess of the log beyond a certain size”. Nobody saw a fault with the way the service run. Nobody saw it as problematic to have a log of a single service being dumped to trash 295 times a day because of its size. But dare use this example to criticize the madness you were witnessing, you would be branded a troll and be banned from the list.

    Between polkit(s), logind, dbus(a whole fleet of them), controlling and monitoring this “modern desktop”, one may get to the point to say, wasn’t Windows7 or NT a bit more efficient?

    So, it is not a simple thing to say, run a desktop with sysvinit, what more do I need? Just yesterday vte3 had to be repackaged because it required systemd. Do you have vte3 on FreeBSD? Are you going to butcher the “dev’s” recommendation for this dependency? As someone who packages things like this explained to me, it is not a running dependency, it is a make dependency. Are you getting chills down your back yet? What if it was a real dependency, would you simulate systemd in FreeBSD just so you can build a terminal program? Why does it build without it? You tell me. It may be preparing you for the future to be aware that you will not be able to build the package without it. A terminal tool!


    I made no such recommendation. I make a point of specifically not recommending anything software-wise to anyone. As I’ve said many time, I use what works for me, I don’t get involved in advocacy. Linux users trying out BSDs is almost always a waste of time and effort. Linux users have preconceived ideas and just want those affirmed.

    Maybe I used the wrong term, but in a way, after I had expressed little interest for it in the past, I went back and tried it because you spoke so highly of it. If you find someone that convinces you he really knows about beer, and at the end of a technical discussion of what separates real beer from the crap mega-corporations sell as beer, he says, I only drink Joe’s homebrew because I know he makes it right …… YOU GO AND DRINK THAT JOE’S BREW, at Joe’s Pub, right in the center of Joe’s village.

    It was actually good, but not enough to want to move to Joe’s village just yet, or ride the bike 3hrs to have the best.


    I have no trouble stating here that:I was easily able to run what I wanted to run on Debian 8 with systemd removed and sysvinit installed instead.

    I am sure that synaptic clicked at a menu and gparted did not start, right? Did sleep and suspend work out of your Gnome menu? 🙂


    The only vestige was libsystemd0 which even the Devuan people now finally admit was benign… they may have spent “years” chasing that one possibly out of purely ideological (“every… last… one!”) reasoning (or in trying to satiate an ideological user base), before realising that a) they couldn’t easily get rid of it and …

    So now they have systemd-libs ….. it is like Jack, wearing his dark navy bomber jacket, leaves, comes back with an orange jacket (turned inside out), and he is not Jack anymore….. and the colored girls sung Tuuuu TuuTuu …Tuu Tuu …

    Hey, I may not know much, but I know this. # /usr/bin/sshd -f /etc/ssh/sshd_config runs till it hits some kind of a glitch. Why does it need a service script? When I need it, I run it. When I don’t I kill it. Dhcpcd runs the same. Damned if I let dbus and logind run wild on their own. What happens when some of those things don’t run, how do I find out why they stopped. I am not an enterprise, I am a home user. I am trying to print something in the bedroom while sitting in the dining room and there is no printer connected. If something is going wrong, what does my service supervisor do? Restart? Every 10s? For ever, it restarts a problematic service in a problematic state? What does the log say that will help figure out the problem? When is that supervision system going to stop trying to run something dead? 3 years have passed and every morning she gets up at 7 to kick her dead husband to wake up and go to work … even though he is not there. How is this home system dealing with this pathology? I know when everything runs fine more complicated tools are needed. In the age of Ipv6 and infinite UUIDs, and changing interface names, and audio visual hw/sw running like a mysterious neural network of inputs/outputs and gibberish in between, we need something more than systemV type of scripting. Remember token-ring networks and how wasteful and insecure ethernet appeared at first?

    Why does what we are talking about here remind me of this:

     

  •  

    I am taking a leap here. I must admit I stumbled onto this website by accident, yay lucky me, whilst searching for answers why obmenu still relies on a python2 build. However looking into this specific ConsoleKit2 topic, because of the implementation of elogind, and the drop of the packge in favor of said implementation got me thinking. If everyone is so bent on using ConsoleKit2 in the first place, why aren’t there any viable substitutions for it?

    I never gave ConsoleKit much thought as I am using my computer solely for my own personal use. Thus I had to do some quick reading on the topic. Correct me if I’m wrong, please do so. But as it seems it is a solely a necessity for gnome and KDE users.

    If one where to use gnome or KDE for that matter (I never liked what they did when they switched up to gnome 3), why use it on a slim running system like Void. They are so bloated and rely to heavily on other dependencies to make them a viable option. But I think that underlines your point even further.

    Hell, before fiddling around with openbox I even gave xfce a shot. But 5 min in, it had my fans spinning so hard that I removed it straight away. Knowing that configuring it to suit my power management would be an undertaking I would not be looking forward to.

    Ok, I’m drifting. Back to topic.

    Taking into consideration the overall hatred toward systemd in the linux world, why hasn’t anyone come up with an alternative? Or if, like you mention, Void must implement heavy weight DEs like gnome or KDE, don’t they actually think of an alternative implementation. Void is after all being mentioned as a viable crossover between Linux and BSD. Seeing that the Package is still beeing maintained under xxxBSD, ever since it was discontinued back in ’17.
    I just started out with Void as an alternative Linux distro that does not rely on systemd, more out of necessity I might add than out of reason. Personally I would rather stick with FreeBSD. And reading through your WAT and the discussion on the official Void Forum (cough), I now think that I am preferably better off in switching back all together.

    Btw. the joke of a Forum they have linked on their Homepage was actually an early warning sign to dislike this distro, even though it looked promising out of the box. This and the fact that the “documentation” is glib at best. Not to mention lacking in substance, if not entirely copied from the Arch Linux Wiki. In retrospect that was the second warning sign.

    On a different note. Great site!

     

  •  

    With the little I know, I don’t know of an alternative to consolekit and elogind. I know that if I got next to unlimited funding to create a tool that would be sold as essential, and have the marketing resources to shove down the throats of devs to use it in their distros, before you know it the team I have hired is producing a really complex and useful tool. In this case it is a tool nobody really missed before its existence, but since it is here (open and free) they keep on using it. To have an alternative to this you must have an equal or better team to create a tool that it is equal or better. Those are hard to come by in the volunteering individual coders’ world. So I can understand if there were no alternatives. Now picture that both the first new tool and the second were funded from the same source and it was an order to kill the first and remake the new, but incorporate it in a set of even more tools.

    The question remains. In exchange for your soul, do you really need such a tool? Can you sell cars without A/C and remote power locks? If you rely directly on your buyers to support you for keep making cars you will not think too much about the choice. I think the dilemma is similar in nature. The strange thing is that Void, yet, has no way to send a donation because you like it so much. Maybe they don’t need to …. because ….! So why are they making the choices they are? Like we kept wondering about RH, eventually we will find out. Sometimes when things don’t all add up … there is a perfectly logical explanation that hasn’t yet been considered.

    So, welcome, and what do you think? Are we past the center of the mine-field or are we just entering it? Personally I had gotten this gut intuitive feeling before in Devuan, one that signaled abort, abort, eject, eject!

     

  •  

    Hello again mobinmob,

    “I would really like a link to that debate if it is in a public forum.”

    So would I – sadly that forum is no more (only recently as well). It was a debate purely about one being “bigger” than the other. I easily proved via comparisons of the installed code that sysvinit was considerably smaller and the other party had to concede. As with the individual who needlessly raised that debate – you can verify this for yourself.

    “Not all upstream projects provided sysvinit scripts and they differed between distributions. The fact that they are provided to the “end user” as packages does not mean much. They still have to be written and maintained. They are still code needed to run. So yes, I consider them “more” code”

    In general, if you were writing code which was intended to run as a daemon, you provided the init script as part of the source – this is because in order to test, maintain and develop the software, then developer would have written an init script, particularly if the software was supposed to run as a daemon.

    “BSDs just have fewer devs and are very conservative because they cannot justify a change if it cannot be maintained by their current developers and/or funding.”

    True in a sense, but the blanket term “BSDs” does not apply as you might think it does. Most of the BSDs certainly do innovate, in those areas which they are focused on, but change for the sake of change is usually not the focus of any project which isn’t corporate backed/funded.

    “That attitude creates very stable and well-engineered systems. It also creates systems that cannot progress very fast if someone does not take up the specific task.”

    The same goes for any project – if people don’t do the work, there is no progress.

    “How do I know that? Because of package managers. Ι spend almost 10 years listening the most inane arguments from my friends that used the BSDs about how their method of using ports and hackish scripts were more stable and generally better than apt. It took (mainly) the efforts of three men to change the situation and suddenly the same friends sung the praises of pkgng and pkgin.”

    Here I’m afraid you’ve set up some strawmen and thrown in some anecdotes and it doesn’t hold water. There are no “hackish” scripts and pkgin and pkgng are the efforts of two different projects.

    pkgin is part of NetBSD’s pkgsrc framework, it’s mainly only used by NetBSD as a means to install binary packages. I don’t really see how some fanbois extolling the virtues of ports and then switching to pkgin, really helps your argument nor illustrates whatever it is you’re trying to illustrate here?

    pkgng is an attempt by FreeBSD to adopt a Linux style package manager. Once again, it’s existence is not some evidence of double standards – it’s one BSD project which have chosen that route over the traditional package tools.

    “It is the same situation with initsystems IMHO. They are developers that know they need more than the traditional init scripts.”

    And IX are also irrelevant to the debate – they are a business and I have no doubt that they will abandon FreeBSD if it suits their commercial interests. Sadly, with FreeBSD it at times seems like IX is the tail wagging the FreeBSD dog, but there’s also Sony, etc. FreeBSD is far from being detatched from the corporate world, even if it’s not so entangled as Linux.

    “Openbsd went ahead and created rc.d [1], a minimalist rc-system with the features they need.”

    True but they did not implement service supervision. rc.d(8) deals with package daemons. You may have misunderstood it’s purpose, I suggest the man page.

    “They [OpenBSD] were also the first to update their packaging tools.”

    This seems ambiguous? Update their packaging tools to what exactly?

    OpenBSD still uses the “legacy” pkg_add(1), pkg_create(1), pkg_delete(1), pkg_info(1), package(5), pkg_check(8) tools, which were ported from FreeBSD (as was the ports system historically) and has not developed nor adopted any newer package manager.

    “FreeBSD tried and failed to port and adopt launchd at the behest of iXsystems [2] and TrueBSD[sic] tried Openrc. They seem to have also considered nosh.”

    IX or TrueOS can indeed try to adopt or develop whatever they like, I’m not entirely sure as to their relevance here? I use neither of them and have no interest in using them. They are a commercial entity who sell products and services.

    “So some people are searching for a better solution, that is not just expanding the current init.”

    Well we can certainly conclude that “some people” may want something else yes, which they may believe to be “better”, but that doesn’t really mean much. Supervision suites are available in ports for FreeBSD and others, but there seems to very little appetite for it.

    If you search the OpenBSD -misc mailing list, for example, you will find probably only a handful of comments about runit. Most recent I found is one thread from 2 years ago, which had zero replies. Nosh also gets a mention in one posting, 3 years ago. For s6 I wasn’t able to find anything at all. Same for OpenRC, same for daemontools – this does not smack of users and developers crying out for service supervision…

    You may, or may not, be interested in the take on “service supervision” from the project leader:

    https://marc.info/?l=openbsd-misc&m=150786234512529&w=2

    (but either way it’s worth consideration as it may explain why it’s “off the table” there – not to say that someone won’t decide to an s6 port and that it might become popular, but in terms of the base system it appears to be a no go at this moment in time)

    Full disclosure: I personally agree on every point – in that running crap, which crashes and just setting up a supervisor to watch it and restart it, is a s***** way of doing things. If that’s what some want – there are options for that. But if I were employed by big corporation xyz and had to ensure that their buggy crap would keep running with minimal downtime – it would be a “solution” for me and I’d doubtless use it there to get myself out of a hole.

    “I believe that supervision suites are a solution.”

    That’s rather open and vague – they may indeed be a “solution” to where service supervision is a specific requirement (see above).

    “It is also the attitude that prevented the adoption of runit/cinit/minit/ninit before systemd and led us indirectly to it.”

    This is yet another leap of logic – and again you’ve provided an example of the kind of thing I’ve been referring to – (1) the myth that those who were supposedly doing nothing, opposed to adopting “new” for the sake of it, supposedly facilitated the rise of systemd and those poor old systemd developers had to do the work because no one else would – I very much disagree. systemd rose through insidious “marketing” and by pushing itself as a dependency and “solution” into a lot of notable mainstream projects (also corporate backed) and (2) that adopting any of those alternatives to sysvinit would have changed the current systemd situation, considering they are “service supervision” suites and systemd is much more… systemd had the gnome entanglement in particular – the same cannot be said for any of those – it’s a flawed comparison, just as it’s flawed to tout those as replacement for sysvinit or systemd – they are all in different categories.

    “An appeal to tradition is as useless as an appeal to novelty.”

    If we’re really going to get into “appeals to …” I can spend time cherry picking from the above and come up with many examples – I won’t. I have not even appealed to tradition, but anyway…

    “Is runit somehow not stable and well tested? Is s6?”

    Again – that was not my argument.

    “Sw is not whiskey to be matured. It is a tool to solve a problem.”

    We can all make attempts at being patronising – I will refrain. By “matured”, I mean that once something is well tested, well known and has been used for years and is widely understood, one can consider it “mature” or “tried and tested” if you prefer. In some absurd scenario – if you were in charge of a data centre and your neck was on the line and you had the choice between s6/runit/OpenRC/one of the many other inits and systemd or sysvinit with a support package and being “industry tried and tested”, you’re going to go for the latter, whether you like them or not, unless you’re utterly, utterly reckless enough to put personal preference first and don’t feel like working or earning a living anymore…

    “Runit and s6 have not succumbed in the race for more features outside their scope.”

    This may be true, but it’s not even in debate here.

    Init system vs init system is not in debate and never was. What was in debate was essentially “does average hobby distro desktop user need “service supervision” – as yet unanswered.

    If the question were rephrases as: “does average hobby distro desktop user need “service supervision” because certain software is s***”, that would have a different answer…

     

  •  

    I don’t want to wedge myself in, but I think this is turning from a debate to a which is bigger/better/faster, mine or yours.

    Yes, the basic question is that if the majority of users are single pc personal computing desktop users, do they need a supervision suite to complement their init and simple starting/restarting services? One side sounds to be defending some BSD choice, if they didn’t need it it must not be needed, the other side says anyone can benefit from the existence of it. Whether xBSD tried runit and disliked it, but didn’t try daemontools and the rest of its children doesn’t constitute a logical argument that “all supervision suites are unnecessary”. On the other hand I can see that automobile argument, if not everyone needs A/C why should people in Alaska have to buy a car with A/C.

    I was thinking of proposing of collecting all this pieces of the arguments and combine them into an article with the title that very question. I don’t see the progress of this debate in assisting such a document. As a good manager I evaluate productivity by the end product. Maybe the end product is this set of comments alone, not much more can come out of it.

    Why fix it if it ain’t broke, is not a scientific approach, especially when we speak of progress and maturity. The good thing about open-free software is someone can adopt the FreeBSD infrastructure, throw the garbage init away (just kidding) and use s6/66 on it and demonstrate how superior it is for a casual user and of course the enterprise sys-admin. I am surprised if someone hasn’t tried. Time and material resources can be a good excuse, and many wise people are lacking both, while mediocre people seem to have both in abundance (Manjaro for example).

    The recent antiX runit edition (beta) shows that there can be interest in something more than traditional debian-esque conservativism. Investing time in learning the complexity of s6 is a step further into untested territory, where runit appears to be stale stable and common, by comparison.

    Peace

     

  •  

    “Just yesterday vte3 had to be repackaged because it required systemd. Do you have vte3 on FreeBSD? Are you going to butcher the “dev’s” recommendation for this dependency?”

    It seems to be in ports, I have no need for it. xterm(1) is what I’ve used for years and I’ve no need for bloated monstrosities. vte is a gnome thing as a recall so the systemd dependence isn’t surprising.

    “Hey, I may not know much, but I know this. # /usr/bin/sshd -f /etc/ssh/sshd_config runs till it hits some kind of a glitch. Why does it need a service script?”

    If the box you ssh into is remote, then it’s useful. If not then you probably don’t need to start sshd at boot. I don’t know how it works in your OS, but in mine it’s configured to start, or not, in rc.conf.local.

     

  •  

    “Here I’m afraid you’ve set up some strawmen and thrown in some anecdotes and it doesn’t hold water. There are no “hackish” scripts and pkgin and pkgng are the efforts of two different projects.”

    Every single one of the (major) BSDs have modernised their binary package manager, roughly 10 years after apt. I am pretty well aware of how and when that happened. (Yes, that is anecdotal 😛 ).

    They have been some more or less hackish scripts before pkgin and pkgng that served as package manager, both public and private. I am pretty skeptical of anyone that uses any BSD, tries to inform me about it and does not know of them.

    Yes I know pkgin and pkgng are different (they actually share some history, bapt@ tried to build on imil@ ‘s work for some time but started pkgng from scratch).
    “OpenBSD still uses the “legacy” pkg_add(1), pkg_create(1), pkg_delete(1), pkg_info(1), package(5), pkg_check(8) tools, which were ported from FreeBSD (as was the ports system historically) and has not developed nor adopted any newer package manager.”

    You are extremely misinformed. Openbsd (espie@ primarily) has rewritten the tools in perl from scratch. They added a lot of features in the process and did some privsev work, which is pretty impressive in that context. They have quite nice presentations on their papers section in openbsd.org.

    “True but they did not implement service supervision. rc.d(8) deals with package daemons. You may have misunderstood it’s purpose, I suggest the man page.”

    No and I never said it implemented service supervision – I offered it as an example that extends what init does in a different and pretty interesting way.

    It deals with all daemons, even the ones in src, you should really read the paper.

    https://github.com/openbsd/src/blob/master/etc/rc.d/amd
    “Full disclosure: I personally agree on every point – in that running crap, which crashes and just setting up a supervisor to watch it and restart it, is a s***** way of doing things. If that’s what some want – there are options for that. But if I were employed by big corporation xyz and had to ensure that their buggy crap would keep running with minimal downtime – it would be a “solution” for me and I’d doubtless use it there to get myself out of a hole.”

    A supervisor does not just babysit a process. The link from the runit site provides information for the basics. In a perfect world, I will not mess with supervision. But daemons do crash and I do need to log their output and to restart them in a clean manner (among other things).

    ““An appeal to tradition is as useless as an appeal to novelty.”

    If we’re really going to get into “appeals to …” I can spend time cherry picking from the above and come up with many examples – I won’t. I have not even appealed to tradition, but anyway…

    ““Is runit somehow not stable and well tested? Is s6?”

    Again – that was not my argument.”

    Yet you choose to distinguish the existing solution as stable, well tested and matured as opposed perhaps to the proposed ones. If they are indeed well-tested and stable (and they are…) then the argument is one of age, maturity and… indeed tradition.

    “Sw is not whiskey to be matured. It is a tool to solve a problem.”

    “We can all make attempts at being patronising – I will refrain. ”

    (…)

    WOW…
    “By “matured”, I mean that once something is well tested, well known and has been used for years and is widely understood, one can consider it “mature” or “tried and tested” if you prefer. In some absurd scenario – if you were in charge of a data centre and your neck was on the line and you had the choice between s6/runit/OpenRC/one of the many other inits and systemd or sysvinit with a support package and being “industry tried and tested”, you’re going to go for the latter, whether you like them or not, unless you’re utterly, utterly reckless enough to put personal preference first and don’t feel like working or earning a living anymore…”

    I will choose runit on top of the existing init system to run daemons any day. You almost always you are bound to the init the supported distibution has, you are absolutely correct. That is not however a measure of its abilities or stability. It just is there and you have to use it for system start. I have proposed the solution for servers and even wrote/offered the config/run script to others in one case (yes, I know anecdotal – it was runit on top of upstart in ubuntu LTS). I hope one day I will be able to give the same recommendation for s6-rc.

    “What was in debate was essentially “does average hobby distro desktop user need “service supervision” – as yet unanswered.”

    Our host has offered examples outside the enterprise. Are they not valid? Does voidlinux does a disservice to its deskop users by using runit and not another init?

    “If the question were rephrases as: “does average hobby distro desktop user need “service supervision” because certain software is s***”, that would have a different answer…”

    We all live in the real world. Sw fails, hw fails, network problems do exist. You may not think they affect the average desktop user. I disagree. I think the desktop user can use the same assurances a server admin does for the services running on their machine. If that can be implemented in a simple, well engineered way, sign me up! Or don ‘t… I am already using voidlinux and obarun.

     

  •  

    “I don’t want to wedge myself in, but I think this is turning from a debate to a which is bigger/better/faster, mine or yours.”

    These debates invariably do. I have said all I need to say and I feel that my position is unchanged, so will happily bow out at this stage and leave it to others to chime in as they see fit.

     

  •  

    mobinmob,

    I hope your 5 minutes of research on OpenBSD’s package management, was suitably enlightening? (Perhaps you even read the man pages.)

    The “complete rewrite” (in perl) by Marc Espie, while indeed a rewrite, was not a drastic change in functionality, privsep also does not change functionality (as with pledge or unveil). It was a rewrite of a simple tool which needed to preserve the same functionality. If you’d ever used pkgng, I’m sure you can appreciate that the two are worlds apart.

    OpenBSD’s pkg_* tools are not an “apt style” package manager implementation, as with pkgng, so I feel that your insistence on winning and proving me wrong, is overtaking and overshadowing any useful debate or discussion here – you’ve not really gained much ground in my eyes, though you may feel you have. Defining the differences between Jordan Hubbard’s supposedly “hacky scripts” (which still exist (barely) in NetBSD alongside pkgsrc) and the perl scripts now used in OpenBSD’s pkg_* tools just doesn’t seem like a worthwhile discussion – as far as tangents go, this is about as bad as it gets.

    Hence my previously post signalling my desire to leave you all to it.

    Thanks you and good night.

     

  •  

    I hope your 5 minutes of research on OpenBSD’s package management, was suitably enlightening? (Perhaps you even read the man pages.)

    Are you out of line? Is this necessary?

    I asked you specifically if after downloading https://web.obarun.org/index.php?id=74 JWM iso, did you spend 5′ to see how unnecessary all this is for the desktop user?

    /usr/lib/66/service contains all the service scripts utilized for the live image. The observice repository contains what is also available. dhcpcd-66serv requires dhcpcd but not the other way around. You can boot and just set the tty of preference then start services anyway you like, 66 will not set anything under supervision by force. Go around and kill processes, services, daemons, anything you like, and tell me whether you loose access to the tty12 that requires user and pw to get in. Not like some others that hand you the system in with root rw privileges when they fall on their faces.

    Tell me what the state of the system is and whether a reboot is required.

    It is equally secure, stable, and useful for someone only browsing facebook or someone managing 30 servers that run at 93% capacity most of the day. If you are a sysadmin and it is Saturday night, you don’t have to go physically back to work to reset a crumbled network, you can do it from home, when you know that the system is still there …

  •  

    cynwolf,

    “I hope your 5 minutes of research on OpenBSD’s package management, was suitably enlightening? (Perhaps you even read the man pages.)”

    I am aware of the rewrite for close to ten years and have used openbsd with this, it is pretty nice. That is also anecdotal of course and perhaps not worthy of your time.

    “OpenBSD’s pkg_* tools are not an “apt style” package manager implementation, as with pkgng, so I feel that your insistence on winning and proving me wrong, is overtaking and overshadowing any useful debate or discussion here – you’ve not really gained much ground in my eyes, though you may feel you have. Defining the differences between Jordan Hubbard’s supposedly “hacky scripts” (which still exist (barely) in NetBSD alongside pkgsrc) and the perl scripts now used in OpenBSD’s pkg_* tools just doesn’t seem like a worthwhile discussion – as far as tangents go, this is about as bad as it gets.”

    It is a pity really you feel the need to respond in such a manner. I tried only to inform about the systems I used and the advantages I believe they have over the preexisting solutions as well as the reasons BSDs have not changed their init systems. I do not seek to win internet points, but to inform about what I use and find valuable. English is a foreign language for me so I might have come across as harsh, ironic or insulting. That was absolutely not my intention. “Hacky scripts” were not about Jordan Hubbard code, but helper tools developed by FreeBSD users to complement them.

    Yes, pkg_* tools in BSD is a really distinct concept if the default are linux package managers, that is true. It has its quirks (pun intended 😛 ) and I find it interesting. But I cannot help by disagree that the rewrite is not a “drastic change in functionality”. Yes, privsep does not change funtionality – it is however pretty novel in the context of a low-level package manager.

     

 

  •  

    “It is a pity really you feel the need to respond in such a manner.”

    How about this “manner”? :

    “An appeal to tradition is as useless as an appeal to novelty.”

    “Sw is not whiskey to be matured.”

    “You are extremely misinformed.”

    “WOW…”

    etc

    I can see where it deteriorated, it’s “a pity” that you can’t. I can also see that your grasp of english is good enough to deliver such “passive/aggressive” put downs – I wasn’t born yesterday.

    If you don’t like the ‘BSDs – I couldn’t care less. If you believe I’m a fanboi here touting the ‘BSDs – I couldn’t care less. If your little mission is to prove you know more about an OS which I use as I my main OS, then I also couldn’t care less. If your friends used ‘BSDs and extolled the virtues of ports and then switched to pkgng and then raved about that – I also couldn’t care less. It still doesn’t relate to the comment I made about why service supervision is needed for hobbyist Linux desktop users. Thus far the reader could well come to the conclusion that fungus and yourself just “like” it, out of a personal preference, but that’s about all. There’s nothing wrong with a personal preference, so long as it doesn’t involve sneering at others choices – a la systemd devs.

    As to “hackish scripts”, there are/were the pkg_* scripts previously mentioned, written in perl and their binary predecessors originating from FreeBSD. I’m not sure which others you’re referring to (the various ports management tools perhaps?), but my memory is failing – plus I still don’t see this argument of yours which seems to amount to “all of the BSDs reinvented their package management tools [to ape apt / Linux]” has any relevance to service supervision. I also disagree with your claims that because of IX and a few efforts by FreeBSD that all ‘BSDs are seemingly looking at changing their init systems.

    You’re cherry picking some examples and then through a few leaps and bounds of logic posting up the hastily made conclusions.

    privsep does not equate to reinventing your package manager “apt” style any more than a privsep of X equates to reimplementing/rewriting X from scratch. So the fact that an OpenBSD dev had a look at the pkg_* tools (around 15 or 16 years ago) and tidied up some code and rewrote them in perl doesn’t mean a lot except that someone saw the need to clean up the code and move away from a binary format… and to *gasp” hackish scripts.

    I really have nothing more to add. I did not come here seeking conflict or hostile interaction – I’m too old for that and have seen more than enough of it on various s*** hole FOSS forums over the years so I will make my exit now. There are no hard feelings from me – never were, but ‘this’ is not something I want to spend any more of my time participating in.

     

  •  

    “An appeal to tradition is as useless as an appeal to novelty.”

    “Sw is not whiskey to be matured.”

    “You are extremely misinformed.”

    “WOW…”

    I can justify all of the above as I have already done for the first two.

    If you think these are attacks that merit the response you gave, I suggest you go back and reread your previous answers. Just give it some time to cool off…
    “Thus far the reader could well come to the conclusion that fungus and yourself just “like” it, out of a personal preference, but that’s about all. There’s nothing wrong with a personal preference, so long as it doesn’t involve sneering at others choices – a la systemd devs.”

    Having multiple well-written init systems and service managers is extremely valuable. I have not pushed for any specific solution in the thread above, I just know pretty well the two I am referring to (runit and 66) and their underlying paradigm. Monoculture in the space will offer nothing and can bring disaster.

    Our host has offered cases in which service supervision is valuable and even gave a call to test the validity of an implementation.

    I tried (maybe not convincingly enough) to give the history of using a supervision suite as an init system in order to explain the evolution and reason of the transformation. The article of Paul Jarc and the relevant material in skarnet is much better than anything I can offer in blog comments and written by people that know much, much more than me. I linked to what runit is trying to offer as an init-system/service manager combo and repeated what runit claims in the following messages when I got the usual answers. I think the cases that fungal referred to and what runit does make them valuable. You disagree. That is perfectly fine 😉

    Comparing the answers to what systemd devs do (repeatedly) and doing that in a forum dedicated to promoting and advocating a plethora of alternative solutions is a bit rich.

    Software we choose, trust, and use is of course personal preference to some degree. That is if we can make the choice. I think I was pretty clear in my answer to the hypothetical datacenter situation.

     

10 thoughts on “5 Does the “typical linux user” have anything to gain over traditional scripts?

  1. It was corrected and explained, a-formalist or non-formalist or rather anti-formalist, is he who avoids or is even against formal organizational structures. One that believes that a group of friends, buddies, with loose organizational structure can accomplish the objectives, set goals and define means, “collectively”, without rules, principles, values, and defined processes.

    When you find a group of people you know and they know you, and you say let’s go and pick apples from the orchard and move them into the barn, an inquiring mind may ask: Why? Someone else may ask: Who, and with who? A third arrogant and aggravating person will ask” How? The a-formalist will get really irritated and curse them out for asking. The formalist will propose they have a meeting. In that meeting they come into an agreement about Why, who and with who, and How. Those are the first founding branches of organization. A formalist will insist this step is essential to the object of gathering apples into the barn, an a-formalist will refuse, and will urge others to avoid any organization, and whoever wants “can follow him in picking apples”. This leads into an authoritarian relationship where one does and others follow.

    Anyhow, Enrico Malatesta goes into detail how formal organization is essential and how the values and principles agreed upon in advance are more essential than the object itself, how the means and the object must be from within the same values and principles and how NOT “all means are justified by the object” as some others have advocated for (Lenin Machiavelli, etc.)

    Furthermore, and I am glad you asked, this is as good of a justification in favor of formalism against any a-formalism:

    ” No revolution can ever succeed as a factor of liberation unless the MEANS used to further it be identical in spirit and tendency with the PURPOSES to be achieved. Revolution is the negation of the existing, a violent protest against man’s inhumanity to man with all the thousand and one slaveries it involves. It is the destroyer of dominant values upon which a complex system of injustice, oppression, and wrong has been built up by ignorance and brutality. It is the herald of NEW VALUES, ushering in a transformation of the basic relations of man to man, and of man to society.” Red Emma Goldman

    Without specific formal processes of organization neither the means, or the purposes, or the values and principles can be discussed and agreed upon, so everything deteriorates to those leading decide without the rest having a say in it.

    Like

  2. I had forgotten this. Amazed that you’ve dug it up. But as you’ve said – you need the traffic, so go ahead. I don’t see the problem with the “debate” however. Nor do I see where others were somehow excluded from making comment. Certainly not by me.

    From my perpsective its very much you who exludes others, because this site is your own personal echo chamber. You did not “moderate” the other participant simply because you happened to agree with his position on service supervision suites.

    Like

  3. But as you’ve said – you need the traffic, so go ahead.

    Where has this blog mentioned that traffic is needed? In most respects people would criticize this site as being most offensive to your “average linux traffic”.

    From my perpsective its very much you who excludes others, because this site is your own personal echo chamber.

    Not only have I not moderated you or anyone else, as long content relates to the vast spectrum of topics in this blog, you should be the least likely person to accuse the site of this as for nearly a year you were invited to contribute as an editor. All such invitations have now been removed, but since day one this blog has been about “proposing new topics or sending material to be published” simply by clicking the “add a new topic” link on the top menu.

    You did not “moderate” the other participant simply because you happened to agree with his position on service supervision suites.

    I did not moderate either one of you, which maybe was a mistake. On an unrelated subject both of you started a discussion about scripts and supervision suites. Any effort from my side to participate was ignored and you both continued your little dialog. It is YOU BOTH that excluded others from the conversation, not me. In my understanding, when in public, discussing a topic, it is very arrogant and offensive to convert the discussion to a private dialog. It is a libertarian culture that authoritarian hierarchic upbringing of people prevents them from understanding.

    I think my comments and review of Spark Linux and sinit/ssm is an invalidation to what you are claiming here. I may admire s6 for its potential for complex systems, I may applaud 66 for making s6 usable by common users, but if my daily work can be accomplished without problems with sinit/ssm (as in Spark) the hell with all those complex systems, like sysvinit and OpenRC. Why wait for your lighter to boot and load services when you can just strike a match?

    I have resigned from being the coordinator here because I failed. I failed to manage or set rules for a debate about such a key issue as this one. From now on there will be rules when such a debate sparks and all participants should respect all other participants or they will be moderated.

    Fungalnet

    Like

  4. I have not noticed much of a difference between running AntiX with oure SysVinit or with SysVinit + openrc daemon control, especially not in ways of performance.

    Like

  5. @schillingklaus: There should not be a noticeable difference in performance after logging in. There should absolutely be noticeable difference in boot time if parallel boot is not enabled in openrc. Does artix use sysvinit or straight Openrc with the openrc-init program?

    Like

  6. Artix uses straight OpenRC, and so did its predecessors of Arch-OpenRC and Manjaro-OpenRC. Runit came 2nd as an alternative with very little modification from Void. On Devuan it was a blend. I am not aware of antix with OpenRC. The runit setup I think was a brief experiment that did not receive much follow up yet. It is a tough candidate to experiment with, debian doesn’t allow much room for playing around. Ever since that noisy vote on alternative inits nothing has really changed.

    Like

  7. AntiX, like plain Debian, has openrc-init and the corresponding shutdown, but it lacks the necessary support for terminal login (getty), which is provided in sysvinit by inittab; so I can’t switch to openrc as pid1, only run it as supervisor.

    Like

  8. I have been playing with runit these past few days, which I think is closer to Antix philosophy.
    I can boot it and I can make it run a few services, there is a need for debian specific runscripts, which will take some time.

    But I will also like to get rid of all of the sysv scripts that I can and have clean runit. Even though it is pid1 due to lack of scripts it is relying on sysv stuff. I would also like to work on the logger of the supervising. I am trying to take lessons from s6/66 and how it creates a supervision log for each service separately.

    It also helps having a void and an artix-runit installation close by for reference.

    Like

  9. The refracta man (fsmithred) a few years ago modified OpenRC and I believe he had it running as pid1. He had added a script for the switch when at the end of the installation/modification you issued he long command which rebooted with OpenRC. He had made some images back then, I can’t remember what site had them biblio or sourceforge, he had several sites with his stuff, I can’t figure out how he kept up with all of them. Somewhere on his sites he had a subdirectory that said experimental. Anything experimental I tried worked great, so it will not be a waste of your time. https://get.refracta.org/files/experimental/ moved here, I see a new OpenRC image. See how he did it, I can’t remember and it probably has been refined.

    On Arch wiki about OpenRC they have incorporated two totally different applications/methods. The 2nd one by artoo (artix chief of stuff – general secretary) did a pure approach. It worked with Arch and Manjaro for years before Artix was founded in 2017.

    I liked runit and s6 so much I never got into OpenRC much.

    Like

If your comment is considered off-topic a new topic will be created with your comment to continue a different discussion. This community is based on open and free communication, meaning we must all respect all in minimizing the exercise of freedom to disrupt such communication. Feel free to post what you think but keep in mind the subject matter discussed. It is just as easy to start a new topic as it is to dilute the content of an existing discussion.

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.