OSNews: http://www.osnews.com/story/20516/Former_AROS_Developers_Start_New_OS_Project_Much_Secrecy Exploring the Future of Computing en-us Copyright 2001-2009, David Adams adam+nospam@osnews.com Wed, 25 Nov 2009 19:05:53 GMT http://www.osnews.com/images/osnews.gif OSNews.com http://www.osnews.com good luck! http://osnews.com/thread?336884 http://osnews.com/thread?336884 All the best with the effort, sadly im as cynical as Thom but hope they prove me wrong! Mon, 10 Nov 2008 23:11:00 GMT donotreply@osnews.com (Adurbe) Comments Kernel http://osnews.com/thread?336885 http://osnews.com/thread?336885 if you really want ot take a kernel to build on top of dont take linux. Take something like QNX. While there are less drivers for it the kernel itself is more stable and has far less overhead. With all due respect for linux (and i mean try linux, the kernel) there are better things to use as a templete for creating a "new" OS. NetBSD 5's code base would be another good example, small, fast, moduler. But I wish them the best of luck.

also as far as OS's that have taking the linux kernel and tried their own thing, there is also The Athene Operating System ( http://www.rocklyte.com/athene/ ). I happen to like them white a bit, and their omega workd bend GUI reminds me of my old Amiga 4000t. good times.Edited 2008-11-10 23:22 UTC Mon, 10 Nov 2008 23:14:00 GMT donotreply@osnews.com (poundsmack) Comments Why not just join Haiku instead ??? http://osnews.com/thread?336886 http://osnews.com/thread?336886 We still need developers to complete our world domination plans! Mon, 10 Nov 2008 23:27:00 GMT donotreply@osnews.com (mmu_man) Comments RE: Why not just join Haiku instead ??? http://osnews.com/thread?336890 http://osnews.com/thread?336890 http://moobunny.dreamhosters.com/cgi/mbmessage.pl/amiga/159911.shtm...

:) Mon, 10 Nov 2008 23:46:00 GMT donotreply@osnews.com (AbuHassan) Comments RE: Kernel http://osnews.com/thread?336894 http://osnews.com/thread?336894 poundsmack wrote:
-"While there are less drivers for it the kernel itself is more stable and has far less overhead."

Far less overhead? iirc it's a hard realtime kernel, hence it sacrifices some efficieny in order to execute prioritized threads at exact times, also since basically everything runs as a user process it seems to me it pretty much must have more overhead than Linux, if you have any facts you can point to that shows otherwise I'd be very interested.

As for Anubis choice of Linux, my guess is that it mainly boils down to hardware support. Don't quite understand the 'stripping' part though, it's not as if the Linux kernel is bloated, particuarly not for what I assume is a desktop oriented os.

While I've always liked Aros due to my Amiga nostalgia, lack of memory protection (guru meditation memories comes back to haunt me) and smp etc isn't the best foundation on which to build a system for modern use. Add to that an API which really hasn't stood the test of time (imo).

So yes, I can definately understand that some developers might want to implement an Amiga-ish environment over a small, very fast kernel with broad hardware support. On the other hand I can also see why people who like Aros will see this as a bad thing.

However it is their spare time and I'm absolutely certain that they are the experts on how they want to spend it.

I wish them luck and will file this under 'another one to keep an eye on' while I passionately continue to stalk... follow the Haiku development. Tue, 11 Nov 2008 01:14:00 GMT donotreply@osnews.com (Valhalla) Comments Comment by merkoth http://osnews.com/thread?336897 http://osnews.com/thread?336897 If you read the comments at the AROS show blog, they clarified that there won't be any "stripping". Also, Michal Shultz told some commenters that they chose Linux mostly because it's available and stable on the three major platforms (x86, x64, PPC) and because it has the biggest hardware support of the available choices.

Ahh, I love the smell of a fresh operating system ;) Tue, 11 Nov 2008 01:47:00 GMT donotreply@osnews.com (merkoth) Comments Yay http://osnews.com/thread?336902 http://osnews.com/thread?336902 ...something new to play with. I hope it all works out for them and I'll be rooting for them if only for trying something new. Tue, 11 Nov 2008 02:43:00 GMT donotreply@osnews.com (miserj) Comments RE: Comment by merkoth http://osnews.com/thread?336908 http://osnews.com/thread?336908
Ahh, I love the smell of a fresh operating system ;)


How does using Linux for the kernel smell fresh?

