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:
it's hard to imagine the kind of performance it was able to squeeze out of that hardware
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.
What are you talking about? A desktop today has no problem playing two dozen low-bitrate mp3s from disk, streaming a dozen movie trailers from youtube at 240p, playing WoW, and talking on Skype at the same time.
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.
I'd be more forgiving of Lion if it could play even one movie on my Macbook pro without occasionally going into frame-dropping VM-swapping. There's no question that my hand-built BeOS box, 15 years ago, had a far snappier userland experience.
I'm running Lion too. If you have repeatable problems, there should be some specific source for it. Tried "Activity Monitor" when it occurs?
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).
I have Lion, on a 2010 MBP, and I have Activity Monitor open ALL THE TIME.
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.
The VirtualBox caught my eye... I loved using VirtualBox for a while. It's free. It basically works. It's free. Oh yeah, and it's free.
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.
Do you by any chance have one or more external hard drives attached? I've been having a lot of lock-up issues while I have six of them connected (through a hub) to a MacBook Pro from 2011 running Lion. It looks like this (also shows it dropping to normal levels instantly):
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.
No external hard drives attached, except when I remember to back up my machine (I frequently, but not always, plug it in when it is on my desk, but it is just for Time Machine).
Also, unless I am running heavy CPU things (XCode, VirtualBox machines, etc), I usually don't get a lot of CPU time like that.
step 1. go into /Library/Quicktime and move ALL the .component files out of there.
step 2. Go into ~/Library/Quicktime and move ALL the .component files out of there.
step 3. (re)-install perian
step 4. Try playing a movie that usually craps out.
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.
OK, I don't use VirtualBox, for performance reasons I use VMWare Fusion. Even with this, I find, as you, that using GUI on the VM slows the Mac much more than ssh'ing to the VM. So, the VM is a serious culprit. Certainly, if I have the VM running, I expect some slowdown and occasional swapping -- basically it means I just gave up 1 GB or memory to the VM (out of 2) plus tons of I/O scheduled by a different OS within my OS.
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.
I think people dislike it because it's not as efficient. Lion takes a while to startup everything where you left it, sometimes I wonder if I would have been better off to close it all and open it with the time it takes. It's getting better though.
Lion takes a good 3-5 minutes to start up from cold to having restored my windows, due to all the disk thrashing it does loading all the programs back up at once. I get the feeling it doesn't often respect my choice of not opening the windows, so I get to sit there and watch it grind away opening programs I probably don't want it to open as that's the reason I rebooted in the first place.
It seems Lion's implementation of restarting apps depends on SSD type speeds. Also a fairly fat application like a browser has an entirely different amount of work to do before it stops loading compared with the very thin media players that this BeOS demonstration would have been demoing. Apples to Oranges, but BeOS's being multi-thread-mandatory from the start where Lion's application resume was an add-on feature to mature apps will make the difference pretty glaring.
I was an occasional user of BeOS 4 and 5. Got the free upgrade to 5 in the mail.
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.
> 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 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.
I'm not sure what Linus' personal intentions were when he first started it, but perhaps the article is talking about the fact that Unix was originally developed for mainframes.
Unix was originally developed on what were called minicomputers[1]. These were a distinct class from mainframes, which have always run a whole separate class of proprietary OSes such as IBM's MVS.
Of course nowadays Linux runs pretty well on IBM's mainframes.
"What really sets Haiku apart, though, is its efficiency and speed. On my three-year-old desktop computer, Haiku boots up from a cold start in 10 to 15 seconds, and when running it uses only about 170 megabytes of RAM."
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
Haiku has a native browser called WebPositive, using Webkit, but it's probably a year or more out of date. I understand that there are efforts underway to sync the browser with a more recent Webkit and get features like HTML5 audio/video in.
It'd be wonderful if someone more familiar with the issue would comment on the browser's status.
Yeah, just tried it. Web Positive has an HTML5 score of ~150/500 whereas Chrome on my Mac has a score of 400/500. As more and more applications are available as browser apps, if Haiku updates the browser it'll be a win. Haiku seems really snappy and responsive.
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.
"Where BeOS drove ahead of other operating systems of its time (and where Haiku is still ahead of contemporary operating systems) is that each individual application uses many threads. The core of the application itself has one thread, and each window the application creates has a thread."
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.
BeOS was (and arguably still is) the only platform with a UI toolkit and system API that strongly encourages pervasive multithreading. Everywhere else, you have the option of writing asyncronous code, but the libraries are all designed primarily for single-threaded use cases.
Multithreaded UI toolkits have been tried and abandoned as impossible to program stable applications in many times, first at Xerox PARC (like so many other things people keep reinventing).
That also made it rather hellish to program, given you had 1990s multithreading technology and debugging techniques to work with. Something more akin to WinRT in Windows 8, where everything works through callbacks on a single thread by default, is a much better way to approach the problem, IMHO.
BeOS's (intended) competition was MacOS 8 and Windows 95, which probably weren't that thread-savvy. In retrospect, the forced multithreading certainly improved responsiveness but also made porting software painful (since all other GUIs have a single event-loop thread).
iOS doesn't actually spawn a new thread for every window in an application. All of the UIKit calls are still very thread-unsafe and expect to be used only from the main thread. This doesn't really cause much of a problem, since apps are page-based: you don't need to update more than one or two windows at one time, anyway.
Yeah, for anyone who doesn't believe this, do a search for _WebThreadLockFromAnyThread sometime. All those Stack Overflow questions are from people who thought it was safe to have threads anywhere near UIKit.
I like the idea of Haiku OS, but from what I've heard, for binary-compatibility reasons (kernel drivers? All applications? I'm not sure) it still ships with GCC 2.95.
Requiring a compiler over a decade old for a modern OS doesn't seem like a good long-term strategy.
Haiku can be built with/for GCC 2 or GCC 4 and ship with libraries for the other. Some time after R1, the gcc2-hybrid releases will probably be flipped to gcc4-hybrid, and the gcc2 libs kept around for backwards-compatibility purposes only.
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.
IIRC one of the reasons Apple passed on BeOS was that the lack of a stable C++ ABI made app dependencies on the OS classes very fragile. For example, API classes had to be padded out with dummy members to make room for later non-breaking additions to apps.
Is this still a problem? Isn't this why just about every other OS exposes it's lowest level APIs as C apis?
If the Apple story is indeed true, there's a certain irony to it: device drivers in the OS X/iOS kernel are written against a C++ API called I/O Kit. For forward-compatibility with newer kernel versions, all the public classes contain a significant number of dummy virtual functions, and many also have a pointer member variable called "reserved" so they can later add new fields if they need to without changing the class size.
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).
I think it's not so much the problem of an ABI but the fact that changing base classes in C++ forces client code to be recompiled because offsets of members and vtable entries change:
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.
WinRT gets around it because it doesn't really export C++ the way you're thinking. What it exports are basically COM objects with a bunch of extra CLR-style metadata.
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.
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,
I remember trying BeOS back in the days. It had a nifty feature where you could download an executable and install directly from inside windows, and then boot up in BeOS afterwards. I used to hang out at OSNews where OpenBeOS was heavily promoted and discussed when they started the project. Sure is a long time ago.
I LOVED BeOS back in the R3-R5 days. I switched over to it completely for a time and started writing software for it. Work carried me in a different direction, and my hobbyist enthusiasm lost steam as I saw that Be was going nowhere corporate-wise. Once Apple decided to go with NeXT instead of BeOS as the basis for its new OS, that was all she wrote. I was disappointed with the technology decision by Apple, but that was way offset by getting Jobs back into the company... and we all saw how well that turned out.
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?
"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.
Palm bought BeOS for $11M (and those assets were later transfered to PalmSource which became Access).
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.
So you are saying that they might as well give up?
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.
"Haiku is probably the best positioned to challenge the mainstream operating systems like Microsoft Windows and Mac OS."
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.
>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.
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.)
> If you feel an urge to "start from scratch" — help rebuild everything for mobile.
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.
This is no longer true -- there are a few quality typefaces made by professional designers available for open source projects, for example DejaVu, Droid, Arimo/Tinos, PT Sans, Ubuntu. Even Mac OS X uses an open source font for a part of their interface (Menlo, based on DejaVu Sans Mono).
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.
I think the problem with the font rendering in this screenshot is the hinting. When you hint the fonts too strongly they lose their character and the diagonals' width becomes inconsistent with the straight lines' width, as you can see in the lowercase 'w', for example. If this uses the FreeType library, you can set the font hinting to 'Slight' or 'Medium' and fonts look a lot better.
The hinting looks fine and freetype2 is currently capable of emulating everything OSX or Windows does. The fonts look like (I'm no expert here) they are from the Liberation family that Red Hat created, and I'd agree that they are somewhat utilitarian and ugly.
I don't think it's so much the font as the font rendering. Not sure because I need to get a Haiku system up and running, but Windows, OSX and now Linux have spent a lot of time getting the rendering working with tricks like clear fix.
Interestingly much higher resolution displays will probably help to offset the need for rendering tricks
"The problem with open-source OS's is that they can't take advantage of things like attractive fonts..." My thoughts while reading this: haha good one, yeah make fun of the non-open source stuff... oh wait, this guy is serious
Except that in this case they do, and have had numerous discussions about default fonts and wanting to not step on patent issues over things like ClearType (for RGB subpixel rendering).
I don't think it's fair of you to imply that I lack the mental capacity to remember that: I recall it just fine. However, it's quite immaterial. I was responding to your statement that they don't care, which is not to say that they couldn't. They clearly care - this, and nothing more, did I intend to point out.
"Generally, there is one thread for each application and one for the operating system’s user interface as well."
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.
There can be many threads per process, but plenty of applications ("Generally") are still single-threaded or even if they aren't, they only use one for the UI.
Back when I wanted to get involved (I had a lot more free time), I saw it as an opportunity to have a graphically friendly operating system á la OS X, but actually completely open source.
We have machines scattered throughout the office for meetings (mostly Jira or other web applications). One of those has Haiku running and people seem to like it just fine.
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.
Protip (sorry for using the term), stop using the titlebar to move Windows. I feel physically encumbered when using Windows or OS X because I can't Alt+Drag windows around. It will make you so much faster because you just hold Alt and click and drag. No more searching for that tiny little microscopic bit of window to drag. (For example, Chrome on OS X has almost NO hit space to drag the window). I guess this post is sorta useless if you don't use Linux, but take it for what it's worth I guess.
I can't bring myself to do that on a 15.4" screen (I like the real estate specifically for multitasking and looking back and forth) but I've seen it leveraged extremely well on a 11/13" Air.
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:
http://www.youtube.com/watch?v=BsVydyC8ZGQ#t=17m36s