LWN: Comments on "The Dawn of Haiku OS (Spectrum)"

LXDE is fast

k8to — Sat, 05 May 2012 17:11:41 +0000

It's funny that the mac os x solution is 'better' when it still stutters and hangs on high cpu AND high I/O on my quad core macbook pro. This if for trivial things like repositioning a window that should have no external requirements.

The Dawn of Haiku OS (Spectrum)

tialaramex — Sat, 05 May 2012 13:28:12 +0000

It's roughly the same split as Linux. So for example, most hardware drivers live in the kernel, but printer drivers (because they don't really do anything directly with hardware) live in userspace just like a typical Linux distribution. The low-level bit banging graphics hardware drivers live in the kernel, but code for drawing windows and so on lives in userspace. Similarly for audio the software mixer lives in userspace while the hardware drivers live in the kernel, the same split as any modern Linux distro (this is true even though Haiku uses OSS drivers, for which the mixer is usually in the kernel) Filesystems live in the kernel, but they have looked at implementing FUSE. Networking lives in the kernel, including both drivers and the TCP/IP stack.

If you ask one of the people actually /working/ on Haiku's kernel about this they don't care. The "hybrid" claim comes from the fanbase, not the developers. To remove the claim from Wikipedia you'd need an authoritative third party source to say it isn't true, and in topics like Haiku there's a lack of such sources... Unfortunately, being able to "cite" Wikipedia, you will see this claim spreading, and then those recitations can be cited on Wikipedia, snowballing. As I said, for an important topic someone would step up and fix this, but for fans making a bogus technical claim about a hobby OS it's unlikely to happen. Genre claims for obscure bands (e.g. claiming some band "invented" a genre years before it was popularly recognised) are likewise subject to fan distortion on Wikipedia.

The Dawn of Haiku OS (Spectrum)

tstover — Thu, 03 May 2012 18:42:24 +0000

made me laugh for about 3 minutes

The Dawn of Haiku OS (Spectrum)

smitty_one_each — Thu, 03 May 2012 17:36:49 +0000

Thinking it fun, I
Decided to comment here,
But ran out of syl-

The Dawn of Haiku OS (Spectrum)

pboddie — Thu, 03 May 2012 11:22:11 +0000

While I would have to wait for a word processor program to load from HD on an Amiga, once it was running it was significantly more interactive, with lower latency, than I see even today on MacOS / Linux / Windows. Less prone to freezing.

Yes, but wasn't it then "locked" into RAM? No demand paging or anything like that? I used Acorn RISC OS back in the day and you could have said the same things (although hard disk performance wasn't that bad and you could run the program from a floppy disk and wait for it to load, too, at least for most applications), and the latency was low because the foreground tasks were given priority to respond to UI events as they occurred (total priority, as RISC OS had cooperative multitasking and thus completely favoured interactivity over throughput).

What we see with Linux (and with Unix traditionally) is a compromise that trades guaranteed low latency for the ability to handle workloads that are actually larger than the resources available to process them all at once. When images and other kinds of data started to grow significantly in volume in the early 1990s, microcomputer operating systems started to struggle with it all, and various extensions were bolted on to provide crude virtual memory features just to make certain tasks possible, given that the alternative solution of adding more RAM only went so far on machines that could only support a few megabytes. It's no surprise that the dinosaurs of the microcomputer era went extinct, very nearly including Apple and of particular relevance to this article, of course.

Just, er, more prone to complete system crashes (see above, re lack of memory protection) but even those were comparatively rare.

Despite the instant UI updates (at a cost of other applications being more or less suspended), I wouldn't want go back to that era where an errant application could hang the system, leaving only the mouse pointer working because it was a hardware sprite updated by an interrupt routine. The only remotely similar thing I've seen on Linux is the graphics hardware freezing due to a driver issue, and even then the system had not technically hung.

The Dawn of Haiku OS (Spectrum)

Comet — Thu, 03 May 2012 07:45:11 +0000