Edit: stupid comment previewEdited 2008-11-11 03:43 UTC Tue, 11 Nov 2008 03:42:00 GMT donotreply@osnews.com (umccullough) Comments Build from the ground up http://osnews.com/thread?336910 http://osnews.com/thread?336910 I think that building an OS from scratch is a wonderful way to learn a huge amount about the internals of all operating systems. But I don't think there is any real utility in it aside from improving the skills of the participants. That said, I can't see any reason to build an OS on top of the Linux kernel, since it seems to me that building the kernel itself is the real deal. Building an OS means getting very well acquainted with memory management, interrupt handling, and all the other myriad details that make up a modern CPU. Go ahead and give it a shot, you will learn a lot. Tue, 11 Nov 2008 04:13:00 GMT donotreply@osnews.com (explainer) Comments another focus shift? http://osnews.com/thread?336912 http://osnews.com/thread?336912 reminds me of syllable. They start out with an interesting unfinished idea, not too many developers to begin with and they decide to work on something else with a linux kernel. Tue, 11 Nov 2008 04:38:00 GMT donotreply@osnews.com (ari-free) Comments Huh?? http://osnews.com/thread?336915 http://osnews.com/thread?336915 Who is going to take seriously the notion that they're actually going to finish what they start if they just give up on AROS??
If they had just completed their original goal of porting OS3.1 to the X86, instead of trying to get AROS to work on every latest whiz-bang piece of hardware, they could have been done a long time ago with AROS. Tue, 11 Nov 2008 06:12:00 GMT donotreply@osnews.com (StychoKiller) Comments RE: another focus shift? http://osnews.com/thread?336919 http://osnews.com/thread?336919
reminds me of syllable. They start out with an interesting unfinished idea, not too many developers to begin with and they decide to work on something else with a linux kernel.


The comparatively tiny amount of work put into Syllable Server does not mean that work on Syllable Desktop has stopped or that we have replaced the current Syllable code with a Linux kernel. The two (Syllable Desktop, Syllable Server) are separate entities with separate purposes. Tue, 11 Nov 2008 07:50:00 GMT donotreply@osnews.com (Vanders) Comments RE[2]: Comment by merkoth http://osnews.com/thread?336923 http://osnews.com/thread?336923
"Ahh, I love the smell of a fresh operating system ;)


How does using Linux for the kernel smell fresh?

Edit: stupid comment preview "

They seem to intend to replace the userspace tools, i. e. the GNU part of common operating systems sometimes subsumed under the name of "Linux". Replacing GNU certainly is ambitious. Tue, 11 Nov 2008 08:28:00 GMT donotreply@osnews.com (B. Janssen) Comments RE: Why not just join Haiku instead ??? http://osnews.com/thread?336925 http://osnews.com/thread?336925 Haiku or Syllable. Both will dominate the world. Tue, 11 Nov 2008 08:41:00 GMT donotreply@osnews.com (fithisux) Comments RE: another focus shift? http://osnews.com/thread?336926 http://osnews.com/thread?336926 Things are not this way. They are porting GenodeOS to their kernel. Tue, 11 Nov 2008 08:45:00 GMT donotreply@osnews.com (fithisux) Comments RE: Build from the ground up http://osnews.com/thread?336930 http://osnews.com/thread?336930
I think that building an OS from scratch is a wonderful way to learn a huge amount about the internals of all operating systems. But I don't think there is any real utility in it aside from improving the skills of the participants. That said, I can't see any reason to build an OS on top of the Linux kernel, since it seems to me that building the kernel itself is the real deal. Building an OS means getting very well acquainted with memory management, interrupt handling, and all the other myriad details that make up a modern CPU. Go ahead and give it a shot, you will learn a lot.


The kernel isn't the make or break of an OS. Sure it's a major deciding factor, but the tools you place on top of the kernel can be just as relevent about how the OS will behave.

Take NT / Vista for example. The NT kernel isn't at all bad, yet Vistas UAC et al destroy any confidence in the OS that the kernel developed. Tue, 11 Nov 2008 10:03:00 GMT donotreply@osnews.com (Laurence) Comments Haiku? http://osnews.com/thread?336931 http://osnews.com/thread?336931 Somebody should poke him in the direction of Haiku. They could always do with additional OS experts on the team and they have an alpha-ready OS that is fast, small, and well designed and thusly aligned with the Amiga principles. Tue, 11 Nov 2008 10:30:00 GMT donotreply@osnews.com (FreeGamer) Comments New OS http://osnews.com/thread?336933 http://osnews.com/thread?336933 If they choose to use a new windowing environment then perhaps we can call it a new OS otherwise if they choose to go with X.org; it will be just another desktop-linux.

