Weekly Edition
Return to the Distributions page
| |||||||||||||
The Dawn of Haiku OS (Spectrum)
IEEE Spectrum has a
lengthy overview of the Haiku OS project which is working to create an
open-source reimplementation of BeOS. "One of the first things
people notice about it is that it doesn’t feel anything like Windows or OS
X or Linux. It’s unique. 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. As a consequence, the kernel sometimes gives
short shrift to the user interface, which Linux users experience as
annoying delays when their computers are doing especially taxing things,
like burning a DVD or compiling code. Haiku’s kernel has always been for a
desktop system, and so it always gives priority to whatever is happening by
way of its graphical user interface."
(Log in to post comments)
LXDE is fast Posted Apr 29, 2012 17:13 UTC (Sun) by gmatht (guest, #58961) [Link]
I don't experience delays when burning a DVD etc. using LXDE. The main annoyance I have with Linux as a desktop system is poor drivers for much of the hardware found in laptops. While there seems to be agreement that Haiku is nicer on desktops, it is not clear what is limiting Linux. Is there any explanation of what Haiku can do that say Linux plus Wayland and a new scheduler couldn't?
LXDE is fast Posted Apr 29, 2012 18:06 UTC (Sun) by flammon (guest, #807) [Link]
I run Ubuntu 12.04 an a modern hexacore system and the UI is still not as responsive as it should. Heavy disk access makes the whole system unusable. I'm not sure where things went wrong but I thought Linus was originally targeting desktops.
Would it be possible to use the Linux kernel and drivers and run the Haiku multi-threaded IU framework on top of it or is the Haiku kernel coupling too tight?
LXDE is fast Posted Apr 29, 2012 22:25 UTC (Sun) by Cato (subscriber, #7643) [Link]
I have similar problems with Ubuntu 8.04 on a Core 2 Duo - very long delays sometimes when I/O is going on (Firefox freezes anyway), and when I boot up, the updatedb processes make the system completely unusable until I kill them.
LXDE is fast Posted Apr 30, 2012 6:17 UTC (Mon) by kevinm (guest, #69913) [Link]
Does putting updatedb in the 'idle' IO priority class with ionice -c 3 -p `pidof updatedb` help?
LXDE is fast Posted Apr 30, 2012 19:47 UTC (Mon) by pboddie (subscriber, #50784) [Link]
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 Posted Apr 30, 2012 7:40 UTC (Mon) by Pawlerson (guest, #74136) [Link]
UI responsiveness you are according to has nothing to kernel. With Wayland Linux should become very responsive. I'm using Kubuntu and in not UI related tasks it's much more responsive than Windows XP. Those Haiku guys are simply lying or have no clue. I heard Haiku is cheating (preloading itself into memory or something like that) and that's why it seems to be fast. I recommend to try Puppy Linux which kills Haiku in every term.
LXDE is fast Posted Apr 30, 2012 9:15 UTC (Mon) by jond (subscriber, #37669) [Link]
How can it 'cheat'? If they're predictive preloading and it works, then that's a good thing, right?
LXDE is fast Posted Apr 30, 2012 11:36 UTC (Mon) by Pawlerson (guest, #74136) [Link] 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.
LXDE is fast Posted Apr 30, 2012 9:42 UTC (Mon) by renox (subscriber, #23785) [Link]
> 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.
LXDE is fast Posted Apr 30, 2012 11:39 UTC (Mon) by Pawlerson (guest, #74136) [Link] 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.
LXDE is fast Posted May 2, 2012 7:35 UTC (Wed) by andreoli (subscriber, #20174) [Link]
Hi flammon, you might want to check this out:
http://algo.ing.unimo.it/people/paolo/disk_sched/
Mauro
LXDE is fast Posted Apr 29, 2012 18:09 UTC (Sun) by arjan (subscriber, #36785) [Link]
there has been a long standing myth that the Linux process scheduler is causing desktop "interactivity" issues, or is not good for desktop use.
Nothing is farther from the truth.
First of all, the process scheduler only matters if you have more than one task that wants to run at the exact same time (in fact, it only really starts to matter when you have more tasks than you have logical cpus.. on a modern desktop system that means more than 4 to 8). In desktop loads, where the cpu is mostly idle... this just does not happen much.
Second.. the scheduler is quite good and fair, especially if you use cgroups.
Now, many of the interactivity issues were caused by the IO elevator and, more so, by the VM writeback mess.... both of which got majorly fixed and the 3.3 kernel should be at a level where the biggest issues are completely gone.
LXDE is fast Posted Apr 29, 2012 19:36 UTC (Sun) by renox (subscriber, #23785) [Link]
You're the only one suggesting that this is about the Linux process scheduler, there are many other components which also matter:
-on BeOS/Haiku each application has a thread dedicated to the GUI making the UI very reactive -the FS is designed so that the file browser can show the files icons quickly (among other features)
Also at BeOS's time, each desktop PC was mono-CPU so the scheduling did matter, with multicores and SSDs, maybe Linux can feel as responsive now as BeOS did?
LXDE is fast Posted Apr 30, 2012 0:58 UTC (Mon) by drag (subscriber, #31333) [Link]
> -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? It's like having the ability to hit the print button 50 times and queue up 50 copies of your document while the printer itself warms up. Yeah sure it's 'very reactive', but is it actually useful?
Anyways Apple figured out a better solution for the problem BeOS was trying to solve by adopting a composited desktop. That way you do not have to worry about the UI hanging and making ugly visual artifacts, tearing, and big blank spaces like you did with Windows or Linux.
> Also at BeOS's time, each desktop PC was mono-CPU so the scheduling did matter, with multicores and SSDs, maybe Linux can feel as responsive now as BeOS did?
Seeing how most of the problems with interactivity with Linux nowadays stems from I/O problems with storage the multiple cpu is probably not needed or the answer. (Although it still is very nice to have) Hopefully fixes introduced in recent kernels mentioned elsewhere improve the situation.
Nowadays on Linux I don't even notice on my laptop (low end dual core CPU) when some runaway process is using up all my CPU. It simple has very minimal impact on the GUI. The only evidence I can tell is when the fan kicks in or higher definition videos start being slow. But heavy I/O can still slow down application reactions quite easily.
LXDE is fast Posted Apr 30, 2012 9:13 UTC (Mon) by renox (subscriber, #23785) [Link]
> What is the point of having a reactive UI when the application logic behind it is hanging on IO Wait?
You have to do it smartly of course, if the application is waiting for something you should have some visual indicator for this.
> Anyways Apple figured out a better solution for the problem BeOS was trying to solve by adopting a composited desktop.
You can use both composited desktop and BeOS threaded application design at the same time: they solve a different issue..
"Pervasive multi-threading" Posted Apr 30, 2012 9:34 UTC (Mon) by tialaramex (subscriber, #21167) [Link]
"if the application is waiting for something you should have some visual indicator for this"
It is a shame, then, that as part of the "Other operating systems stall but ours doesn't because they suck and we don't" propaganda, BeOS and thus Haiku do not provide a busy pointer or other indicator. The belief seems to be that if the user isn't explicitly told something is blocked they will think it's still working. (BeOS was not the first OS to try this rather cheap trick, I believe OS/2 did it earlier).
Anyway, the important thing about Be's design isn't that there's "a dedicated thread for the GUI". You can do that trivially on any modern system, and if programmers don't choose to pay their taxes‡ that's on them, not the system.
No, the design decision in BeOS was that there's a dedicated thread for every individual UI window in the system. If you create three windows (say, a main application window, a settings dialog, and a dialog which asks people to fill out a few entry widgets) then you get three threads, each of which must only directly work with its own UI window. If you touch the wrong window, you deadlock or crash. All of these threads will, of course, spend nearly all their time idle, just taking up precious kernel resources for their state. And to write complex multi-window applications you have to do lots of extra donkey work to ensure that information passes from the thread that has it to the thread which can do something useful with it. If you get any of your locking wrong, you deadlock or corrupt the user's data. All for... what? I suspect the answer is: to make it a little easier for one programmer at Be Inc. almost twenty years ago.
‡ The idea of programmers "paying their taxes" is that there's a bunch of work you have to do when writing software that isn't the fun part, such as localisation, error-handling, usability testing, and it's tempting to skip this, but like paying your taxes it is mandatory if you want (your program) to be a good citizen.
"Pervasive multi-threading" Posted Apr 30, 2012 9:55 UTC (Mon) by renox (subscriber, #23785) [Link]
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.
"Pervasive multi-threading" Posted Apr 30, 2012 10:39 UTC (Mon) by tialaramex (subscriber, #21167) [Link]
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.
"Pervasive multi-threading" Posted Apr 30, 2012 11:36 UTC (Mon) by renox (subscriber, #23785) [Link]
> 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?
"Pervasive multi-threading" Posted Apr 30, 2012 20:24 UTC (Mon) by Cyberax (✭ supporter ✭, #52523) [Link]
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 Posted Apr 30, 2012 14:53 UTC (Mon) by whitemice (guest, #3748) [Link]
>> -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.
LXDE is fast Posted Apr 30, 2012 15:45 UTC (Mon) by drag (subscriber, #31333) [Link]
>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.
LXDE is fast Posted May 5, 2012 17:11 UTC (Sat) by k8to (subscriber, #15413) [Link]
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.
LXDE is fast Posted Apr 30, 2012 19:36 UTC (Mon) by mhelsley (subscriber, #11324) [Link]
"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.
LXDE is fast Posted Apr 30, 2012 23:41 UTC (Mon) by jzbiciak (✭ supporter ✭, #5246) [Link] 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.
Funny Posted Apr 29, 2012 18:12 UTC (Sun) by ncm (subscriber, #165) [Link]
It's funny to see facts from ten years ago trotted out as if they were current. I recall, back in 2001, waiting awhile for a shell prompt when a dd was running, but it's been quite a few years since I had such an experience. (Even BeOS would stall when it was thrashing its swap file.) It appears that the main reason for HaikuOS to exist evaporated before long they finished it.
The smartest thing for them to do now would be to implement a BeOS system-call emulator, a la Wine, to run on top of Linux. Or has that already been done?
Not so funny Posted Apr 30, 2012 7:37 UTC (Mon) by xav (subscriber, #18536) [Link]
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.
Not so funny Posted Apr 30, 2012 7:42 UTC (Mon) by Pawlerson (guest, #74136) [Link]
Did you try running tracker on Haiku to have some comparison? Oh wait, there's no tracker...
Not so funny Posted May 1, 2012 15:55 UTC (Tue) by juliank (subscriber, #45896) [Link]
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.
Not so funny Posted Apr 30, 2012 9:37 UTC (Mon) by the.wrong.christian (guest, #73127) [Link]
> 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.
Not so funny Posted Apr 30, 2012 9:59 UTC (Mon) by xav (subscriber, #18536) [Link]
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.
Not so funny Posted Apr 30, 2012 14:55 UTC (Mon) by whitemice (guest, #3748) [Link]
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
openSUSE 12.1
The Dawn of Haiku OS (Spectrum) Posted Apr 29, 2012 18:59 UTC (Sun) by cmccabe (guest, #60281) [Link] Hybrid micro/monolithic kernel? It's been done-- look at Mach.Multithreaded applications? Um, Linux has had that since approximately forever. Filesystem that can index extended attributes? Ok, that's kind of a new one. But it seems rather unnecessary. Better handling of IO scheduling / VM writeback / process scheduling-- Linux already has this, at least in the newer kernels. There are probably some things that could still be improved slightly, but that hardly justifies a whole new OS. A multithreaded GUI toolkit... now that is interesting. It's been described as a "failed dream" before. I'm curious if the BeOS people will have any better luck with it.
The Dawn of Haiku OS (Spectrum) Posted Apr 29, 2012 20:07 UTC (Sun) by tialaramex (subscriber, #21167) [Link]
Haiku doesn't actually have a "hybrid" kernel, whatever that means. It's just a simple monolithic design like Linux. BeOS had some nods to microkernel architecture, putting the TCP/IP stack and sockets layer into a userspace server. But that worked out very badly for them, the performance was lousy and the traditional "a socket descriptor and a file descriptor are really the same kind of thing" trick from Unix didn't work, nor was there a workable replacement (as there is in NT based systems). So by the time Be Inc ceased to exist it was well known that the company intended to put networking inside the kernel, and Haiku follows this approach today.
The Dawn of Haiku OS (Spectrum) Posted Apr 29, 2012 20:48 UTC (Sun) by drag (subscriber, #31333) [Link]
> a "hybrid" kernel, whatever that means.
A hybrid kernel is created using 1 of 2 methods:
Method 1:
A proprietary software company advertises operating system uses a microkernel as if it is a big selling point. Then you have a huge slew of fanboys that by into such advertising unquestionably and then touts that feature as evidence of the technical superiority of their consumer product of choice. Then more knowledgeable people point out that it's not actually a microkernel at all and it damages the reality distortion field. To repair the reality distortion field people then go out and write articles on wikipedia and various other places about hybrid microkernel kernel design.
See Also: XNU
OR
Method 2:
You have a major corporation that actually starts off with a real microkernel and then switches to monolythic after the initial release when they realize that the microkernel design would never be competitive with contemporary operating systems on contemporary hardware.
See Also: NT
The Dawn of Haiku OS (Spectrum) Posted Apr 30, 2012 7:03 UTC (Mon) by danieldk (guest, #27876) [Link]
In fact, the leaked Dano (R6) builds had a BSD-based networks stack in the kernel.
The Dawn of Haiku OS (Spectrum) Posted May 2, 2012 1:02 UTC (Wed) by cmccabe (guest, #60281) [Link]
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):
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.
The Dawn of Haiku OS (Spectrum) Posted May 5, 2012 13:28 UTC (Sat) by tialaramex (subscriber, #21167) [Link]
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) Posted Apr 29, 2012 20:10 UTC (Sun) by pranith (subscriber, #53092) [Link]
"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"
I am sure I am not the only one who noticed the inaccuracy of this statement.
The Dawn of Haiku OS (Spectrum) Posted Apr 30, 2012 9:10 UTC (Mon) by cabrilo (guest, #72372) [Link]
It's an interesting mistake, though. In 10 years we may be reading something like: "Linux, for instance, is based around a core—called a kernel—that was originally designed for use in mobile phones and only later modified for desktop systems" :)
The author obviously didn't do even most basic research. The second paragraph in Wikipedia article on Linux starts with: "Linux was originally developed as a free operating system for Intel x86-based personal computers". Not to get into the whole OS vs kernel confusion...
The Dawn of Haiku OS (Spectrum) Posted Apr 30, 2012 11:38 UTC (Mon) by tialaramex (subscriber, #21167) [Link]
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.
The Dawn of Haiku OS (Spectrum) Posted Apr 29, 2012 22:28 UTC (Sun) by theoldrang (guest, #71818) [Link]
I have been rooting around for something better than Ubuntu 10.04/10.10 (there is nothing past those that I care for).
I tried Haiku, at the suggestion of this site.
I found that it loaded very well, and used the Live-CD version to test.
After some poking around and only using a small part of the learning curve, that I feel will be required, I have these impressions...
1) I know that Commodore was really good stuff, back when it was new. I had 2 of their systems. I liked them. Things have progressed... I feel that the Haiku system has not progressed quite as far.
2) Drivers (mentioned by others) are not up to today's standards.
3) The live-CD is powerful (not so many restrictions, and can see really neat things that might be done... unfortunately, most would be cracking not hacking. Great tool for either)
4) On my system (homebuilt with M68MT-S2P 8gig 3Tb yada-yada-yada) it looked to need either a lot of visual tuning, or the afore mentioned drivers.
5) Using the learning curve and other tests, within its limits, it worked well and fast. Very fast, on a Live-CD set-up...
6) I found no 'glitches'... I found limits, not faults.
The GUI needs work (lots) and usually, the needed work with add a little 'slow' to what is there. But, I say, it IS fast.
I did not install it.
It is an Alpha, and needs work.
The Dawn of Haiku OS (Spectrum) Posted Apr 29, 2012 22:47 UTC (Sun) by kolla (guest, #23560) [Link]
Commodore? What does Commodore have to do with anything here?
The Dawn of Haiku OS (Spectrum) Posted Apr 30, 2012 7:44 UTC (Mon) by Pawlerson (guest, #74136) [Link]
It was probably more complete and professional than Haiku. ;)
The Dawn of Haiku OS (Spectrum) Posted May 3, 2012 7:45 UTC (Thu) by Comet (subscriber, #11646) [Link]
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 ...
The Dawn of Haiku OS (Spectrum) Posted May 3, 2012 11:22 UTC (Thu) by pboddie (subscriber, #50784) [Link] 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) Posted Apr 30, 2012 0:58 UTC (Mon) by fest3er (guest, #60379) [Link]
It needs work. But that goes with it being a work in progress.
GNU/Linux/X11 is nice, but there are just too many oddities, too many things that just don't work right. Grub2 works right in exactly one scenario: a system that always boots from the same drive. Udev still needs a lot of repair and catching-up. X11? It really needs to be redesigned and rewritten.
On a single CPU, BeOS always outperformed GNU/Linux simply because of X11. Adding a second CPU lets X11 perform more reasonably. But BeOS was always SMP. I still have two of the dual PPC-603 systems they built for development.
Also, multimedia was built into BeOS from the beginning. It was intended to handle video, audio and MIDI (among others) rapidly and smoothly without affecting the rest of the UI. And it did that very well. And did it years before GNU/Linux and Windows could.
HaikuOS is the effort to recreate BeOS from the ground up. And greatly improve it in the process. BeOS was my sole desktop system for several years. When HaikuOS becomes viable, it will probably again become my sole desktop system.
Not many drivers? Write 'em and contribute! Netpositive is 'lacking'? Enhance it and contribute!
For a pre-alpha system, HaikuOS is surprisingly usable. Even more surprising considering the small number of people working on it. The way I see it, one can provide positive feedback or negative opinions. I prefer the positive approach.
The Dawn of Haiku OS (Spectrum) Posted Apr 30, 2012 2:34 UTC (Mon) by Doogie (guest, #59626) [Link]
Did you just wake up from a 17 year long coma?
The Dawn of Haiku OS (Spectrum) Posted Apr 30, 2012 3:54 UTC (Mon) by jospoortvliet (subscriber, #33164) [Link]
that is a bit rude but yeah, you have a point. I also had very good experiences with BeOS but the world has moved on. I don't think there really is a need for it - linux does almost all of it and the work needed to rebuild BeOS would, as someone said in the comments above, surely be more than 'fixing' linux.
The Dawn of Haiku OS (Spectrum) Posted Apr 30, 2012 5:59 UTC (Mon) by kolla (guest, #23560) [Link]
As I see it, the world has not moved on on the desktop, rather the contrary, it has been standing still and even gone backwards in many ways. The desktops on Linux seem to have one aim, and that is to resemble Windows as much as possile in order to atract "most users", which for me renders them totally uninteresting. I much rather use a working Windows installation than a broken wannabe, and I think that's what "most users" also think. Linux is good for a lot of things, I'm a Linux user since pre 1.0 days and been using it on a whole range of archs, but these days I'm giving up on Linux for anything else than "embedded" and server use, the deskop environments offered for Linux are just way too bloated, bling-centric and dumb, so my reasons for leaving Linux on desktop are the same now that I had for not liking Windows earlier. Not that I'm that much fond of OSX either, but at least it is rather consistant and somewhat snappy on Apple hardware. Funny to see Linux zealots bad-mouhing alternatives, the irony is striking.
The Dawn of Haiku OS (Spectrum) Posted Apr 30, 2012 6:02 UTC (Mon) by Cyberax (✭ supporter ✭, #52523) [Link]
Sure, it's fun. However, can you point out how BeOS is different from Windows?
The Dawn of Haiku OS (Spectrum) Posted Apr 30, 2012 6:41 UTC (Mon) by kolla (guest, #23560) [Link]
Why, you don't know?
The Dawn of Haiku OS (Spectrum) Posted Apr 30, 2012 7:34 UTC (Mon) by drag (subscriber, #31333) [Link]
I'd say it's much less obvious then you think it is.
The Dawn of Haiku OS (Spectrum) Posted Apr 30, 2012 7:51 UTC (Mon) by Pawlerson (guest, #74136) [Link] Funny to see Linux zealots bad-mouhing alternatives, the irony is striking.In case you didn't notice the Haiku zealots are bad-mouthing Linux. The reality shows where this haiku is and it's nowhere. Puppy Linux kill it!
The Dawn of Haiku OS (Spectrum) Posted Apr 30, 2012 11:54 UTC (Mon) by sorpigal (subscriber, #36106) [Link]
> 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.
The Dawn of Haiku OS (Spectrum) Posted Apr 30, 2012 14:53 UTC (Mon) by tjc (subscriber, #137) [Link]
I doesn't matter who is bad mouthing whom; it's all very juvenile and tiresome.
The Dawn of Haiku OS (Spectrum) Posted Apr 30, 2012 9:28 UTC (Mon) by bricef (guest, #80336) [Link] The desktops on Linux seem to have one aim, and that is to resemble Windows as much as possile Or worse, Mac... What is it with copying bad ideas from someone simple because they're successful? Bad usability is bad usability. Even if they get it right most of the time, that isn't a good reason to copy everything they do without rubbing two braincells together first. the deskop environments offered for Linux are just way too bloated, bling-centric and dumb Really? Archlinux/wmii or Archlinux/Openbox are bloated and bling-centric? Could have fooled me... Seriously, Your desktop is what you make it. Unity makes me want to pluck my eyes out as much as the next hacker, but it isn't fair to say that the desktop environments offered on Linux are all crap because you didn't do the research properly. Instead of complaining that a solution hasn't fallen in your lap, take responsibility for turning your desktop into a powerful tool.
The Dawn of Haiku OS (Spectrum) Posted Apr 30, 2012 15:52 UTC (Mon) by Doogie (guest, #59626) [Link] 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.
people do not use a computer to use it's desktop Posted Apr 30, 2012 16:21 UTC (Mon) by dlang (✭ supporter ✭, #313) [Link]
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) Posted May 3, 2012 18:42 UTC (Thu) by tstover (subscriber, #56283) [Link]
made me laugh for about 3 minutes
Progress need variety (The Dawn of Haiku OS (Spectrum)) Posted Apr 30, 2012 12:18 UTC (Mon) by maurizio.dececco (guest, #6585) [Link]
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 :).
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
Progress need variety (The Dawn of Haiku OS (Spectrum)) Posted Apr 30, 2012 13:52 UTC (Mon) by Pawlerson (guest, #74136) [Link] 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)) Posted May 1, 2012 6:41 UTC (Tue) by zlynx (subscriber, #2285) [Link]
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.
Progress need variety (The Dawn of Haiku OS (Spectrum)) Posted May 1, 2012 7:23 UTC (Tue) by Cyberax (✭ supporter ✭, #52523) [Link]
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)) Posted May 1, 2012 14:28 UTC (Tue) by whitemice (guest, #3748) [Link]
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)) Posted May 1, 2012 16:20 UTC (Tue) by nybble41 (subscriber, #55106) [Link]
Here are some settings that helped me out with a similar issue:
# Limit total dirty data to 60MB
# Only use transparent hugepages on request via madvise()
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.
Progress need variety (The Dawn of Haiku OS (Spectrum)) Posted May 2, 2012 2:46 UTC (Wed) by salimma (subscriber, #34460) [Link]
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.
Progress need variety (The Dawn of Haiku OS (Spectrum)) Posted Apr 30, 2012 15:21 UTC (Mon) by drag (subscriber, #31333) [Link]
> 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.
The Dawn of Haiku OS (Spectrum) Posted Apr 30, 2012 14:50 UTC (Mon) by whitemice (guest, #3748) [Link]
> 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
This issue is historic. Both hardware and kernel scheduling has much improved.
The Dawn of Haiku OS (Spectrum) Posted Apr 30, 2012 16:43 UTC (Mon) by tialaramex (subscriber, #21167) [Link]
"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.
The Dawn of Haiku OS (Spectrum) Posted May 1, 2012 1:31 UTC (Tue) by whitemice (guest, #3748) [Link]
> 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].
The Dawn of Haiku OS (Spectrum) Posted May 3, 2012 17:36 UTC (Thu) by smitty_one_each (subscriber, #28989) [Link]
Thinking it fun, I
Decided to comment here, But ran out of syl-
|
|||||||||||||