Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The Dawn of Haiku OS

spectrum.ieee.org

Post reply on HN
Print view View original

71–80 of 115 posts

Re: The Dawn of Haiku OS

#71

Post by batista »

wtracy wrote: post #38
eslaught wrote: post #10

"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…

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.

So, BeOS is somewhat akin Node.js for operating systems?

Re: The Dawn of Haiku OS

#72

Post by batista »

nkoren wrote: post #68
falling wrote: post #61

Earlier quoted context omitted.

and now that Lion reimplemented the feature people are hating it.

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'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.

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.

Re: The Dawn of Haiku OS

#73

Post by gecko »

cageface wrote: post #59
pjmlp wrote: post #55

Earlier quoted context omitted.

I never heard this story before. 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.

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: 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.

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.

Re: The Dawn of Haiku OS

#74

Post by gecko »

wtracy wrote: post #38
eslaught wrote: post #10

"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…

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.

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.

Re: The Dawn of Haiku OS

#75

Post by tqh »

rbanffy wrote: post #65
nitinmartolia wrote: post #45

Just started downloading Haiku ,looks cool to me.

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…

The stack and tile functions might make you reconsider: http://www.youtube.com/watch?v=4Y-6YmGd30A

Re: The Dawn of Haiku OS

#76

Post by brazzy »

wtracy wrote: post #38
eslaught wrote: post #10

"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…

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).

Re: The Dawn of Haiku OS

#77

Post by Avshalom »

brackishlake wrote: post #54

"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 hal…

>The world needs great developers to build awesome apps for a whole new class of machines.

... for very idiosyncratic definitions of "the world" and "need"

Re: The Dawn of Haiku OS

#78

Post by Lewisham »

shadesandcolour wrote: post #69
falling wrote: post #61

Earlier quoted context omitted.

and now that Lion reimplemented the feature people are hating it.

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.

Re: The Dawn of Haiku OS

#79

Post by unimpressive »

brackishlake wrote: post #54

"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 hal…

>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.)

Re: The Dawn of Haiku OS

#80

Post by nkoren »

batista wrote: post #72
nkoren wrote: post #68

Earlier quoted context omitted.

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'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. 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.

Well, that's weird. Mine's a 2009 model and I sorely regret installing Lion on it. The thing absolutely crawls.
Post reply on HN