Actually, Devuan still has a lot of hanging dependencies.

dpkg -l | awk '$1=="ii" {print $2}' | xargs -rn1 -I+ sh -c "dpkg -L + | grep --label=+ -Hw systemd" > systemd-references.txt

Seems to certainly suggest otherwise. Renaming something to 'libsystemd0' doesn't change the fact it's a systemd surrogate.

This thread seems pretty decisive on where I stand on the matter, and this is clearly not even a valid argument.

Really?

This search for systemd in posts producing over 5 pages and a thread literally titled "When you can't tell the difference between Windows and systemd" and the fact Devuan's entire purpose is to be systemd free seems to suggest otherwise. I imagine the Windows and Microsoft quips are just as regular here.

What I really don't get is you've got a guy - devel - who only literally registered yesterday (seems for the simple intent of replying to my post as a sock account), who, not only is their name Red Hat based (when installing dev packages on a Red Hat system it ends with the term 'devel'), advocates a pro-systemd position, which by itself isn't a problem, but the second I refute their position, you guys go ape and start attacking me.

I mean, if you guys already know all the systemd rebuttals, aren't interested in systemd topics, and are opposed to systemd, why are you clicking on a thread literally titled "arguments against systemd" and then attacking the guy who is actually opposed to systemd (whilst ignoring the pro-systemd guy)?

What is this, a secretive pro-systemd club?

A better saying; if you don't have anything nice to say, you shouldn't say anything at all.

Post pro-Devuan arguments not on a Devuan forum? Even if we take it strictly as being systemd, wouldn't this just iterate the point about systemd counter-arguments being 'scattered over the internet'? Why would someone be searching for a 'blog site somewhere' for arguments on why to adopt Devuan or oppose systemd?

But that's the thing, as my first post notes in the very first line (which anyone should have read upon entry), that the people of this forum already know most of these points. But it also clearly says "this is more aimed at new users who are unfamiliar with the whole systemd crisis". New users of Devuan. It does not ask forum users to contribute (nor would I expect them to), just that it's an option if they wish.

New users who aren't necessarily on your forums, nor familiar with the systemd issues.  Intelligence is only capacity to process, it does not mean one already possesses knowledge. More users means more developers, more donations, there's no logical reason why you'd want to brush why someone would want to switch from Debian to Devuan under the carpet.

For example, what do you guys do if someone asks 'but why don't you use systemd', or 'why is systemd bad', or 'why should I use Devuan instead of Debian'? What collated thread or repository of information do you point them to? Do you expect them to assume it as true without knowing the whys and hows? Init comparisons are long since gone because the nature has changed, and merely saying 'package freedom' would merely involve stating the above points (point 8, specifically), except you'd then have to answer 'why is systemd not free?'.

You guys are already here, why would I be trying to win you over to Devuan? It's the new users, the undecided you want to encourage to join.

So, hold on, let me get this straight, you said you weren't worried about trolls because you had 'almost no code of conduct', but you're concerned about serious, fact citing debates? Your own code even says "We are all adults capable of having intelligent, adult discussions", and I've not done anything to dissway from that position.

Of which, lets be clear here, is presented in the spirit of Devuan, a community I had presumed to be opposed to systemd (I mean, you spent the last 2 years trying to rip the thing out so you can't be fond of it) and would therefore welcome a key summary with points that, naturally, boost the position you've taken and encourage others to join your particular community - "We accept everyone's contributions".

No ad hominems were presented, citations applied appropriately, civil presentation utilised and you added your own points without it being an issue at that point (the graphs were excellent, haven't even seen those). I've not encountered any place that centralises or explains any of the concerns of systemd in a clear enough manner (not even the anti-systemd wikipedia which fairly technical), and is certainly scattered through-out the internet (certainly, the diverse sources cited are a hat tip).

I wanted to both summarise and counter a lot of cliche arguments I've read.

If you feel I've misguaged Devuan (I had presumed it to be anti-systemd), I will gladly leave, including dropping all associated projects, and resume my search for an OS that is opposed to systemd in spirit.

It's good, no need for a lock, as you said in the questions thread, forum has a lack of code of conduct, and as a man of freedom I'd like to see if anyone else has replies or anything else to add.

Foreword: Your post reads like a pro-systemd user, but at a few select junctions you say 'other people say'. Poe's law. Regardless of if you're parodying systemd supporters or being legitimately serious, I will direct the argument at you as if you are one and the same. If you're not, don't take it personally, you're just getting how I would naturally react.

Strawman argument, citations were provided, you even immediately contradict yourself on that line by saying:

So which is it? Misinformed or factually correct?

Ad hominem. As you already acknowledged, it's factually correct.

Feel free to point out which parts aren't and I will dig out appropriate additional references for those.

Strawman argument.

Firstly, systemd was not presented as an 'umbrella' project but an 'init' system (I quoted the fedora magazine which is about as pro-Red Hat as you can get on that one). You know what a systemdaemon is, right? A background process classically in charge of one thing. Saying there's 'lots of different pieces' doesn't refute the fact parts of it still hook onto PID1 making it pretty crashable.

Citations you'll find are on suckless, some of which come verbatim word of mouth.

This is a gross generalisation. 'Some parts'? What parts? What part are you actually trying to refute?

Again, generalisation. 'That happened' - what happened? 'Things got fixed' - what things?

Source?

Here's mine:

https://cgit.freedesktop.org/systemd/sy … ec9c#n1128

Yes, if you had bothered reading my post, you'd have seen the link under 5. Here's another reference:

https://cgit.freedesktop.org/systemd/sy … ec9c#n1500

Sounds like a terrible argument trying to justify systemd decisions, which:

Google servers point is easily refuted:

1) Systemd was an init process. Since when did they go from calling themselves an init into a DNS? And who authorised that expansion? What vote? By what group?

People only approved adopting it as an init system. Not a 'lets connect to google by default' system.

1) Even if we irrationally ignore that first point, who, if anybody, did they consult with when determining which DNS service, if any, they should pick as a fall back? Tor browser manages DNS lookup without being reliant on a single one, so what's the deal?