Commodore purchased Amiga, and released the Commodore Amiga line of computers.

There are a number of strong similarities between AmigaOS and both OS/2 and BeOS. Mostly because the AmigaOS was just ahead of its time. When I talked with the owner of a BeBox or the local OS/2 fan, they acknowledged the links and the homage. Once upon a time, fans were able to not be completely condescending about something just because it was different. (Er, except some Amiga fans, but it really was ahead of its time).

32-bit fully re-entrant preemptive multi-tasking microkernel message-passing OS; alas, it lacked memory protection, because back in the days it was released, those CPUs cost a lot more.

Oh, notify events, I remember when I was learning Unix being told that I was silly for wanting them and they just caused security holes by making race conditions easier to exploit. My, how times have changed.

While I would have to wait for a word processor program to load from HD on an Amiga, once it was running it was significantly more interactive, with lower latency, than I see even today on MacOS / Linux / Windows. Less prone to freezing. Just, er, more prone to complete system crashes (see above, re lack of memory protection) but even those were comparatively rare.

(See, "when I were a lad", programmers had to actually understand systems and programming concepts, instead of just glueing together a bunch of open source components and talking about how hip and skillful they are. "Youth of today" ...)

Seriously, interactive latency today just does not compare. But this seems to be an attribute confined mostly to word processors, as everything else seems to have gotten better.

