For the heads up, I haven't actually made or stated to make or even know how to make and OS, so far I plan on looking at more of the theory behind it, and making a plan of what I want to accomplish before starting and change the said plan as I progress so I can see my own progression.
I currently use ArchLinux as my primary OS, and for any that do not know of it, it is a rolling release Linux distrobution, from my experience with using it, I much prefer the rolling release model to static releases, so I wonder how one would go about creating an OS that is rolling release, hypothetically. Is it more or less simply updating the kernel and packages on-top of themselves or is there a more important underlining process to it? Furthermore, would you also need to make the operating system self compilable for this to occur?
Thanks in advance for any input
Rolling Release?
- Combuster
- Member
- Posts: 9301
- Joined: Wed Oct 18, 2006 3:45 am
- Libera.chat IRC: [com]buster
- Location: On the balcony, where I can actually keep 1½m distance
- Contact:
Re: Rolling Release?
As a gentoo user (which is a rolling release too) I've seen a few things that you might want to be aware of.
The thing is that once you update something, then the interfaces might also change. New functions can be added, older ones can be removed, a totally new interface may be in place. If you update some library and the interfaces change then you should check all the dependent programs to see if they still work.
To manage this kind of thing you need a form of package manager that can either fix broken dependencies, or warn the user of their Bad Idea. Since it needs the information present on your system, it might as well be running on your system, which means that other applications should work too. (including the stuff needed for self-hosting)
You can of course distribute things as precompiled binaries, but that wouldn't help you when some program requires the new version of a library, and a different program wasn't updated and will only work with the old version.
That should give you a good start to think about.
The thing is that once you update something, then the interfaces might also change. New functions can be added, older ones can be removed, a totally new interface may be in place. If you update some library and the interfaces change then you should check all the dependent programs to see if they still work.
To manage this kind of thing you need a form of package manager that can either fix broken dependencies, or warn the user of their Bad Idea. Since it needs the information present on your system, it might as well be running on your system, which means that other applications should work too. (including the stuff needed for self-hosting)
You can of course distribute things as precompiled binaries, but that wouldn't help you when some program requires the new version of a library, and a different program wasn't updated and will only work with the old version.
That should give you a good start to think about.
Re: Rolling Release?
I would, IMHO, switch away from a rolling-release OS while attempting to develop and OS. The reason I say this is because your code may work with one version of gcc/(f,n,m,t,y)asm/binutils/bochs/qemu/virtualbox/etc... but out of nowhere there may be a new update that trashes your code and you will have a hard time figuring out what. Also, a lot of the rolling-release OS's tend to fight with you over downgrading things, it usually tries to update it back to what it wants.
I personally stay away from rolling releases, and if I do use one, I turn off the non-critical patch updates.
I personally stay away from rolling releases, and if I do use one, I turn off the non-critical patch updates.
Website: https://joscor.com
- JackScott
- Member
- Posts: 1036
- Joined: Thu Dec 21, 2006 3:03 am
- Location: Hobart, Australia
- Mastodon: https://aus.social/@jackscottau
- Matrix: @JackScottAU:matrix.org
- GitHub: https://github.com/JackScottAU
- Contact:
Re: Rolling Release?
Which is one of the very good reasons to use a GCC Cross Compiler (as documented in our very own Wiki). Having a version of GCC that's not under the OS's control is a great way of making sure it doesn't get updated.