Ncmcpp, MPV with scripts

ConnectBot is fine.

It doesn't support OPDS-PSE, which is the most common way of tracking progress.

It actually has a ui. But it looks minimal enough. I'll try it.

the added difficulties of making it system agnostic did not compensated for the low user base

• 2003: Udev was launched, providing support for musl, non-systemd distros, and others.
• 2004: NetworkManager was launched, with Udev as a crucial dependency.
• 2006: Dbus was created without dependencies on distro-specific packages.
• 2009: Dbus becomes a dependency for NetworkManager.
• 2010: Red Hat introduces systemd, with core components including logind, journald, and timers.
• 2012: Developers made udev less compatible with old kernels, musl-based, and non-systemd Linux distros by merging it with systemd. You can find more information about this here: https://lwn.net/Articles/490413, https://lwn.net/Articles/529314/
• 2017: PipeWire was launched, with logind as a dependency.
• 2017: Reimplementations of the bus protocol called dbus-broker were launched. Its compatibility launcher requires systemd.
• 2020: After systemd had already been adopted by all major distros, systemd-tmpfiles gained the ability to be built as a standalone executable.
• 2022: WirePlumber was launched, with pipewire as a hard dependency.

Looks like Red Hat makes everything they can systemd-dependent. Including Gnome.

It's really cool, when automation tools create more problems than they actually solve.

Gollum. Hit integration is required if you value wiki content.

There is really no reason to implement extensively audited runC in C, but the Dev only has the journey, no goals.

Not really. Best Foss projects do not always thrive. Git wasn't really better than mercurial. But it had happened to be published earlier, so it got wider adoption.

Kavita, same as Komga requires too much RAM.

Komga can track ebook reading progress, by converting them to images.

Fortunately such "new choices" get abandoned very quickly. Making new solution instead of improving existing ones is counterproductive. Unless there is a large legacy codebase. Smart people have invented Unix principles to avoid that.

Wayland is like Busybox runit. Xorg is like SystemD.

Some seem to use Debian.

Linux Libre makes Guix unusable on most hardware. It also requires much effort to configure. Learn scheme, how to use shepherD, etc.

IMO the closest one.

Openrc...

If you will create "next gen" desktop, you will just solve some problems of already existing ones and create your own. Maturity of software is far more important, than uniqueness. GNOME didn't evolve into its current state for no reason.

Not really. Void, alpine, gentoo are the only usable ones(besides non-systemd forks of arch and Debian). These are the only ones maintaining enough packages, providing enough documentation, not being just poorly maintained forks of X distro.

Yes, systemd modules depend on systemd, that's like complaining that a GUI application depends on X.

SystemD is not modular. Logind is just an executable that depends on systemD libs. Red Hat could design it to be init-agnostic(similar to elogind). But they didn't. Any assumptions, why?

There is an example: https://www.agwa.name/blog/post/how_to_crash_systemd_in_one_tweet

See the answer on your logind statement.

The thing is that it can work. Which shown by eudev. Looks like it's important for Red Hat to make everyone dependent on SystemD suit.

I deleted it. No need for two almost identical posts to exist.

It doesn't, that's ridiculous, several distros don't use systemd and still have udev

Void uses eudev. Alpine uses eudev. Gentoos uses udev with patches. What non-systemd distros use vanilla udev?

Because they don't execute million lines super thoroughly checked shell code or why exactly? Without any explanation total FUD.

Because they are not merged with journaling system, job scheduler and watchdog. More features→more attack surface.

Compare it to vulnerabilities found in SysVinit, which was as common as systemd-init is now. There were no similar bugs, that would allow crashing an entire system just by executing a single command.

What an average Mint user gains from systemd? A bit slower boot time? A bit more ram used? 50mb heavier system updates? What problems systemd solves? I use systemd, runit and openrc on different machines and I don't face any significant problems.

Again, more attack surface does not mean anything, to add to that example most people use the precompiled kernel that comes with their distro instead of compiling a leaner one to diminish attack surface, because that's irrelevant.

Most people also don't use selinux or apparmor, compile the kernel with -ftrivial-auto-var-init=zero and verify downloaded files using pgp signatures. But it doesn't mean these things are irrelevant. Even your phone has selinux=enforced option set. Why do you think your pc is not worth it?

Misconfiguration is possible in any software. It's not specific to sysvinit or systemd-init. Selinux was created to solve this.

Really? Didn't known. Lemmy.today seems to not work properly on mobile apps.

in there.

Whonix Dev quote:

Use a distribution with an init system other than systemd. systemd contains a lot of unnecessary attack surface... ©Linux Hardening Guide

It's a matter of probability. Probability of discovering vulnerabilities in multiple tools doing same thing is higher than in just one.

Why do we invent new DEs instead of making proper settings app in already existing ones?

We know.