The officially official Devuan Forum!

You are not logged in.

#1 Re: Off-topic » Adventures of the systemd clownface » 2017-10-23 16:15:21

fog wrote:

this is your vm setup/vid card fault.

Despite the fact that I've hosted 10 different Linux OSes in VM on this machine perfectly fine.

(All the working ones have one thing in common: they either minimise or don't have systemd on them on default install.)

Lubuntu is also of course L, for 'Lightweight', which means graphics shouldn't be an issue, and any graphics failure should drop down into text based, not this weird-ass clown face.

Connectorivity wrote:

I do believe that is 17.04. Joshua was using 14.04.

I was using 16.04, but you're still correct, his version doesn't align.

cynwulf wrote:

Setting aside what I might think of systemd, this kind of thread only fuels the argument that many systemd opponents are just ill-informed fanboi types.

It's a bit hard to make rational arguments against systemd if you get banned for it (after administrators turn pseudo-trolls to bait adversarial responses).

Curiously, this shallow thread prompted nothing, but a thread of substance and research prompts a ban? Go figure.

cynwulf wrote:

I'm not sure what Linux KMS/DRM video driver stack and server have got to do with systemd.

Even putting aside the blatant blame-shifting game (what bug hunting or diagnosis did you use to reach the conclusion on what's occurring on my machine?), it's a valid question - but directed at the wrong person, and should be directed at the systemd developers themselves; one wonders why desktop environments (such as say, LXDE, KDE and XFCE) are being integrated into systemd.

Along with, of course, everything else.

And don't bother with the 'init'/'umbrella project' switcheroo, someone already tried it and from what I saw they didn't come back (unless it was under a sock account).

#2 Re: Off-topic » Arguments against systemd » 2017-10-08 01:24:02

golinux wrote:

That is pretty twisted.  It's obvious to anyone with connected brain cells that devel was a troll.  But your first post was the flame into which the moth flew.  Your continuing argumentative responses defending your poor judgment indicate that you are STILL clueless.  That's why you're getting the heat.  It seems that not all trolls are pro-systemd . . .

Indeed, seems some anti-systemd users are trolls as well.

Even if devel is a troll, if the points (no matter how badly argued) aren't refuted, people will assume that naturally they have validity. I will still refute the 'hypothetically someone else's argument', even if spurious.

You guys seem to be operating on a subset of clique knowledge where you seem to expect people to know the implied social rules of your forum, and if I'm taking the heat for that, gladly, means another user doesn't have to suffer it.

ralph.ronnquist wrote:

I liked post #19 though; it was short and succinct, and its mere presence so elegantly violated its own sentiment.

And yet a man who professes to be an intellectual has trouble reading two paragraphs requires said posts be broken down into an overly simplified idiom, likes it, but not to the degree that he follows through on it.

(Also, I take it you didn't like the post pointing out the hypocrisy of you 'not reading' a post but then 'replying' to it anyway?)

I thought you guys were extremely busy, why are you still here?

#3 Re: Off-topic » Arguments against systemd » 2017-10-07 23:09:40

FOSSuser wrote:

Devuan is an operating system, & this forum is for those who use it, the fact that it is systemd free is why we are here.

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.

If you can't make up your own mind about systemd,

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

that's not a suitable subject matter to be discussed here, It's like talking about Microsoft, & of no relevance at all.


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?

#4 Re: Off-topic » Arguments against systemd » 2017-10-07 09:41:15

I mean, I don't get it, if you're not going to read the post (either the first one, the direct response or even a single line), why even reply?

You're all but effectively ignoring the thread, so why waste the effort of coming here to 'not read' a post and then posting a reply to a post you've 'not read'?

I mean, who's writing the troll bait now?

#5 Re: Off-topic » Arguments against systemd » 2017-10-07 09:15:24

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

#6 Re: Off-topic » Arguments against systemd » 2017-10-07 07:47:43

golinux wrote:

If you think that reinventing the wheel is a good use of your time, go for it.   We have more important things to do.

I certainly feel I could definitely contribute, and this thread is not intended to prevent you guys/gals from your developments, nor would I expect anyone to specifically contribute or aid me or this thread as such, nor was any such help asked for. In-fact, I would go so far as to explicitly decline that help but I did not want to be rude. I'm perfectly content to debate solo, and this was my assumption from the outset.

Devuan will fail or succeed on its own merits,

Certainly (I was not suggesting Devuan did not have merits, just that advantages over systemd are not clearly stated), and I intend to draw attention to those merits and encourage other users to switch over to Devuan (which means ideally this thread will see re-use as a reference point so I don't have to rehash the same points when introducing them to it, I like to save myself future work, as any smart person does).

There is no need to 'win' over users who should be intelligent enough to find the many excellent analyses that are already available (and have been for years).

And I intend to collate such analyses here, such users don't, as you say, reinvent the wheel by ending up doing similar searches, uncovering similar information, and putting it together to form similar conclusions, all of which takes time and resources (in a technical sense, they are being indirectly won over). Hopefully they will find all that they need here. Nor do I want to make exclusive provisions for only technical users (as your code of conduct says, you welcome all types of people, and I intend to befriend all types), but also users who may find certain concepts unfamiliar, I try to avoid assuming anything about my audience if I can, so it is accessible for all, I find a lot of analyses tend to be pretty technical, and I wouldn't expect a newcomer from Windows (who asks me what Linux distro should they use and why) to understand, so don't be surprised if my comments seem 'rudimentary' or 'obvious'. One thing I've learned is to never assume someone else knows what I know when it comes to learning.

I feel that we have perhaps gotten off on the wrong foot here, and I feel, to paraphrase Thomas Hardy's poem, had the circumstances been different, we'd be - perhaps, not to assume - friends. I merely wish to offer, besides the background images and planned contributive support (such as the assimilation conversion kits), verbal rhetoric supporting Devuan. I'm not your enemy! I must admit these responses did kind of surprise me. I waited the 2 years as Devuan matured into RC (I had tried the early beta release that had only XFCE - I was the guy who made that one-off post requesting LXDE and mentioned the package modules idea on the early discussion board buried in one of the long early threads, and I was pleased when you guys added it along with KDE), and I wouldn't wait those 2 years to just scuttle it now.

Friends? Or at least maybe neutrals?

#7 Re: Off-topic » Arguments against systemd » 2017-10-07 06:21:39

ralph.ronnquist wrote:

Why don't you find yourself a blog site somewhere, where it'd be good and natural to line up all those beautiful words.

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?

This forum is populated by mostly intelligent people with no need or desire to waste (more) time and thought on 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.

#8 Re: Off-topic » Arguments against systemd » 2017-10-07 04:23:28

golinux wrote:

This thread serves no purpose except as troll bait (and it worked).  So can you please take a deep breath, leave the dramatic gestures and defensiveness aside and take it down a notch.  Thanks.

Firstly, no-one does research for 'troll bait' and that's clearly not my intention, so I do find the point insulting and confusing (and are you inferring devel is a troll?). Trolls use emotive, generalised rhetoric that aren't substantiated by facts. Why would I waste numerous months compiling information for a 2 day troll? Why not just make a generalised thread and be done with it?

On the contrast, you've got a literal baity style thread comparing systemd to Windows. This is a factual analysis of it's flaws, you know, using citations and facts.

None of these gestures have been dramatic (text never conveys intention well), nor are they 'defensive'. I'm simply not interested in investing time and resources into a group if they are, in-fact, not anti-systemd, so it's more a query for clarification.

If I'm not able to factually reason why a person would want to logically swap out systemd for an alternative (which is the main reason a person would want to adopt Devuan, note), then there's no point me aiding an OS development that actively inhibits it's own userbase from arguing in favour of it's own existence. I'm not interested in investing time putting things together if it's only going to either get locked or classed as 'troll bait'.

If you had, alternatively, explicitly stated in your code of conduct (which is absent any real codes) that you prohibit debates over systemd, or indeed, any information regarding systemd, not only would I have likely not posted this thread here, I likely wouldn't have registered at the forum either. Users do not expect to find implicitly held admin rules by 'discovery' because it implies a time investment that might, ultimately, be wasted.

#9 Re: Off-topic » Arguments against systemd » 2017-10-07 03:34:34

golinux wrote:

We do not have a "lack have of code of conduct".  We have an (almost) No Code of Conduct.  I personally don't see how anything good can come of rehashing this topic (which has been beaten to death for many years).  it is also a waste of bandwidth,  But let it continue for a while.  Hopefully it will grind to a halt with not even a whimper.

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.

#10 Re: Devuan Derivatives » Early doors: King-Pigeon series and friends [AKA Modular Linux] » 2017-10-07 02:48:25

darry1966 wrote:

Same issue with my ASCII Refracta install using nox 9 version - have to logout and shutdown from lightdm.

Thanks for the confirm.

fsmithred wrote:

For shutdown and reboot, check that you have consolekit, policykit-1, libpam-ck-connector, and maybe policykit-1-gnome. Maybe something else, too, and that might depend on what desktop you're using.

For dns, I just set it in my router. To set it in the system, you can put it in /etc/resolv.conf (nameserver) or /etc/dhcp/dhclient.conf (prepend domain-name-servers) or /etc/network/interfaces.

Thank you for the troubleshoot advice, I'll try that out on my next ASCII upgrade test. I vaguely recall someone building a CK/PK1 independent shutdown into LXDE who had encountered a similar issue (which was pretty barebones but it worked). Can't recall where I saw it though.

I've got DNS set in my router, but the OS wasn't referencing it for some reason (it's what my normal machine uses).

DNS configuration information should be useful, will have to devise a list of DNS services for users to choose from, perhaps even region specific.

Man, I keep adding more and more to my plate.

#11 Re: Off-topic » Arguments against systemd » 2017-10-07 02:26:24

golinux wrote:

Good grief . . . 2641 words (including quotes).  You really have outdone yourself this time.  Perhaps this might a good time to lock it?

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.

#12 Re: DIY » Howwww... aaaabout some Dev1 backgrounds, hey? » 2017-10-07 01:53:08

Hi fungus.

I initially tried a forest/sea theme with sunset style text, but the image looked unnatural to me, and I thought maybe I was trying to mash together too many different themes, so I focused on the sea aspect:


I hope you like it.

I intend to make others but I'll be spacing these out for a few days as I dig into the assimilation and vdev programming parts giving me hassle in Pigeon.

#13 Re: Off-topic » Arguments against systemd » 2017-10-07 01:39:06

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.

devel wrote:

Yes, systemd sucks, but this is really misinformed

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

but at least it is factually correct from all I can tell.

So which is it? Misinformed or factually correct?

2) This needs a lot of tin-foil,

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.

1) Systemd is an umbrella project, that contains a lot of different pieces. Most of it is unrelated to PID1.

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.

3) Some parts running in a severely restricted environment had bugs. These are unrelated to PID1.

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

4) That happened, but things got fixed anyway.

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

5) PID1 does not do DNS,


