Syllable vs Haiku

Linux kernel links each with graphics (with fairly similar layouts) to show & prove that Linux's kernel is monolithic & for comparison.
http://book.opensourceproject.org.cn/embedded/oreillybuildembed/opensour...

http://tldp.org/LDP/sag/html/kernel-parts.html

http://www.ibm.com/developerworks/linux/library/l-linux-kernel/

Of extra interest is also the Source Lines Of Code to show how complex (big & error prone) the Linux kernel is getting.
January 2001 : 3.37 Million
December 2003: 5.92 Million
March 2011 : 14.29 Million

My latest comment is sat in the spam filter apparently.

Among those millions of lines of code are all the drivers for the hardware that simply doesn't work in Haiku. Everything from the DVB dongles to entire computers that are powerful and effective with Linux, but are just paperweights with Haiku. Whole platforms that Haiku not only doesn't boot on, but hasn't even begun porting to.

Not to mention the network protocols and filesystems, or the features like virtualisation or suspend to RAM that lots of people use everyday with Linux but remain on some distant future "TODO" list for Haiku.

Yet when I boot Haiku I see 13 of 17 running processes are servers. Boot Haiku & check against the server list below to see for yourself.
http://dev.haiku-os.org/browser/haiku/trunk/src/servers
I guess those servers are just for show then?

I'm very sure I have said that hybrid is modified microkernel two times already. Have you not understood that? Hybrid is closer to microkernel than monolithic design.

More likely that a) the term hybrid did not exist (or too new) back then or b) people like you that believe there are only micro & monolithic kernels. Haiku is closer to microkernel and why they would have chosen that term instead. Not right but closer in design before people accepted hybrid term.

What the heck are you going on about? Microsoft has a picture showing exactly what they mean. You have trouble interpreting pictures? Look for the gif link I gave. For Windows NT, you'll see: Security, OS/2, WIN32, POSIX Subsystems. Those are the servers that talk to the applications & kernel. Windows 95 does not have these subsystems (servers). Look again. The picture is self explanatory itself. Then compare to Windows 95 picture in one of my other links.

You've been told Haiku's kernel is hybrid (or microkernel) by me, AndrewZ, thatguy & MichaelPeppers and still won't accept it.

Before Haiku-OS website redesign in 2008 the site used to say:
"The Haiku kernel is a multi-threaded, modular hybrid kernel based on Travis Geiselbrecht's NewOS. At the point of this writing, it's still under heavy development to create the stable and reliable foundation you will expect of Haiku."

So the best you can do is point to a thread where two non-kernel developers assume (or guess) Haiku's kernel to be monolithic. With no proof or any good reasons to show why this would be and you take their word for it because no other developer bothers to reply back to correct them. But me giving many quotes & references to show why I'm right you don't believe and want me to give specifics. Doesn't this seem like a double standard? I have asked you to provide links to linux kernel/expert developers saying & proving Haiku's kernel is monolithic and you have been unable to do so! No surprise there because you're wrong and won't admit it!

Not right. All I had to prove was that Haiku uses servers & I know I've managed that. If you bother to boot Haiku you'll see the servers in ProcessController. Also, many people will agree with me rather than you because I'm right!

You wanna know what is wrong with linux and most UNIX systems?

Too much cruft and cheap hacks to make them work.

One example : http://lwn.net/Articles/436012/

Just read the article and see. This happens all over the place, from networking where they first introduced the GUI part (nm_applet) and then they startted writing the non-gui part, to sound and storage technologies.

Haiku maybe smaller and simpler, but it is consistent with it self.

My only problem is that by the time Haiku is ready for general use, then nonmore desktop computers will exist.

I did not realize you were the expert. How come everyone else, even NoHaiku, was saying Linux had a monolithic kernel? The fight was whether Haiku was monolithic or hybrid. We all agreed Linux was monolithic.

There are books & websites & Wikipedia that will tell you that Linux's kernel maybe more modular but still monolithic. That is why Andy T & Linus were fighting back in 1992 & again in 2007. Also, if you read any of Linus' posts you'll see he is strongly opposed to microkernels and does not believe in hybrid kernels. So, would be big surprise if Linux was not monolithic.

http://www.realworldtech.com/forums/index.cfm?action=detail&id=66630&thr...
On May 9, 2006 Linus said "As to the whole "hybrid kernel" thing - it's just marketing. It's "oh, those microkernels had good PR, how can we try to get good PR for our working kernel? Oh, I know, let's use a cool name and try to imply that it has all the PR advantages that that other system has"