2) Why was google specifically chosen and none of the other countless other DNS services? Don't say 'reliability' because it presumes universal accessibility, which ignores geo-politics. Ever tried to connect to google from a country (Egypt, Libya, Syria, etc etc) that tries to kill off it's internet? Systemd developers thinking with an American-centric viewpoint, which is not particularly all inclusive.

3) Why was the option to have no default DNS service at all not, more importantly, chosen, or even instead a list of selectable DNSes (should a user so want that), picked?

Google are the absolute worst choice for numerous reasons, as previously provided (abuse of power, censorship, eagerness on backdoor politics involving destabilising governments, oh and major point: profit by datamining), and it's clearly highly questionable.

This doesn't refute my point, given I refer to systemd itself. If systemd breaks on PID1, how it's going to restart then? PID1 should be as simple as possible to avoid the biggest chance of crashing. Adding DNS and remote access and everything else through it is asking for trouble.

And why are you arguing a pro-systemd stance when falsely claiming stuff about 'undermining devuan's credibility'?

Preference implies freedom of choice, which systemd removes. See earlier point.

Citation? Statistics? Numbers? What is 'like a lot'? In comparison to what?

Weasel words don't work here. Where are your facts?

Really? Because I don't see people with a viable alternative. Looks more like it got injected into Debian upstream and OSes were forced to adopt it (being based on Debian, EG Mint, Ubuntu and their derivatives likewise), which given the large numbers of complaints across the board (including the existence of Devuan itself), absence on Alpine, and the total verbal rejection by the BSD community largely suggests otherwise.

Wasn't Ubuntu working on Upstart before they were forced to ditch it?

Devuan can only do that by offering a genuine alternative, which is my primary criticism levelled at systemd, which takes that freedom of choice away. All of my favourite OSes have systemd on it, and I hate systemd, but by your inferred logic, because I didn't choose 'otherwise' I 'like it' (because you reverse justify by suggesting if someone owns systemd they must implicitly like it, which makes huge assumptions to users unaware).

Now to address your other blatantly pro-systemd arguments (for someone supposedly anti-systemd?):

Weasel words. Citations please. Who are these 'lot of people'?

You didn't even address the root privilege exploit or the remote DNS code execution that Poettering refused to patch and you call it 'more secure'? You do realise the code exploit works by a DNS lookup, right? Just a DNS lookup?

Sounds super secure to me (not).

Ability to be deployed on a wide vary of systems, especially with the emerging 'Internet of Things' and embedded systems (used pretty much everywhere these days) is extremely important. Unless you have a narrow 64-bit desktop only view.

From what I've seen OpenRC and sysvinit held that position, until a 50/50 vote split (apparently meaning 'popularity' and not 'controversy') forced systemd through the door, which I do believe violated general voting priniciples as it's usually by a large margin and not a small one, so someone must have been pulling a few strings.

Software doesn't 'depend' on systemd so much as systemd ripped out their previous dependencies with no choice and developers were forced to adopt it or die out.

How are you going to hook a shutdown event without systemd if systemd oversteps it's boundaries and controls that? Or the firewall? The port forwarding? The DNS? What the hell doesn't systemd control that developers can call?

Removal of choice does not equate to acceptance, and you know it.

Plus, no citations bro.

Next lame pro-systemd argument:

Except you contradicted yourself because you stated, and I quote:

So which is it? An init system or an umbrella project? An umbrella project infers no flexibility because it absorbs everything. If it's an init, why the hell is it picking DNS services for me? Can't just pick and choose 'what systemd is' to suit one situation over another.

What, text based terminals rendered inside graphical environments like Wayland? I refer to text-only login systems used by servers to keep their processes lightweight (believe it or not servers rendering graphics is unnecessary, consumes CPU, and servers do not equate to desktop systems, which is surprising because surely a Red Hat developer should already know that, right?). Saying that 'another init system provides this service' is entirely my point that 'systemd doesn't'.

The fact you can only offer two options, either X11 (a graphical system that has been around since forever and didn't need systemd, so this isn't something 'systemd offers' anyway) or it's blatant systemd replacement Wayland, which is basically GNOME-only (because who wants a different desktop environment? Not all those other users out there with Trinity and Lumina, KDE, XFCE and however many other environments I can't count), proves my point it has no diversity. Do I have to rip out systemd if I don't want Wayland too?

You woo me with your diverse options.

All inits require 'core tools' (to quote Cinema Sins 'why is it called the CORE if it isn't central to anything?'), systemd included (doesn't matter if it absorbs them, it's still there), and this argument is dishonest because it presumes systemd already contains less resources. Are you honestly suggesting that systemd, which 'pulls in everything', has no option to remove anything and has no way of knowing what I want in advance, could compete with a system I've manually selected the packages for?

This cannot be answered by anyone honest, because who has done a 'systemd only' bare metal base OS install in the Red Hat team to set a baseline? Is it updated every time they absorb a new package? We don't know because systemd keeps adopting more and more things.

Why would I need graphics, DNS and a firewall on an embedded system whose only job is to operate a power system?

And does sysvinit have a remote code DNS backdoor? No.

My stability argument is on the PID1 crashability basis on the OS level. Because systemd isn't an init but a Monolith (your own Devuan page states how it was like stripping everything off a bicycle), it's crashable because PID1 is no longer a simple 'restart shell script' but a complex monstrosity.

If we're talking some bizarro 'sysvinit versus only the init components of systemd and not systemd as a whole' which is pretty fallacious (given the 'umbrella project' argument), I've encountered quite a few pages where developers have complained about the difficulty in initialising processes using systemd (back when it was still an init), which were incredibly buggy, and when they filed bug reports, they often got slammed by the EWONTFIX technique. The absence of documentation on processes greatly impedes stable development. I doubt I could find those links again, but I can testify I read those and it's what initially soured my opinion of systemd.

If they want to however strip out systemd into a stand-alone init, it'd allow tests to be done for stability, but I treat systemd as a whole, and not just it's init system parts (because that would be like saying the 'US military' is responsible for wars but not the 'US government').

I think the real proof though is if systemd remained as just an init (and didn't absorb everything and force other systems to become dependent upon it), it would have been fairly subject to competition from other init systems. The fact it's been designed to stifle competition suggests they're not interested in the best one succeeding.

The onus is on systemd to provide accurate numerical reporting of which bugs are closed under which heading (as we're not privvy to systemd's statistics because we're not Red Hat). If they purposefully merge statistics of bugs reported and bugs closed but don't delineate between which have been fixed and which haven't been acted upon, the only one that can be accused of inaccurate reporting is systemd itself for purposefully blurring the numbers.

The fact there are news articles reported in major news outlets reporting on the EWONTFIX attitudes of systemd developers itself suggests it is a systemic problem, especially when one considers the context of not acting on a remote code exploit that is injectable via a DNS server. Good job Google with their DNS services have 'never' been caught underhandedly working with any agencies or we would all be boned.

Now I just need to find where I left my tin foil hat...

Folks who want an easier way of obtaining the Download-Github.sh script (without using a browser), run the following in bash:

curl https://raw.githubusercontent.com/JoshuaFlynn/Modules/master/Download-Github.sh > Download-Github.sh

Or, if you just want to get the Modules system to immediately download (and not leave a Download-Github.sh hanging):

curl https://raw.githubusercontent.com/Joshu … -Github.sh | bash

Above pipe command does not work (unless the first command has been run), apologies.

Github and Linux really don't want to play nice when it comes to copying a large number of files to a pre-existing destination (which is, of course, preventing the Modules system from being able to pull in updates).

A lot of sites suggest the usage of rsync, but from what I recall of my systemd contamination investigation, rsync indirectly had hovering references (will need to double-check that) to libraries that indirectly pointed to systemd. Naturally, if I want King-Pigeon to be systemd-free, I got to avoid relying on items and services that might pull in systemd or it's relatives.

So naturally, I wrote my own bash script that does a recursive copy (available under HelperScripts if anyone is interested in using it). Yes, it handles notorious newlines and 'bizarro characters' in filenames, and calls itself again if it encounters a new directory, passing additional arguments.

It also prints the data quite nicely (or at least I think so). Even returns colour codes for success/failure of the copy event:

Those of you on different colour terminal backgrounds (IE white, bright green, etc) will be pleased to know that the background of the coloured characters should be black (regardless of terminal background colours), so it should remain ideally visible even on differently coloured terminals.

Script is a bit hacky in that the print characters (the nice spacing you're seeing) is passed as an argument so it can recursively stack, but without doing super complex code, there's no straight way of solving it.

Query:

Is there some way to pass a subset of supplied terminal arguments to another bash script that is dynamic in numbers?

It'd be really useful if the Recursive-Copy script became a generic 'run this command' Recursive-Command type script where the command to run is passed to the script itself along with any arguments to said command. Lots of useful possibilities. Also sounds kinda tacky.

Further edit:

For anyone wondering about the functionality of Download-Github.sh, it switches mode. If Modules doesn't already exist, it simply uses a mv command (less expensive), which means first time it's run it shouldn't need Recursive-Copy.sh to deploy Modules. Subsequent calls will do, but Recursive-Copy.sh should be included in Modules by then. If not, simply delete the directory (and report the bug).

I think it's certainly another tool to add and look into. I'll eyeball that at a later stage.

As a status update:
In the meantime I'm redesigning the github script deployment system because github is no friend to non-empty directories (which is a nightmare if you need to update files without trashing useful ones), and their command structure gets messy and problematic, so I'm building a 'Download-Github.sh' script whose sole purpose is to download from, as you guessed, github.

Because I want to follow a 'keep it simple' approach, this script will become a central focus point. So instead of downloading a specific Blueprint script, you'd run this, which it will then download all of the Blueprints locally (it basically calls... itself). Eventually I'd like to make it into a User Interface where the script, when first run, asks you what blueprint or module you want to deploy.

As a result of this major github change, all of the scripts are being internally rewritten to call through this, so bear with me.

(This is what testing is for!)

Made a couple more images that I wanted to try prior to the upload of the last images. The Devuan logo looks suspiciously like a futuristic Starship Logo, unfortunately what I had imagined and what I ended up producing were two different things, and I wasn't happy with the end result:

After seeing the vegetation tool by accident, I knew I wanted to try a purple alien planet type theme:

I think it turned out okay.

I often write in depth, character trait.

They're only suggestions at the end of the day, you can ignore them, just I'd like to see more users join the Devuan forums.

Also, good point about the no code of conduct.

I presume because each bot has a different purpose:

1) Spiders (that simply datamine/harvest, either for search engines, or garbage 'rip-off' sites that need to all die in fires).
2) Pharmaceutical/Counterfiet bots (money is in the purchases of the dubious quality product).
3) Lobbyist bots (money is in achieving the desired outcome. See the FCC getting spammed with copy-paste comments from what looked to be Comcast as an example).
4) Propaganda bots (money in getting people to like or adopt a specific lifestyle choice, for example, pro-vaccine bots which I've personally encountered and exposed).
5) Military bots (attempting to achieve government policy, and thus already has the money. Usually spreads either propaganda, false information about particular targets, or is used to attack individuals to drive them off or away from a particular place).