Here's mine:

systemd-resolved now includes a caching DNS stub resolver
          and a complete LLMNR name resolution implementation. A new
          NSS module "nss-resolve" has been added which can be used
          instead of glibc's own "nss-dns" to resolve hostnames via
          systemd-resolved. Hostnames, addresses and arbitrary RRs may
          be resolved via systemd-resolved D-Bus APIs. In contrast to
          the glibc internal resolver systemd-resolved is aware of
          multi-homed system, and keeps DNS server and caches separate
          and per-interface. Queries are sent simultaneously on all
          interfaces that have DNS servers configured, in order to
          properly handle VPNs and local LANs which might resolve
          separate sets of domain names. systemd-resolved may acquire
          DNS server information from systemd-networkd automatically,
          which in turn might have discovered them via DHCP. A tool
          "systemd-resolve-host" has been added that may be used to
          query the DNS logic in resolved. systemd-resolved implements
          IDNA and automatically uses IDNA or UTF-8 encoding depending
          on whether classic DNS or LLMNR is used as transport. In the
          next releases we intend to add a DNSSEC and mDNS/DNS-SD
          implementation to systemd-resolved. … ec9c#n1128

that is a separate process, Being able to change any file in a container is inherent in all container management tools, never heard of remote PID1 (do you have a reference here?)

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

