hunger

Filesystem enable age verification in pretty much the same way as systemd does: You can optionally store a user's birthday. That is such a ridiculous statement.

To be fair: None of the other inits cared for udev. None contributed or helped by providing features they wanted to improve udev. The systemd devs care for the lower level plumbing overall... and not just for the init system. So it is very natural for low level plumbing projects to land under the systemd umbrella today.

Systemds track record wrt. security flaws is actually pretty good. Not many went through the cracks,maven though some were indeed pretty ghastly. Hardly any was in the core functionality, most were in new code not widely used yet.

On the other hand, the service hardening that systemd enables has improved the overall security of a typical Linux system by quite a lot.

What you can expect when switching from a system management tool written for Linux to an init tool targetting the least common denominator of general Unix functionality?

Less functionality, less security, less information about the state the system is in, less reliable switching between states and a whole lot less of linux kernel features exposed to your use in convenient ways.

It's not as if systemd was started to be complicated, the world got complicated. E.g. we used to just create all the device nodes in /dev statically during system installation. Then USB became a thing and supported so many different kinds of devices with thousands of potential ports to connect them to. They would not fit into the device node namespace! So we needed to make device nodes dynamic, which is also convenient.You do not have lots of device nodes that do not exist on your system and you no longer need to change system configuration when you plug your mouse into another port of your system.

Filesystems, security (often linux specific) features, everything is easy more complex (and more dynamic) today than it was when sysv init was a thing. That simple stuff was great when you had to power off your machine to change its available devices. It is less cool when you plug an USB-C cable into your laptop and want to use all the stuff that is now suddenly available.

What did you write to the lawmakers in California?

You do not even need to patch it out. It is basically an extra entry in the user db (think: /etc/passwd). Just don't fill it in and you are done, just like your location and a ton of other stuff you can put there if you want to.

Nobody can read it outside your system either... it's a defined place when (not if -- not anymore) something wants to store that information. Better have a properly protected defined place ready than have 10 different programs request that info separately and store it all over the place.

More than that: "its only an init daemon that does not even make use of Linux features". They all try to work on all posix systems while systemd is Linux-only and uses everything the kernel can offer to make things safer and more reliable.

Immutable distros are the future for everything. We just need to wait a for the people most heavily invested into the status quo to retire.

Any user can delete important OS files by turning their computer off while an upgrade is running in almost all traditional distros:-) Sure, you can disable updates, but that is not an option either.

First off, you do not need to know most of that stuff. Tooling around container-based development is really nice nowadays. It just works almost all the time -- and way more often than in mutable setups.

As a beginner you can not really transfer docs from one distribution to another, so you look for docs on your distribution and ask in the official support channels. Those of bazzite are pretty responsive and will be able to help. The community is able to help way better than in a traditional system where every installation is almost but not exactly the same.

Nothing is as bad as accidentally removing some important OS files and not knowing how to restore them. That will just not happen in an immutable setup.

I have installed immutable distros on lots of computers and the users usually are happier than they were on traditional linux: Nothing breaks anymore, the setup is way more solid. Its great for me, too, as I need to support them less often.

Seriously, you should give this a try: Immutable OSes are a huge step forward. Takes a few days to get used to, but I am pretty sure you will not want to go back afterwards.

The OP has no experience with either immutable nor mutable linux. So let him go with the rubust version already installed over recommending some package-based, old-school distro, just because you are more familiar with those.

OP will need to learn things either way, let him learn the future proof stuff, not the outdated ways.

Actual developer and 30+ years Linux expert.

Don't use anything but immutable distros for development work. Hands down.

Just develop in containers and have one container per project. Doing anything else will lead to broken projects as you can not properly control dependencies per project otherwise.

It is not harder to work in a container than on the real system.

I revolve very much around copyleft and its ideology. Free software formed my entire career, just as it did for the founders of Slint. From my point of view slint is GPL and offers some other license options for users that do not want GPL for whatever reason.

Forking slint is just as easy as forking any other GPL licensed project: Take all off slints code under GPL and you are done. Yes, you can not relicense that fork to a more permissive license without replacing all the code that you did not write... but that is exactly the same as with any other GPL project you fork. Any use of Slint under GPL is exactly as using any other GPL project, with the same obligations and protections to all parties involved.

I get that you are feeling slint is not GPL, but I do not understand where that feeling comes from. Is it "just" because there is a company backing it? Or because that company is selling their product in addition to oing it under GPL? That is fine for the GNU project from all I understand. Or is it because of contributions happen under MIT terms? But that does not effect the end users that the GPL is protecting in any way.

So to be a GPL project you need to be able to trust the project to release all future releases under GPL in addition to having released existing code under GPL?

I do not like this approach:

First of, you need a crystal ball to decide whether a project is GPL or not: Some projects managed to pull off a license change before, just by asking devs whether they are ok and replacing code from devs that did not agree. Its rare, but it happens, so checking for CLAs, copyright assignments, ..., is not enough.

Secondly this definition excludes lots of projects that release their source code under GPL, including the GNU project. They ask for copyright assignment, both to defend the GPL license, as well as to be able to relicense when weaknesses in the current licenses are found. I give you that GNU is probably way more trustworthy wrt. not changing away from the free software spirit than some random company.

You are fine with a free software project using Slint as well: Slint is a GPL project, with everything that implies. The releases are out there and the slint project is bound to the terms it released them under. In theory we could release new versions without the GPL option, but we can not take the sources of the released versions away. Neither the other licensing options nor the contribution rules change that. If youbare happy with GPL dependencies, you can use Slint just as any other GPL dependency, with the same risks and benefits.

The copyright holders of any GPL project can decide to relicense their (future) releases. I admit that it is a bit simpler in Slints case due to the contribution rules, but other projects have similar rules in place. Copyright assignments, CLAs, ..., they all exist to simplify a possible future relicensing effort. And even GPL projects without such provisions in place have manged to relicense before.

As a user of Slint you typically never get into contact with our contribution setup at all. Only a contributor might pause and decide not to spend time on Slint due to that. IMHO that is entirely normal: I use tons of free and open source projects that I would never contribute to -- for various reasons ranging from contribution terms, to programming language being used or the projects community.

In many cases you can also publish slint related code in your own repository under whatever license you like. While this obviously does not work for core functionality that has to live in Slint itself, it does work for a wide range of things you might want to make available (like new widgets, ...).