It is because of Linus (who likes to bash & attack when he disagrees with others) that people like NoHaiku see hybrid kernels as non-existent and as monolithic. When you have Linus, founder of Linux, running around saying hybrid is hype (marketing term) then people follow and believe him even though Wikipedia & others recognize the term for good reason. ie, Linus will still argue hybrid is not real and people will still believe him. Even Andy T mentions hybrid. See near end of my post for Symbian quote.

I agree but what I was trying to point out is with a monolithic kernel as it gets bigger & bigger in size it risks 1) more serious bugs (code size) 2) loses efficiency (code bloat) and 3) reduces stability (code complexity)

Linus now spends most of his time reviewing kernel patches because any bad code and the Linux kernel would be crashing & unstable.

Below from: Linus calls Linux 'bloated and huge'
http://www.theregister.co.uk/2009/09/22/linus_torvalds_linux_bloated_huge/

"Citing an internal Intel study that tracked kernel releases, Bottomley said Linux performance had dropped about two percentage points at every release, for a cumulative drop of about 12 per cent over the last ten releases. "Is this a problem?" he asked."

Linus said, "I mean, sometimes it's a bit sad that we are definitely not the streamlined, small, hyper-efficient kernel that I envisioned 15 years ago...The kernel is huge and bloated, and our icache footprint is scary. I mean, there is no question about that. And whenever we add a new feature, it only gets worse."

Debunking Linus's Latest
http://www.coyotos.org/docs/misc/linus-rebuttal.html
"Linus, as usual, is strong on opinions and short on facts.

"When you look at the evidence in the field, Linus's statement ``the whole argument that microkernels are somehow `more secure' or `more stable' is also total crap'' is simply wrong. In fact, every example of stable or secure systems in the field today is microkernel-based. There are no demonstrated examples of highly secure or highly robust unstructured (monolithic) systems in the history of computing."

If you want to know more about microkernels and hear Andy's side then read his post from 2007:
http://www.cs.vu.nl/~ast/reliable-os/
Andy T said,"Symbian is yet another popular microkernel, primarily used in cell phones. It is not a pure microkernel, however, but something of a hybrid, with drivers in the kernel, but the file system, networking, and telephony in user space."

The nice thing about technical issues is that those who most need to care can see for themselves what's right. They may not know the terminology (we can see threads where Haiku developers use "hybrid" to mean "modular" for example) but none of them believes that the X server on a Linux distribution is part of the kernel, or that running the PPP client daemon in user context is an innovation.

I'd have been completely happy to learn something and change my position, but the trouble is that you never refuted a single thing I said, preferring instead to find endless pretty box diagrams to link to and trying to equate Haiku's high-level servers like the app server with the servers in a microkernel system that handle low-level stuff like device drivers.

Hybrid kernels are a marketing exercise. Take a monolithic kernel, rebrand it, the technical people will say "that's a monolithic kernel" but no need to worry about them, because the marketing works on some people who then believe - and post at great length - that it's inherently better than the alternatives.

Imagine if someone told you their car had a "fusion" flat 6 engine. Upon opening the bonnet you realise it is an ordinary (inline) four cylinder. They keep saying "flat 6" and "fusion" and insisting that this is resulting in a very smooth ride. Obviously if you point out that it has four cylinders they may refuse to listen. They may have a colourful brochure which insists it's a new "fusion" between an four cylinder and a flat 6, and how can you contradict such a glossy piece of marketing? And they're enjoying such a smooth ride. Still, it's not true. Maybe they (and a horde of other people who've been sold these hypothetical cars) will write magazine articles and Wiki entries based on what they read in the brochure. It's a lot easier than doing actual research.

All anyone has to do is open the bonnet, and they'll find all the low level components of Haiku running in Ring 0 in the monolithic kernel just like a typical Linux system. No matter how many people add Haiku to a list of microkernels, or nanokernels, or any other classification, one look under the bonnet confirms it's just a regular monolithic kernel.

What is the difference between "hosting" and "using" modules? If the natural meanings of these words are used, it seems a "hybrid kernel" cannot really exist.

You write here "controlled mainly by" but you don't explain what you mean. Does my telephone "control" the Indian takeaway in this sense? Haiku's servers you mentioned each use system calls to access device drivers, which run in Ring 0 and are part of the monolithic Haiku kernel. This is roughly the same as their counterparts in a Linux system, such as the X server, GPM, PulseAudio or GStreamer.

