Serpent OS Pre-Alpha-0 released(serpentos.com)
serpentos.com
Serpent OS Pre-Alpha-0 released
https://serpentos.com/blog/2024/08/01/serpent-os-prealpha0-released/
53 comments
I don't know the author but it's worth keeping in mind that... Sometimes people end working on a project because
- 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.
- 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.
Absolutely, thanks for pointing that out. I really hope it didn't come across as condescending, as I didn't intend it to be - because I have the same habit. Do something until it's not exciting anymore and move on. Though unlike myself more often, he tends to actually finish what he's working on initially.
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.
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.
Sometimes you start a project, more and more people start to collaborate, and eventually most of the project's contributors want to move it in a direction that doesn't interest you.
At that point you can either be a spoilsport, or step away amicably.
At that point you can either be a spoilsport, or step away amicably.
I would add:
- 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.
- 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.
I was a Solus user back when Ikey left. It was highly unusual, maintainer team had no insight, and frankly as a user it left a fairly bad taste.
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.
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.
It might be an "OS" but it has a Linux kernel. It's a self-acclaimed "pioneering Linux distribution". It has some features other distros/tools implement to some extent as well: rebootless atomic upgrades, rollback. See Fedora/rpm-os-tree, Nix etc.
Why someone would want an imperative distro over a declaratively configured one?
Because most real-world problems are subject to hysteresis [1], and declarative systems fail very badly at modeling history.
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.
[1] https://en.wikipedia.org/wiki/Hysteresis
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.
[1] https://en.wikipedia.org/wiki/Hysteresis
No idea. It seems to have gone off in the direction of "shiny and new" without deeply considering more practical architectural decisions like isolating system vs. userland, configuration management, or manageability. It's unfortunate because there are zillions of Linux distros, and most of them (numerically) are terrible, insanely impractical, user hostile, and/or poorly documented. If you're going to create a distro, at least have a use-case justification for it where other distros or other OSes ([wd]o|ca)n't meet the needs of them adequately.
> It seems to have gone off in the direction of "shiny and new"
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.
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.
> 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.
What I meant was: the thesis has to be crystal clear rather than building into the aether "organically" by hope and wishes rather than practical need. This is a similar failure of coding away on a "startup" without sales only to discover no one needs or wants to buy the result.
Time and time again, Linux distros create messy, commingled system with user dependencies that increase system entropy and footgun stability. Even Alpine isn't immutable or really self-contained. The major, novel departure in this area was Core OS.
As an example under-served category in the marketplace: If one wanted to create a more resilient server OS, I would evaluate bringing together aspects of the following:
- Qubes - app isolation
- RHEL - kernel
- Rocky/Alma - governance
- Core OS - system isolation
- NixOS - package management
- FreeBSD - development, integration, and QA as a system
- (N/A) - fleet management (missing in 99.999% of Linux distros)
What I meant was: the thesis has to be crystal clear rather than building into the aether "organically" by hope and wishes rather than practical need. This is a similar failure of coding away on a "startup" without sales only to discover no one needs or wants to buy the result.
Time and time again, Linux distros create messy, commingled system with user dependencies that increase system entropy and footgun stability. Even Alpine isn't immutable or really self-contained. The major, novel departure in this area was Core OS.
As an example under-served category in the marketplace: If one wanted to create a more resilient server OS, I would evaluate bringing together aspects of the following:
- Qubes - app isolation
- RHEL - kernel
- Rocky/Alma - governance
- Core OS - system isolation
- NixOS - package management
- FreeBSD - development, integration, and QA as a system
- (N/A) - fleet management (missing in 99.999% of Linux distros)
> Why someone would want an imperative distro over a declaratively configured one?
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.
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.
Had to click around to figure this out: it’s yet another Linux distribution. Seems to be focused on quality-of-life for Rust developers.
prealpha is such a weird name, just call it a dev/nightly build or an actual alpha
Beta is typically close to feature complete.
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.
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.
For the level of development I would consider preAlpha, I would count myself lucky if it built on any given night.
I think of it as, "hey, this one doesn't immediately implode. Let's let people look at it"
I think of it as, "hey, this one doesn't immediately implode. Let's let people look at it"
I find it very hard to get excited about this shell-scripts-in-YAML-with-macros language:
https://github.com/serpent-os/recipes/blob/b269cef9b42645b89...
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_installIt’s ikey! I’ll follow this and when it goes to beta really dive in.
> Rebootless atomic updates - no more interruptions
Does 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.
Does 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.
linux (the kernel) supports "Kernel Live Patching" and several distros provide the updates to do it
As I said. It is technically possible, but it is relatively elaborated (for the provider of these patches). As far as I know you don't get them without having an online account at the provider of these patches.
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/...
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/...
did they implement the linux system call interface or come up with their own? how linux-compatible is it? it must be pretty complete if it can run firefox
> We're creating Serpent OS, an independent Linux distribution built from the ground up to look after itself.
I'm pretty sure it is a Linux distro, if slightly unusual userspace.
why are they calling it an os then? cosplaying arnold kling?
Its fairly common to refer to Linux distros as an OS, or even include OS in the distro name (Pop!_OS, NixOS, CentOS). Linux is the kernel, and disros add stuff to make a functional operating system.
[deleted]
It's a trademark thing; there are some prerequisites and manual approval involved before you get to officially name your distro "[Distro Name] Linux".
https://www.linuxfoundation.org/legal/the-linux-mark
https://www.linuxfoundation.org/legal/the-linux-mark
that's not much of an excuse for pretending to have written an os; the only real requirement in https://www.linuxfoundation.org/legal/sublicense-agreement is that you acknowledge that linus torvalds owns the linux trademark
ChromeOS
SteamOS
PopOS
ElementaryOS
EndeavourOS
ZorinOS
CentOS
SerpentOS
Cosplayers, all of them!
SteamOS
PopOS
ElementaryOS
EndeavourOS
ZorinOS
CentOS
SerpentOS
Cosplayers, all of them!
MacOS
MacOS is not a Linux distribution, though.
Well why are they calling it an OS then!
Because it is one? Linux distros are a subset of OSs.
Because at Apple, everyone was under the Ontological Supposition that Jobs was the second coming.
[deleted]
macos is an actual operating system, a variant of mach
It is true that macOS is a bad example here because it is not using a Linux kernel.
But Apple also names operating systems that use the same kernel different "OSes": iOS and iPadOS share a kernel with macOS, and for all I can tell, so do watchOS and tvOS.
An operating system consists of both a kernel and a userland. The Linux kernel by itself does not make an OS. I think this makes it legitimate to call CentOS, NixOS, SerpentOS, iOS, watchOS, etc., OSes.
But Apple also names operating systems that use the same kernel different "OSes": iOS and iPadOS share a kernel with macOS, and for all I can tell, so do watchOS and tvOS.
An operating system consists of both a kernel and a userland. The Linux kernel by itself does not make an OS. I think this makes it legitimate to call CentOS, NixOS, SerpentOS, iOS, watchOS, etc., OSes.
> iOS and iPadOS share a kernel with macOS, and for all I can tell, so do watchOS and tvOS.
Even worse is that iPadOS and iOS are effectively the same operating system, one ships with a phone dialer and the other ships with UI tweaks for tablets. I would not be shocked if they are built from the same source tree.
Even worse is that iPadOS and iOS are effectively the same operating system, one ships with a phone dialer and the other ships with UI tweaks for tablets. I would not be shocked if they are built from the same source tree.
i think the ios and centos people are putting on airs because they wish they were ken thompson
Without being too pedantic, MacOS was to Unix what ChromeOS/AndroidOS is to Linux so I stand by my comment.
unlike, say, illumos, macos doesn't contain anything genetically descended from the v6 unix kernel; the darwin kernel is mach, with chunks of freebsd grafted into it, chunks that carefully reimplemented without copying the functionality in original unix
by contrast, 'chromeos' and android run on fairly normal linux. they even keep up with linus's tree, and though they do have their own patches, they try to get them merged back into linus's tree
by contrast, 'chromeos' and android run on fairly normal linux. they even keep up with linus's tree, and though they do have their own patches, they try to get them merged back into linus's tree
For an ISO, "Live Mode" can be one of the most useful things.
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.