I think they should fork the whole AROS windowing environment on top of Linux and start from there and not even consider X.ORG. Tue, 11 Nov 2008 11:11:00 GMT donotreply@osnews.com (OSGuy) Comments RE[3]: Comment by merkoth http://osnews.com/thread?336951 http://osnews.com/thread?336951 While replacing GNU is ambitous, it is definitely exciting to hear someone is considering it. Tue, 11 Nov 2008 14:02:00 GMT donotreply@osnews.com (aesiamun) Comments Hopefully, it will be different http://osnews.com/thread?336953 http://osnews.com/thread?336953 It would be nice to see a successful desktop OS using the Linux kernel. Everyone always says the 'Linux is only the kernel', yet there are a zillion distributions with the same crufty crap that makes Linux as a desktop OS suck. Develop an OS around the kernel and start from scratch a new design for everything else.
Thom pointed out several attempts that have failed, but I think those were more proof-of-concept attempts by a 1 man team. Tue, 11 Nov 2008 14:23:00 GMT donotreply@osnews.com (GCrain) Comments Comment by Jenne http://osnews.com/thread?336955 http://osnews.com/thread?336955 I think MorphOS turned out pretty decent lately... ;-)

http://www.morphzone.org/modules/myalbum/photo.php?lid=100

All those "pseudo" OSes which take a Linux Kernel and put their "my concept is the bestest eva!" thing on top are still just another flavour of Linux. So many times all their good work is worth nothing in the end than just another personal nerd playground. Unfortunately... Tue, 11 Nov 2008 14:43:00 GMT donotreply@osnews.com (Jenne) Comments RE[4]: Comment by merkoth http://osnews.com/thread?336956 http://osnews.com/thread?336956 No doubt about it!

Replacing the GNU tools will alter system usage more substantially than replacing the kernel, which I think is what most people fail to realize.

I wish them good luck. Tue, 11 Nov 2008 15:14:00 GMT donotreply@osnews.com (B. Janssen) Comments RE[3]: Comment by merkoth http://osnews.com/thread?336958 http://osnews.com/thread?336958 If true, why? What will their ls do that other ls commands don't?

Best of luck to them anyway. AROS is a great project. Tue, 11 Nov 2008 15:23:00 GMT donotreply@osnews.com (rhyder) Comments RE[2]: Comment by merkoth http://osnews.com/thread?336959 http://osnews.com/thread?336959 About as fresh as recreating an OS from 2000Edited 2008-11-11 15:26 UTC Tue, 11 Nov 2008 15:24:00 GMT donotreply@osnews.com (Soulbender) Comments Piggybacking is the only sensible policy http://osnews.com/thread?336962 http://osnews.com/thread?336962 As for the rest, I believe that piggybacking on an existing kernel (Linux or FreeBSD) is the way to go.

Let me explain, an OS provides two main functionnality:
1- making the hardware work
2- making the software work by providing a base model

