I -believe- I read that a lot of this work will be going into Solus, a previous Ikey project, which has a new team and small community now. So hopefully this is kinda best of both worlds if true for both sides.
- it has no future, ran its course, proved wrong somehow
- cannot add more that others could do better
- an alternative makes more sense long term
It's true that many people end working on something because it gets too hard or they lack focus.
But in this case, seeing the breath of the projects, this is not the case.
I guess I was trying to paint a short historical picture and why I'm pretty excited about it as a Solus user - its package manager is a bit long in the tooth. I think could be a really great relationship having one team/person prototype and another adopt into something more stable.
At that point you can either be a spoilsport, or step away amicably.
- it accomplished the task of teaching some technology/language/practice to the author, so that it becomes subjectively useless after that knowledge is absorbed.
Sometimes people start building a car because they need an incentive to practice making wheels.
But, Ikey had his reasons, and as I've grown up a bit over the years, I realize it is okay. Other maintainers picked up the tab pretty well, and for all its worth, quite a few of those maintainers have joined Ikey on this new distro, which signals a reconciliation.
Combined with other comments, I'd say what happened at Solus was imperfect, could have been communicated better, but probably still couldn't be avoided. Such is life.
A very simple example:
* install a server program, which for security is run as a dedicated (newly-created) user
* run the server program, which generates logs owned by that user.
* uninstall the server program - but the user must not be deleted while the log files exist
This example is simple enough that many declarative systems don't require too much massaging to handle it, but many more complicated examples exist.
Ikey's last foray into distro-building also left same impression on me.
> without deeply considering more practical architectural decisions like isolating system vs. userland, configuration management, or manageability
I dunno, FWIW, Solus was very well regarded in UX for a while. It had the best steam integration, and the whole thing felt fairly well thought out for something built and maintained by half dozen people.
> If you're going to create a distro, at least have a use-case justification for it
That is unfair. The developers felt there is a gap between fully imperative state-modifying mudball and fully declarative purity-land, which is true, and decided to try their hand at it. How well they did is yet to be seen.
Perhaps most people are not aware of the difference or why it should matter?
After years of reading and study I only have a vague and hazy understanding of functional vs imperative languages, and what one can do in a functional language.
I have not seen any project built around functional programming that really makes a serious effort to explain why it is different or why anyone should care. My overall impression is that most take the attitude of IYKYK -- "if you know, you know" -- and don't even try.
While this is an understandable response to years of incomprehension and lack of interest, it's still a poor response.
I have spent _hours_ talking with Nix folks trying to get a better understanding and for the most part I have failed.
I would guesstimate that 99% of programmers do not understand FP vs imperative programming and so neither know nor care about FP.
So when the definition of efforts such as Nix and Guix is "we specify configuration using a pure functional language", most readers won't know or care what that means.
The Reddit-ism of "explain it like I'm 5" is a powerful criterion.
I look for people who can give me clear, simple, lucid explanations of what their software is and how it works. When nobody can, I tend to suspect that the software is either not much general use, or that advocacy for it is not based on facts and understanding but by clan loyalty.
Projects which few people can cogently clearly explain to me without jargon and bafflegab include Kubernetes, OStree, and OpenShift. It is, notably, a hallmark of Red Hat, and I speak as a former employee. I was hired to work on one product's documentation. I found that nobody in the company could explain what the product was or did, until I met the 1 person who came from the company that wrote it and which RH acquired.
I think I have an extremely sketchy understanding of the point of Nix and I have tried to explain it, but I am sure it is a weak, poor understanding.
More effort to explain what it means and why it matters would go a long way.
If people were clearly told what "declarative configuration" meant, what it was and what it did and how it worked and why they might want it, then maybe they would care.
I suspect, but do not know, that most do not.
Alpha is basically not close to feature complete.
Pre-alpha is check this out but here be dragons! For an OS it makes sense, seeing failure typically means a hard reboot.
I think of it as, "hey, this one doesn't immediately implode. Let's let people look at it"
https://github.com/serpent-os/recipes/blob/b269cef9b42645b89...
setup : |
%patch %(pkgdir)/enhance-config.patch
%patch %(pkgdir)/0001-Make-sway-stateless.patch
%meson -Ddefault_sysconfdir=%(vendordir)%(sysconfdir)
build : |
%meson_build
install : |
%meson_installDoes it mean the same as in all other distros when you install packages and they restart the services? Or does it actually replace the kernel as well? Maybe a stupid question, but the latter would be revolutionary, even if it is technically already possible, but very elaborated.
If the latter is not true, you should still reboot after a kernel update and there is not much difference to most other distributions.
But the questions was: Does SerpentOS have the ability to change the kernel without reboot?
Edit:
> This will mean that the /lib/modules tree may not have the current kernel version, but the OS will still be usable while having had a live atomic update. Of course, to use the new kernel you must reboot. Unlike other atomic OS implementations, it will be up to you when you do so: no more deferred updates!
https://serpentos.com/blog/2024/04/30/calm-before-the-storm/...