OSDev.org

What is your oppinions about ideal updating periods of OS-es?

Originally, i planned to release a new version of Dawn maximum once per year (or, more likely, once in every 2-3 year).
But it turns out i basically cant stand bugs if i alreday fixed them, so Dawn is usually having monthly one release.

Of course Dawn will always have the same IO and binary compatibility forever forth and back, so updating the system for the users on they machine is not obligatory.

Therefore, a major, compatibility breaking releases will never appear, so technically i can do releases again and again.

Dawn is very flexible, so i can do this kind of rapid release cycles. I basically will dont need to do a lot of security-related patches, as Dawn does not have user management or protected mode, so there is nothing to crack about that.

There could be other security-type bugs, of course, and they must be fixed, or other kind of bugs causing data losses, but nothing that needs short release cycles. So its technically not justifiable for me to create monthly one release, and it even takes hours to do it (compiling it, copying the disk image, editing the webpage, uploading mirrors, etc).




So what is the oppinion on this? Is more release anoying, and less release is better? Or more release is better, as it gives more confidence and trustability about manitenance?

What could be an ideal release cycle for an os like Dawn, and what could be an ideal cycle for other types of OS-es?

Hi,

Geri wrote:What is your oppinions about ideal updating periods of OS-es?

My theory is that:

a) Software should not be officially released at all until it's "finished" (all intended features implemented, all known bugs fixed, all in-house testing passed). If you release too early people's first impression of it is bad (incomplete, buggy) and it takes a huge amount of work to change their original impression.

b) Updates for critical security patches should happen as soon as possible; with no delay to fit a regular release schedule.

c) Updates for features and performance improvements aren't important (because the software wouldn't have been released at all if they were important) and can/should wait until either a security patch makes the update necessary anyway, or (ideally, when there's no security updates) for no less than 12 months since the last update.

d) Every update should be accompanied by a heartfelt apology. Something like:

• "We (the developers) sincerely apologise for failing to avoid this update and inflicting hassle, time and cost onto you (the end user). We will continue to do our best to ensure that no further update will be necessary. The reasons we were unable to avoid this update are: ...."

Cheers,

Brendan

You want genuine points of view, so I'll write mine without reading Brendan's first.

An OS update is annoying, potentially dangerous, and there will always be breakage, no matter how carefully you intend to craft things. Perhaps something as simple as a user screwing up with the instructions, or a power failure in the midst of the update process. Perhaps compatibility issues rendering a system that "just worked" into a nightmare of "nothing works anymore". (Been there twice -- madwifi and Xorg were the culprits back then -- and am right in the middle of a third "experience" of that kind with some breakage in the vicinity of pam_ldap.)

Thus, an OS update should only be made if there is value added to the user experience.

This can come in two flavors:

• Security updates, bugfixes. These should be released ASAP (but no sooner). They still are annoying, but they are necessary.
• Feature updates. These should be tested to hell and back before being inflicted even on the betatesters, let alone end users. Don't stick yourself to a time cycle. If you have something, release it. If you don't have something, don't bother.

From the above it should be clear what I think about "release early, release often".

aha, so we heard two (three, including mine) very similar oppinions, with minor differences.

so basically everybody agrees about the instant release of security/integrity updates, and everybody (or at least you two) thinks feature updates can wait until they are tested a bit, and working properly.

but even i agree on this, there is one big problem with this:

-if you started to implement a feature which may not 100% complete, and you discover a vulnerability, you have to release it with the not so greatly tested feature (which maybe can have a security problem again)

-you can only skip to release the not so complete feature, if you copy an older version of source code (back fork+backport), fix the vunlerability/security problem there too, and release that, so you dont have to make a release with a maybe incomplete feature, which can be extremely annoying.

would you do the backport, or would you release with an incomplete feature silently?

Hi,

Geri wrote:but even i agree on this, there is one big problem with this:

-if you started to implement a feature which may not 100% complete, and you discover a vulnerability, you have to release it with the not so greatly tested feature (which maybe can have a security problem again)

-you can only skip to release the not so complete feature, if you copy an older version of source code (back fork+backport), fix the vunlerability/security problem there too, and release that, so you dont have to make a release with a maybe incomplete feature, which can be extremely annoying.

