Huh. I run four monitors for screen real estate. Two of them are 1920x1080, one is 1920x1200 (the resolution $DEITY intended) and one is an e-ink monitor with a native resolution of 3200x1800, but the text is way too small for me, so I run it at 1800x900.

The e-ink monitor is easiest on my eyes, but needs a manual refresh every so often because the black pixels don't get completely reset when the image changes.

My boyfriend has a 4K monitor, which is huge. I prefer my tradeoff over a massive 4K monitor.

Agreed. Starbucks coffee is disgusting. When you've tasted proper coffee in places like Europe or Australia, you can never go back to the Starbucks slop.

A more relevant question might be if the satellites have non-European electronic components.

I'm sure they do. But I bet most/all of those can be sourced outside the USA.

Agreed. Starbucks coffee is disgusting. When you've tasted proper coffee in places like Europe or Australia, you can never go back to the Starbucks slop.

I think we are witnessing the software equivalent of Planck's Principle.

Parallel startup? Who cares with the hardware speeds we have today.

I care a lot about this on my laptop. It makes a significant difference.

I argue that anything that systemd does, you can write an init script that does the same job with around 1 million less lines of code, less bugs, less attack surface, and 50-75% less processes running in RAM.

And I'd argue that you're wrong. Does the average sysadmin write init scripts with the same care that software developers (are supposed to) take when they write software? That is, using version control, writing tests, having code reviews, etc? Maybe some do, like around 1% of them. Most spit out a script and never look at it again as long as it "works".

In my opinion, the less code an admin has to write to get things done, the better.

When every Linux distro that matters is using systemd, it's not much of a lock-in.

And guess what? I distribute email-filtering software that runs on a wide variety of UNIX systems. I include sysvinit scripts for systems that use that, and systemd units for ones that use systemd. There's no lock-in.

OK, so you disagree with my point 3. How about the other 5 points?

So much wrong.

Devuan is free and you no have dependencies on suppliers

So Devuan ships zero packages from third-party suppliers? That's a hot take.

Uses less energy because less is running in memory

Another hot take. A program sitting in memory uses essentially no energy unless it's scheduled to run.

One of my recent email servers, with dovecot 2.4 and postfix, has only 121 running processes.

My Raspberry Pi server running dovecot and postfix has 247 processes, but it also runs PostgreSQL, Asterisk, an IRC server, a mattermost-to-irc bridge, home automation software, Pi-Hole, Xymon, nginx, and a bunch of other things. If I do: ps auxww|grep -c [s]ystemd the answer is 9. Oh the horrors! 9 whole processes!!!!

Finally, I think you'll find that in most cases, systemd machines are not slower than non-systemd ones, and in my experience, they boot quite a bit faster.

Yes, I obviously have a lack of engineering skill... hmm... M.Eng in Electronics; seven engineering patents to my name; retired on the proceeds of selling a successful software company... yeah, that's it. Low skill for sure.

LOL. It's so funny how insecure people get personal instead of actually discussing technical merits.

Everyone is a "guy" dude. You aren't special man.

In case it's not obvious, about 50% of people are not "guys". I guess sysvinit folks are not great at seeing cases outside their own experience. :)

Change just for the sake of change isn't a good thing.

Yes, I agree. However, on balance, I think systemd (or something like it) is a good change for a number of reasons I've outlined in other posts:

1. Easy ability to do dependency management.
2. Ability to start services in parallel (which flows from 1).
3. Remove the necessity for every service to write its own daemonization code; you can just let systemd do it for you.
4. Standard way to run services as a non-root user
5. Standard way to use newer Linux features like cgroups and namespaces.
6. Standard commands for monitoring and controlling the status of a service.

All of those things can be (and probably have been) implemented in sysvinit environments, but usually as hacks. systemd at least standardizes the procedures and reduces the amount of hacky sysvinit code support required.

OMG, lookit the triggered snowflake! LOL. A whole paragraph to whine about a simple two-letter spelling correction.

Meh, whatever. If you don't want to use systemd, that's fine. But debate it on its merits, not because its author has an abrasive personality or because it doesn't follow some nebulous "UNIX philosophy".

A few things that are hard to do with sysvinit scripts: Parallel startup, dependency management, and management of running services. Also, every service has to duplicate the bits of code needed to properly daemonize a service under UNIX, instead of having the service manager do it for them. Glibc does have a daemon library function, but it is non-standard.

There are hacky or ad-hoc solutions for all of these things, but they no longer really resemble the "simple" sysvinit scripts of the past.

I remember when people joked that Emacs stood for "Eighty Megs And Constantly Swapping"

*sob* VSZ of a current Emacs at startup is about 740MB and RSS is over 90MB.

But I still use Emacs. My muscle memory goes back 36 years and it's not going to change.