Kernel as your base kernel

[Radian]

Hi,

if you want to create an OS for desktop but you think it is not feasible to create it from scratch, which kernel (linux, *bsd, or others) you want to pick up as your base for your new kernel.

And what is your reason.

Thanx in advance.

[bluemoon]

It depends on how you define creating; and what actually your goal is.

it is not feasible to create it from scratch

It depends on your goal and budget.

[Solar]

if you want to create an OS for desktop but you think it is not feasible to create it from scratch, which kernel (linux, *bsd, or others) you want to pick up as your base for your new kernel.

That's called a "fork", and it wouldn't be a new kernel at all.

It would be difficult to implement anything fundamentally new / different without breaking compatibility with the driver base / userland, at which point your advantage of starting with a ready-built kernel evaporates. This is especially true for Linux, which is a very much moving target to develop against.

Adding to that, the Linux kernel is a very much moving target, and you would be hard-pressed to keep up with it in order not to lose compatibility with its driver

With *BSD, you could keep your work closed source, but I don't think the community would thank you for it or be very supportive of your effort.

And in any case, the best you could hope for is ending up with another Unix-alike OS - like Linux / *BSD, just worse.

Bottom line:

I wouldn't bother.

[gravaera]

I would not waste my time creating another unix based operating system and then relying on fanatical "flexibility" or "stability" arguments to prop it up against the 20th century age of properly designed, high usability, people focused computing. I would build a new kernel that is actually usable by human beings.

[Synon]

I would not waste my time creating another unix based operating system and then relying on fanatical "flexibility" or "stability" arguments to prop it up against the 20th century age of properly designed, high usability, people focused computing. I would build a new kernel that is actually usable by human beings.

That just seems needlessly inflammatory, and I also don't see what "properly designed, highly usable, people focused" kernels you're talking about. Mac OS is discounted because it's UNIX based, very few if any of the kernels written by people here are in wide use and most are not "people-focused", and Windows is... Windows. I use it for games but I wouldn't call it properly designed (though I will say it is way better than it is sometimes given credit for - most of the BSOD issues, for example, are mostly hardware or driver errors). Where Windows wins (alliteration unintentional) is in the realm of compatibility, especially backwards compatibility. I guess that's what you're talking about when you say "high usability" (though I'd contest that) and "people focused" (I certainly wouldn't contest that).

p.s. UNIX based systems do have a tendency to be more stable than others, which is why the vast majority of servers run Linux or FreeBSD.

[TylerH]

Linux would probably be easier, because it's so widely used and (I assume) better documented. You may be interested in the Linux From Scratch project.

[gravaera]

...and Windows...

You caught on :O

Most people don't care about stability enhancements that they can't see, and recent NT desktop distributions have been stable enough that the "stability" refrain will soon become less impressive for unix based kernels. Windows Server edition is quite good, as far as "stable" goes, if you buy the actual server edition.

--Peace out
gravaera :>

[Solar]

Could we keep comparative Unix vs. Windows flaming out of this? Both suck hard in their individual ways.

[Radian]

That's called a "fork", and it wouldn't be a new kernel at all.

Yes and No.
Yes, it will take a lot of code from the chosen kernel.
No, it wouldn't called a "fork" as it would be different from the design standpoint and it would not be another unix-like kernel, so ..

Adding to that, the Linux kernel is a very much moving target, and you would be hard-pressed to keep up with it in order not to lose compatibility with its driver

.. no need to keep up with its very fast changing drivers code.

The chosen kernel will be only used as "one time snapshot", further development of new kernel will be independent from the development of the chosen kernel.

I would not waste my time creating another unix based operating system and then relying on fanatical "flexibility" or "stability" arguments to prop it up against the 20th century age of properly designed, high usability, people focused computing. I would build a new kernel that is actually usable by human beings.

That's my point, I would not waste my time creating a new OS entirely from scratch.
I agree with "properly designed, high usability, people focused computing" principles but making it from "proper design" to "working OS" and code it from entirely zero line of code is just not feasible as it would need too much time to do that and as there's so much good code already written by people I can pick up and also to avoid as much as "reinvent-the-wheel" plague.

