How can Void be best the one day malware the next?

How can someone here, defend Void’s honor from a tremendously sloppy and unjustified criticism by the corporate rag (as in the piece of cloth used to wipe genitals after corporations take a crap, and they do all the time, especially on May Day and when strikes and mass protests are taking place around their headquarters) “distrowatch” ….  and the very next day attack void as being the worst form of malware that has hit the open and free software world?

Basically we are not a “fan club”, defending anyone as being god, or hating someone as being the antigod.   Criticism, for those that understand the term within rational thinking, has to and must be objective, to the best reasonable effort (that is all we human can do).  Only then can there be a dialectical agreement about reality, our best interpretation of it.  Despite of how many of you here, feel like they are finding a home at this systemd hate club of hooligans, enjoying braking knee caps of their opponents.  No, it is all objective criticism at something that is gradually becoming a “social danger”.  It is the Trojan Horse (and damn the damn Greeks for inventing this strategy to defeat the peace-loving Thracians and take over their land and resources, which they did, that is not Homer’s mythology but a historic fact) that is used by mega corporations to swallow and end this industry of open and free software, running on non-open and non-free hardware in lack of an alternative, which should be a social goal.  In this respect open and free software is an industry from those below against the interests of those above, a miracle or a mistake by those that rule and dominate.

We feel that Void is precious as a social construct, as a platform for good things that can come out of it.  Better than many.  But there have been signs of slippage recently.  Developers and maintainers getting so much into the details of packages working and cohabitating harmoniously (the packages not the devs) that harsh choices had to be made.

… Void, for those that didn’t know, was one of the earliest test beds of systemd.  They loved the stuff when everyone else was looking down on it.  One day they realized that it didn’t fit their bill.  They wanted to embrace different architectures and platforms, like making a parallel distribution based on musl instead of glibc, and have the two be equally functional and effective in all hardware architectures they catered to.  Short story is that systemd will not run on anything other than glibc, and would take enormous work to make it work with anything else other than linux.  So this is as far as systemd can go; linux and glibc, a sub-sector of unix forks.  Openrc, s6, runit, and many others are much more portable, in a true unix fashion…..

So devs, seem to be forcing the needs of their individual packages as policy for the entire team, and since other team members don’t have the time or the patience to provide better suggestions, they just let others do as it is necessary.  As long as things don’t conflict each other everyone in Void does their thing and the cumulative effort is what we see outside.  Yet another miracle, that this tower is holding up and not collapsing.  So, who made after years valid live-images for people to install void, when the previous ones were pointing to false inexisting repositories?  Are those official images, are they a collective effort and signed as void?  Nobody knows.  They just appeared.

The other autistic tendency void had was to support the most popular desktops and applications out there.  Yes, even the crappiest of all, gnome and cinnamon.  (I am sorry, are you one of their users, tough shit, go away).  With all the good efforts and struggle to make them work, some beaten and exhausted from continuously struggling, gave up and discovered this easy way out, using a piece of systemd (a good chunk of it) but which is easily portable (has been by others, not void, specifically I believe it was Gentoo’s work) and stop fighting the monster (systemd – gnome – pulseaudio – freedesktop – IBM).  All those other desktops, DMs, window managers, if and when it is necessary (not very often) used consolekit2 to satisfy their happy gui clicking customers.  Systemd believes in multileveled management.  Between user and the essential core system responsible of booting and providing a console, there are several layers of management.  It takes a labyrinth system like elogind to monitor and control all actions between those levels.  It is a pain in the neck to even audit a single machine single user system, let alone an enterprise system comprised of several machines and numerous users.  But it works.  Even a dummy entry level sys-admin can set a system up.  You plug in at the one end and go to the other end and it is working.  What happens in between only IBM would know.  If you trust IBM to sleep with your partner you have nothing to worry about.

When such discussions come up, the most hypocritical of all devs and coders will bring up the issue of security.  Security, as in real life politics, forces an issue to be withdrawn from the public social sphere of being political in becoming a “military issue” where experts are called to make the decisions instead of the “non-expert” public.  So when you hear “security” being drawn into a conversation, it is 99% sure someone who is bringing it in is denying to discuss a political matter and wants to convert it into a closed chambers meeting of expert generals in charge of security.  So don’t readily buy into the security “issues” as an argument as it is a common scapegoat by authoritarians to divert an issue to be discussed by common mortals.