systemctl's -H switch for connecting to remote systemd
          machines has been extended so that it may be used to
          directly connect to a specific container on the
          host. "systemctl -H root@foobar:waldi" will now connect as
          user "root" to host "foobar", and then proceed directly to
          the container named "waldi". Note that currently you have to
          authenticate as user "root" for this to work, as entering
          containers is a privileged operation. … ec9c#n1500

6) A part of systemd will use Google DNS servers if nothing else is configured by the distribution nor the administrator. So if this ever happens, it is far from systemd only that fucked up.

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

undermines the credibility of devuan

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.

7) But systemd restarts services that break! It surely is great for servers!

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'?

8) is mostly a matter of preference.

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

Developers like systemd a lot,

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

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

that is why it gets used everywhere,

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?

leading to the entanglement that devuan sets out to unmake.

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?):

* "Security": I ran into a lot of people that claim that their systems get more secure with systemd since it makes it so simple to restrict what daemons can do. It would be great if Devuan could tune its init scripts to run all daemons with the same restrictions as they run on Devuan to show that this can be done with any init system.

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

* "Portability": The systemd crowd will argue "Why is that important?" Do you have any argument for that? Is there any init system that is used widely between different OSes?

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.

* "Development Capabilities": Why does so much software depend on systemd if developers are hindered to do what they want? Any good argument for to counter that?

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:

* "Flexibility": Why is that? All inits just start stuff up, why would one way to start stuff be less flexible than another?

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

Systemd is an umbrella project

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.

* "Visual Appearance": I do not understand what this point is about at all. You can surely run X11 and wayland and text based terminals in systemd, too?

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.

* "OS footprint size": The counter to your argument I get to that is "but systemd does so much more" and "sysv-init needs a shell, core tools and a lot of other cruft that is built into systemd, so systemd is actually lighter on resources". How to counter that?

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.

* "Stability": I have not seen anybody debate that systemd is more stable than sysv-init yet. Did you run into that claim yet?

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.

"WONTFIX" is not a thing on github, it is just something used colloquially to mean "a bug closed without any action being taken". All the "WONTFIX"es in systemd are just closed bugs and thus part of the graph you referenced.

It would be nice if we could get the facts straight so that it is harder to reject our claims as invalid.

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

#14 Off-topic » Arguments against systemd » 2017-10-05 22:41:06

Replies: 28

Whilst I'm aware most users here will be familiar with the arguments I'm about to present, this is more aimed at new users who are unfamiliar with the whole systemd crisis, and is built to both inform and refute some pretty stale arguments I've seen. Please be aware that for the purposes of this argument, I will have to quote adversarial sources to catch key points, and users are informed this list is not exhaustive.

Arguments against:

1) Systemd was declared an init system which has bloated beyond scope and context. Programmers call this "feature creep", and it's well known for producing buggy and unstable code. Quoting the least informed source of information Wikipedia:

Following its integrated approach, systemd also provides replacements for various daemons and utilities, including the startup shell scripts, pm-utils, inetd, acpid, syslog, watchdog, cron and atd. … _libraries

Annnd it also controls the firewall, port forwarding.

It has gone from an init system to a total bloat that guzzles packages like Red Hat's paychecks depended on it. Besides "feature creep" this has a number of issues:

a) Red Hat were dishonest regarding the intention of systemd as 'just an init system' from the outset, and used it to deceive members of the Linux/Unix community (duping them into accepting it), and thus is basically a trojan, and thus cannot be trusted.

b) Systemd replacing everything violates the Unix philosophy of 'do one thing and do it well'. We'll cover why this is important in more depth later on, but basically this move does not allow the best packages to succeed, but only the systemd ones, which degrades user performance.

c) Systemd has no boundaries, and ergo is basically turning into a monolith. Monolith OSes are extremely hard to maintain (see Windows), and this undermines package flexibility, which in turn stifles competition.

d) Any OS that does not fall within systemd's grasp is fundamentally rejected, which lowers the number of available OSes for users to choose from. This is bad from the user's perspective.

2) Red Hat, who build systemd, work for the NSA, XKEYSCORE (a notably X-server themed name) is deployed on Red Hat servers to that effect.

3) As no surprise to anyone, systemd is inherently insecure, such as allowing remote code executions via DNS, or gaining root by adding a digit to the start of your username. Having dug into this, systemd's main developer Poettering had stated that 'users are root by default', as opposed to be, err, users.

4) Poettering & co often refuse to fix blatant bugs within systemd. Including the two security flaws above, quoting the register verbatim:

The issue was raised through a GitHub Issues submission a week ago, but Lennart Poettering, one of the lead maintainers of systemd, insisted the software is working as intended and declined to implement changes. … _accounts/

IE systemd is intentionally insecure by design. The attitude of not fixing bugs and blaming everyone else also means buggy code that might even crash your machine has no fix date or period. Not so much collaborative as controlling.

5) All of this. The biggest eye openers from that list include:

a) "pid 1 does DNS" (for non-nerds, PID1 is the master process, which should only be occupied by a simple OS process restarting script. Giving an internet connection access to your master process is basically backdoor city)

b) "systemd-nspawn can patch at will any kind of file in a container" - basically encrypted containers can be backdoored.

c) "remote pid 1" - I think this one is pretty self-explanatory.

6) Systemd prefers to dial home to google servers by default, quoting:

Since the Google resolvers are a very reliable widely anycasted service
which third parties are encouraged to use they actually look like a sane
fail-safe default, hence I am closing this bug.

Ah, good job reliability of a single server service is the only criterion and not say, DNS redundancy (IE multiple DNS fallbacks) through several censorship resistant networks.

For those of you unfamilar, Google were previously funded by In-Q-Tel, the CIA's investment arm[1][2], regularly found abusing their positions of power[1][2][3] and regularly censoring people[1][2][3][4][5], or even plotting coup d'eats certainly make it a questionable choice, especially against the backdrop of free and open software for the greater good not censored by anyone.

7) The design of systemd is bad for anyone who runs servers (which is ironic given Red Hat mostly deal server side).

The increased bloat of 'ever more' dependencies means 'bare metal' OSes running in VMs is not realistically possible, and those wanting to keep their servers as lightweight as possible (you know, to save footprint space and CPU) are immediately denied by the presumptious nature of systemd that basically tells you, the user what it wants (perhaps an accurate reflection of the attitudes of the systemd developer's writings). It's no coincidence that Alpine Linux, built primarily for servers and VM containers (and security) boots up with... err, OpenRC. The over-reliance of sticking everything into PID1 which increases the risk of an actual system crash runs contrary to the mandated stability required by servers and their uptimes.

8) 'Do one thing and do it well'

There's a reason why programmers, developers, coders, designs etc do not have 'all-rounder' abilities; most try to specialise in a specific area of knowledge, and get good at that one specific area. For example, I would not expect a network programmer to start handling graphics (unless there was, somehow, overlap between the two, such as a remote session), or for someone who builds user interfaces to go around telling library developers what to do.

Systemd, by adopting so many disjointed and unrelated packages to it so-called 'init' claim, is arguing that it doesn't just specialise in 'inits', but in every other package that it absorbs, which is patently absurd (they can't even do the init part right, what with it's backdoors and crashability, see above). Even if we assume they're walking masters of everything (which they're obviously not), the more packages they take on, the less manhours they have available to package development, which means, you guessed it, fewer bug patches and fewer security patches.

This also means another thing; fewer features. Packages having their own dedicated developers who know it inside and out can build features into it in a dedicated way (IE more efficiently, thus using less code and less CPU), which in itself allows other developers to use those packages more effectively. By absorbing everything into a monolith, it becomes the monolith's maintainer's responsibility to add features, which means their knowledge is applied more generally.

There's a famous saying: many hands make light work, and in this case, merging too many packages spoils the broth. What exactly is systemd? Init? Networking? Login? Logger? Firewall? Calendar? We don't know; the overall monolith itself becomes less maintainable because more knowledge is required by new developers before they can even properly approach the thing, where-as separate, isolated packages can be easily taken up and managed.

So to round off, who exactly benefits? So far, we've established:

a) Desktop users don't benefit (less package selection, less OS selection, less security, bigger footprint space on their harddrive, greater odds of crashing).

b) Server users don't benefit (repeat).

c) Developers don't benefit (more entangled mess that 'absorbs everything', giving package developers no way to be able to introduce their own packages, hard to read documentation, poorly kept code, inaction on bug and security issues, refusal to collaborate, refusal to accept blame when appropriate).

d) Corporations [other than either Red Hat, Microsoft, and possibly Google - assuming they're okay with Android systemd pwnage] don't benefit (see counter-arguments).

Who in their right mind would want this kind of setup?

1) Red Hat (removes competition, more profits to them if everyone is using their kit, if it causes issues they get consulted)

2) Agencies (introduces insecurity, exploitable bugs, backdoors) [irony here is given they use Red Hat technology, they're making their own stuff insecure.]

3) Microsoft (remove competition. The division alone is scoring them points).

And as far as the Linux/Unix community is concerned, at least two of those are the bad guys.


P1) Systemd offers improved boot times.