Linux would probably be easier, because it's so widely used and (I assume) better documented. You may be interested in the Linux From Scratch project.

No, I'm not willing to make GNU/Linux OS. I was just interested looking at the kernel.

In short, the new OS will be designed from scratch, but not code it from scratch. I need to decide which piece of code written by which people to pick up and to speed up development furthermore maybe i can just use one, the chosen kernel, as my starting point.

The following is the big picture of what I think:

Goal : Open source Desktop OS

Background :
( correct me if i'm wrong ... )
The failure of Linux as desktop OS.
I only mention Linux as it is the most succesful open source operating system used widely as desktop OS.

But I noted two weaknesses of Linux that make Linux would be so hard to become proper desktop OS: X window and its device driver development.

1. X window
IMO it is funny to have a desktop OS (so that the User Interface is its main component) but its UI subsystem decoupled far enough from the kernel (you said modularity?). There is only limited communication between kernel and X. People struggle to make X as efficient as possible. There's noted effort such as KMS, DRI, TTM, GEM to cope with problems created by X itself but I think X itself is the main problem.
There is Wayland project http://wayland.freedesktop.org/architecture.html with its main goal is to replace X. There is also Mark Shuttleworth announcement for his future plan to replace X with Wayland in his Ubuntu.

2. Device driver development
Stable-API-nonsense at http://www.kroah.com/log/linux/stable_api_nonsense.html is good from technical standpoint as device driver code tightly integrated into the kernel (modularity?) which make the whole system more robust. But I believe this is the major obstacle to make a new device get its driver ready as soon as the device launched to the market. Yes, the device manufacturer need to join on Linux device driver development in order to make the driver for their new device.
Actually, the question is why not so many good quality device driver for Linux (for new device)?

The Design :
I made a division of operating system environment:
device-drivers, kernel, libraries, utilities, user-libraries, user-applications

Based on dependency between them, let we see what these OS does regarding to the division above :
Linux = device-drivers + kernel
FreeBSD = device-drivers + kernel + libraries + utilities
Windows = kernel + libraries + utilities

Which model is good? It depend on what your goal is. But I must admit that I would choose the windows model as it let the device manufacturer develop their own driver for their device, be it open source or closed source.

( Are GPL'd code could do this, linked to closed source code ? )


Motivation : fun ... right?

[TylerH]

Linux = device-drivers + kernel
FreeBSD = device-drivers + kernel + libraries + utilities
Windows = kernel + libraries + utilities

I have no idea where you get the idea that Linux doesn't have utilities and libraries, but it does. *BSD and Linux are almost too similar to tell the difference, in terms of system design. (In fact, I don't really know of any differences, other than directory layout and boot mechanisms.)

Same with Windows and drivers. It has more drivers than Linux.

[brain]

Linux = device-drivers + kernel
FreeBSD = device-drivers + kernel + libraries + utilities
Windows = kernel + libraries + utilities

I have no idea where you get the idea that Linux doesn't have utilities and libraries, but it does. *BSD and Linux are almost too similar to tell the difference, in terms of system design. (In fact, I don't really know of any differences, other than directory layout and boot mechanisms.)

Same with Windows and drivers. It has more drivers than Linux.

In my experience of using both freebsd and linux for a long time now, i find that freebsd maintains backwards compatibility much better than linux does, even in terms of binary compatibility. The linux philosophy seems to be a lot of the time 'meh, users will just have to recompile their binaries', which can be painful. I would rather fork freebsd than linux as for drivers it is much less of a moving target and this pays dividends in stability too.

[Yoda]

I have no idea where you get the idea that Linux doesn't have utilities and libraries, but it does. *BSD and Linux are almost too similar to tell the difference, in terms of system design. (In fact, I don't really know of any differences, other than directory layout and boot mechanisms.)

