My username ain't lying, I am in fact "ESR".  If that declaration makes you sit up and pay attention, good - it was supposed to.

Practically, I want to get the hell out of systemd-land before that gigantic crock collapses into rubble. Theoretically, Devuan's premise - holding out for Unix modularity and loose coupling against monolithic monstrosity - appeals to me greatly.  I do respect and admire what the Devuan crew has done so far on a purely technical level, something I especially need to make clear because I'm going to use strong language about some things Devuan has *not* done - and needs to.

To set the scene, here's how my house net looks:

I have an experimental install of ASCII  running on a fanless compute brick (hereafter "grue") downstairs. Its twin brother, hereafter referred to as "grelber", has been running stable under Ubuntu 16.04 LTS as my mailserver for a couple of years - that's the first machine I'd like to Devuanize. They have a potential triplet, "hurkle", which is just now in pieces on my worktable.  All three are a brand called Jetway, if that matters - generic Chinese mini-PCs intended for use as media centers and in light industrial computing. 

There  are two upstairs machines. The first, my wife's home-office machine, is "minx", an Intel NUC running Mint 19 - I've tried to Devuanize that and failed.  The second is snark, aka the Great Beast, my desktop, running Ubuntu 18.10. The network glue is quintaped, a CeroWRT-equipped router which will not make any further appearances in this rant because it Just Works.

In an ideal world, I'd migrate all of these to Devuan.  I can't yet.

The near subject of this diatribe is the problems I discovered while attempting to convert my house machines.  The far subject is how Devuan can stop shooting itself in the foot. If you want to have more devs, you need to attract a larger userbase.  To attract a larger userbase, you have to be friendly - or at least not passively hostile - to new users. Right now, Devuan is passively hostile, not just to non-techies but even to old Unix/Linux hands like me.

Yes, I know you inherited a lot of this passive hostility from Debian; now stop making excuses and face the actual problem.  If the fightback against systemd is going to be won (and I'd like to see that) it's not going to be won by outcompeting Debian but by *demonstrating superiority to the mass-market distros*.

The problems start with choosing an install image.

Here'a a clue: if the user has to *choose* an install image, you've lost the plot before he/she even got started.   To be fair Mint and others make this mistake too, which is one reason Ubuntu stays stubbornly dominant.  But, again, stop making excuses: to beat systemd you have to beat Ubuntu, and that road starts with outcompeting the Ubuntu installer.

No, I'm not talking about choice by hardware - of course you need different installation images for different host processors, that's unavoidable.  I'm talking about bullshit, pointless distinctions like "classic" vs. "live" or "desktop" vs. "server" installers.

Sure these are different use cases for the installed system.  There is no reason for these cases to have different *installers*, though (large thumbdrives are cheap), and three excellent reasons they shouldn't.

1. User confusion and frustration.  A user-friendly experience does not start with "Oh no, which installer image do I pick?" and follow with "Oh, shit, I got to the 43rd prompt and realized I got the wrong installer, now I have to waste time starting from scratch." A user-friendly experience starts with a frictionless install in which the user is guided through a fanout of installation types by questions from the *one* installer.

Anyone who comes back at me with "Oh, no, these choices are easy, you just read this obscure piece of documentation or these buried release notes or this particular web page" is announcing loudly that they have *no clue* what "frictionless" means.  If you want to beat back systemd - which means beating Ubuntu and Red Hat - you have to be smarter than this.  You have to build your installer as if no documentation outside it exists or ever will.

Anyone who comes back at me with "But, nobody gets this quite right" gets answered with "That's called 'window of opportunity'.  Do you want to argue for your limitations and fail, or fight back effectively and win?"

2. Inconsistent behavior.  When you have multiple installers you will have genetic drift and inconsistent behavior.  I have been personally bitten by this; the "Live" installer offers to install drivers (some of) my Jetways need, but the Classic one does not.

Hello?  Hello?  Is there intelligent life here?  That behavioral divergence just said "We don't care if we frustrate our users; they can deal with our bad choices or fuck off to Ubuntu/Mint/Red Hat." 

3. Total defect load.  Multiple installers are duplicative.  It's simply bad software engineering to repeat yourself - takes more effort, invites more bugs.

So. *One* installer. Which is also the live image - you know, the way Ubuntu does it.  There's no reason one installer couldn't cover the whole range of desktop and server installation cases from text-only minimal up.  For extra credit, give the ARM live image the capability to flash the SD on an RPi.

Anyone who says "If you think this is such a good idea, do it yourself" is missing my highest-level point.  To attract and retain the devs who can do these things the Devuan crew needs to demonstrate that it has a clue about what better user experience looks like and is willing to make the strategic commitment required to get there.

Anyone who says "Well, if you don't accept Devuan's present style and design objectives, what are you doing here?" gets answered with "Accept limiting design objectives as now defined and remain an almost-irrelevant niche distro, or play to win. Choose one."  And if you choose to lose, there's certainly no reason for *me* to stick around.

Second major topic: proprietary firmware blobs.

Look, I don't like those any better than the next guy. But you've inherited from Debian a set of practices about them that is counterproductive and insane, and you need to fix it.

Debian practice: Don't install those blobs by default. Require user to explictly opt in or out to proprietary things as a class *before he/she knows whether any are actually needed*.  (At least I think this is Debian behavior. I've never done a Debian install; it could be worse.)  Make a big ideological deal about being "pure".

