Next Gen of Linux

[lu]

I know that this is a tad general - but what do we expect in a next generation operating system?



I'm asking this because I starting a new project on sourceforge and lanchpad called Exolu

It is intended to change the linux kernel into an exokernel...

Any comments...



--ginki

[01000101]

It's hard to say. The kernel is probably going to make a ton of "experimental" changes that are probably mostly counter-productive, and only a few worth-doing changes soon. User space is going to be tied up when it comes to MS application support and gaming as it's either "evil money-hogging Microsoft" or "Business needs Microsoft" that will play tug-of-war and not actually get anything productive accomplished.

I don't see anything major happening, and even if it does, I don't see it mattering to the rest of the computer-literate world.

[Colonel Kernel]

IMO, exokernels stopped being interesting with the advent of hardware-accelerated virtualization and hypervisors.

[nekros]

Linux(and Windows) really just need to be scraped. No amount of "improvements" will save them.

[quanganht]

Old kernel architectures is going down, and exo-kernel is going up, up and up

[nekros]

I'm not so sure it's exokernels....

[Solar]

Linux kernel is unmovable unless your name is Thorvals, Cox or similar. I absolutely agree on the stability issue of the kernel interface. And much more important than the kernel architecture, IMHO, is the absolute mess that's called "package management", and the complete lack of a "reference configuration": Every distro goes its own way, Q&A boards are usually highly distro-specific (and thus of little help to other Linux users), and what works in one distro (say, WLAN configuration) is a pain in the other and vice versa.

Choice might be beneficial to advance technology, but it's a PITA when it comes to usability.

[Colonel Kernel]

Choice might be beneficial to advance technology, but it's a PITA when it comes to usability.

Yes! Someone else who understands!! It's amazing how many developers are so focused on features that they lose sight of this basic fact of human psychology...

[piranha]

My biggest issue with all of this kernel development is that new features for chipsets/processors/devices etc are being made all the time. So a kernel that now supports a certain feature will usually have that feature simply added on to the current kernel feature set, and therefor a lot of the time features will be tacked on to a kernel without being properly implemented inside the kernel itself. Modules get around this issue a little bit by allowing themselves to be loaded whenever, so they don't mess up the kernel too much. Modules however also add the problem that their new features are even less properly implemented into the kernel, which can cause problems. Therefor modules are inherently unstable.

It's an endless cycle, because as soon as parts of the kernel are rewritten, new features appear yet again. I also want to mention that yes, some features are implemented properly from the ground up, yet some are not.

From this we get a picture of a kernel's features like this:

Code: Select all

\---------/
 \          /
  \        /
   \      /
    \    /
     \  /
      \/

instead of this (which it should be):

Code: Select all

       /\
      /  \
     /    \
    /      \
   /        \                      
  /           \
 /             \
/-----------\

Edit: Formatting fail, but you get the idea.
The best solution to to freeze development of new features and develop a kernel based on those features, and those features only, but also allowing room for new features.

Very impractical I know, so I'll get started on a time machine.

-JL

[nekros]

The thing is, the kernel itself shouldn't have *features*. It should do what it needs to let applications run at their full potential.

[earlz]

The thing is, the kernel itself shouldn't have *features*. It should do what it needs to let applications run at their full potential.

agreed.. assuming you are talking of a small kernel(most drivers outside of kernel) but if you have a monolithic kernel, then the kernel should be featureful so applications can work like on any OS and drivers can work better than on another OS(the best part of monolithic kernels is that drivers actually know about one-another at development time, increasing speed, stability and ease of development)

[piranha]

Well, I meant more like implementations of features rather than features themselves. However, yes, a monolithic kernel should have actual features built in.

-JL

[Solar]

I couldn't care less for any "features" of the kernel and how they're implemented, if they wouldn't break my perfectly functional system every now and then because they cannot be ars*d to keep the frigging kernel / driver interface stable.

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

[Kevin]

I couldn't care less for any "features" of the kernel and how they're implemented, if they wouldn't break my perfectly functional system every now and then because they cannot be ars*d to keep the frigging kernel / driver interface stable.

If you need that kind of stability, you are supposed to use a distro over the kernel.org versions targeted mainly at developers and those liking experiments. Distros usually try to keep the interfaces stable for updates in the lifecycle of one release - and for the next one you'll get a new package for the binary driver anyway.

[Solar]

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

And that doesn't even take into account those instances where a kernel or driver patch is mandated for security, and you're stuck with the choice of a functional, insecure system and a secure but broken one. (Counted three instances of that in the last few years.)