Hypocritical!  Why?  Because those same idiots claiming expertise on security, want the “average user” to have access better kept for those better than the average user, but the transition of this power elevation must be handled by high security systems.  The clueless, retarded as I was called in the above mentioned thread, where at least two void devs are anonymously taking part, would ask if it is a security issue why give anyone other than root access to resources restricted as being threatening to the system’s integrity?  Some other clueless person may also ask, if the user has to have access to such system modifying resources, why restrict them in the first place?  But it is the elevation process stupid, that becomes a security issue.  Yes, but you are creating this complicating sub-system to be doing this elevation, subject to even more chances of being breached.

See, how simple matters are if you are not a military expert?  Just type % su and your system’s password, and do as you please.  But you’d rather click on things and let them work automatically.  Well, yes, you are not really secure minded anyway, you rely on the great fathers of void to protect you.

Now wait a minute!  Are we talking about one person installing software in their own machine for their own use or are we talking about a sys-admin having this mega-system in this mega-network, allowing users to login and use the resources?  Two different stories.  On the first it makes no sense, if the user wants to be root he can because it is his machine and he is root and user after all.  On the second example, are you going to trust any guest in your system root privileges to screw up the system for everyone else?  Am I making sense?  We can get lost here for days discussing the details and the sub-specific examples of should and shouldn’t for each one, and that is exactly what a login-daemon does.  It may allow some to some resources, prevent some from some others, and the when and how.  It gets very militaristic trust me.  You shouldn’t browse the net, especially chatting and loging into news-sites and social media as root.  You shouldn’t be able to format and repartition a disk as user.  You shouldn’t turn hardware on and off for the entire system as user.  Another user in the lab may be conducting an experiment with radio-isotopes and you just turned their hardware off measuring radio-activity, or took the transmitter out of a radio station.

So how does void relate to all this?  I will not reproduce all those things discussed in the above thread, I’ll let you take some time to digest it, take my word and wipe void off of your disk as malware, or at least malicious software (is it different?) or take some reddit ab-users’ advise and keep on “void”ing and block this site as a source of malware.

Keep this in mind though.  Many, many, really serious distributions, have no evidence of elogind and have many functional desktops.  Many still use gksu as they don’t buy all this propaganda on security issues with it.  Many are still using consolekit2 (the evolution of the abandoned consolekit which was systemd-IBM’s employees work) swear it is good enough, and even some really fresh really promising distributions just starting now ALSO utilize consolekit2.  Not to be extreme, for those gnome lovers (I almost slipped and said rags again), I don’t have an issue if a distribution says let them have it, we will build it for them to make their lives easier.  But keep consolekit2 for those that don’t want to use it.

THE WAY to go about removing software from a distribution, SHOULD (and here I accept discussion for which Void denies having any) first make a serious effort to alert users of dropping support, then remove it all together from their dependencies to it, then remove it from the repository, then remove it from the source repository showing how they built the thing they passed around.  What does void do?  Quitely, one piece at a time, cut the dependencies off.  Then had some little chat and comments on github, not really reflecting a “collective decision to”, just indicating that they MAY in the future, THEN ONE DAY, remove the source.  The binary still stands, has a dependency on the corresponding polkit, which now has a dependency on libelogind.  But tomorrow it may be removed all together.  For now, it is a binary blob, without any source to show what it is and how it was built.  You just have a size of a blob, and a name on it.  This is really slipping into unofficial microsoft off the torrent-land binaries with the name of popular games and applications territory.  It has never happened before in the unix world.  I had heard of the case of Kodachi not having sources, and it was reasonable to an extent, but Kodachi was just using debian repositories and scripts that you could read directly before you run them, I think they made a public source repository for their scripts to satisfy criticism from competition (tails, heads, kali, parrot, etc.) but this is the only case I had heard before.  Someone calling themselves open and free and offering binary blobs without a source, Void has broken the record for being irresponsible.

What else is there?  There is more.  There is recent history and several packages, that were removed by void from users’ installed system without their consent.  How?  Let’s say you take this package from upstream called gksu.  Let’s not start an irrelevant tangent here as well as whether gksu or consolekit are good pieces of software or not, this is not the issue.  You place the upstream source, you modify it and package it, you build it in your super-dooper-server void owns, and flood the users machines with this blob.  Then one day you make this package with the same name, leave it blank inside but have all the characteristics of a xbps package, signature and checksums for this piece of hot air, and name it after the original creator’s name, gksu-3,3-3, replacing gksu-3.3-2.  Not alert the user who didn’t pay attention of the size differential (do you, out of 20 upgraded packages becoming larger and smaller, do you pay attention to the differential size?) and effectively delete data (the original gksu) from your disk.  Then you click on this shortcut or hot-key you have for gksu nano /etc/hostname and it is not working.  Aaahhh… you should have been on irc 24/7 and have read comments elsewhere on github mentioning the removal of gksu, not on void’s github /gksu section (that has now vanished) but elsewhere …  and you would know about it.  You are responsible to know what different devs chat about somewhere.   None of those devs speak as they are void themselves, unless you are part of the little buddy group, you don’t know which one has rights to push software, who is just a contributor suggesting a patch, who is the “leader”, and who are the “lead”.  Nobody ever comes out and speaks as “Void”, except for the News section on the website, who shall remain nameless as well.

