I did Linux From Scratch once. I got it to the point it was booting a kennel that supported everything I needed, had a working init (sysv), a helper script that "installed" packages (symlinked stuff to integrate them into the system) and kept "recipes" for whatever I compiled.
If I had kept going and compiled everything I needed and kept maintaining that I'm guessing it would have been pretty close to the Slackware experience, right?
It was very cool to know I can do all that and I learned a lot but if I had kept going I feel like it would have become limiting rather than empowering.
Like, it's cool to go camping and catch your food, and cook it, and sleep outdoors and to know you can survive in the wild, but I wouldn't want to have to do that every day.
The problem with making the core immutable is that you have to decide where you draw the line between immutable and regular packages.
It sounds nice to be able to always have an immutable blob with some built-in functionality that you can fall back to, but the question is how far do you want to take that blob?
Things that go into the immutable blob don't offer much (if any) choice to the user. I can see it being used for something like the kernel and basic drivers, coreutils, basic networking. It starts getting blurry when you get to things like systemd and over-reaching when it gets to desktop functionality.
Also, you say it's more reliable but you can get bugs in anything. Version x.y.z of the kernel can have bugs whether it's distributed as part of an immutable core or as a package.
I definitely think distributing software as immutable bulk layers can be useful for certain device classes such as embedded, mobile, gaming etc. The Steam Deck for example and other devices where the vendor can predefine the partition table and just image it with a single binary blob.
On the desktop however I struggle to see what problems immutable solves that are not already solved some other way. Desktop machines require some degree of flexibility.
Immutable was adopted for Android because Google and the Android vendors wanted to lock down the platform, and because they always distribute their OS images and updates as binary blobs.
It offers no benefits to an open ecosystem like Linux, that you can't already accomplish with existing security measures.
It offers some benefits to distro maintainers who are only willing/able to focus on the core system and delegate the rest of the software to distro-agnostic packages. That's definitely an interesting niche and I look forward to it. But please note that whether the core is immutable is completely irrelevant in this scenario.
Generally speaking, if you want to use distro-agnostic packages you can do that regardless of whether the system is immutable or not.
And since we're on the topic, if we're borrowing things from Android I would love to have the application sandboxing and permissions. I think they'd be a much bigger benefit – to all distros, immutable or not.
Copyright licensing allows the owner to control how a work is distributed, not how it's consumed.
First of all, that's incorrect.
Secondly, by default you have zero rights to someone else's work. If something doesn't explicitly grant you rights, you have none. If there's a law or license, and if it's applicable to you, you get exactly what's specified in there.
The "personal use" or "fair use" exceptions in some places grant some basic rights but they are very narrow in scope and generally applicable only to individuals.
Just because something is available for public viewing does not mean it's licensed for anything except personal use.
The strawman here is that since physical people benefit from personal use exceptions in the law, machine learning software should too. But why should they? Since when is a piece of software ran by a corporation equivalent to an individual person?
But denormalized databases are not a new thing. There are engines that build on it on purpose in order to be more efficient, like Cassandra. Most data warehousing engines use this "trick". And of course you can do it with a regular RDBMS too.
To some extent all software is disposable. Some places take it to a more ridiculous level than others. If they have money to burn just make sure as much of it as possible ends up in your pocket.
Unfortunately all the volume-based email providers I know (Purely, MXroute, Migadu) are one or two-person operations. Doesn't stop them from being excellent, of course.
I wish the volume-based pricing model was more popular but unfortunately very few people know about it, and is course the large providers prefer to charge by account or add all kinds of artificial limitations because they make much more money that way. Having multiple mailboxes for the same domain costs the provider nothing and yet you get charged per mailbox.
Use a volume-based email provider like MXroute, where you pay strictly for the resources you consume (storage space and mails sent) not made-up limitations like number of accounts, aliases, domains etc. that cost the provider nothing.
Kubuntu comes with snap support but you can uninstall it and the default snaps, mark the snapd package as forbidden and that's pretty much it.