Linux community at kernel.org is aware only of kernel and drivers. But AFAIK, Linux distributions use set of standard utilities that come under FreeBSD license. That's the difference, Radian is talking about.
What concerns the directory layout - there is no yet common convention amongst Linux distributions, not mentioning FreeBSD.

Same with Windows and drivers. It has more drivers than Linux.

Radian means that MS (in contradiction to Linux) doesn't develop the whole bunch of drivers for every OS. May be only the basic set of ugly builds until device manufacturers develop their owns. And he is right.

But he is wrong in the following. If you design new OS, don't think that all OEMs/ODMs will be eager to immediately release drivers for your OS. They want money. The money is the market. Market is MS. A vicious circle.

[Solar]

No, it wouldn't called a "fork" as it would be different from the design standpoint and it would not be another unix-like kernel, so ..

I don't think you can go very un-Unix-like with a Linux or *BSD fork as starting point. The interdependencies are enormous.

In short, the new OS will be designed from scratch, but not code it from scratch. I need to decide which piece of code written by which people to pick up and to speed up development furthermore maybe i can just use one, the chosen kernel, as my starting point.

I don't think that kind of modularity was part of the Linux design, but I'm not the expert on the matter.

But I noted two weaknesses of Linux that make Linux would be so hard to become proper desktop OS: X window and its device driver development.

Actually, I think that's two of its stronger points.

2. Device driver development
Stable-API-nonsense at http://www.kroah.com/log/linux/stable_api_nonsense.html is good from technical standpoint as device driver code tightly integrated into the kernel (modularity?) which make the whole system more robust.

But I believe this is the major obstacle to make a new device get its driver ready as soon as the device launched to the market. Yes, the device manufacturer need to join on Linux device driver development in order to make the driver for their new device.

Not only that; the device manufacturer has to have a bunch of driver developers that keep up to date with current Linux kernel developments, at the expense of the manufacturer. Since the Linux maintainers take the liberty of changing internals as they please, and don't provide the level of driver development seminars that Microsoft provides, this is a cost factor. Additionally, you have to release your drivers as GPL in order to have them included in the kernel proper - the only way to keep them up-to-date without unreasonable investments.

I.e., you have to lay open how your hardware works - not only to the Linux maintainers but, by extension, your competition too. You also have to play by the rules of the Linux maintainers, right down to things like coding style (ref. ReiserFS 4).

Actually, the question is why not so many good quality device driver for Linux (for new device)?

Do you really wonder why manufacturers are reluctant to play by other people's rules?

But I must admit that I would choose the windows model as it let the device manufacturer develop their own driver for their device, be it open source or closed source.

( Are GPL'd code could do this, linked to closed source code ? )

Yes, you can link GPL'ed code to closed source libraries. But with drivers, it's the other way around - you are linking against the GPL'ed kernel, which means the GPL applies to your driver source too.

[Yoda]

I don't think you can go very un-Unix-like with a Linux or *BSD fork as starting point. The interdependencies are enormous.

Quite so. I already tried this, but if you build a brand new system the only thing that can be really done is just an inspection, how one or another task is solved in Linux. Nothing more.

Since the Linux maintainers take the liberty of changing internals as they please, and don't provide the level of driver development seminars that Microsoft provides...

Generally speaking, Linux driver development is ugly documented if it may be called "documentation" at all. In contrast, MS well documents every step of development.

[Radian]

But he is wrong in the following. If you design new OS, don't think that all OEMs/ODMs will be eager to immediately release drivers for your OS. They want money. The money is the market. Market is MS. A vicious circle.

Yes, you're right. But at least we can make driver development comfortable, both technically and legally, for everyone. The point is you can't write the driver for every device in this planet yourself. Let people write driver for device they like (mostly) independently from the other part of OS. This is the very first step we should take. Market is the next step.

I don't think you can go very un-Unix-like with a Linux or *BSD fork as starting point. The interdependencies are enormous.

Quite so. I already tried this, but if you build a brand new system the only thing that can be really done is just an inspection, how one or another task is solved in Linux. Nothing more.

Right, maybe what I can do is just look to see how things are done.