OSDev.org

And exokernel have all the things you need: security, flexibility. Am I wrong?

Solar wrote:Luckily it seems like they at last got the whole /dev shebang working with udev. (You remember? mknod, devfs, ...)

But that messed up the device numbering scheme, so everyone had to switch their fstabs to GUIDs instead of device names. Absolutely horrible.

I am not sure what you are aiming at. An exokernel isn't an operating system without its libOS. Imagine a libOS constantly changing its ABI or API. Or worse, an exokernel changing that way (although difficult to picture as it's so minimal), forcing all libOS's to change accordingly or go "blooop".

Solar wrote:So the distros have to make up for the shortcomings of the kernel programmers.

Not shortcomings, but different goals...

And of course, the sets of distro makers and kernel programmers are not disjoint. You know yourself that in fact a great part of the kernel development is done by employees of the distributors. So kernel.org is the development branch, and it's stabilized by distributors for a product. Users who want things to "just work" definitely need to go for the latter. If you want to have bleeding edge software, you need to do some work by yourself - with other OSes you wouldn't even get such versions, so I think you have a fair choice.

Kevin wrote:

Solar wrote:So the distros have to make up for the shortcomings of the kernel programmers.

Not shortcomings, but different goals...

And of course, the sets of distro makers and kernel programmers are not disjoint. You know yourself that in fact a great part of the kernel development is done by employees of the distributors. So kernel.org is the development branch, and it's stabilized by distributors for a product. Users who want things to "just work" definitely need to go for the latter. If you want to have bleeding edge software, you need to do some work by yourself - with other OSes you wouldn't even get such versions, so I think you have a fair choice.

In reality often the things that's supposed to just work doesn't, that's the problem, gettit?

And kABI changes are to blame? Care to elaborate on that?

Constantly changing within one version of your distribution? You must use a funny distro - at least one which is not suited for the "just works" requirement. Your own fault then.

Kevin wrote:Constantly changing within one version of your distribution? You must use a funny distro - at least one which is not suited for the "just works" requirement. Your own fault then.

Are you suggesting that people never upgrade?!?!? That would be a security disaster.

You're missing my whole point. Distros do provide (security) updates without changing the kABI. You don't need to go for the latest kernel.org versions. From a good distro you get the bug fixes without the whole rest of the changes which basically means that you have one constant kernel version throughout the lifecycle of a distribution version plus some small parts which are updated and don't touch the kABI. (I know, sometimes that doesn't work and an important security fix actually needs to change the kABI - but in general it works and isn't "constantly changing").

Kevin wrote:You're missing my whole point. Distros do provide (security) updates without changing the kABI. You don't need to go for the latest kernel.org versions. From a good distro you get the bug fixes without the whole rest of the changes which basically means that you have one constant kernel version throughout the lifecycle of a distribution version plus some small parts which are updated and don't touch the kABI. (I know, sometimes that doesn't work and an important security fix actually needs to change the kABI - but in general it works and isn't "constantly changing").

Which brings us back to what Solar wrote: "So the distros have to make up for the shortcomings of the kernel programmers."

Each distro have to do a lot of work to backport security fixes because they can't give out the lastest fixed versions, because then things break. It's just silly.

Which brings us back to what I wrote: Distro makers and kernel developer are the same people. They have kind of a development branch (kernel.org) and a stable branch (distro) - and you won't argue that having such is a bad thing, right?

What you are saying, effectively, is that the development department needn't bother with providing a stable product including maintenance support, because that's up to the sales department.

I disagree. I consider the kernel developers - and quite a few of the base system package maintainers - to be a bunch of asocial bordercase hackers with blinders who've locked themselves up in an ivory tower where they can play with the bleeding edge and not give a d*mn about everyone else, because it's up to the distro builders to patch everything together so it actually works.

Software Engineering looks different.

Edit: Yes, in a way I envy them. Hey, they can do pretty much whatever they want - change ABIs, change APIs, change complete subsystems without so much as a grace period or a maintenance branch, and still people think they're great developers. Not in my book. They're hackers, programmers at best. But a Software Engineer has to be much more than that - he must make a solid design beforehand, and has to support it for its lifetime afterwards. The kernel maintainers do neither.

I guess we should stop generalizing and talking about "the kernel developers", this is leading nowhere. Probably there are some asocial bordercase hackers, I won't argue that. On the other hand, there are also those contributors who are working on the kernel for distributors, doing bleeding edge development and stabilizing the kernel for the distro and maintaining it during the lifecycle. This is definitely not about leaving the work for others.

mknod - devfs - udev

ipw3945 - iwl3945

uvesafb - v86d

iptables - ipchains

madwifi / madwifi-ng

"Generic IEEE 802.11 Networking Stack" (which one of the two currently in the kernel?)

And that is only those that have bitten me personally, only those related directly to the kernel, and only those I still remember.

Read /usr/src/linux/Documentation/stable_api_nonsense.txt for the official POV of the kernel dev's. In one line, no driver that's not in the kernel repo (i.e., fully disclosed GPL source) will ever be considered, and they think this is a good thing to do.

I stand by my above statement. Everybody who gets into bed with them, will be hung with them. (In a metaphoric sense, of course. Don't get any ideas. )

Kevin sounds familiar.

http://marc.info/?l=openbsd-misc&m=123846734629145&w=2

This "no change" mentality will soon become obsolete.

Not that I approve of the inconsistent nature of Linux environments, there isn't any sort of singular direction in that community..