When you say here that the kernel "only hosts it" you are including a lot in that. There is no mechanism to directly access these add ons (driver modules) from userspace. Instead userspace performs system calls, which are interpreted by the kernel, and in some cases the execution path inside the kernel will execute code from a relevant device driver module. This is, of course, pretty much the same as on a Linux system or indeed most modern operating systems.

The serial mouse is not a bad example. You have a serial driver, which is kernel code, and you have some trivial code in the input server to deal specifically with serial mice. But without that serial driver, the mouse code is useless. The driver, Ring 0 kernel code, deals with interrupts, I/O registers and other hardware specific issues, while the code in input server is oblivious to this.

In a microkernel, that serial driver would be a userspace program. If an interrupt occurred the driver program would receive a message from the microkernel, the program would interrogate the hardware directly, read any pending data and send this as a further message to any listening programs.

And here is why you will never understand what hybrid is. You've already started out biased and closed minded! Linus is the one that strongly holds this position and has brainwashed others into believing the same. Yet, many programmers (including Andy T) recognize hybrid to be real and an entry is even on Wikipedia explaining hybrid kernels. But the Linus camp will never accept or recognize it and really believe hybrid is another name for monolithic.

In fact, I read a post by Linus few days back saying that Amiga OS is not microkernel. Linus was saying that Amiga OS is really monolithic kernel. No wonder people are getting confused and misinformed when you have Linus running around spreading lies like these. Guess Linus does not want other people to know the truth, otherwise he'd get pressured to switch Linux to hybrid or microkernel too. So, Linus goes around making stuff up. ie, making it look like everyone else is using monolithic kernels when in reality only Linux, Solaris & BSD are. So, Linus says hybrids do not exist, that microkernels are bad, bad, bad, etc. so people will side with him. But if people really look at both sides they'll see that it's just Linus' strong opinion & bias and Linus has not proven anything.

I have a post blocked by spam filter that will show Linus saying Linux is bloated & inefficient in 2009! But Linus won't admit that monolithic kernel has made the problem real bad for Linux. There is also a link to Ph.D computer science graduate that shows how Linus twists the truth to arrive to his biased conclusions!

So now I actually had time to sit down with the Haiku source code and write a reply addressing the trickier part of your post.

It would actually be possible (although fraught with danger) to do this, but Haiku doesn't. Instead you can see

                length = _kern_read(fd, programHeaders[i].p_offset,
                        (void *)(region->start + (programHeaders[i].p_vaddr % B_PAGE_SIZE)),
                        programHeaders[i].p_filesz);

The Haiku module loader routine simply reads the ELF sections into reserved kernel RAM. So all the realtek code (and everything else) is read from disk into RAM by this call. There is code to map an ELF image from a disk file into virtual addresses such that subsequent page faults bring it into RAM but so far as I was able to confirm that's only used for userspace programs, not Haiku's kernel add ons.

As we see this isn't true. Not only is there no need to load all this "hardware detection code" from every driver on Linux as I explained above, but Haiku does in fact load the entire driver into RAM.

Of course, many of the things Haiku lacks are a result of your limited resources. But it does no good for people to insist that Haiku does this, or has that capability, when in fact it does not "for lack of resources".

This change landed in 2.6.29, over two years ago. I suppose this is "recent" in terms of Haiku's decade-plus lifecycle but most general purpose systems have a much faster turnover. When Haiku began (as OpenBeOS) the Intel HDA proposal did not exist.

Indeed, however the decision not to use an existing, mature kernel was never forced upon Haiku's developers. OpenBeOS (as it was then called) made an explicit decision to re-invent the wheel. If they want to revisit that decision now they don't need a bug report to do that. But I suspect you will find that the sunk cost fallacy rules the day.

Michael do not be nervous, NoIntelligenceForMe err... NoHaikuForMe is a troll.
Please all do not feed a troll.

It's not anymore. Most work done in kernel land since a couple of years is not anymore in what is actually called "the kernel" but in drivers and their userland composants.
And when it comes to write hardware drivers, any alternative operating systems have a manpower issue. After 20 years, Linux has now enough market share to get some most complex and critic hardware (GPU, network adapters) support from their manufacturers themselves. The standardisation of several hardware *busses* and devices *classes* (AHCI, USB, ACPI, even HDA ;-) ) make this task more easier than it used to be 20 years ago when outside Windows your hardware had no support at all, and no technical datasheet from manufacters. This trend benefit Linux, but more even smaller alternative operating systems.

