The Dawn of Haiku OS (Spectrum)
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."
Posted Apr 29, 2012 17:13 UTC (Sun)
by gmatht (subscriber, #58961)
[Link] (24 responses)
Posted Apr 29, 2012 18:06 UTC (Sun)
by flammon (guest, #807)
[Link] (9 responses)
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?
Posted Apr 29, 2012 22:25 UTC (Sun)
by Cato (guest, #7643)
[Link] (2 responses)
Posted Apr 30, 2012 6:17 UTC (Mon)
by kevinm (guest, #69913)
[Link]
Posted Apr 30, 2012 19:47 UTC (Mon)
by pboddie (guest, #50784)
[Link]
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.)
Posted Apr 30, 2012 7:40 UTC (Mon)
by Pawlerson (guest, #74136)
[Link] (4 responses)
Posted Apr 30, 2012 9:15 UTC (Mon)
by jond (subscriber, #37669)
[Link] (1 responses)
Posted Apr 30, 2012 11:36 UTC (Mon)
by Pawlerson (guest, #74136)
[Link]
Posted Apr 30, 2012 9:42 UTC (Mon)
by renox (guest, #23785)
[Link] (1 responses)
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.
Posted Apr 30, 2012 11:39 UTC (Mon)
by Pawlerson (guest, #74136)
[Link]
Posted May 2, 2012 7:35 UTC (Wed)
by andreoli (subscriber, #20174)
[Link]
Mauro
Posted Apr 29, 2012 18:09 UTC (Sun)
by arjan (subscriber, #36785)
[Link] (13 responses)
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.
Posted Apr 29, 2012 19:36 UTC (Sun)
by renox (guest, #23785)
[Link] (12 responses)
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?
Posted Apr 30, 2012 0:58 UTC (Mon)
by drag (guest, #31333)
[Link] (9 responses)
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.
Posted Apr 30, 2012 9:13 UTC (Mon)
by renox (guest, #23785)
[Link] (5 responses)
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..
Posted Apr 30, 2012 9:34 UTC (Mon)
by tialaramex (subscriber, #21167)
[Link] (4 responses)
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.
Posted Apr 30, 2012 9:55 UTC (Mon)
by renox (guest, #23785)
[Link] (3 responses)
So claiming this design was only for making it a little easier for a programmer at Be Inc seems not very credible.
Posted Apr 30, 2012 10:39 UTC (Mon)
by tialaramex (subscriber, #21167)
[Link] (1 responses)
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.
Posted Apr 30, 2012 11:36 UTC (Mon)
by renox (guest, #23785)
[Link]
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?
Posted Apr 30, 2012 20:24 UTC (Mon)
by Cyberax (✭ supporter ✭, #52523)
[Link]
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.
Posted Apr 30, 2012 14:53 UTC (Mon)
by whitemice (guest, #3748)
[Link] (1 responses)
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.
Posted Apr 30, 2012 15:45 UTC (Mon)
by drag (guest, #31333)
[Link]
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.
Posted May 5, 2012 17:11 UTC (Sat)
by k8to (guest, #15413)
[Link]
Posted Apr 30, 2012 19:36 UTC (Mon)
by mhelsley (guest, #11324)
[Link] (1 responses)
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.
Posted Apr 30, 2012 23:41 UTC (Mon)
by jzbiciak (guest, #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.
Posted Apr 29, 2012 18:12 UTC (Sun)
by ncm (guest, #165)
[Link] (6 responses)
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?
Posted Apr 30, 2012 7:37 UTC (Mon)
by xav (guest, #18536)
[Link] (5 responses)
Posted Apr 30, 2012 7:42 UTC (Mon)
by Pawlerson (guest, #74136)
[Link] (1 responses)
Posted May 1, 2012 15:55 UTC (Tue)
by juliank (guest, #45896)
[Link]
Posted Apr 30, 2012 9:37 UTC (Mon)
by the.wrong.christian (guest, #73127)
[Link] (1 responses)
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.
Posted Apr 30, 2012 9:59 UTC (Mon)
by xav (guest, #18536)
[Link]
Posted Apr 30, 2012 14:55 UTC (Mon)
by whitemice (guest, #3748)
[Link]
And I do not see sluggish UI performance, even when all six of the hard
openSUSE 12.1
Posted Apr 29, 2012 18:59 UTC (Sun)
by cmccabe (guest, #60281)
[Link] (5 responses)
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.
Posted Apr 29, 2012 20:07 UTC (Sun)
by tialaramex (subscriber, #21167)
[Link] (4 responses)
Posted Apr 29, 2012 20:48 UTC (Sun)
by drag (guest, #31333)
[Link]
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
Posted Apr 30, 2012 7:03 UTC (Mon)
by danieldk (guest, #27876)
[Link]
Posted May 2, 2012 1:02 UTC (Wed)
by cmccabe (guest, #60281)
[Link] (1 responses)
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.
Posted May 5, 2012 13:28 UTC (Sat)
by tialaramex (subscriber, #21167)
[Link]
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.
Posted Apr 29, 2012 20:10 UTC (Sun)
by pranith (subscriber, #53092)
[Link] (2 responses)
I am sure I am not the only one who noticed the inaccuracy of this statement.
Posted Apr 30, 2012 9:10 UTC (Mon)
by cabrilo (guest, #72372)
[Link] (1 responses)
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...
Posted Apr 30, 2012 11:38 UTC (Mon)
by tialaramex (subscriber, #21167)
[Link]
Posted Apr 29, 2012 22:28 UTC (Sun)
by theoldrang (guest, #71818)
[Link] (18 responses)
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.
Posted Apr 29, 2012 22:47 UTC (Sun)
by kolla (guest, #23560)
[Link] (3 responses)
Posted Apr 30, 2012 7:44 UTC (Mon)
by Pawlerson (guest, #74136)
[Link]
Posted May 3, 2012 7:45 UTC (Thu)
by Comet (subscriber, #11646)
[Link] (1 responses)
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 ...
Posted May 3, 2012 11:22 UTC (Thu)
by pboddie (guest, #50784)
[Link]
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. 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.
Posted Apr 30, 2012 0:58 UTC (Mon)
by fest3er (guest, #60379)
[Link] (13 responses)
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.
Posted Apr 30, 2012 2:34 UTC (Mon)
by Doogie (guest, #59626)
[Link] (12 responses)
Posted Apr 30, 2012 3:54 UTC (Mon)
by jospoortvliet (guest, #33164)
[Link] (10 responses)
Posted Apr 30, 2012 5:59 UTC (Mon)
by kolla (guest, #23560)
[Link] (9 responses)
Posted Apr 30, 2012 6:02 UTC (Mon)
by Cyberax (✭ supporter ✭, #52523)
[Link] (2 responses)
Posted Apr 30, 2012 7:51 UTC (Mon)
by Pawlerson (guest, #74136)
[Link] (2 responses)
Posted Apr 30, 2012 11:54 UTC (Mon)
by sorpigal (guest, #36106)
[Link]
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.
Posted Apr 30, 2012 14:53 UTC (Mon)
by tjc (guest, #137)
[Link]
Posted Apr 30, 2012 9:28 UTC (Mon)
by bricef (guest, #80336)
[Link]
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. 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.
Posted Apr 30, 2012 15:52 UTC (Mon)
by Doogie (guest, #59626)
[Link]
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.
Posted Apr 30, 2012 16:21 UTC (Mon)
by dlang (guest, #313)
[Link]
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.
Posted May 3, 2012 18:42 UTC (Thu)
by tstover (guest, #56283)
[Link]
Posted Apr 30, 2012 12:18 UTC (Mon)
by maurizio.dececco (guest, #6585)
[Link] (7 responses)
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
Posted Apr 30, 2012 13:52 UTC (Mon)
by Pawlerson (guest, #74136)
[Link] (5 responses)
Posted May 1, 2012 6:41 UTC (Tue)
by zlynx (guest, #2285)
[Link] (4 responses)
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.
Posted May 1, 2012 7:23 UTC (Tue)
by Cyberax (✭ supporter ✭, #52523)
[Link] (3 responses)
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.
Posted May 1, 2012 14:28 UTC (Tue)
by whitemice (guest, #3748)
[Link] (1 responses)
Posted May 1, 2012 16:20 UTC (Tue)
by nybble41 (subscriber, #55106)
[Link]
# 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.
Posted May 2, 2012 2:46 UTC (Wed)
by salimma (subscriber, #34460)
[Link]
Posted Apr 30, 2012 15:21 UTC (Mon)
by drag (guest, #31333)
[Link]
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.
Posted Apr 30, 2012 14:50 UTC (Mon)
by whitemice (guest, #3748)
[Link] (2 responses)
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.
Posted Apr 30, 2012 16:43 UTC (Mon)
by tialaramex (subscriber, #21167)
[Link] (1 responses)
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.
Posted May 1, 2012 1:31 UTC (Tue)
by whitemice (guest, #3748)
[Link]
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].
Posted May 3, 2012 17:36 UTC (Thu)
by smitty_one_each (subscriber, #28989)
[Link]
LXDE is fast
LXDE is fast
LXDE is fast
LXDE is fast
LXDE is fast
LXDE is fast
LXDE is fast
LXDE is fast
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
LXDE is fast
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
http://algo.ing.unimo.it/people/paolo/disk_sched/
LXDE is fast
LXDE is fast
-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)
LXDE is fast
LXDE is fast
And the point is that it feels much more responsive: BeOS did feel much more responsive than Linux or Windows at the time.
One example: on Wayland (which is composited), if you resize a window and the application becomes slow, then the animation of the window will stutter, because the compositor is waiting for the application's buffers.
With a dedicated thread for the GUI, normally the application should never be slow to answer..
"Pervasive multi-threading"
"Pervasive multi-threading"
"Pervasive multi-threading"
"Pervasive multi-threading"
Any benchmark which support your "guess"?
"Pervasive multi-threading"
LXDE is fast
>> the UI very reactive
> What is the point of having a reactive UI when the application logic
> behind it is hanging on IO Wait?
LXDE is fast
LXDE is fast
LXDE is fast
LXDE is fast
Funny
Not so funny
Not so funny
Not so funny
Not so funny
Not so funny
Not so funny
drives are grinding away.
Hybrid micro/monolithic kernel? It's been done-- look at Mach.The Dawn of Haiku OS (Spectrum)
The Dawn of Haiku OS (Spectrum)
The Dawn of Haiku OS (Spectrum)
The Dawn of Haiku OS (Spectrum)
The Dawn of Haiku OS (Spectrum)
> Haiku doesn't actually have a "hybrid" kernel, whatever that means
> 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.
The Dawn of Haiku OS (Spectrum)
The Dawn of Haiku OS (Spectrum)
The Dawn of Haiku OS (Spectrum)
The Dawn of Haiku OS (Spectrum)
The Dawn of Haiku OS (Spectrum)
The Dawn of Haiku OS (Spectrum)
The Dawn of Haiku OS (Spectrum)
The Dawn of Haiku OS (Spectrum)
The Dawn of Haiku OS (Spectrum)
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.
The Dawn of Haiku OS (Spectrum)
The Dawn of Haiku OS (Spectrum)
The Dawn of Haiku OS (Spectrum)
The Dawn of Haiku OS (Spectrum)
The Dawn of Haiku OS (Spectrum)
The Dawn of Haiku OS (Spectrum)
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)
I read this is justifying another free OS by pointing out deficiencies of the popular one.
The Dawn of Haiku OS (Spectrum)
The Dawn of Haiku OS (Spectrum)
The desktops on Linux seem to have one aim, and that is to resemble Windows as much as possile
the deskop environments offered for Linux are just way too bloated, bling-centric and dumb
Funny to see Linux zealots bad-mouhing alternatives, the irony is striking.
The Dawn of Haiku OS (Spectrum)
people do not use a computer to use it's desktop
The Dawn of Haiku OS (Spectrum)
Progress need variety (The Dawn of Haiku OS (Spectrum))
Sure, there is lot of nostalgia in rebuilding a system based on a 17 year old system (of which i know almost nothing about).
Progress need variety (The Dawn of Haiku OS (Spectrum))
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))
Progress need variety (The Dawn of Haiku OS (Spectrum))
Progress need variety (The Dawn of Haiku OS (Spectrum))
Progress need variety (The Dawn of Haiku OS (Spectrum))
sysctl vm.dirty_bytes=62914560
echo madvise > /sys/kernel/mm/transparent_hugepage/enabled
Progress need variety (The Dawn of Haiku OS (Spectrum))
Progress need variety (The Dawn of Haiku OS (Spectrum))
The Dawn of Haiku OS (Spectrum)
> originally designed for use in servers and only later modified for
> desktop systems.
> doing especially taxing things, like burning a DVD or compiling code.
The Dawn of Haiku OS (Spectrum)
The Dawn of Haiku OS (Spectrum)
The Dawn of Haiku OS (Spectrum)
Decided to comment here,
But ran out of syl-