Reinvent the OS cont

[Fats]

I find it funny how DragonFly keeps coming up as a buzz word among amiga users, but how many of those mentioning it has actually used it?!

I do have it installed in a VM but did not actually use it much. I'm more a Linux guy than a *BSD guy.
The reason DragonFlyBSD is mentioned is of course because of Matt Dillon who has a history in the Amiga world. (People who know what a Fish disk is should also know Matt and DICE).
He did base some of the internals of DF on Amiga architecture. AFAICS they are not exported to user land but I think that is the first thing to do for a retought incompatible Amiga-like OS.
Personally I think anyone who want to come up with a totally new OS architecture is DOA (dead-on-arrival). The OS market is mature enough that I think it is impossible to get track on something totally different (see it like the flying cars etc.). GNU bootstrapped on commercial UNIX, Linux bootstrapped on GNU, Android bootstrapped on Linux, all *BSD bootstrapped on original Berkely UNIX, MINIX is now using NetBSD, Win NT has links with VMS although there are debates on how strongly they are, ...

Although my AROS dev work (any Amiga dev work actually) is really low to non-existing at the moment one of the goals for me was to see how far one could go with the Amiga architecture and API without breaking backwards compatibility.

[Fats]

I'm sorry to see good, committed AROS developers dropping out just as the project is reaching completion.

FYI, I did not drop out; I'm just hibernated

[Fats]

... but what tires me the most is the absence of any stable interface between kernel modules and the core kernel code in Linux - this interface changes on a daily basis, essentially disallowing vendors to program against a stable API. Either, you as a vendor have to continuously clean up behind the kernel hackers and adapt to the latest API changes, or you have to release your source code and have to have somebody else do the dirty work for you.

One way or another, it is an approach that does not scale very well. It only works because a lot of people put a lot of time into keeping the kernel running.

It is only a problem as you say if you don't want to release the source code of your driver so most of the kernel devs see that as a feature and not a problem.
Once you have done the job of getting your code in the kernel it will be maintained. In the meantime you likely also have improved the quality of your code considerably.

[Fats]

You forget one thing. Even if I release the source code, it means that the source requires continuous updating and maintaining to keep it working with the kernel. Now, which company wants to make this commitment, namely not only release source, but also employ engineers to continuously update the source whenever the kernel interface changes - i.e. with every release.   Using the passive here means that you don't know who maintains it. It is like throwing source code over a wall and hoping somebody picks it up, and that this "somebody" has enough knowledge and experience to do a good job. That is a problem for professional software engineering.  

If you are lucky, you do not need further commitment. If you are not so lucky, your driver will stop working with the next kernel release and your investment is lost.

True that just releasing the source code is not enough; you need to do the job of getting your code up to kernel standards and upstream it. But this is a one-time effort and from then on your driver will be maintained by the kernel devs; if some internal ABI changes your driver will be updated if needed before the ABI change is included in a release kernel.

Examples? Last week, kernel update, but vmware does no longer work. Some obscure call in the network layer of linux takes now one argument instead of two, where the second argument was always zero. The cost to include a backwards compatible call that ignores the second argument (which is in this particular case the right approach) would have been close to zero. The cost of patching vmware is (for us) larger because it includes downtime and man hours of work.

Another example? Apparently, some kernel call the NVIDIA driver needs is no longer in place, so if you update your kernel, graphics no longer works, and re-compiling the nvidia driver fails. There is a new driver, but this has other bugs that were not fixed. This is "annoying" for a personal user because the procedure of updating such drivers is more complex than on other systems, but it causes real costs on large scale systems.  I don't have a company, but I'm working in a computing center. Even if I had a company, I would rather prefer to sell products that continue to work for ten years with drivers unchanged and have the operating system maintainer to keep care of it rather than to continuously have to invest money in a product that no longer creates any profit because it is no longer sold. Somehow the engineers that do all the patching and cleanup behind the kernel hackers have to be paid, too. You seem to forget that.

Two examples of companies that have chosen to not go for the right thing and upstream their drivers and have chosen to use the open source code from other people but not wanting to open their own code. Yes, in that case they are on their own. It means you should stick to configs supported by those companies.

It rather means that the Os "vendor" does not have the goal of creating a commercial ecosystem that would allow hardware vendors to invest into.

Sure the core kernel devs are not marketing driven; one can debate if that is good or bad. From the other end Red Hat seems to be doing pretty fine in commercializing Linux. Recently also long term supported older kernels have been made more official.

Which is pretty much the problem why open source never reached mainstream. Unixoid systems are successful where its vendor keeps care about it itself and uses a much stricter development model, and where hardware and Os are much more coupled than in the PC market.

As if PC drivers don't cause problems. The number of people doing PC support is much bigger in our company than for Linux; and we are doing EDA so Linux is not a minority overhere. Some of those PC support people do nothing else then testing drivers and even user land software to see if they don't cause problems before rolling out company wide.