A1) Boot times are pretty unimportant in the grand scope of things. Rarely do users complain of how long their computer takes to boot (unless it happens to be loading a Windows OS on a decrepit machine), and Linux init systems have always kept boot times within perfectly acceptable constraints, which comes down to a subjective psychological perception and not a logical hard fact (for what purpose are we trying to make boottimes 'faster'? This isn't an episode of 24 where a missile will detonate unless we can run a bash script within 30 seconds).

It's curious that this is one of the few arguments 'in favour' (if boottime is your only justification, I've got a brick over here that boots instantly), when a system has a multi-tude of factors (and boot times must be pretty unimportant given how many people still use Windows OSes), factors which include:

1) Security. [systemd violates this]

2) Portability. [systemd violates this]

3) Compatibility. [systemd violates this]

4) Development capabilities (IE how easy is it for the developer to build or implement what he/she wants?). [systemd violates this]

5) CPU speed. [systemd does not offer any enhancements]

6) Flexibility. [systemd violates this in a big way]

7) Visual appearance (EG text versus graphics, ability to choose desktop enviroments). [systemd violates this]

8) OS footprint size. [systemd violates this]

9) Stability [systemd violates this, see bug patching attitudes and PID1 obsession above.]

Essentially, Red Hat is asking 'are you willing to sacrifice major features of your OS (IE complete freedom) for a couple of seconds off your boot time'? Any sane person would say 'no'.

P2) Systemd offers corporations predictability/consistency.

A2) Corporations looking for 'predictability' or 'consistency' can and usually do go one of two routes; they either choose to build their own in-house OS (often on-top of a Linux/Unix etc system, for example, Apple, Google, Nintendo, Sony etc), or they go down the Windows route (Windows already offers 'consistency' plus a huge dollop of 'adaptability').

If corporations go down the former route - which they often do - they want to be able to customise the OS to their needs, and this is where systemd crashes into a wall and bursts into flame. By restricting init systems and blocking package flexibility, corporations cannot customise their copy of Linux/Unix etc type OSes because it's already 'locked in'.

There's a double downside to this, because it also means only Red Hat holds the experience (can anyone say 'money'?) and 'as a service' organisation, being able to anti-competitively form a monopoly on Linux/Unix etc designs actually hurts corporations when it comes to Linux/Unix because it means they can either choose Red Hat with systemd, or they basically choose nothing at all. I'm sure someone from FreeBSD will scream out they're systemd-free (try installing KDE or XFCE and then eyeballing for /lib/systemd), but the trojan horse nature is unlikely to stop at just 'every Debian OS ever'.

In conclusion:

If users truly care about privacy, security, stability and freedom, and does their due diligence research into systemd, they would recognise no-one in their right mind would want a systemd setup, and should not merely adopt a passive approach to it, or sit on the fence and watch, but take an active participatory refusal as if the NSA itself had come round in person and offered to install backdoors. If we don't show we wholly reject such a monolithic monstrosity, it will merely encourage them to try again, sooner and elsewhere.

#15 Re: Devuan Derivatives » Early doors: King-Pigeon series and friends [AKA Modular Linux] » 2017-10-05 18:50:30

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

curl >

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

curl … | bash

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

#16 Re: Devuan Derivatives » Early doors: King-Pigeon series and friends [AKA Modular Linux] » 2017-10-05 17:41:53

King-Pigeon ASCII upgrade has a couple of issues (seems to be with the dist-upgrade process? Unclear):

There's no LXDE shutdown or reboot option (terminal also doesn't acknowledge shutdown or reboot as commands.) [edit: using VM to send a shutdown signal results in nothing happening. Does the dist-upgrade pull across all appropriate options, or has this been disabled due to systemd madness?]:


There's no internet connectivity (ping successfully reaches targets specified as IPs, but dig, with URLs does not: does the ASCII dist-upgrade correctly set the DNS?):


Also, minor visual error in King-Pigeon logout image isn't present but that issue is my end.

For clarification: These issues do not exist in the Jessie King-Pigeon conversion, and only appear after a dist-upgrade is executed.

#17 Re: Devuan Derivatives » Early doors: King-Pigeon series and friends [AKA Modular Linux] » 2017-10-05 17:06:30

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.


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, 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 to deploy Modules. Subsequent calls will do, but should be included in Modules by then. If not, simply delete the directory (and report the bug).