For years nobody knew that the “official void forum” listed on their own website was not held by them, but by some user who donated the amount to keep it running.  When other users declined his blackmail to have money sent to him to keep it up, he took this entire void resource and vanished.  All those discussions and historic documents displaying how void evolved, vanished.  Then the founder vanished.  Then the founder is back.  Then …

You get the picture, if I have the wrong one please tell me.  It is a madhouse and a babel tower about to collapse if some formal organization effort doesn’t hold it together.  I see clear signs of it.  I have also seen real outspoken devs, especially the one I had a serious argument on his fascism months ago about gksu, also vanish.  Where did they go?  Why?  None of our business.

 

WHEN you issue binary blobs without a source IT IS OUR BUSINESS VOIDers!

WHEN you fake popular software with their name and send out bubbles of emptiness replacing REAL AND FUNCTIONAL software out of my disk , It is my business.  You can’t use the name linux-5.5 and put nothing in the package just so you can delete linux-5.4 out of my disk.  What is on my disk is mine.  You are deceiving me of an improvement just so you can have your way on my disk.

How thick can those babel inhabitants be to think they are mini-gods doing any punk like act and getting away with it solely on fame and glory?

ENOUGH!!!

Shape up, and I am really sad void is allowing to collapse by the irresponsibility of its members, and I hate to delete it, and I am sure not upgrading anything any more, but I have to see some sign of improvement to turn positive again.  Till then I can only underline my criticism as stated in this thread at reddit.

 

WHY REDDIT?

 

It is the ONLY official forum Void lists (just click on the link that says forum on their website), I don’t trust to ever enter the hackerland called irc, or don’t expect anyone can keep up with chat on github on 20000 packages and 7 architectures.  Get serious when you make suggestions like this.  You should be serious about devising mechanisms to deceive users to have data removed from their machines.

I have rebroadcasted before Void news for anyone who have missed an announcement, you have gone as far as making April fools jokes on that medium, but you want to alert users of wanting to delete data from their disk PLEASE announce it somewhere with a low signal/noise ratio, or you are going to hear it, here and on reddit, and in your little buddy buddy chat rooms.

And keep your little pups and dogs (fan club) on a leash because we are a pack of wolves and we eat poodles for breakfast.

Is it a war against systemd?  No it is a war of people against corporations.  If you can’t handle it get out of the trenches, there is no room for apolitical flowerkids here.  And that is political, it is not a “security” issue.  Go smoke weed elsewhere while chatting on gnome, we have work to do.

 

