The Dawn of Haiku OS
spectrum.ieee.org
spectrum.ieee.org
BeOS was demonstrated to me during my senior year of college. The guy giving the talk played upwards of two dozen mp3s, a dozen or so movie trailers, the GL teapot thing, etc. simultanously. None of the apps skipped a beat. Then, he pulled out the showstopper.
He yanked the plug on the box.
Within 20 seconds or so of restarting, the machine was chugging away with all of its media files in the place they were when they were halted, as if nothing had happened.
If you've never played with BeOS on an old Pentium II, it's hard to imagine the kind of performance it was able to squeeze out of that hardware. Here's a rough idea:
Try my MacBook Pro then, I play movies all the time on it with no problem of frame-dropping or swapping. And it's a 2007 model.
Common problems can be: Spotlight doing indexing at the time, Flash fucking around, too little available hard drive space (less than 5GB), some rogue app, etc.
MBP 2007, 2GB RAM. I have now open: Chrome with 7 tabs, Sublime Text, Terminal (2 tabs, one SSH), Mail, iA Writer, Adium, iTunes, TunnelBlick VPN, Photoshop, Transmit, Dropbox, Alfred, Little Snitch and VLC and the movie plays just fine. I use either VLC or MPlayerX though, very rarely QuickTime w Perian.
Now, some people open 50 tabs and think that the browser should automagically handle them all, with 20 instances of Flash running in videos and apps, etc. Not so. VMs are also very resource hungry.
That said, the laptop is noticeably slower than my 4GB / i7 iMac, but not to the point it swaps --unless I start my 1GB linux VM (VMWare).
On Snow Leopard, I found what you say to be true. On Lion, either the mysterious process is eluding me, or it is just much slower. I do development and I can tell you that the iPhone Simulator is a frequent culprit, VirtualBox is also rough (but if I ssh in to my virtual machines rather than use the GUI it's fine), also the Time Machine daemon trying to backup causes things to slow down (even when not plugged in to a disk), but even after that performance is downright crap compared to Snow Leopard.
If you have any idea what my specific source could be I'd be thrilled to hear it. Frequently at the top of my Activity Monitor is WindowServer and kernel_task, except when compiling or other fun things. Even when the interface is locking up I can't find anything fun.
http://cl.ly/1s3N2r2X1u2J2K010H2i
There's no process running wild from what I can see in the Activity Monitor, but it appears to happen a lot less frequently or not at all when I don't have my external hard drives attached.
Also, unless I am running heavy CPU things (XCode, VirtualBox machines, etc), I usually don't get a lot of CPU time like that.
One of the annoying things about Mac OSX is that a rogue codec can mess up ALL media playing activities on the computer- so when you encounter problems, I've found the most successful strategy is to figure out which codec is messing things up.
Other than that, I also don't run Time Machine at all -- I use Carbon Copy Cloner or Super Duper to make incremental and/or bootable backups every week or so. With iCloud, Dropbox etc for the important day to day documents, I don't see much need for Time Machine anymore.
So those would be two places to look at.
Besides those, you can try running some DTrace scripts for a more detailed look when your system starts to crap out.
Recently, work sprung for a Parallels license for me. Yikes, I pity my past self for putting up with all the VB issues because it was free. Just little things like playing nicely with the app/spaces switch key combos, lack of crashes, and performance make me really regret wasting all those mental cycles on VB. Don't get me wrong, having a free x86 VM is wonderful and the VB developers deserve kudos galore... but I reminded myself that my time and sanity are worth a few bucks here and there.
No no no, you have it backwards. It's hard to imagine what a "modern" OS (Windows, Linux, OSX) is actually doing with all those CPU cycles, that it can't do stuff like this even with >10x the compute power.
Now if you try to do that with only itunes or windows media player or equivalent "monolithic" player, you'll probably run into some slowdown, but only because those are designed to maximize the experience for one single piece of media at a time. Something like media player classic would do it in a heartbeat though.
It's anachronistic I know, but I think the biggest issue with the OS was timing. If the FOSS movement had as much commercial maturity as today, I think the story of BeOS would be way different. It was pretty well placed at the time in terms of offering a solid media experience coupled with a POSIX compliant environment. I'm pretty sure it would be used like OS X is today by many devs, but without the hardware lock-in.
It was super fun to use BeOS, I just didn't have a workflow that matched it at the time.
As far as I understand the history of Linux, this is just plain not true: Linux was originally a toy project with little focus on either desktop or server systems.
Am I missing something?
Of course nowadays Linux runs pretty well on IBM's mainframes.
Which is reasonable for a desktop single-user OS, but completely unacceptable for a multi-user server OS.
Sounds good to me, but 10-15 seconds running on what specs?
Also, looking at the video, it seems like this OS is stuck in the 1990s. That is fine as long as it runs a standards compliant browser, but it just seems lacking based on this video- has this changed?: http://www.youtube.com/watch?v=ixvppiSB7hc
I do like that it is just the basics though.
It'd be wonderful if someone more familiar with the issue would comment on the browser's status.
Sounds like you're saying this solely based on what the GUI looks like. Yes, it's extremely dated and doesn't have all the fancy glitz of modern desktop environments, but the underlying system itself is quite modern.
I might not have been around when BeOS was first created, but this is certainly not a new concept today. I don't think I can name a major OS today that doesn't support this model. Both Android and iOS are well known for this technique, but they were hardly the first to adopt it.
I can name Modula-3's Trestle and Pike's Newsqueak language/GUI from the top of my head. Didn't Xerox' Mesa use threads for this?
On those days Windows NT was already available with a multithreaded kernel from day one and the ability to make use of them at the UI level as well.
When compared with the 9x family, yes, but not with the NT family.
Requiring a compiler over a decade old for a modern OS doesn't seem like a good long-term strategy.
http://www.haiku-os.org/news/2008-05-18/steady_progress_towa...
The current setup is really only used to the benefit of applications - the kernel interface is not ABI- or API-compatible, for the most part, with that of BeOS R5.
Is this still a problem? Isn't this why just about every other OS exposes it's lowest level APIs as C apis?
E.g.: http://www.opensource.apple.com/source/xnu/xnu-1699.24.23/io... - note the
ExpansionData * reserved;
member variable and the block of private:
OSMetaClassDeclareReservedUsed(IOMemoryDescriptor, 0);
#ifdef __LP64__
OSMetaClassDeclareReservedUnused(IOMemoryDescriptor, 1);
OSMetaClassDeclareReservedUnused(IOMemoryDescriptor, 2);
OSMetaClassDeclareReservedUnused(IOMemoryDescriptor, 3);
OSMetaClassDeclareReservedUnused(IOMemoryDescriptor, 4);
OSMetaClassDeclareReservedUnused(IOMemoryDescriptor, 5);
OSMetaClassDeclareReservedUnused(IOMemoryDescriptor, 6);
OSMetaClassDeclareReservedUnused(IOMemoryDescriptor, 7);
#else /* !__LP64__ */
OSMetaClassDeclareReservedUsed(IOMemoryDescriptor, 1);
OSMetaClassDeclareReservedUsed(IOMemoryDescriptor, 2);
OSMetaClassDeclareReservedUsed(IOMemoryDescriptor, 3);
OSMetaClassDeclareReservedUsed(IOMemoryDescriptor, 4);
OSMetaClassDeclareReservedUsed(IOMemoryDescriptor, 5);
OSMetaClassDeclareReservedUsed(IOMemoryDescriptor, 6);
OSMetaClassDeclareReservedUsed(IOMemoryDescriptor, 7);
#endif /* !__LP64__ */
OSMetaClassDeclareReservedUnused(IOMemoryDescriptor, 8);
OSMetaClassDeclareReservedUnused(IOMemoryDescriptor, 9);
OSMetaClassDeclareReservedUnused(IOMemoryDescriptor, 10);
OSMetaClassDeclareReservedUnused(IOMemoryDescriptor, 11);
OSMetaClassDeclareReservedUnused(IOMemoryDescriptor, 12);
OSMetaClassDeclareReservedUnused(IOMemoryDescriptor, 13);
OSMetaClassDeclareReservedUnused(IOMemoryDescriptor, 14);
OSMetaClassDeclareReservedUnused(IOMemoryDescriptor, 15);
dummy methods.There is also a system in place for the linker to patch the vtables of dynamically loaded classes (i.e. third-party drivers). They've also built an Objective-C-like Class/metaclass system in C++ via macros for I/O Kit, for some very basic reflection (mainly to keep track of whether instances of a class exist, and if not, unloading the kernel module).
Mac OS X drivers are written in C++.
Symbian is fully written in C++.
The new WinRT API for Windows 8 is C++ based along as the user space driver framework.
There is no reason why Apple could not have defined a standard C++ ABI in BeOS, if that was the reason.
The decision to take NeXT instead of BeOS, surely did not have anything to do with technical merits of the underlying systems.
http://haiku-os.org/legacy-docs/benewsletter/Issue2-25.html
Apparently Apple gets around this the usual way by padding out their API classes with extra unused members. I wonder what the solution is in Windows 8 & Symbian.
COM avoids the C++ issue because it only allows you to consume interfaces, and, for all Windows compilers when COM was invented (and obviously since), vtables are always in a set location. So the trick is:
1. Never change existing interfaces
2. Always add new interfaces to the end of the vtables
When you want a COM object, you instantiate it, but you don't work with it directly; you ask for the interface you want to use to talk to the object. As long as the object vendor maintains the old virtual methods, the worst that happens is you ask for the old interface and everything works as normal. This works very well with only a minor speed hit.I think right after //build, I could tell you how they used CLR metadata to extend the system out to supporting subclassing, but I just honestly don't remember. Similar general idea, though; they still avoid the problem by not actually hitting it.
One can see COM as a kind of operating system OO ABI.
OS/2 SOM was better, but never got much following.
Any OO language with native code generation suffers the same problem.
It is one of the consequences of the fragile base class problem in OO.
And it actually has private data members! Isn't that nice.
(Private meaning they aren't declared in the public headers, not meaning it uses the useless 'private' attribute.)
This is not only about data member access. It also applies to adding methods on the base class that change the behavior of existing methods in already declared subclasses.
Take a cup of coffee and read this famous paper about the issue,
http://www.cas.mcmaster.ca/~emil/Publications_files/Mikhajlo...
Anyhow, the C++ API of BeOS was amazing. OSX/Objective-C still don't give you that OO access to the OS feel that BeOS had. My one major gripe with their approach was in the way that they managed run-time binding -- it was very brittle from release to release of the OS. As a developer, you had to ship separate binaries for each OS release you wanted to support. Nasty.
I'd love to see Haiku take off and become a viable platform. If for no other reason, just to have a reference version of how things CAN BE DONE.
That cheerleading aside, I have to say that with a fresh OS install, my OSX Lion 2009 PB performs great. Very snappy, runs cool, starts up quickly. It's only when you start installing all your apps, VMs, widgets, drivers, and misc. junk that it slows down. Would Haiku do any better if it had that rich of a software environment?
Wait, there's only one set of system calls into the kernel. What exactly are they talking about here, anyone know?
For example, are they counting libcurl in Linux's total? How about Gecko, WebKit, and KHTML?
As it stands, the statement sounds either wrong or indicative of a completely bizarre design on the Haiku peoples' part.
"Linux, by contrast, has hundreds of APIs and about as many user interfaces, so you can’t just switch seamlessly from one version of Linux to another. The version you use can greatly alter the appearance of your computer screen, the way programs boot and execute, and various other things, all of which make it quite difficult to develop software that consistently runs well on all Linux systems."
That's a mix of true and false statements. The false is that UIs necessarily change by distro: Different distros pick different default UIs, but all of them can run all the same window managers and desktop environments. My telling you I'm currently running Ubuntu tells you nothing about how my screen currently looks.
Also, switching from one distro to another is hardly a difficult process; switching from one computer to another is more annoying.
It's true to some extent in that some distros ship with modified kernels, but that usually isn't a problem for anyone: The changes distros make tend to be invisible to most applications, which sit directly on higher-level APIs anyway.
Finally, implying having fewer APIs is a good thing is disingenuous: An API is a tool and, therefore, a way to organize thought; having fewer APIs implies artificial restrictions on thought.
In 2001 (when BeOS was bought), it might have made a bit of sense. Be was pretty modern then - competing against Windows XP and either the Classic Mac OS which it was far better than or OS X which was very new and so incredibly slow it was nearly unusable - I don't miss those days being a Mac user. However, in 2001 it had just been bought. Palm wasn't going to turn around and say "we spent $11M on this, you guys want it on the cheap?"
Today, Haiku has probably surpassed BeOS in any relevant way. The issue is that the world has moved on. Imagine a really well-made car/engine from 1990 (and imagine that it was like code which doesn't corrode and such). It can still be a great car today in many respects - maybe its performance characteristics still make it a lot nicer than many modern cars. However, you then start thinking about how it doesn't have anti-lock brakes, traction control, electronic slip protection, air bags, a CD player, iPod hookup, bluetooth; plus, it has a an analog carphone installed in the center. That's a bit like was BeOS would be like today.
For example, Haiku just got preliminary WPA support in October. Frankly, if an operating system doesn't have wonderful WiFi support, it's missing a key practical piece for me. Likewise, other operating systems have put considerable energy into compositing window managers to provide things people take for granted today like shadows, transparency, minimization effects, etc. Plus, and this is pure speculation since I haven't used Haiku recently enough to really comment, I'm guessing the web browser ports aren't quite as mature/good as they are for other systems that have a lot more users/developers.
So, licensing the BeOS IP isn't the issue. It would basically be buying an operating system that hasn't been updated since Windows XP came out. Sure, Windows XP isn't terrible today, but part of that is because Microsoft continued to update and maintain it since its release in 2001. Even then, it seems old.
If BeOS was open-sourced in 2001, it might have seen decent adoption. It had a nice GUI, was really ready for the multi-core processors to come, and it might have gotten the traction to see things like Mozilla concentrate on it as a platform. When OpenBeOS (Haiku's former name) started, I think there was a lot of hope. Of course, as they were concentrating on replicating BeOS R5, the world moved on and Apple, Microsoft, and the Linux community had an army of programmers working on advancing their systems while Haiku had a small team trying to resurrect their beloved system. BeOS was very advanced for its day and in some ways I think it's still better, but BeOS today would just be old in many practical ways even if it was awesome in many other ways.
they have to start somewhere, and choose a good base to start from, from now on its adding those more advanced features and the gravy that users expect.
Perhaps the linux guys should have given up around Slackware 1.0? I mean it wasn't exactly as good as the Sun and SGI boxes I was using back then.
This is an absurd statement. Stop wasting time solving problems that don't exist for 98% of the market. "More choice" is not a better than if the choices suck.
"Within 20 seconds or so of restarting, the machine was chugging away with all of its media files in the place they were when they were halted, as if nothing had happened."
This was really cool in the early days of BeOS. But that was more than a decade ago.
People of earth: there is a talent crisis right now. The world needs great developers to build awesome apps for a whole new class of machines. If you feel an urge to "start from scratch" — help rebuild everything for mobile. It's a big job, there are too many projects and not enough developers, and you'll be contributing to a seismic shift in computing.
Stop solving problems that don't exist for most people. Build apps that people will use. Do big things that address 98% of users. These guys clearly have dev chops that I admire, so don't waste them on a project like this.
Given that mobile hardware is about where desktop hardware was when BeOS was invented, I wonder if some company could use it as a new smartphone OS. There's an unfinished ARM port in progress but would probably need commercial support to complete.
The thing about innovation is, it's not always possible to predict what will be valuable or not. Not many people would have predicted Linux back in Linus's early days, for example.
Now they can say "That's what we intended all along" ;-)
Developers work on things they find cool, not the things you need done. To get those done, you either do them yourself, or you pay someone to do them.
And let them work on whatever they find fun on their own spare time.
... for very idiosyncratic definitions of "the world" and "need"
I know this site was originally called start-up news, but going to a site branded "hacker" news and seeing a post like this creates something of a LMFAO experience.
Please read your own post over again, and if you somehow don't see the irony in telling a group of people who at this point almost certainly qualify as hackers to stop working on a project they love on a site called hacker news, I suggest revisiting the published literature laying out what a 'hacker' is. (Starting with Hackers: heroes of the computer revolution if you haven't read it yet.)
There has got to be a better open-source font than what Haiku is currently using (http://www.haiku-os.org/docs/userguide/en/deskbar.html).
Interestingly much higher resolution displays will probably help to offset the need for rendering tricks
timc is right, what you see is unattractive font rendering (no subpixel rendering, full hinting). For the state of the art of font rendering in open source projects, look at Ubuntu or Infinality.
The font seem to be DejaVu Sans, and it's pretty good with proper rendering: http://i.imgur.com/ixI70.png
Haiku actually has ClearType support in the source, but it is not enabled at compile-time by default because it's patented.
http://www.antigrain.com/research/font_rasterization/index.h...
I think the article writer meant "process" -- there are many threads per process, and that is present in most "contemporary operating systems". If this is their (Haiku Inc.'s) attempt at PR... they are not doing it well.
I do find, however, the ergonomics of the window manager to be atrocious. The little tabs, while faithful and part of the visual identity of BeOS, are, perhaps, the worst idea since the invention of overlapping windows. I'd suggest focusing on the 80's icon style and 45° perspective as visual identify and ditch the title tabs.