In terms of Devuan, I imagine it's mainly 2 peppered with 5 (Red Hat being mainly funded by the US government, one of their biggest purveyors, likely does not want 'secure alternatives' cropping up. NSA got Microsoft to pwn Windows for them, and Red Hat is literally directly funded by the NSA, so chances are, given the NSA's Linus Torvalds backdoor offer failed [he went public on it], they want Red Hat to pwn most, if not all of, Linux [they already give Linus 'suggestions' on the NSA's behalf]. Only way to do that is to prevent people swapping to different configurations if they can't backdoor the kernel).

Curious thought of the day: if they approached Linus to install a backdoor in the kernel - code that is open-source - does this imply they're confident they could hide a backdoor in open-source code in broad daylight?

Does anyone still use SELinux these days?

Quite a few things pull it in implicitly. Udev is a big culprit, but XFCE and KDE leave hanging libraries for it too.

I don't suspect BSD up to no good, I just don't think they realise systemd is trying to get in via the backdoor IE via higher system packages.

Edit: I'm told initially OpenBSD didn't have it initially with it's default desktop, but because it (the desktop environment) was 'unusable' ('comically unusable' - their words) they had to install XFCE (which had hanging dependencies for systemd - unclear if it's actually there). They argue might be useful as a server (without the XFCE desktop environment), but from a desktop user POV not ideal.