#18 Re: Devuan Derivatives » Early doors: King-Pigeon series and friends [AKA Modular Linux] » 2017-10-05 04:48:02

greenjeans wrote:

4. File-roller? Gonna drag in a lot of gnome crap isn't it? Maybe some nasty gtk3?  I would try Engrampa, same thing but more Mate-ish than Gnome-ish.

Bad news my friend.

I did a dependency check in King-Pigeon ASCII comparing Engrampa and File-roller:


  Depends: bzip2
  Depends: caja-common
  Depends: engrampa-common
  Depends: gzip
  Depends: p7zip-full
  Depends: tar
  Depends: libatk1.0-0
  Depends: libc6
  Depends: libcairo-gobject2
  Depends: libcairo2
  Depends: libcaja-extension1
  Depends: libgdk-pixbuf2.0-0
  Depends: libglib2.0-0
  Depends: libgtk-3-0
  Depends: libjson-glib-1.0-0
  Depends: libmagic1
  Depends: libpango-1.0-0
  Depends: libpangocairo-1.0-0
  Breaks: engrampa-common
  Recommends: gvfs
  Recommends: mate-icon-theme
  Recommends: unzip
  Recommends: xz-utils
  Recommends: zip
  Suggests: arj
  Suggests: binutils
  Suggests: cpio
  Suggests: <lha>
  Suggests: lzip
  Suggests: lzma
  Suggests: lzop
  Suggests: ncompress
  Suggests: rar
  Suggests: rpm2cpio
  Suggests: rzip
  Suggests: sharutils
  Suggests: unace
  Suggests: unalz
 |Suggests: unrar-free
 |Suggests: unar
 |Suggests: unrar
  Suggests: p7zip-rar
  Suggests: zoo


  Depends: bzip2
  Depends: p7zip-full
 |Depends: dconf-gsettings-backend
  Depends: <gsettings-backend>
  Depends: libarchive13
  Depends: libc6
  Depends: libcairo2
  Depends: libgdk-pixbuf2.0-0
  Depends: libglib2.0-0
  Depends: libgtk-3-0
  Depends: libjson-glib-1.0-0
  Depends: libmagic1
  Depends: libnotify4
  Depends: libpango-1.0-0
  Recommends: gvfs
  Recommends: yelp
  Suggests: arj
  Suggests: <lha>
  Suggests: lzip
  Suggests: lzma
  Suggests: lzop
  Suggests: ncompress
  Suggests: rpm2cpio
  Suggests: rzip
  Suggests: sharutils
  Suggests: unace
  Suggests: unalz
  Suggests: unar
  Suggests: unzip
  Suggests: xz-utils
  Suggests: zip
  Suggests: zoo

Both pull in libgtk-3-0 as a dependency.

I'll have to eyeball some other archiver at some point.

Edit, forgot to mention:

Good news for everyone:
The standalone works on King-Pigeon (Jessie). However at present it requires manual input, and seems to take an extremely long time. It (the upgrade) also installs a couple of unwanted extras (EG gnome-screenshot), however I will build custom scripts for King-Pigeon etc to remove that.

#19 Re: Devuan Derivatives » Early doors: King-Pigeon series and friends [AKA Modular Linux] » 2017-10-05 00:39:56

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 '' 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!)

#21 Re: DIY » Howwww... aaaabout some Dev1 backgrounds, hey? » 2017-10-04 06:15:39

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.

#22 Re: DIY » Howwww... aaaabout some Dev1 backgrounds, hey? » 2017-10-03 23:49:34

fungus wrote:

I can't get into the purpy thing no matter what, but otherwise they are great.  For a while I thought I was seeing a human figure under the U on the plasma theme.  Something like the great reaper would go well with purpy.

What sort of colour scheme would you like to see? I'll make a few new ones for your tastes.

Ogis1975 wrote:

Very nice! Already stolen it. Keep a good work!

Will do, thanks for the compliments.

Looks nice on the dark background of the site page. Thank you for the visibility!

greenjeans wrote:

That top one is gorgeous, Devuan-Hulk approves. wink

I'll make more along those lines, feedback always appreciated!

#23 Re: Forum Feedback » Registration questions are questionable. » 2017-10-03 23:11:58

golinux wrote:

Tor doesn't work for registering either.  Have you seen Can't register because you are a 'spammer'?  If someone gets thwarted by the spam measures and really wants to be here, they can contact us to do it manually.  We've done it several times.  Personally I despise captchas.  But let's see what the backend admins think about your suggestions.