All these new OS which reinvents the wheel focus on (2) of course that's the fun part, the interesting one, but in the meantime there's several hundred of engineers working on (1) for Linux kernel, so it's nearly impossible to catch up..
And unfortunately Unix/Linux's sw model has many limitations: BeOS has really shown this, its application responsiveness has not been reproduced on Linux even on much more powerful hw and I don't expect this to change anytime soon..
:-( :-(

Now is-it possible to build a new OS with the Linux or FreeBSD kernel underneath?

I don't know.. But I would point that Blue Eyed OS isn't a good failure example: I don't think that it was a serious effort: if memory serves, at startup, I tried to ask what license was going to be used for this OS, I never got a clear answer..
In this day and age, an open source project without a clear license policy is doomed to fail! Tue, 11 Nov 2008 15:53:00 GMT donotreply@osnews.com (renox) Comments RE: Huh?? http://osnews.com/thread?336965 http://osnews.com/thread?336965
Who is going to take seriously the notion that they're actually going to finish what they start if they just give up on AROS??
If they had just completed their original goal of porting OS3.1 to the X86, instead of trying to get AROS to work on every latest whiz-bang piece of hardware, they could have been done a long time ago with AROS.


Then again, who is going to take 3.1 API seriously in 2008? I sure don't see an explosion of new users for OS4 or MOS, do you? There is a reason for that, even though you probably wouldn't want to admit it. Using a Linux kernel is the smartest thing anyone has done in a long long time. Decent kernel with a ton of drivers, perfect. Tue, 11 Nov 2008 16:02:00 GMT donotreply@osnews.com (damocles) Comments RE: New OS http://osnews.com/thread?336966 http://osnews.com/thread?336966 AROS already runs on Linux on top of X and has done for years. ;)

i386-hosted:
http://aros.sourceforge.net/cgi-bin/nightly-download?20081110/Binar...

x86-64 hosted:
http://aros.sourceforge.net/cgi-bin/nightly-download?20081110/Binar...

PPC hosted:
http://aros.sourceforge.net/cgi-bin/nightly-download?20081110/Binar...

Have fun! ;) Tue, 11 Nov 2008 16:07:00 GMT donotreply@osnews.com (AbuHassan) Comments RE[2]: New OS http://osnews.com/thread?336968 http://osnews.com/thread?336968 I think most people don't realize what AROS is, what it isn't and what it's already capable of... Tue, 11 Nov 2008 16:11:00 GMT donotreply@osnews.com (neozeed) Comments RE: Build from the ground up http://osnews.com/thread?336969 http://osnews.com/thread?336969 >>That said, I can't see any reason to build an OS on top of the Linux kernel Tue, 11 Nov 2008 16:12:00 GMT donotreply@osnews.com (renox) Comments RE[2]: Kernel http://osnews.com/thread?336970 http://osnews.com/thread?336970 while there are tons of QNX vs LInux articles i could fine, none of them were comapiring QNX to the 2.6 linux kernel so I chose this one, ( http://www.qnx.com/news/pr_2870_1.html ).

I can verify this is correct that QNX can boot in a few seconds and is lightning quick and utalizes (at least on intel) multi core CPU's better than linux currently ( as up 2.6.27.5 ) as i have and develop for both. this has actualy promted me to do a bench marking of the 2 systems, both in just kernel and text mode, as well as light weight GIU's (linux with something like fluxbox, and QNX with photon).

but as someone who uses embeded version of QNX and linux daily i can honestly say QNX is faster in boot, alication load, and data write to the file system. as far as apication usage and responsiveness, well that usualy depends on the app, so it's a toss up.Edited 2008-11-11 16:28 UTC Tue, 11 Nov 2008 16:15:00 GMT donotreply@osnews.com (poundsmack) Comments RE: New OS http://osnews.com/thread?336971 http://osnews.com/thread?336971 Could you explain why you say this?

X is a low level API so if it was wrapped in something higher level why would your applications care?

The biggest problem I could see with X is the thread safety which could have an impact on the higher level API and the fact that X.org itself requires quite a lot of Linux system libraries why you don't necessarily want the application to your new OS API to see.. Tue, 11 Nov 2008 16:23:00 GMT donotreply@osnews.com (renox) Comments RE[2]: another focus shift? http://osnews.com/thread?336977 http://osnews.com/thread?336977 It's not stopped but surely it slows down development when you have to work on 2 OS's with completely different cores. Tue, 11 Nov 2008 17:02:00 GMT donotreply@osnews.com (ari-free) Comments RE[2]: Build from the ground up http://osnews.com/thread?336978 http://osnews.com/thread?336978 Whoever marked me down, I respect your opinion and right to disagree with me, but please at least reply with your reasoning rather than "hit and run" voting.

I'm interested to hear why you disagree with my point that user-space tools can make or break an OS. If I'm wrong, I'd want to know so. Tue, 11 Nov 2008 17:22:00 GMT donotreply@osnews.com (Laurence) Comments RE: Piggybacking is the only sensible policy http://osnews.com/thread?336980 http://osnews.com/thread?336980
Now is-it possible to build a new OS with the Linux or FreeBSD kernel underneath?


MacOSX is actually such thing, in lower levels, it runs a forked FreeBSD (Darwin). Tue, 11 Nov 2008 17:31:00 GMT donotreply@osnews.com (ebasconp) Comments RE: Piggybacking is the only sensible policy http://osnews.com/thread?336986 http://osnews.com/thread?336986

And unfortunately Unix/Linux's sw model has many limitations: BeOS has really shown this, its application responsiveness has not been reproduced on Linux even on much more powerful hw and I don't expect this to change anytime soon..
:-( :-(


This is my observation as well.

I wonder what it is exactly in the Linux stack that makes the responsiveness so slow?

X?
GTK/Qt?
The kernel?

Every OS that makes applications more responsive than Linux has my support. Tue, 11 Nov 2008 18:12:00 GMT donotreply@osnews.com (chris_dk) Comments RE[2]: Piggybacking is the only sensible policy http://osnews.com/thread?336987 http://osnews.com/thread?336987 I wonder what it is exactly in the Linux stack that makes the responsiveness so slow?

X?
GTK/Qt?
The kernel?

I'd probably say the biggest issue is X itself. It is getting rather dated and carries with itself a lot of outdated stuff. X does of course have features not available to Windows users for example, but there's nowadays many things lurking there that could be done more efficiently with modern hardware and software. For example, there simply is not sold any graphics hardware that can't accelerate any kind of video output or graphics operations, and many generations old hardware can do those things as well.

I don't have the skills to do anything even remotely as good as X is now, but someone who has the skills and the knowledge should perhaps start working on something new and optimize it for more modern hardware. Tue, 11 Nov 2008 18:53:00 GMT donotreply@osnews.com (WereCatf) Comments RE[2]: Piggybacking is the only sensible policy http://osnews.com/thread?336988 http://osnews.com/thread?336988 OSX runs on a Mach kernel, not a FreeBSD kernel. Tue, 11 Nov 2008 18:54:00 GMT donotreply@osnews.com (Soulbender) Comments RE[3]: Piggybacking is the only sensible policy http://osnews.com/thread?336991 http://osnews.com/thread?336991 OSX runs on a Mach kernel, not a FreeBSD kernel.

"Darwin is built around XNU, a hybrid kernel that combines the Mach 3 microkernel, various elements of BSD (including the process model, network stack, and virtual file system),[2] and an object-oriented device driver API called I/O Kit."

So, it does have BSD elements in it and it is not a pure Mach 3 microkernel either. Also, the userland consists of code taken from NEXTSTEP, FreeBSD and a several others.

http://en.wikipedia.org/wiki/Darwin_(operating_system) Tue, 11 Nov 2008 19:08:00 GMT donotreply@osnews.com (WereCatf) Comments RE[4]: Piggybacking is the only sensible policy http://osnews.com/thread?336993 http://osnews.com/thread?336993 Right, it's a modified Mach kernel with parts inspired and taken from freebsd. Very different from being based on a freebsd kernel. Tue, 11 Nov 2008 19:15:00 GMT donotreply@osnews.com (Soulbender) Comments wow, how exciting http://osnews.com/thread?336997 http://osnews.com/thread?336997 Another linux distro.

Yes i know, i'm oversimplifying.
But using the linux kernal doesn't seem the way to create an 'Amiga inspired OS'. Tue, 11 Nov 2008 20:09:00 GMT donotreply@osnews.com (Bully) Comments RE[2]: Piggybacking is the only sensible policy http://osnews.com/thread?336999 http://osnews.com/thread?336999

I wonder what it is exactly in the Linux stack that makes the responsiveness so slow?

X?
GTK/Qt?
The kernel?


I think it is the combination of the three. The design of the three components is independent between each other in the case of a Linux system. They are not build with the only purpose of working well together. x.org implementation of X protocol is multiplatform, so its design account for that. The same for GTK and Qt. They are meant to make the development of applications in multiple platforms more easy. Working in different platform has its disadvantages, you can't take for granted that certain feature is available at all times, nor that the programming model is the same in all platforms (like multi threading model differences). About the kernel, the Linux kernel only provides basic services for the desktop, and as a generic kernel, its objective is not only to improve the desktop performance, it is also to improve the server use case.

In systems like BeOS and others, where all components are designed under the same roof and aim to the same objective, some assumptions can be made to make the system more responsive or efficient. They have the flexibility design their display server, the display driver API and the user API together, without worrying affecting other platforms. This enable to have a more clean, cohesive, consistent and, in some cases, more efficient design. Tue, 11 Nov 2008 20:16:00 GMT donotreply@osnews.com (rob_mx) Comments RE[3]: another focus shift? http://osnews.com/thread?337000 http://osnews.com/thread?337000 No. Kaj can provide more detail, but the bulk of the work for Syllable Server has so far been in writing Builder recipes. Builder was already in a state that made it perfect for creating Syllable Server. It has not taken Kaj away from anything he would already be doing for Desktop anyway (I.e. developing Builder).

Writing the compatibility library and Linux-specific drivers for the appserver will take a small amount of my time, but after that everything else pretty much is shared development between both Desktop & Server. Tue, 11 Nov 2008 20:27:00 GMT donotreply@osnews.com (Vanders) Comments RE[3]: Kernel http://osnews.com/thread?337011 http://osnews.com/thread?337011 poundsmack wrote:
-"and utalizes (at least on intel) multi core CPU's better than linux currently ( as up 2.6.27.5 ) as i have and develop for both. this has actualy promted me to do a bench marking of the 2 systems, both in just kernel and text mode, as well as light weight GIU's (linux with something like fluxbox, and QNX with photon)."

Well, the link was pretty pointless as it contained no comparison whatsoever. Also, while it's good that you have benchmarked it, a total lack of data aswell as how you've benchmarked them makes the statement pretty pointless and lumps it together with all the other subjective 'it feels faster' nonsense scattered across the web. By design, monolithic kernels should be faster than microkernels, is anyone disputing this? There are advantages with running everything in it's own process (stability being number one, modularity also comes to mind), but speed is not one of them. In a monolithic kernel the system call cost is setting and resetting the supervisor bit, and no overhead at all once in kernel space where all memory is accessable. In a microkernel you have to pass messages through the kernel out to different processes and they again have to respond through the same message mechanism which is alot slower than accessing process memory directly.

Now one can certainly question just how much this overhead is actually costing (I know there has been alot of improvement in the messaging and context switching which should help lower the speed penalty), and this is where some up-to-date hard data benchmarks would come in handy.

AFAIK most kernel's today that employ micro-kernel characteristics are so-called 'hybrid' kernels which uses ideas from both microkernels and monolithic kernels. Haiku (my favourite OS project uses a hybrid kernel where hardware drivers and (I think) the filesystem runs in kernel space (and thus can potentially crash the system), just like they can in a monolithic kernel. Personally I prefer speed over the chance that a buggy driver may cause havoc. If my system goes down due to a buggy driver, I will blame the buggy driver, not the system. If this happened to me often then maybe I'd sing another tune, but I seriously can't remember when I last had a system crash which was related to hardware/driver malfunction. Of course if the system were somehow responsible for keeping me alive or some such, then I'd probably go with maximum stability ;) Tue, 11 Nov 2008 22:48:00 GMT donotreply@osnews.com (Valhalla) Comments RE: wow, how exciting http://osnews.com/thread?337018 http://osnews.com/thread?337018
But using the linux kernal doesn't seem the way to create an 'Amiga inspired OS'.


Why not?

The UNIX-like "personality" of Linux is given by two factors: its POSIX interface and its GNU tools; the POSIX interface is not a big deal, because a lot of non-unix OSes implement it [including Windows in some way] and the GNU tools, are built in userland. Removing the GNU tools or developing a parallel set of tools instead of them, creates a brand new operating system with a totally different personality (let's see the case of MacOSX) Tue, 11 Nov 2008 23:16:00 GMT donotreply@osnews.com (ebasconp) Comments RE[3]: Piggybacking is the only sensible policy http://osnews.com/thread?337020 http://osnews.com/thread?337020
MacOSX is actually such thing, in lower levels, it runs a forked FreeBSD (Darwin).

XNU evolved from a merge of Mach 3 (old NextStep's kernel) with the upper halves of the network and VFS stacks from 4.4BSD, and a new (object oriented) hardware subsystem and api (IOKit, based and written in embedded C++)

Apple took code from FreeBSD, but there's not enough to consider the kernel a fork - OTOH the whole platform is, because of the inclusion of BSD userland

I wonder what it is exactly in the Linux stack that makes the responsiveness so slow?

X?
GTK/Qt?
The kernel?

as it has often been said, one of the main factors BeOS was responsive was pervasive multithreading - if every BeOS program was to be multithreaded yes programmers had to always develop with concurrency concerns in mind, but it also meant the kernel was designed to enable large numbers of lightweight threads (so, say, every new Tracker window could run its event loop in a different thread)
Linux instead wasn't born with threading as a major feature (i actually recall Torvalds being very vocal against mechanisms for thread support in the kernel for a long time) - threads have been implemented (as an afterthought) mapping them on normal processes, and the (kernel, non userland library - level) api for them was based, on a (costly) syscall that clones a process's address space to create a new one
with time, internal mechanisms have been refined (for instance all children subprocesses related of a single process would carry the same PID - interestingly, it was not so in the beginning - locks have been optimized and locking influence inside the kernel, reduced, to yield better preemptability and lower latencies)
but the overall structure and low level kernel interfaces seems to not have changed much, to retain self compatibility - so apparently, threads still carry higher inherent overhead than on other systems, and their usage on applications, the "use sparingly" warning

on the other hand, BeOS windows were managed by a single process, also managing the input loop and focus mechanism, which avoided the kernel-X-kernel-WM-kernel-X round trip
the IPC mechanism itself was (as in other microkernel, or desktop optimized OSs) more modern and efficient (due to beos initially, being microkernel based) than what was (and still is nowadays) available from the classic unix kernel
also interesting, message based IPC and hardware events on Linux are other afterthoughts - DBUS actually does in a daemon what other system do with native kernel facilities (message ports) inside the kernel, requiring a round trip (thus, overhead) for the message exchange operation

to reply to the original question, i'd say both each single, and the pretty much conservative overall structure of a server derived system
I'd probably say the biggest issue is X itself.It is getting rather dated and carries with itself a lot of outdated stuff.

i suggest the reading of Mark Kilgard's (former SGI , now nvidia employee) paper about D11
dated 1995, it pretty much sums up X11's inefficiencies (which were the same we try to tackle today, not much has changed) and redesigns the X11 code path optimizing for the local case - basically bypassing everyting:
bypassing server side rendering (rendering on client private surfaces)
bypassing protocol en/decoding, shared memory, sockets, and IPC altogether (instead, relying on an innovative (for unix) procedure call mechanism to share data between the client and the serv.. pardon, graphic kernel)
the drawback was applications needing to adopt the protected procedure call model and the XClientPrivateSurface api - but as a matter of fact btw, Kilgard also thought about legacy compatibility, and the option of running a ported X11 server on the D11 kernel

but someone who has the skills and the knowledge should perhaps start working on something new and optimize it for more modern hardware.

those with the skills have already started, or actually done such new solutions

the problem is, the comunity at large is actually ignorant - meaning people often *ignores* the very existence of whatever is born outside of *nix, or outside of FOSS - OTOH X has become so entrenched with the current state of community friendly for the community accepting its replacement anytime soon to be a realistic scenario...Edited 2008-11-12 00:17 UTC Wed, 12 Nov 2008 00:06:00 GMT donotreply@osnews.com (silix) Comments AROS http://osnews.com/thread?337036 http://osnews.com/thread?337036 "Even though in theory it appears as if using the Linux kernel is a nice leg-up, practice is much different. "

Actually, that`s quite sad and miserable way of making "new-old" OS`s ... Wed, 12 Nov 2008 05:13:00 GMT donotreply@osnews.com (marcp) Comments RE[2]: Piggybacking is the only sensible policy http://osnews.com/thread?337061 http://osnews.com/thread?337061 My answer would be 'none of the above': the traditional way to make an application on Unix/Linux is the 'event loop': you have a main loop, when the user click on something it executes the corresponding action and then resume, of course when it executes an action the HMI isn't responsive as the main loop doesn't process events.

So to avoid being too unresponsive, the application delegate some of the very long action to another process/thread but developers do it as little as possible as it increase complexity and overhead (on a single CPU any additional thread reduce the overall performance).

Whereas BeOS was initially planned for a bi-CPU computer so they used thread everywhere to use efficiently the two CPU and this has the very nice effect of producing a responsive OS even on a single-CPU.

If I'm right, then it means that we'll get responsive application on Linux only when the userspace applications and framework (X) are recoded to use parallelism (thread|process), this will probably happen as someday everyone is going to have a quadcore under their desk, so the incentive will be there but it'll take a long time.. Wed, 12 Nov 2008 12:07:00 GMT donotreply@osnews.com (renox) Comments RE[4]: Kernel http://osnews.com/thread?337069 http://osnews.com/thread?337069 I am surely not expert in the OS internals area, but here's some possible parameters to consider:

1) "monolithic kernel sucks" is general attitude of many ppl, myself included, and you can't do anything about it :-) (you know, Amigan, message based system)

2) now really - what was interesting, was back then, when Amiga under the Gateway wings, was supposed to use QNX as a base for new OS. I remember when Linus joined the message board, with some claims, and as fast as he joined he left, because real gurus were there - with QNX. You could see many ppl claiming, that QNX had some 20-30 (micro?) sec latency, whereas Linux, at that time, some 600? Well, it was in 1997/8? I do remember Dave Haynie (one of Amiga designers) stating something like Linux was not at all usable for things like multimedia, e.g. sound, like BeOS was at that time - just because of latency. So - why had it so bad latency, while being monolithic? I suppose nowadays, the issue with latency is gone, and who knows, maybe my understanding of the issue is not correct anyway ... Wed, 12 Nov 2008 13:56:00 GMT donotreply@osnews.com (-pekr-) Comments RE[4]: Kernel http://osnews.com/thread?337081 http://osnews.com/thread?337081 "Also, while it's good that you have benchmarked it, a total lack of data aswell as how you've benchmarked them makes the statement pretty pointless and lumps it together with all the other subjective 'it feels faster' nonsense scattered across the web."

by "prompted me to do a benchmark, it means i havent done one officialy yet but due to this I will be doing on, and it will be fairly extensive. I will likely do it this weekend when i get time. Wed, 12 Nov 2008 16:13:00 GMT donotreply@osnews.com (poundsmack) Comments RE[5]: Kernel http://osnews.com/thread?337082 http://osnews.com/thread?337082 haha, that whole gateway/amiga deal was one of the things i was going ot reference. but being as it is now so far out of date i didn't bother. you are right though about the events that transpired. glad i am not the only person who remembered that/took part in it. Wed, 12 Nov 2008 16:16:00 GMT donotreply@osnews.com (poundsmack) Comments RE[5]: Kernel http://osnews.com/thread?337089 http://osnews.com/thread?337089
you know, Amigan, message based system)
you could implement message based IPC in a macrokernel too ;-)