You'd hopefully have some kind of revision control; and hopefully have a "stable branch" and "not released yet branch". As soon as you find out there's a security vulnerability you'd stop whatever you're doing, add security fixes to the stable branch, test it, and (re)release the fixed stable branch as soon as possible. Then you'd make the same security fixes (if necessary) in the "not released yet branch", and continue whatever you were doing before. Eventually (when the new feature is ready) you'd release the new version; and after that (possibly after it's been in use for a while without any bug reports) you'd rename the branches so that the old "stable branch" becomes a deprecated version, and the old "not released yet branch" becomes the new "stable branch"; and then you'd create a new branch to start work on the next feature.

However; all of this ignores my (previous) first point: software shouldn't be released until it's "finished", so you should never be working on any new feature after anything has been released.

Also note that my perspective is a micro-kernel developer's perspective, where there's many separate/isolated pieces; and where you can write one piece (e.g. micro-kernel) until it's finished/released and then hopefully never touch it ever again, then write the next piece (e.g. VFS) until it's finished/released and then hopefully never touch it ever again, then write the next piece (e.g. ATA driver) until it's finished/released and then hopefully never touch it ever again, then... It occurred to me earlier that this doesn't work for some cases (e.g. big monolithic "spaghetti monster" kernels where you have to release a new version of the kernel every time a new driver is created, even though people who don't have the device the new driver is for won't notice any difference if/when they "update"); but I'd consider those to be cases of extremely poor engineering (e.g. you could have "modular monolithic with stable driver interfaces" to avoid the pain of pointless updates).


Cheers,

Brendan

I disagree

I don't think monolithic vs micro makes any difference at all to this topic -- an OS update is an OS update and includes all the same things regardless of whether the update touches the kernel or not (of course, imho, new drivers shouldn't be considered "updates" at all, but rather new software installs) -- so it doesn't matter if the changes are in a single component or in the kernel or in multiple separate distinct components, from the end-user perspective, an update is still an update whether it is an update to fix the VFS, or an update to add a VFS because you originally released without a VFS at all because the VFS wasn't "finished"


edit: of course if your end user/admin needs to know what a "VFS" is -- or even that there is such a thing as a "VFS", I think you have already failed (all the typical user knows is that the "OS" needs an update)

I don't think components like a microkernel or a VFS can ever be "finished". Like monolithic kernels, they have to adapt to changing environments. Unless we are in fairy tail land and you (and every person that will ever contribute to your OS) get everything right from the start.

Demanding that components are completely finished also kills innovation as it prevents developers from iterating fast and correcting mistakes. However I do acknowledge that stability is something that users want. Projects like the Linux kernel do what Brendan suggested and never ever change existing APIs again while other projects make more liberal use of deprecation.

Hi,

JAAman wrote:I disagree

I don't think monolithic vs micro makes any difference at all to this topic -- an OS update is an OS update and includes all the same things regardless of whether the update touches the kernel or not (of course, imho, new drivers shouldn't be considered "updates" at all, but rather new software installs) -- so it doesn't matter if the changes are in a single component or in the kernel or in multiple separate distinct components, from the end-user perspective, an update is still an update whether it is an update to fix the VFS, or an update to add a VFS because you originally released without a VFS at all because the VFS wasn't "finished"

My point was that if everything is a single blob of source code (e.g. Linux), it's impossible to release a new driver without releasing a new version of the single blob of source code.

It's modularity that makes the difference - "big monolithic"spaghetti monster kernel" vs. "modular monolithic with stable driver interfaces" (or micro-kernel, or ...).

JAAman wrote:edit: of course if your end user/admin needs to know what a "VFS" is -- or even that there is such a thing as a "VFS", I think you have already failed (all the typical user knows is that the "OS" needs an update)

I'd assume there's some kind of "OS updater" that determines a list of pieces that are needed, compares version numbers for whatever pieces are already installed to version numbers in some sort of (online or on-disk) repository to create a queue of things that need to be updated, then (possibly after admin approval) downloads and installs pieces that need to be updated. The user doesn't necessarily know what is being updated unless they care enough to look.

Korona wrote:I don't think components like a microkernel or a VFS can ever be "finished". Like monolithic kernels, they have to adapt to changing environments. Unless we are in fairy tail land and you (and every person that will ever contribute to your OS) get everything right from the start.

Demanding that components are completely finished also kills innovation as it prevents developers from iterating fast and correcting mistakes. However I do acknowledge that stability is something that users want. Projects like the Linux kernel do what Brendan suggested and never ever change existing APIs again while other projects make more liberal use of deprecation.

The point is to try to release pieces that are "finished" and never need to be touched ever again (using research, planning, testing, etc). Of course there is a massive difference between trying (and possibly failing) to release pieces that are "finished" and releasing pieces that actually are "finished" in practice (without ever failing).

There is also a massive difference between trying (and possibly failing) to release pieces that are "finished" and not trying at all (e.g. slapping together whatever happens to "sort of work for now" with no research or planning; then unleashing a long stream of updates that could've been avoided with some hindsight).


Cheers,

Brendan