As to trolls . . . have you read our (almost) no code of conduct?

Your enthusiasm is commendable.  But your thoughts have been a bit much for me to process.  Mostly I tune out after about two paras . . .  wink

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.

fungus wrote:

Condition:  Thousands of bots trying to break into a public forum/list
Response:  Admins trying to keep out bots
Solution:  No anonymous users ever participate in the forum
Question:  What are the identity criteria for a bot?

1st of all the user does not see any bots, so it is logical to doubt the admin.
Admin is not interested what users think, she/he does what it takes to keep the forum "safe and functional".

Question/Hypothesis:  In an organic/bio gardening forum, there may be thousands of users, but there haven't many bot attacks.  Why do bots attack linux forums in specific (if they do)?


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?

#24 Re: Devuan Derivatives » Early doors: King-Pigeon series and friends [AKA Modular Linux] » 2017-10-03 22:39:13

Yep. I still got a lot of things to learn about Devuan.

greenjeans wrote:

I kept thinking about this project yesterday, and it struck me that the very detailed listings in that script would be perfect for a live-sdk "blend" file too, that may be something to look at.

I've never heard of a live-sdk blend file before, could you tell me more about it?

I probably could run off and do a search but I often find Linux documentation to be patchy at the best of times.

Your basic template you have up now works pretty good as a base, i'm trying to document the changes I make to things better so I can write a blend myself at some point, not necessarily for my own project but something more targeted at just basic improvements, connecting installed programs and making the user environment better, dotting the i's and crossing the T's so to speak.

Let me know if you find any 'garbage' programs/packages that need removal or possible improvements for King-Pigeon.

I totally get using file-roller over x-archiver, I swapped it too with engrampa mainly because engrampa supported more file types out-of-the-box and the user interface seems a tad better too.

I'll definitely try it out at some point. I am looking to reduce GNOME dependencies ever since they opted to sell out and move towards systemd so this should be helpful, although as this will be older GNOME I'm not too worried (yet!). With 47,000+ packages plus the ability to build from external git, it should be possible to develop workarounds for this. My main concern is systemd at this stage, and I encourage people to change their copy of King-Pigeon how they see fit, as it's kinda like <insert your own packages here>.

fsmithred wrote:

The version of yad (0.38) in the ascii repo uses gtk3 and does not work will with refracta tools - buttons are off-screen. I made gtk2 verions in jessie, but they seem to be working fine in ascii - … _packages/

Or, you could package them yourself. I already made the one or two small changes for gtk2.

I previously posted on your forum under the username Gravimetric after I had issues with the Liveboot portion.

The text version works nicely from manual install, but my concern is both maintainability and usability. How does one update a manual install? And is a user going to want to use text?

Without trying to be rude (but written text always does sound like it), Devuan dev team might want to sort out Refracta so it's more consistent on Jessie/ASCII, because as I mentioned on fsmithred's forum, Refracta is secretly Devuan's biggest strong point, and whilst it is technically external to Devuan, it's allowing for so many spin-off OSes based on Devuan to be made, which is fundamentally drawing power away from systemd OSes, which is, of course, what we want. We have to show that a monolithic, all-encompassing monstrosity is beaten out with adaptability and flexibility.

Ideally Devuan should aim to draw both disgruntled developers who have been shunned by systemd and users likewise (more users, more visibility; more visibility, more developers), and Refracta is definitely enabling that. I wouldn't be here without it, as ISO creation kits are notoriously difficult to find or use, and Refracta is one of the better designed ones I've seen so far. Sure, I could learn to build an OS from scratch but the complexities involved consume vast amounts of time, and why reinvent the wheel?

Anyway, getting off-topic there, for current purposes King-Pigeon does what it needs to (regarding Devuan ISO deployment choice), just wanted to answer the queries of why I didn't do things a particular way. Believe me, I prefer easier routes, I usually only divert via scenic if the easy route isn't easy or isn't available.

#25 Re: Off-topic » When you can't tell the difference between Windows and systemd » 2017-10-03 22:14:13

FOSSuser wrote:

That surprises me about OpenBSD, it's Canadian based, & when I use it, it is with Fluxbox & Firefox, it must be the programs that are added bringing it in. sad

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.

Board footer

Forum Software