So - why had it so bad latency, while being monolithic?

preface: i prefer the word "macrokernel" because "monolithic" is really the opposite of "structured", as in a system that enforces logical data / function separation between components, and defines boundaries and communication interfaces for them, be they in the same address space or not
actually the microkernel / macrokernel difference depends on the amount of abstractions the kernel supports via its facilities, and is orthogonal to the monolithic / structured one... but anyway
so, the word "monolithic" or "macrokernel" says something about the way a kernel appears when it has been loaded into memory (i.e. what its binary image contain, from a functional point of view - i.e. it may contain device support code - drivers - it may contain VFS node handling code - filesystems - etc)
if one doesnt take the above digression into account, reading "monolithic" may also denote the way the kernel has been organized, code- and structure wise (that is, implemented with global data structures instead of per -subsystem private ones and access APIs )

but it says nothing about the implementation details of those data structures, and the algorithmic efficiency of code that manupilates them
in practice, one can have a kernel with an internal FS layer and drivers performing, or appearing to perform (that is, depending on the use case and the evaluation metric) worse than a system in which they're external - for some applications global throughput is far more important than latency, for others the converse is true

the problem with latency mainly lies in the cost of resource sharing across processes and now threads
on unix and operating systems derived and inspired from unix, the kernel completely virtualizes the underlying system, and then *is* the system, for all intents and purposes of applications, that can only access the HW via kernel calls
thus the kernel itself is a shared resource, on older kernels this translated into a global mutual exclusion lock, that ensured only one process at a time could be running inside the kernel (meaning, could be waiting on an impending syscall while the kernel executes its part)
this ensured the rest of the kernel code could be lean for the sake of (relative) simplicity, but it also made it not very scaleable
on the other hand, a similar mutual exclusion was introduced by the "hardware layer" of the kernel - when executing some privileged HW operation on a bus or device, HW interrupts were disabled to be reenabled when the operation is completed - this effectively means the systems does not react to user input during that timeframe, since mouse or keyboards events are ignored