The integrated media handling system which came later, DataTypes, was way ahead of anything else for letting an external library just handle the picayune details of media types (pity that it wasn't too efficient). Even the original media handling, with the IFF format, lives on in the strong influence of IFF on the design of PNG.

Dear me. HAM8 ...

LXDE is fast

andreoli — Wed, 02 May 2012 07:35:20 +0000

Hi flammon, you might want to check this out:
http://algo.ing.unimo.it/people/paolo/disk_sched/

Mauro

Progress need variety (The Dawn of Haiku OS (Spectrum))

salimma — Wed, 02 May 2012 02:46:18 +0000

And when the write target is a USB thumb drive, everything slows to the point that Firefox and Thunderbird can't cope and display "component not responding" warnings.

The Dawn of Haiku OS (Spectrum)

cmccabe — Wed, 02 May 2012 01:02:22 +0000

tialaramex said:
> Haiku doesn't actually have a "hybrid" kernel, whatever that means

I was quoting wikipedia. From http://en.wikipedia.org/wiki/Haiku_(operating_system):
> The Haiku kernel is a modular hybrid kernel and a fork of NewOS,[4] a
> modular kernel written by former Be Inc. engineer Travis Geiselbrecht.
> Like the rest of the system it is currently still under heavy development.
> Many features have been implemented, including a virtual file system (VFS)
> layer and rudimentary symmetric multiprocessing (SMP) support.

To be honest, I have no idea which parts of Haiku are implemented in kernel space and which in user space. It would be nice to see a list somewhere.

Progress need variety (The Dawn of Haiku OS (Spectrum))

nybble41 — Tue, 01 May 2012 16:20:03 +0000

Here are some settings that helped me out with a similar issue:

# Limit total dirty data to 60MB
sysctl vm.dirty_bytes=62914560

# Only use transparent hugepages on request via madvise()
echo madvise > /sys/kernel/mm/transparent_hugepage/enabled

These settings may not be for everyone. In particular, the second issue is supposedly much better in recent (>= 3.3) kernels. However, these changes did get rid of most of my writeback issues.

Not so funny

juliank — Tue, 01 May 2012 15:55:39 +0000

It doesn't need something like Tracker, because it's built into the file system itself. The file system is a searchable database, not a simple tree.

Progress need variety (The Dawn of Haiku OS (Spectrum))

whitemice — Tue, 01 May 2012 14:28:03 +0000

This may not be terribly helpful - but something *else* is wrong with your box. The settings are dorked, some hardware is not operating correctly, or you have some kind of mismatched kernel

Progress need variety (The Dawn of Haiku OS (Spectrum))

Cyberax — Tue, 01 May 2012 07:23:53 +0000

Which it shouldn't.

Writeback initiated by one process should minimally interfere with other processes. As it is, right now I'm experiencing slowdowns in Firefox when I do heavy 'dd' in a terminal. Even on an SSD drive.

Progress need variety (The Dawn of Haiku OS (Spectrum))

zlynx — Tue, 01 May 2012 06:41:57 +0000

I don't think 64-bitness has much to do with the disk IO problems, if that is what you are referring to.

What does have an impact is big piles of RAM. When the operating system can dirty, say, 10 GB of RAM and yet it can only write it out at 100 MB/s or slower, things get into trouble. That is over 100 seconds of disk write, even if the system stops producing new IO requests.

The Dawn of Haiku OS (Spectrum)

whitemice — Tue, 01 May 2012 01:31:29 +0000

> I don't think Linux is any older, and certainly not "much". Be Inc.

It is considerably older on 'normal' hardware. The early BeOS was multi-core in an age when multi-core PCs, and even multi-core workstations, were quite rare.

There architecture on the x86 hardware of the time would have been epic-fail. Even the ringed security architecture of NT 3.5 a few years later was brutal on the hardware at the time [hence the faster but in some ways inferior NT 4.0 that followed].

>and BeOS claims to date back to 1991.

I remember it. And it ran on very proprietary and very expensive hardware. It got some press in the excellent UNIX Workstation magazine and some others [back when there were interesting IT periodicals... sigh].

LXDE is fast

jzbiciak — Mon, 30 Apr 2012 23:41:00 +0000

The 603 and 603e lacked hardware support for SMP. That doesn't mean they couldn't do SMP, though, without software help, as Be demonstrated.

The main restriction I can see that imposing is that you couldn't have a writeable page that was shared by two threads running on different CPUs, unless they took pains to manually trigger writebacks and invalidations when data needed to be made visible to the other CPU. Also, you need to kick private pages out of the cache whenever you migrate a thread from one CPU to the other.

It seems doable if you design your primitives this way from the beginning, but an absolute pain if you try to retrofit it onto an existing OS that expected hardware-managed coherence.

"Pervasive multi-threading"

Cyberax — Mon, 30 Apr 2012 20:24:41 +0000

Not really. The basic utilities were indeed responsive.

But complex applications were not. For example, Gobe office was much slower than contemporary Microsoft Word on Windows 98.

Other applications ported from Linux/Windows were not any more responsive as they just emulated a single-threaded event-loop driven model. In the end, I'd argue that BeOS's way of making responsive user interfaces sucks because it requires over-complex synchronization.

IMO, the only workable model for multithreaded interfaces seems to be scene graphs.

LXDE is fast

pboddie — Mon, 30 Apr 2012 19:47:02 +0000

I'm using Ubuntu 8.04 on less impressive hardware and found that updatedb was taking most of the I/O bandwidth, but then I also suspect that the hard disk has something to do with it, given that I noticed this becoming more of a problem after switching to a Western Digital Caviar Green model that apparently belongs to a range of products that have various performance-related issues.

I've since reconfigured the auto-parking feature on this particular WD drive - which really shouldn't be the cause of a bandwidth issue, but it was misbehaving in a pathological fashion - and I haven't noticed any really bad performance issues so far, so maybe you're experiencing some equivalent problem with your storage.

(All these claims about Linux needing multicore CPUs to be responsive are, in my opinion, nonsense. My hardware is around seven years old, apart from the hard disk, and it's easily responsive enough.)

LXDE is fast

mhelsley — Mon, 30 Apr 2012 19:36:51 +0000

"Also at BeOS's time, each desktop PC was mono-CPU so the scheduling did matter"

Yes, that's true of PCs and Macs of the time. Yet the BeBox was an oddball multi-cpu PowerPC 603 (603's were cheaper but lacked SMP support. Yet they made it work somehow). So BeOS on BeBox also had multiple cores.

The Dawn of Haiku OS (Spectrum)

tialaramex — Mon, 30 Apr 2012 16:43:27 +0000

"It is simply the fact that LINUX is much older than Be-OS"

I don't think Linux is any older, and certainly not "much". Be Inc. was founded in 1990, and BeOS claims to date back to 1991. It's old enough to have been written for the ill-fated Hobbit CPU architecture and had to be ported to PowerPC and then Intel.

BeOS was trying to be more "forward looking". So while Linux soon needed a traditional Unix "big lock" multi-processor conversion, BeOS was designed for symmetric multi-processor systems from the outset, and instead of needing _LARGEFILE_SOURCE BeOS always defined off_t as a 64-bit value too. However more often than not their crystal ball was cloudy. They wrote for the ill-fated Hobbit CPU, they assumed Internet connectivity was relatively unimportant, and they relied heavily on C++ before it had even been standardised, let alone settled on a maintainable ABI. As a result of that last misstep Haiku must rely upon GCC 2.x because that's the last compiler which implements the C++ ABI the original BeOS R5 is wedded to.

people do not use a computer to use it's desktop

dlang — Mon, 30 Apr 2012 16:21:52 +0000

people do not use a computer to use it's desktop, they use the computer to get things done (either to play games, access the web, e-mail, write documents, watch video, etc)

a desktop either makes this easy or makes this hard depending on how it gets in the way of the user or assists the user.

Far too many desktop developers seem to think that the Desktop Environment is the end purpose of the computer, rather than just a means to get other stuff done.

The Dawn of Haiku OS (Spectrum)

Doogie — Mon, 30 Apr 2012 15:52:46 +0000

Funny to see Linux zealots bad-mouhing alternatives, the irony is striking.

Pointing out that some people have not moved beyond the same silly advocacy arguments from two decades ago is not "bad mouthing alternatives". Haiku may well be fantastic, but arguing that it has "multimedia built in" is not going to convince me.

LXDE is fast

drag — Mon, 30 Apr 2012 15:45:44 +0000

>So when the user does something... *something* happens. Even if it is a "system busy" response. Anything is better than nothing happening.

Actually if I remember correctly what happens is that the OS will silently drop UI requests from the user. The OS maintains the queue from the UI to the application thread and if it gets built up it will just start dropping items from the queue. So that if you click 'send to printer' but the application is busy it may or may not completely ignore your request.

This is one of those things that the OS did to make things 'simple' for the application developer to write threaded applications. I could be very mistaken, of course.

Progress need variety (The Dawn of Haiku OS (Spectrum))

drag — Mon, 30 Apr 2012 15:21:26 +0000

> Sure, it is great, and most of clichés that came out in the discussion refer to old and solved problems; sure, problems like HD latency cannot be magically solved by a new kernel

Fixing bugs in I/O scheduling can be fixed by running a updated kernel that has a fixed I/O scheduler. Nothing magical about it. It's not a easy problem to solve, but it seems very possible.

> But there is no progress without variety; if somebody do not try something different, there will never be something different; so, i think the Haiku OS people deserve praise for trying, even if you think their effort will not produce anything directly.

I don't think anybody deserves praise just because they like to hack on a toy OS. I certainly hope, though, that they get out of it what they are seeking and have fun doing it.

Just like people screwing around with GNU/Hurd, ReactOS, Mini, Debian GNU/kFreeBSD, or any other number of vanity OS projects. I am sure it's all very much fun for them.

> Yes, there are kids playing the fanboy game; who care ?

Correcting people is not a sin. And I fully expect that the actual developers and people directly involved in the project actually are very knowledgeable and understand what is going on very well.

Good luck to them.

Not so funny

whitemice — Mon, 30 Apr 2012 14:55:08 +0000

I also have a powerful quad core workstation. I run tracker. I also have a PostgreSQL database on my workstation - which I hammer.

And I do not see sluggish UI performance, even when all six of the hard
drives are grinding away.

openSUSE 12.1

The Dawn of Haiku OS (Spectrum)

tjc — Mon, 30 Apr 2012 14:53:34 +0000

I doesn't matter who is bad mouthing whom; it's all very juvenile and tiresome.

LXDE is fast

whitemice — Mon, 30 Apr 2012 14:53:02 +0000

>> -on BeOS/Haiku each application has a thread dedicated to the GUI making
>> the UI very reactive
> What is the point of having a reactive UI when the application logic
> behind it is hanging on IO Wait?

So when the user does something... *something* happens. Even if it is a "system busy" response. Anything is better than nothing happening.

But well designed applications work this way, even on LINUX. It is an issue of application design.

The Dawn of Haiku OS (Spectrum)

whitemice — Mon, 30 Apr 2012 14:50:29 +0000

> Linux, for instance, is based around a core—called a kernel—that was
> originally designed for use in servers and only later modified for
> desktop systems.

This is simply, factually, false. The first LINUX systems were desktops. It is simply the fact that LINUX is much older than Be-OS and meant to run on conventional hardware; hardware at the time that was pretty limited compared to the Be Box.

> which Linux users experience as annoying delays when their computers are
> doing especially taxing things, like burning a DVD or compiling code.

This issue is historic. Both hardware and kernel scheduling has much improved.

Progress need variety (The Dawn of Haiku OS (Spectrum))

Pawlerson — Mon, 30 Apr 2012 13:52:20 +0000

Sure, it is great, and most of clichés that came out in the discussion refer to old and solved problems; sure, problems like HD latency cannot be magically solved by a new kernel (buy an SSD :).

It's worth to note such problems seems to be common on 64bit hardware. The same happens on Windows. If someone wants to compare some haiku to Linux then compare it on 32bit hardware.

Progress need variety (The Dawn of Haiku OS (Spectrum))

maurizio.dececco — Mon, 30 Apr 2012 12:18:37 +0000

I frankly find this discussion depressing.

Pretending that Linux is the end of history in term of kernel and OS development is just silly.

Sure, it is great, and most of clichés that came out in the discussion refer to old and solved problems; sure, problems like HD latency cannot be magically solved by a new kernel (buy an SSD :).
Sure, there is lot of nostalgia in rebuilding a system based on a 17 year old system (of which i know almost nothing about).

But there is no progress without variety; if somebody do not try something different, there will never be something different; so, i think the Haiku OS people deserve praise for trying, even if you think their effort will not produce anything directly.

Progress may come for trying new ideas or retrying old ones. For the example, most of the "modern" UI toolkits use a programming paradigm defined in the middle of the 70s (object tree and callbacks), even if the lowest levels moved a lot (composing, OpenGL backend and so on). So, any project trying or re-trying something different will be useful, imho, even if just for rediscussing the ideas.

Yes, there are kids playing the fanboy game; who care ?

Maurizio

The Dawn of Haiku OS (Spectrum)

sorpigal — Mon, 30 Apr 2012 11:54:16 +0000

> In case you didn't notice the Haiku zealots are bad-mouthing Linux.
I read this is justifying another free OS by pointing out deficiencies of the popular one.

It's not necessary for Haiku to beat Linux of today in its R1 release, it just needs to beat Linux of 2001 (that is, after all, its goal: Be BeOS in 2001). With the R2 release in 2015 or so we will see whether it's going anywhere worthwhile or whether it simply can't compete.

LXDE is fast

Pawlerson — Mon, 30 Apr 2012 11:39:16 +0000

Very funny, one more post which claim that Wayland will fix everything..

We don't like Wayland, do we? Not everything, but just UI responsiveness and it seems you have agreed. It doesn't matter if Wayland itself is not enough.

The Dawn of Haiku OS (Spectrum)

tialaramex — Mon, 30 Apr 2012 11:38:43 +0000

Ryan Leavengood (the author of the IEEE Spectrum article) has been told this claim is wrong before. He's not interested in its veracity because it serves a purpose in the narrative independent of its status as a claim about the real world. It is, to use a technical term, bullshit.

"Pervasive multi-threading"

renox — Mon, 30 Apr 2012 11:36:54 +0000

> but of course that just leads to fans saying that all software needs to be written from scratch for BeOS in order to perform well.

BeOS has a multithreaded API, so it seems sensible that to be really efficient, programs must be designed to use the multithreading, but of course those who point out this fact are "fans"!

As for the permission checks, there are many differences between Linux and BeOS why do you think that it's the permission checks which have such impact?
Any benchmark which support your "guess"?

LXDE is fast

Pawlerson — Mon, 30 Apr 2012 11:36:26 +0000

How can it 'cheat'? If they're predictive preloading and it works, then that's a good thing, right?

It has to be verified if it preloads itself or does something else. It's cheat, because when you modify your setup, install third party applications its speed will go away. If someone wants to have a good comparison then he should compare haiku to Linux distribution that's doing something similar. Puppy Linux running on CD is increadibly fast and responsive.

"Pervasive multi-threading"

tialaramex — Mon, 30 Apr 2012 10:39:54 +0000

BeOS had, and Haiku has today, a system that seriously lacks application software.

This means that people's perceptions of "most responsive" tend to be very superficial because they aren't comparing apples with apples. If you go to a bunch of effort to _port_ some apples so that you can do the comparison BeOS does not come off very well, but of course that just leads to fans saying that all software needs to be written from scratch for BeOS in order to perform well...

If you want to know where BeOS is getting the responsiveness advantages it does have, do not look at the (pointless) waste of extra idle threads, I suggest instead considering things like heavy reliance on explicit priorities (which is fragile but it works) and the complete lack of security (in say Linux, every low-level operation is permission checked, BeOS can skip all this work because despite the superficial appearance of POSIX-style file permissions in reality it's a single user system with no privilege separation)

In terms of specific application tricks, storing the icon for a file in the metadata block is a costly but effective way to speed up rendering a folder view. One of Haiku's few genuine novelties is the bit frugal vector icon format which lets it squeeze decent looking icons into a small space on disk to make this happen.

Not so funny

xav — Mon, 30 Apr 2012 09:59:36 +0000

Of course it's due to too much I/O. That desktop has a RAID 5 setup, I think it's why it's so obvious. Still, I/O contention is a real weakness on current Linux desktops.

"Pervasive multi-threading"

renox — Mon, 30 Apr 2012 09:55:19 +0000

A working system is much better than words: BeOS had the most responsive system at the time. That's a fact.

So claiming this design was only for making it a little easier for a programmer at Be Inc seems not very credible.

LXDE is fast

renox — Mon, 30 Apr 2012 09:42:49 +0000

> With Wayland Linux should become very responsive.

Very funny, one more post which claim that Wayland will fix everything..

So FYI, Wayland should improve performance, but for the responsiveness this is more complicated: for example Wayland with server side window decoration&management (planned for KDE) should be more responsive than Wayland with the default Weston compositor and the client side decoration&management.

Not so funny

the.wrong.christian — Mon, 30 Apr 2012 09:37:47 +0000

> I have a reasonably modern system (Quad Core @ 3GHz), and believe me, as soon as something like Tracker does its infamous indexing job (which is way too often) the desktop feels really sluggish. Waiting 20s to launch firefox is the norm.

Funny. On my SSD equipped, but otherwise modest laptop, launching Firefox happens within a second or two (while also launching Lotus Notes and Sametime). I guess you're more limited by the HDD latency, as Tracker cause the HDD to skit back and forth across the disk.

In fact, most UI pauses in Linux are caused by disk IO latency, as Linux swaps in code that is not in memory. HDD contention only makes the problem worse.