We don't complain. Knowing and acknowledge that some drivers are not the best design they could be is not complaining. Otherwise, I'll bet that pretty much every operating software developer is complaining, then.
You're the one complaining that our HDA driver design is not good enough, which I acknowledge.
You want a better designed driver? Stop complaining about it and start contributing.
I'm not complaining about the lack of contributors, I'm just complaining about people complaining that an open (aka contributed by people for people) project is not good enough to their taste without seeing that it's pointless: it's not bad enough if you don't care enough to actually do yourself something to improve it.

Which, ironically, is a better solution than taxiing home earlier while you're still quite drunk. Nothing better than a long walk to think about issues at hand
;-)

Nobody will never knows because, well, simply nobody did it. Someones tries this path with Linux Kernel (the BluEyeOS project IIRC), but never reach critical mass.

Call it stupid[est] decision as much as you want but one thing remains: only Haiku reach "let's rewritten BeOS in open source" critical mass. It doesn't make it perfect, it's doesn't make it the only possible way to do it, but so far it's the only one attempted which did it.

And it's not an under-designed single audio hardware driver that will change that fact.

What part of "the developers didn't want to use a server/unix kernel" didn't you get ?

I for one would never consider using a linux kernel. I'd rather gouge out my eyes then untangle that sphagehtti mess of code.

Actually the linux kernel has better overall throughput performance then haiku or BEOS or GNU Hurd minix and the NT kernels.

It does have that, but with that small 3-5% edge over some other kernels comes a huge mess of crap I personally don't want to deal with it either. The biggest problem with linux is that it is essentially anarchy and no one is leading. Without leadership, focus and vision, you get a big mess.

haiku will continues to use code that makes sense and it fiarly well designed. I don't have a problem with the hda driver either. Works fine for me.

did you create a account at freelists.org ? You have to create a account and then join the mailing list.

Once you do that your email will be sent.

Mostly I find linux developers to be hacks, Not hackers. Just hacks.

http://dictionary.reference.com/browse/hack

to damage or injure by crude, harsh, or insensitive treatment; mutilate; mangle: The editor hacked the story to bits.

Can we please call this a dead horse?
This thread has outlived its usefulness.

Not right because people are still working on Hurd at a slower pace. You understand that there's a difference between slow development and no development? Also, the microkernel choice has changed a couple of times setting Hurd back further.

Yet for some reason Debian offers Hurd release. Also development on Hurd is still going on with the release of GNU/Hurd 0.401.
http://www.gnu.org/software/hurd/

"The Hurd is under active development, but does not provide the performance and stability you would expect from a production system. Also, only about every second Debian package has been ported to the GNU/Hurd. There is a lot of work to do before we can make a release."
http://www.debian.org/ports/hurd/

There is even an Arch Hurd ISO in the works.
http://www.archhurd.org/news/19/

Posted Nov 25, 2010
"How many developers are working on the GNU Hurd?
Not many. One handful work on it in their free time, and another two handful do help with Debian GNU/Hurd and Arch Hurd packaging. Also, an additional handful of former developers are still available for answering technical questions, but are not really participating in the current development anymore."
http://www.gnu.org/software/hurd/faq.html

I've already done this. I provided a link to a news story where Linus admits to this himself. Of course you may argue that was in 2009 and now 2 years later but the situation is not likely to have improved. Direct quotes from Linus & the reporter to prove this:

Linus directly says the kernel is getting bloated & huge himself!!! So now you don't even believe Linus? I also showed the code size of the kernel getting bigger and bigger very fast which makes it more open to code bloat. Do you even read any of my posts or links? I gave that same link above in another post in this very thread. I am sure I provided the exact same quotes in that other post too.

The inefficient issue was in comparison to previous releases of the Linux kernel. With every release the kernel was getting slower and slower. ie, becoming inefficient; performance was dropping - took 12% hit. The benchmark was provided and done by Intel. Maybe you don't believe Intel either? I did say inefficient right? Pretty sure I never compared or stated worse or better than other OS kernels in performance. There is a difference between the two. You do realize that?

I was trying to point out that because Linux kernel is huge, bloated, inefficient and complex that many alternative OSes don't bother using it. Those are the reasons why the GNU project itself is looking to not use Linux kernel and move to Hurd in the next 10 years. R. Stallman only recently accepted Linux kernel in 2010 because 1) way too slow development on Hurd 2) performance issues to deal with because Hurd was still not finished 3) the vast amount of drivers for Linux kernel. Had there been more developers then Mr. Stallman would have been pushing for Hurd instead. Why should other OSes use the Linux kernel when they cannot even convince the GNU project to use it? Can you not see the irony there?

My ram drive now works!

Thanks to the Haiku developers for the needed clues.

Now to add compression.