what time brought to linux and bsd, was incremental algorithmic updates that pushed locking "down" to individual data structures, making resource contention more granular and increasing scalability at the cost of some added complexity - and, with preemption points, a reduction (yet no complete elimination) of the inactive interrupt window - which yielded higher than before responsiveness and lower *innterrupt* latency (which, it maust be noted, is a separae thing from syscall latency - the time taken by system calls to execute vary greatly across types of calls and with the size of the working sets - thus a worst case value, is usually accounted)

OTOH, other systems developed from scratch have been able to tackle the above problems earlier and more effectively by taking a different design right from the start
many if not all modern microkernels have a couple things in common - one is a fast, usually message based IPC, necessary to achieve adequate throughput while retaining user space servers
another is their claiming to be "fully preemptable" (a new operation may be submitted to the kernel at any time, and the kernel is nearly always ready on interrupts - so the nominal latency becomes the latency of an interrupt serve)
since there are always some lowest level pivileged operations that cannot be preempted, the kernel cannot really be preempted at *any* time, but since these are usually extremely short (orders of magnitude shorter than the normal kernel code path), atomic operations, they might become the actual granularity unit without imposing noticeable overhead

the third is one that partly derives from the former: if you have userland services and a message based IPC system, chance is you'll implement a flexible and so-not-old-unix transaction dispatch mechanism

one interesting side effect is that, if versatile enough, the dispatch mechanism may go as far as to support both user and in kernel servers
then one may build primary services back into the kernel for performance reasons
but because of that dispatch mechanism and because of what is "at heart", it probably won't be a monolithic kernel, rather a structured extended kernel based on a microkernel

you'll have effectively reinvented NT ^_^Edited 2008-11-12 16:57 UTC Wed, 12 Nov 2008 16:47:00 GMT donotreply@osnews.com (silix) Comments