"Worse" is what the Devuan Classic installer does: never offers to install them at all. You end up where I was, with higher display resolutions on one of my my Jeways not working and me having no clue why. (Radeon chip; enough said.)

Someone actually said to me on #devuan IRC "Well, you have to read the release notes to find out how to install the proprietary firmware blobs."  Which is pretty much the same as saying "We don't care how painful the install is, users who aren't old Linux hands can just get stuffed."

What is anyone involved in this clusterfuck actually *thinking*?

If being a software-purity refusenik about proprietary firmware blobs put any pressure at all on hardware vendors, there might be some shred of justification for this nonsense. Clue: it doesn't.  They don't care and will never need to care. Your virtue-signaling is pointless.

The only way you can drive these blobs out of existence is by outcompeting them - doing what they do *better* in open source. Until then your "purity" only harms Linux users without having any positive effect at all.

Since hackers seem to be *particularly* dense about this, I'll make some logic explicit. When I bought the Jetways I wasn't thinking about avoiding hardware that needs proprietary firmware blobs - because it's not practical to do that; the hardware blacklist is too big and complicated to apply when you're shopping on Amazon or Newegg.  And I'm an *expert* at this compared to J. Random Newbie.

Often you can't even *get* to the relevant facts about the hardware.  One of my Jetways (grue) needs the Radeon blob. The other (grelber) doesn't. If you think the Amazon listings for these puppies gave me any clue either way, you're dreaming.

When I got grue and found out after a long, tortuous series of diagnostics that I need to manually install firmware blobs, it's wasn't the vendor that had screwed me over and wasted my time; it's the distro that could have installed them automatically, no muss, no fuss - but didn't.

The right way to handle this would be with install-time dialogues that say things like: "Your graphics chip is a a Radeon card that requires a proprietary firmware blob to run at resolutions above SVGA. Install?" And then default that to "Yes", because your job is to *enable* your users.

If that's too complicated, install all blobs rather than risking that a missing one will degrade performance.  Because your job is to enable your users, not make an ideological point about which the vendors will never, *ever* care.

This is the person who discovered and wrote down the economics of open- vs. closed-source business models telling you to stop being stupid about it.

Third topic: stale kernel.

Two weeks ago, when I upgraded my wife to an Intel NUC from an aging tower system running Ubuntu that had developed flakiness in its graphics card, I wanted to upgrade her to Devuan.  Couldn't do it.  I had to fall back to Mint 19, and my window is closed now.  If I destabilize minx when I don't absolutely need to Cathy gets upset - and with good reason, these migrations are *always* pains in the ass.

The problem turned out to be that the Devuan ASCII kernel is too old. The list of vendor-ID/subtype pairs for the e1000 didn't include the subtype the NIC on the NUC has.

The e1000 is not weird hardware, and the NUC series is pretty popular.  This is the universe's way of telling Devuan its release frequency needs to increase.

I think this is a minor problem compared to the others I've pointed out, but worth a mention.

What I'm willing to do:

At the moment, I can't justify putting more effort into improving Devuan myself. That's because none of my production machines are running it yet. When that changes (and I want it to) budgeting some of my time to pitch in could happen.

There is no way I'd even consider destabilizing the Great Beast before I have successful experience with multiple Devuan installs.

I am much further away from the point where I can shout from the rooftops: "Hey everybody!  Devuan is a good thing and you  should totally switch!"  Because right now, considered as a polished, user-friendly distribution - a competitor to Ubuntu or Mint - Devuan still sucks pretty badly.

That can change.  But the existing Devuan community has to *want* it to change, first.  In this diatribe I've tried  to make the case why you should.

I can't make that choice for you.  What you decide about this issue of direction will, more than anything else, determine whether I stick around.