64 thoughts on “How can Void be best the one day malware the next?

  1. I have no earthly idea why xbps drags libelogind and mozjs60 as dependencies for Consolekit2. There are not declared in the template and I do not see how they can be automatically discovered. Maybe libelogind is needed if you support both elogind and ck2.
    The declared dependencies are:
    hostmakedepends=”git automake libtool pkg-config gettext-devel glib-devel”
    makedepends=”acl-devel eudev-libudev-devel polkit-devel glib-devel libX11-devel pam-devel libcgmanager-devel”
    checkdepends=”libxml2″ # for xmllint
    depends=”dbus cgmanager”
    BTW, that is not a new version, it is the old one that has not been removed from the repos (yet) after the removal of the template and associated files.

    Like

  2. “WHEN you issue binary blobs without a source IT IS OUR BUSINESS VOIDers!”

    If you refer to the template and associated files, they exist in the repo history 😉

    Like

  3. I think it is the elogindish evolution of void’s universal polkit that is dragging the carnival with it. If I am mistaken, I can’t seeem to find the source for consolekit2 on github, not from void anyway. I suspect the template you are talking about is included in the package.

    Another can of worms.

    Void’s packaging doesn’t automatically reflect the compression method and software, as it is labeled .xbps. As far as I have seen it is xz, just a tarball renamed from tar.xz into xbps. It is not going to become visibly noticeable when void switches to zstd, which I am sure they will. They seem to be running after Fedora like a grayhound chasing a rabbit. When arch switched from xz to zstd the very same day pkgs ending at .tar.xz were named .tar.zst

    I made noise about ck2 because I anticipate the same atrocity to gksu, a pkg named ck2 with a higher version, with pressurize helium in it. I think when xbps-pkgdb -m hold is abused it is time to say goodbye!

    Like

  4. Voidlinux does not host the code of the packages on gh, just the packaging bits.
    https://github.com/void-linux/void-packages/commit/c2b89d6bff8354564f1a40e7354b64db79d899ba

    Deb files are ar archives that contain tar archives. RPM files are cpio archives with special headers. It is easy to determine the default compression algorithm for xbps packages:
    https://github.com/void-linux/void-packages/blob/e603791e64c2ea533434134208d7d5e79d9b059f/etc/defaults.conf#L85-L89

    Like

  5. I know you mean well but it is all about trust and once you lose it and have to dig all the time to see what they are up to it is time to move on.

    By the way, what is this?


    DOCTYPE plist PUBLIC "-//Apple Computer//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd"

    Like

  6. I actually agree with you about the way older removals were handled. I also disagree with the proposal for removed-packages. I will very much prefer a new policy:
    1. Write down a policy for removing a package after x months and publish it in the void site.
    2. x months before removal publish a final revision of the package with identical contents, plus a message for removal after x months to be shown at install time that may explain the reasons, link to the policy and propose possible replacements.
    3. After x months just remove the template from void-packages repo and the package from the mirrors.
    However, the ck2 template was not handled the old way (as the gksu was) or with removed-packages.

    Like

  7. The angrier I got the more I dug into their chatting about such issues on github. They have members (senior I presume) who have criticized their own practices and then the “issue” is being diverted always to some technical detail. But I am being cursed for criticizing their freedom to do what they like with “their” distribution.

    There is wide spread irresponsibility in Void. Many people speak to common mortals as they are the ultimate authority, then it appears that there is no authority (a collective one, to speak as void) and the different ones contradict each other. That is an indication of lack of organization. A group of friends meeting in the coffee shop, playing cards, drinking ouzo, talking about the economy, is not a form of an organization. None can speak as the whole group. This is my criticism paralleling void with Babel.

    It is actually pretty amazing how long this can go on without the building crumbling. But it is inevitable. There is no “void” taking the responsibility for this guy’s lightdm failing today (reddit recent post) and since this lightdm is madly rerun, restarted, crashing, on his installation he can’t log in at all. Yes, I know how to fix it, but it is reasonable the average user may not know. All he knows is that it worked for the longest time, he upgraded, rebooted and he can’t login.

    When asked what services he had running, he said consolekit2, among the rest! Who is responsible? Void as a collective, the dev that broke it. I bet you they are going to treat it as something the user didn’t do, he didn’t read deep enough, he didn’t dig into release notes, didn’t notice new dependencies or how they relate to their desktop’s functionality, and it will go away.

    They are looking at the problem and will not come out and say what is the issue. They are deflecting this into a personal problem. Some arrogant zsmuck (not smack) will come out and say “if you don’t like it ask void for your money back”. When I see statements like this, where free as in freedom is reduced to free as in beer by the very devs that supposedly contribute to “free” …. I get really mad.

    Again, the issue is not as technical as it is political. The key is trust! You have to earn it, not buy it.

    APPLE can come in and buy this Void entity and its group of devs, give them some play money and some restricted stock, and have them abandon void, and create this new system for this new hw architecture they have secretly worked on and not released for years. Who would be better up for the job than the Babel 0 Inc.

    … and the billboard says, come and play, come and play ….

    Alex Kontos, poor Alex, was purchased a year after startpage by this UK marketing group, system1 …. that was 2-3 months before it was announced, and he spent those couple of months in So.California meeting the group of devs that are behind system1 …. https://www.youtube.com/watch?v=O3X8pP-4xTQ

    Like

  8. Why write such an opera?
    Use VOID if you like it, avoid it if you don’t, add a custom repo or fork it if you only want to change parts.

    I like VOID.
    It has interesting stuff under the hood.
    But I cannot work on a rolling release for some undisclosed reasons. 😦

    Like

  9. > Why write such an opera?
    > Use VOID if you like it, avoid it if you don’t

    This is exactly it, this is why I write opera and prose and satire.
    This neo-logic, the neo-liberal morality, is exactly what has fallen as the great plague all over earth and this is why the earth is getting destroyed. It is a department-store/grocery-store logic. Criticism is useless, if you “dislike” a product move on and “buy” something else, this is why “the industry” provides such a huge variety. But that doesn’t solve the problem of why resources are being depleted for all the wrong reasons, why the ecosystem is destroyed in an accelerating manner, it only says if you don’t like what results from all this destruction, just move on buy something less destructive.

    Smart phones have become a mass consumable product being replaced at the rate of 2/year for every (ab)user. Whole mountains are being torn up to dig for copper deposits to manufacture $1 toys, a cheap excuse for a neglecting parent that they gave a boring gift to a child. It is cheaper to dig up more mountains and destroy forests than to try to recycle any of the raw materials used. “If you don’t like the toy, buy something else”. We are all FREE to shop! Criticism is unnecessary.

    That is not an answer to problems, that is advise coming from any industry to dissatisfied customers. It is even more extreme in this exception to the rule of open/free software, as smart asses are quick to say “ask for your money back”.

    There is organic coffee from Chiapas available in the world’s largest urban centers, free of toxins, free of destructive environmental practices, free of oppression and exploitation, and at a competitive price. People don’t know of it and do not seek it or ask for the local grocer to bring some, because there are too many Voids and Manjaros and Ubuntus around.

    You want me to fork void because I don’t like some of their practices? If I wanted to get into something like this I would look at Gentoo, or BSD, but you think I am writing “opera” because of what I want to use? Does it matter what I use? I could be using Windows 7 all along, it doesn’t change anything. The criticism of things happening and evolving in the “Open and Free” software world may still stand. If you have valid reasonable arguments to discredit this criticism THIS FORUM is open.

    It is open for Duncaen even if I am now banned from “his” domain because he can’t handle criticism.

    So you brand this “opera” and you contribute ZERO to discrediting my criticism.
    I will keep using Void in both flavors just so I have a close look to be able to criticize.
    I will keep using Void till the day they switch to facebook’s zstd compression because it is fashinable, marketable, and will get them closer to be part of the global stock market game. This is why they are striving to make Gnome work, and many other crappy desktops.

    So, what do you have to say. Show me a current or historic example of how in the open and free software “business” there are other incidents of faking software using their name, removing their license from their name, and using them as trojan horses to delete data from someone’s computer. I have copies of gksu with content AND LICENSE, and a later package with void’s signatures on it called gksu with a higher version, containing nothing, just the ability to replace data on my disk with empty space.

    Opera? Yes, it is the world’s famous Void-Linux-Malware opera, I will sing it as long as there is no valid argument against it.

    Like

  10. I like VOID.
    It has interesting stuff under the hood.

    As far as I know and can tell, unix, was meant to be a file system organized by the distributor, allowing the system-administrator to configure things on /etc/
    Void has this bad habbit of spreading things all around the system and worse of all advising the sys-admin to alter /var setup to regulate the system. Is this a good system? Even the way runit has been employed by Void is quite unorthodox. Void is striving to make the system appear like systemd just without systemd in it. They like the MX model and popularity so much they are trying to replicate it. It is like Manjaro just with an alternative init. Why? You are not an opera fan anyways, so I will spare you the drama. Say hello to any Void devs if you run into them when you visit Lower Saxony, Goslar in specific.

    Like

  11. Quote: “When such discussions come up, the most hypocritical of all devs and coders will bring up the issue of security. Security, as in real life politics, forces an issue to be withdrawn from the public social sphere of being political in becoming a “military issue” where experts are called to make the decisions instead of the “non-expert” public. So when you hear “security” being drawn into a conversation, it is 99% sure someone who is bringing it in is denying to discuss a political matter and wants to convert it into a closed chambers meeting of expert generals in charge of security. So don’t readily buy into the security “issues” as an argument as it is a common scapegoat by authoritarians to divert an issue to be discussed by common mortals.”

    Someone has said (not quoting verbatim) something like: “Where experts arise, personal responsability withdraws.”

    Let’s face it, this pretext of “security issues” has now spread in the Corporate too (acting like a war machine indeed), which has learnt much from Deep State strategies & tactics, especially in the software business.

    Have a look at this page –and, if you are in a hurry, press Ctrl+F “security reasons”:

    https://onezero.medium.com/apples-secret-monopoly-5718272c16a5

    Like

  12. @fungalnet
    Coincidentally, I was installing Void a few days ago, maybe just when you were writing your paper about DW’s review. And so far, I’m quite happy with it. It revives an old 32-bit netbook on which MX was too slow (even with Fluxbox). And I find their management of services quite simple, neat and educational — for what I get of it (I had never managed services before ever.)
    I’m not advanced enough to understand all the technical finesses of your last articles on Void. But I’m beginning to get worried. I hope you’re wrong but I fear you’re right.
    I’m begining to regret not having listened to the inner voice that was telling me not to trust a distro whose only forum is some crappy reddit. 😉

    Like

  13. Two questions @Fungalnet
    1. To be a little more specific and serious (although I’m not quite sure yet to get the whole picture), the problem seems not to be as much elogind (in itself) and the way this “they”-Void-entity take decisions as the way they communicate or, in the case, miscommunicate to the user. Am I correct?
    2. When you wrote, in the reddit thread, quote: “Void’s decision to “support” the crappiest of all desktops is what makes elogind a necessity”, were you refering to Gnome?
    Thanks in advance & regards

    Like

  14. Yes, and no. Antix, devuan, artix, and others have adopted elogind for where consolekit2 doesn’t cut the mustard. In technical merit, those that respect its role and I don’t, say it is very good, despite of its origin. The original consolekit I believe came from the same source but they decided to kill it. Then it was forked and continued outside of the “IBM sweat shop”.

    The choice to keep elogind and remove consolekit2 is different. “They don’t want the user to have a choice, they want to dictate their choice”. I have a gutt feeling that such decisions are taken indoors by some but not all void members, but I can’t have inside information to prove this. It is a reflection of Babel dynamics.

    The way they go about removing software all of a sudden is trully bothering me, and I brand it unacceptable and behaving as “malware”. And it hasn’t been consistent. It definitely is not done by warning the user but by deceiving him.

    The last part is having binary blobs without a connection to how they were built. Removing ck2 from git and still keeping it in the repository. That is so rogue that malware is an understatement.

    I was refering to gnome and maybe cinnamon, but I was pointed out that not even cinnamon is as bad as gnome (I thought the later was based on gnome). The whole distro is being reoriented to meet the needs of Gnome.
    Gnome is a product of the same IBM group, for which I blame all evil and believe it has been a branch of IBM for many years, funded by it for many years, and it just now became official. It is IBM trying to buy open/free linux software, control it, maybe kill it at some point and turn it a closed for sale software like ms-windows or apple crap.

    Like

  15. Since you have been very honest with yourself I owe you the same in return.

    How do I feel about what I wrote? Really bad. I really do like void, up until a week ago if you had asked me I wish Obarun would dump Arch and base its software on Void. “My installationS of Void glibc and musl with s6 and 66 run excellent”. If it wasn’t for trying to keep an eye on arch development and how it affects obarun I would have moved my daily work on s6/66/void. I have self appointed myself as testing all arch testing stuff and try to catch problems before they appear in stable so Eric and JM can take appropriate evasive actions 🙂 Sometimes I piss them off, I tell them of breaking things that haven’t broken yet, like a palm reader, or reading the turkish coffee ground patterns.

    I think it is more anxiety and disappointment on Void than anything else. If I didn’t like it and expect so much from it, I wouldn’t bother. Do I give a damn that devuan and artix (not to mention the cheapest prostitute MX) using all kinds of tricks, elogind being the least, to accommodate any fancy toys freedesktop throws at them? No, I don’t expect much from them anyway.

    I also can’t help to sense that lack of organization (proper, formal organization, hierarchical or horizontal but I always propose the later) will drive Void to the ground. There is obvious miscommunication and partial decision making taking place and many just let too many things slide too easy for the benefit of “let’s just get along”. There has to be a point in human development where “high school” relations have to be put aside and serious “self-organization” should take place. This, only happens in our societies when people get to do something financial. Buddies all of a sudden become “business partners”, and economics replace acquaintances. It is so primitive I am rejecting it as a practice. People can’t get organized unless it is to make money together as a group. All other forms of organization is discouraged by this society and “system”.

    There are many many “contributors” of void, if you look around in github, there is a sea! But there is an “inner circle” (which the Phantom “xtraeme” abandoned as owner and returns as prince) and the “workers”. How is this organized? By the same mentality of banning me from reddit/r/void You disagree, you are out. In a state run this way, “you disagree you are out”, out is prison, gulag, exile, or execution. We don’t have to hear your disagreement anymore, we don’t have to reason against your disagreement, we have the power to silence you.

    Numerous strikes on all the different levels that I consider important.

    See, if you have a dream, and in this dream, Void is a big part of it, and all of a sudden you see Void being just another rotten apple like the many, you react. Some do, I do, some don’t, they just casually keep on walking pretending they didn’t see the rape, the abuse, the injustice, …. WE HAVE CHOICES… the grocery store shelf is full of different brands and color combinations, and flavors.

    It is like pointing out and screaming this brand of coffee contains arsenic, I tested it in the lab because I was getting sick. Then you have all those neoliberal zombies around telling you, be quiet, if you don’t like it try the next flavor, or the other brand. Some people like arsenic poisoning.

    This is different from an individual, an individual can be any nice or crappy or weird person, it is ok. When a group of people begin to have characteristics that can’t be controlled by formal organization, it is a sad affair for the entirety of humanity.

    You can only tolerate living with zombies for so long, then you start crashing their party.

    Maybe it is my upbringing, punk rock was a live thing in my age group. If they didn’t allow you to see the concert, you break their doors and gates and fences, and you either enjoy the concert or there will be no concert 🙂

    There is always Adélie Linux where there will be vacuum from the demised void. And they have ck and no elogind, and I hope it is a very conscious and collective choice. In Obarun it is just what Eric decided. You see the little Stalinist inside of me popping out, which I am trying to hide with so much effort and pain? NIET!!! in Cyrillic

    PS I don’t use ck, haven’t for as long as I figured out a way to do everything without it. Even dbus is vary rarely allowed to pop its ugly head. It is not like the move took any functionality for me away, or that I used gksu so much that I cared. It is the direction this void vessel is moving I dislike. If you want to use Gnome, take a hike!

    Like

  16. Well I can see now why you are so irate. I could “sense” it was with reason, because, why, as a rational person, would anyone spend so much time & energy to encourage & promote a project (namely, here, Void) and then, the next day, “crash the party”, as you put it with?
    There is indeed very sad news in what you are bringing to light for a few days from the darkness & opacity of this bizarre binary (and manpower) management…

    I won’t erase Void from my 32-bit computer, just because of this elogind. (It’s a bit early. My installation has 5 days and I’m so proud I managed it. It was years I was considering giving Void a try. And I like it BEYOND what I had hoped!)

    But I will keep in mind your warnings. Very concerning.

    Like

  17. EDIT (3rd line): and then, the next day, “crash the party”, as you put it with sense of humour?

    Like

  18. @fungalnet
    Maybe that’s too late for you to care, maybe not. The concerns you have uncovered don’t have to keep us saying about Void the good things we think about it (you have done so, in a very touching way, in your last posts.) But to the point:
    When posting my previous message, I had to make cut it considerably to make it short. For, without really intending to, when respondinq to your testimony by mine, and just talking about my (young and naive) experience with Void, I somehow wrote… a Void review!
    So now, my question is: do you think it is worth its proper Topic?
    I just need to warn you that it would NOT be a “savvy/techy” review or installation guide, tweaking with code. But it could be a real, true, honnest review (far better than many I read here and there on certain sites I won’t name because they already have enough traffic). And it would be a review from the perspective of a false n00bie or somehow semi-advanced end-user. An experience feedback. Let me know.

    Like

  19. This is what I have intended since the start of this blog, to be a community forum and meeting place, not a personal 1 man’s voice. Write it, I will publish it and if I disagree with parts of it I will comment on it.
    No editing, cutting/pasting/fixing. You write it and it goes up.

    Like

  20. Void is still good. When one morning I wake up and realize they have switched compression to facebook’s and all their packages use zstd … it is gone. I hope someone forks void in the meantime and I can move there 🙂

    Like

  21. I am focusing right now in understanding and playing with Spark-Linux, an Arch modification running with Sinit, one of the world’s smalles init systems. It is running well, I am excited.

    Like

  22. Playing with Spark? Just from memory: the not-distro but “build-concept” of that guy who claims he “hate[s] disabled people” haha. You’re restless, fungalnet.
    About a Void review: Thanks! I’m gonna have to postpone a bit my proposition though. I just lost control of my main station, the one I wrote my text on. Hence, I’m now writing from the Void. :° (Sorry, I could not resist that one.) I have to go and send an SOS on the forum we both know.

    Like

  23. By the way, while i’m in my Void, i checked. No more consolekit2 and elogind indeed. 😦

    Like

  24. About Spark, yes he is a little abrupt but if I didn’t believe that by disabled people he means those who use gnome and systemd (and elogind) I wouldn’t want to have anything to do with it. So this “faith” helps me carry on the examination of sinit on arch 🙂

    Like

  25. ck2 depends now on polkit and cgroups, current polkit and cgroups depend on elogind, so if you don’t have old versions of all those three in your cache to use xdowngrade with it is either you remove ck2 or install libelogind.

    When Stalin in the Kremlin decides what is best for its people, its people must be grateful and respectful of his choices. It is pretty simple. If you don’t like it move to the next grocery store where Trump and NYSE decide your options and what is good for you.

    As long as we are free to choose what we consume it is all great, nothing to talk about, move on people, move on. Nothing to see here.

    Like

  26. Thanks for clarifications. I never believed the dude was seriously mocking (really) handicaped people. (Although, I thought that, through this claim, he was deriding politically correctness.) Now, if “disabled” means the weed-smokers that jerkoff when fancying gnome & systemd technologies, that makes twice more sense.

    Like

  27. By the way, when talking about (already) looking for an alternative to Void and playing with some candidates, have you tried NuTyX more lately? Your last topic about this Swiss or French distro was sort of admirative. The designer, Thierry, even posted a short comment to say something like: “at last somebody who gets it”
    And what about KISS linux too? (I personally would have given it a try if there was a 32-bit version…)

    Like

  28. @fungalnet
    Hi again. For now, about the “Void review” to be.
    Just saw you updated the content of “Top distros covered” in a direction which does not let place to a “review” of Void. I don’t mind, i can understand you do not want to promote anymore a distro that you have cherished and that, then, betrayed your hopes.
    Besides, the “review” i’m talking about is still a draft. (Lucky enough I saw your quick change of mindstate early enough.) And this draft may take a different course after all. More something of a testimony of an end-user lost in the so-called “free Unix” galaxy after quitting the blue prairies of Windows and the metal-brushed mounts of Apple.

    Like

  29. @fungalnet
    Hi again. For now, about one of your ideas.
    Yes, in spite of their communicational autism and obscure management (but that’s a thing-human) Void (as a thing-system) is bloody good. Have you tried to speak with Éric about forking it? If he has the expertise (I’m sure he has) and time (this is less sure) it would be a good revenge (towards Void vacuity) and a beautiful gift to those of us who need a frugal, solid, efficient system.

    Like

  30. Long discussion about PC in general. It is a bureaucratic way to keep political issues outside the “production”/business, so left, middle, right-fascists, can co-exist harmoniously in the work place and be productive. It is a hypocritical way to deal with social conflict in general. The employer doesn’t care if you have viewpoints or not, he (it is most often a he) just needs to exploit your work ability and make money. Civil war is OK as long as “his” business is not affected by it.

    Now, on the other hand, branding people because of their physical characteristics and be prejudicial, discriminatory against them, is a form of violence, a verbal violence that is tolerated in a violent society. I think we need to minimize verbal violence to advance discussion and communication. At least that is what I practice in real life.

    Like

  31. I remember Nutyx being something positive but I’d have to go back to my notes and maybe check a new image out.
    In many things apart from arch-based and void the package managers seem to me as very simplistic poor excuses. With xbps being second best pacman is hard to compete with. I am sure gentoo being a different form of package management may be even more elastic but all those other projects seem to be deficient due to this software.

    Kiss yes I tried early on when it was first announced, actually I think Dylan blames me for preannounce it because he told me over reddit about it, so I thought it was public knowledge 🙂 It is a promissing project but I think it needs some time to mature. It is in very good direction, if you like custom compiling stuff.

    The foundations to grow and go far are laid by adelie. Just remember in the future I said so.

    Like

  32. If he had the capacity I think he would have forked arch instead. Void is already taking a turn where Eric will not go. Void and Artix seem to be converging in goals and orientation.. Before we know it most of those distributions catering to this “large popular market” will converge in flavors of the same system. Too much fluff and no substance. Where linux/unix makes a difference is in large scale commercial servers, supercomputers, etc. Those people know how to pick fluff away from the skeleton of robust systems. Nothing even comes close to s6 in such systems, it would take some time to recognize its superiority. Runit is good for personal computing, too bad it was abandoned because its author didn’t want more out of it.

    Forking a large distribution not only takes man-hours it takes resources, physical servers, repositories and such. Obarun doesn’t have money for this. Someone is donating huge servers to build pkgs to Void, and those donations can’t be without say and influence. Obarun has chosen a lonely independent road, but sometime it is hard. https://sysdfree.wordpress.com/wp-admin/edit-comments.php This system constantly runs, 24/7/365 and there is a que constantly for people to take turns and build their stuff. That is not a common pc. On out systems it takes sometimes days to do what this thing crunches in an hour.

    Imagine arch supports one single architecture, intel/amd64. Nothing else, and it is considered second to debian in breadth of software supported.

    s6/66 doesn’t really need any specific base, it can be adopted to run on any linux and possibly on BSDs and other unix based systems. There is this thread group of how 66 was tried in all different systems. Both void and antix run great for me.

    Like

  33. 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.

    Like

  34. 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).

    Like

  35. 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.

    Like

  36. @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

    Like

  37. 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…

    Like

  38. 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.

    Like

  39. 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.

    Like

  40. “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.

    Like

  41. 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

    Like

  42. 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.

    Like

  43. 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.

    Like

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

    Like

  45. @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?

    Like

  46. 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:

    Click to access WRL-88-4.pdf

    Like

  47. 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!

    Like

  48. 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!

    Like

  49. 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…

    Like

  50. 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

    Like

  51. “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.

    Like

  52. “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.

    Like

  53. “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.

    Like

  54. 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.

    Like

  55. 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 …

    Like

  56. 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.

    Like

  57. “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.

    Like

  58. “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.

    Like

  59. Pingback: 5 Does the “typical linux user” have anything to gain over traditional scripts? | systemd-free linux community

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.