Jerome ‘Korli’ Duval has adapted Haiku’s MESA-based OpenGL subsystem to an addon format, allowing renderers to be plugged in, with the first one being a MESA software renderer. This system will allow hardware 3D renderering drivers, such as Rudolf’s one when adapted, to plug in without requiring specialised libGL.so’s for every card. This extends the common BeOS concept of modularity even further, and is somewhat similar to how Be’s OpenGL beta worked – each graphics card acquired a third, .3da driver, to add to the kernel and .accelerant drivers.
This is just another step in the right direction, and with such amazing progress as the haiku is doing i cant help to feel impressed. Hope to see even more progress in the near future. “Dan aka. Judgen”
Was this available on the old BeOS as well, or is this one of the first technical advances Haiku is making on BeOS (besides bugfixing and hardware support)?
How any OS (SkyOS and Haiku come to mind),that doesn’t have native drivers from the vendors gets hardware acceleration without reverse engineering or trying to get a NDA?
That’s why I always thought a little project that died called BlueEyedOS was the right approach. It was going to use the linux kernel and X as the “kernel” for the OS, and then write the BeOS api on top of it. You could still keep all of that proprietary and even fork the kernel if needed. Not only do you get hardware-accelerated 3d for free, but you get all the drivers too.
I know the Haiku reasoning. “It’s not a desktop kernel”. How much are you giving up by it not being “a desktop kernel” though?
Vista is around the corner, XGL is stabilizing, and OSX has their hardware-assisted compositing. Where does this leave these other guys?
I’m not bashing their decision, I’m just curious how these realities are factored in.
Vista is around the corner, XGL is stabilizing, and OSX has their hardware-assisted compositing. Where does this leave these other guys?
With all the fancy-smanchy xglopengl3dfxatiradeonnvidia desktops of X/Vista/OSX, none have ever even been able to come remotely close to the UI responsiveness BeOS exhibited.
With all the fancy-smanchy xglopengl3dfxatiradeonnvidia desktops of X/Vista/OSX, none have ever even been able to come remotely close to the UI responsiveness BeOS exhibited.
And Haiku isn’t BeOS and this isn’t 1998. Fanboy nostalgia? Still doesn’t answer the question.
With all the fancy-smanchy xglopengl3dfxatiradeonnvidia desktops of X/Vista/OSX, none have ever even been able to come remotely close to the UI responsiveness BeOS exhibited.
I almost hate to say it, being a bit of a Be fanboy. But linux with xgl/compiz feels as fast or faster than my BeOS install, and definitly faster than my haiku installation. And firefox flied on xgl compared to either BeOS or Haiku.
I love the idea of Haiku, but it seems more and more to be associated with strawman attacks against other operating systems, rather than actually standing by anything in itself.
I’ll try to explain, although you have already said that you don’t agree with the reasoning that I have already given. 🙂
There is a some reverse engineering in Rudolf’s work, some knowledge from the released 3d specs for older cards, and a lot of hard work. That’s how it happened. That’s how the OSS drivers for linux are progressing, too.
As far as video drivers, don’t forget that the layer(s) between linux and the nvidia/ati drivers are GPL’ed, IIRC. There is no reason that someone couldn’t port them to our kernel. As far as other drivers, if the source is open, as it is with linux, it isn’t the tremendous amount of work to make a driver that it is if there is no source, especially if there is open documentation as well.
Vista is not even an issue, in my mind. Almost no one will set out to buy it. I believe that > 95% of the sales are through OEMs (i.e. preinstalls). Which means that it is basically the same, business wise, as XP. It isn’t an issue of competing with Vista, but educating the user why they shouldn’t use Windows. But we have a whole lot of stuff to finish first. 🙂
Having a whiz bang hardware composited desktop is a nice thing, but I think that the real problems that users have are much different than that. I believe that 90% of users would rather have a system that doesn’t lose their data, makes sense, is easy to use and is fast than a system that allows them to put their windows on a rotating cube. Of course, BeOS sort of led the way on the rotating cube (3d demo), but still… 😀
It should also be noted that the DRI drivers for Intel’s integrated GPUs are open source, and fully supported by Intel. Not only are the GMA chips the most popular GPUs out there (numerically), but as of GMA3000, their performance should be perfectly adequate for even intense uses of OpenGL-accelerated 2D.
There is a some reverse engineering in Rudolf’s work, some knowledge from the released 3d specs for older cards, and a lot of hard work. That’s how it happened. That’s how the OSS drivers for linux are progressing, too.
Yeah, and that leaves out (what 90%+) of the ATI and Nvidia cards in existing systems.
As far as video drivers, don’t forget that the layer(s) between linux and the nvidia/ati drivers are GPL’ed, IIRC. There is no reason that someone couldn’t port them to our kernel. As far as other drivers, if the source is open, as it is with linux, it isn’t the tremendous amount of work to make a driver that it is if there is no source, especially if there is open documentation as well.
I had thought about something like that. Basically you would reverse-engineer the bits in between the binary blob, how that translates to X, and fit into the BeOS graphics system.
Vista is not even an issue, in my mind. Almost no one will set out to buy it. I believe that > 95% of the sales are through OEMs (i.e. preinstalls). Which means that it is basically the same, business wise, as XP. It isn’t an issue of competing with Vista, but educating the user why they shouldn’t use Windows. But we have a whole lot of stuff to finish first. :-
Vista is an issue, whether you want it to be or not ,since 5 years from now the vast majority of desktop users will be using it.
Having a whiz bang hardware composited desktop is a nice thing, but I think that the real problems that users have are much different than that. I believe that 90% of users would rather have a system that doesn’t lose their data, makes sense, is easy to use and is fast than a system that allows them to put their windows on a rotating cube. Of course, BeOS sort of led the way on the rotating cube (3d demo), but still… 😀
Your premise that existing systems with much better driver support don’t do that already is wrong.
“Where does this leave these other guys?”
It leaves them doing something they want to do.
I know the Haiku reasoning. “It’s not a desktop kernel”. How much are you giving up by it not being “a desktop kernel” though?
Apparently you have never run BeOS / Zeta / HAIKU. The x server system is just too slow to get that feel that is the BeOS experience. If you have never run the OS you would not understand how uncomfortable any Linux / BSD desktop system is … feels like you are running your computer under water… everything is just too slow.
Apparently you have never run BeOS / Zeta / HAIKU.
And apparently you are wrong, because I have run BeOS. And let me tell you something. It wasn’t all that zippy because there was no 2d acceleration for the neomagic chipset in my 1998-era hardware that I ran it on.
The x server system is just too slow to get that feel that is the BeOS experience. If you have never run the OS you would not understand how uncomfortable any Linux / BSD desktop system is … feels like you are running your computer under water… everything is just too slow.
You’re confusing toolkits (gtk+) with X. X isn’t slow. In fact, the BlueEyedOS (BeOS api on top of X/linux) developer wrote an article for OSNews years ago, showing how X was not slow.
If it’s not going to have accelerated 3d, then it’s not going to be much of a desktop operating system in 2007-8 and beyond, no matter what kind of nostalgic feelings you have for it.
there was no 2d acceleration for the neomagic chipset in my 1998-era hardware that I ran it on.
Ummmm did your Neomagic run fast on any platform?
The point of Haiku is to recreate the R5 experience as a solid foundation, THEN move onto new features (I think they call that project “Glass Elevator”). This way they don’t waste time arguing about what features will or won’t be included in the first release. It’s the quickest way to get the actual product out.
Linux distros nowadays are so bloated and slow to bootup that they’re just not true to the Be vision. Let the Haiku guys reach that first milestone and THEN worry about where to go next.
Be was about leaving behind legacy cruft. It could be argued that R5 itself is legacy, but I’d argue that it’s a whole lot less crufty than modern Linux.
Ummmm did your Neomagic run fast on any platform?
It was plenty fast on 98.
The truely entertaining part of this statement is that BeOS’s graphics engine really was never that fast. NT’s was faster, and X was faster still.
What made BeOS fast was that the whole thing was designed under one roof. The kernel scheduler, UI toolkit, graphics server, and window manager were all designed by the same group of people, and the window manager and graphics server were co-located in the app_server. As a result, synchronization could be handled propery, and the illusion of speed and responsiveness could be maintained.
the reason Linux GUIs are sedate by comparison is three fold. First, there is no synchronization to speak off. When you resize a window, the application, the X server, and the window manager all have to coordinate. But the kernel basically runs them randomly, and only eventually do you get the desired result. Second, many apps aren’t multithreaded properly, or don’t use a non-blocking I/O mechanism like select(). On BeOS, this was mandatory in the API. Third, the BeOS UI toolkit was very simple. It was pixel based, not font-sensitive, and had no layout engine. When you resize a window in a GTK+ app, the toolkit goes relayouts all the contents. It does widget layout, based on the widget containers specified in the window. It does internationalized text layout, with correct line-breaking. It also calls the theme to get newly-drawn widgets that fit the new layout. BeOS’s toolkit didn’t have to do any of that, because it didn’t support widget containers, or font-sensitive UI elements.
Nice to see some more Haiku progress!
I wonder when the basis of the system would be strong enough for daily use… I’m sure that software development will be growing a lot when that happens! =]
To my knowledge, the NeoMagic chipset was some “off-the-beaten-path” chipset that was really ONLY supported by Windows, because windows supports EVERYTHING! Besides, only those not paying attention would have not known that BeOS never really officially supported laptops of any brand. They’re too integrated/proprietary. Notice how BeOS supported more commonly available desktop video chipsets like S3, ATI, Nvidia, and Matrox. And they even had hardware accelerated 3D for the 3Dfx Voodoo chipset!
BeOS never really focused on laptops. It was desktops they were after.
So, that in mind, it’s not suprising the Neomagic chip in your laptop wasn’t supported. Because *laptops* never really were.
BeOS, on *supported* hardware, however, runs really nice and fast.
To my knowledge, the NeoMagic chipset was some “off-the-beaten-path” chipset that was really ONLY supported by Windows, because windows supports EVERYTHING!
Actually, a few(couple) years ago there was work being done on the chipset(2d acceleration was supposed to be added). Future work was irrelevant to me though. Neomagic was popular in IBM thinkpads, so hardly off the beaten-path.
Besides, only those not paying attention would have not known that BeOS never really officially supported laptops of any brand.
Considering the prominence of laptops today, it looks like BeOS would have died anyway if it wasn’t paying attention to laptops.
BeOS, on *supported* hardware, however, runs really nice and fast.
Yeah, that’s the whole problem. Who is going to build a PC around something like BeOS. 20 people maybe?
I think Lamda has a point, though. In a couple of years the vast majority of the public is going to view any OS without 3d effects as old and ugly, no matter how fast it actually is. Which means Haiku will have to either develop these effects too or resign to being an enthusiasts desktop only, for people that like visiting OSNews. Perhaps that is all they care about, though – there is nothing wrong with catering to a small but picky audience.
I think Lamda has a point, though. In a couple of years the vast majority of the public is going to view any OS without 3d effects as old and ugly, no matter how fast it actually is.
It reminds me of 15 years ago when you had people running around wondering why we needed bitmapped desktops at all. Yeah, I could use a bunch of a virtual terminals, I could use some window manager from 1997 and a bunch of Xlib apps, but I have other alternatives.
It reminds me of 15 years ago when you had people running around wondering why we needed bitmapped desktops at all. Yeah, I could use a bunch of a virtual terminals, I could use some window manager from 1997 and a bunch of Xlib apps, but I have other alternatives.
I don’t think the Haiku guys are content to stay in the past. Let me reiterate that is why they have Glass Elevator.
Relax Lambda, rest assured that you’re not the only person to make these brilliant observations (great minds think alike, right?). It’s going to progress, Tracker surely will be 3d-accel someday, but only AFTER they finish the first release. Hell, they didn’t even have OpenGL working until recently, right?
I have other alternatives.
(start smartass) Cool! Then I guess I won’t have to worry about you restating the obvious on any future Haiku boards.
(end smartass) Man, it’s like you expect Haiku to compete with Windows right out of the gate. Even your precious Linux hasn’t been able to achieve that.
Haiku is looking to follow a different path from Linux and Windows. They’d gain many things by using the Linux kernel, but they’d lose their identity as a total BeOS replacement. The tight integration that Rayinor wrote about is what they’re after, and for that they wouldn’t be interested in using the Linux kernel or X anyways.
I don’t think the Haiku guys are content to stay in the past. Let me reiterate that is why they have Glass Elevator.
In one way they are. They are re-implementing the BeOS API, and user-level apps. If it’s a great design, then so be it.
Relax Lambda, rest assured that you’re not the only person to make these brilliant observations (great minds think alike, right?). It’s going to progress, Tracker surely will be 3d-accel someday, but only AFTER they finish the first release. Hell, they didn’t even have OpenGL working until recently, right?
I’m plenty relaxed and could care less what happens to Haiku. In fact, my question was more of a general question about alternative operating system, and how they are going to cope with not being able to have the major vendors produce drivers for them.
(start smartass) Cool! Then I guess I won’t have to worry about you restating the obvious on any future Haiku boards.
(end smartass
I’ve never been on a Haiku board.
Man, it’s like you expect Haiku to compete with Windows right out of the gate.
No, because I never stated that, and it never will be a serious competitor to Windows.
Even your precious Linux hasn’t been able to achieve that.
Haha, now that’s funny. Linux is far from precious in my book.
Haiku is looking to follow a different path from Linux and Windows. They’d gain many things by using the Linux kernel, but they’d lose their identity as a total BeOS replacement.
Did OSX/Mac lose its identity because it uses Mach and FreeBSD?
The tight integration that Rayinor wrote about is what they’re after, and for that they wouldn’t be interested in using the Linux kernel or X anyways.
“Tight integration” is handwaving unless you care to be more specific.
I wish the haiku developers all the luck. As you stated, desktop linux never took off, so maybe there’s a shot to carve out a niche.
“Tight integration” is handwaving unless you care to be more specific.
I can be more specific.
Current GUIs have a few major conceptual pieces. There is the graphics engine (eg: X or the GDI), the window manager, the UI toolkit, and the application-side event handlers. The kernel-level scheduler is also a crucial component in the whole. Integration between these pieces, or more importantly, synchronization between these pieces, is crucial in creating a performant UI.
Consider, for example, what happens when the user resizes a window. The resize operation is actually one of the most complex and performance-sensitive operations in the UI, especially in buffered UIs in which window-movement can happen without redrawing underlying windows. At each step of a resize, all the pieces must coordinate. The mouse-move event goes to the window manager, which calls into the graphics API to enlarge the window’s drawing context. The window manager then redraws the window frame. Then, the graphics API informs the application that its content area has been resized. The toolkit handles this resize message, and redoes the window layout. In the process of doing window layout, it has to call into the user-level event handlers of each widget, to handle resize logic and redraw. At each redraw step, the graphics API gets called, and at each process switch, the kernel scheduler gets involved. All this has to happen in about 50-100ms, to ensure a smooth 10-20fps resize rate.
The key thing to note here is that there is easily enough CPU time to meet a 50ms target. I worked on the XSYNC-based resize NETWM spec some years ago, and I found that even on my P4 laptop, Konqueror could perform layout of a moderately complex page in 20-25ms. The CPU time taken by the rest of the logic is trivial, a few ms at most. Yet, at the time (and probably even now on much faster machines), Konqueror could not be resized smoothly. Why? Synchronization.
Consider what happens when this process is carried out in an X11 GUI:
X reads /dev/mouse. It generates a mouse-move event for the X11 window that contains the window-frame (the app’s X11 window is nested inside the window-frame’s X11 window). Then, it keeps computing, servicing requests from other applications, either until its input queues are empty, or until it runs out of its timeslice (which can be tens of ms). Then, the scheduler kicks in, and often runs one or more random processes, again for potentially tens of ms. Eventually, the window-manager gets scheduled. It reads the mouse-move event out of its socket. It sends window-resize requests for the X11 window containing the window frame, as well as the app’s X11 window, and either keeps servicing unrelated clients, or blocks. Now, the kernel scheduler kicks in, and runs some random process. Eventually, X gets scheduled again. It processes the window-resize request, and generates a window-resize devent for the app’s window and the window manager’s window. Again, it services unrelated clients until its queues are empty, or its timeslice expires. The kernel scheduler kicks in, and eventually, the window manager gets scheduled, sees the resize event, and redraws the window frame. It services unrelated clients until its queues are empty. The kernel scheduler kicks in again, and eventually the app gets scheduled. It sees the resize event, and does the re-layout, and redraws the window contents. If the UI toolkit is stupid, like GTK+, it’ll wait awhile to buffer more requests before handling them as a batch. We’re not done yet. The kernel scheduler kicks in. Eventually X gets scheduled again. It sees the drawing requests in its queues, and draws the new window frame and window contents on the screen. Now, hundreds of ms after the user moved his mouse, he sees one step of the resize.
Of course, things get even more entertaining. The above process is what GNOME/Metacity behave like now. Before XSYNC-based resize, it was even worse. Because the window-manager can redraw the window frame much much faster than the app can redraw the window contents, what’d happen is that more mouse-moved events would come in as soon as the WM handled the resize, and the WM would start the next-resize step before the app had finished the last one. X, because of its fair-share scheduling, would happily oblige, and the result would be that the window frame would be resized and redrawn dozens of times every time the window contents were resized.
Note where the inefficiencies in the process lie. It’s not in the drawing speed. X will draw millions of primitives for you before you can blink. It’s not in the window managent speed. X will move, circulate, resize, etc, tens of thousands of windows per second. It’s not in the IPC. Sockets will move hundreds of megabytes per second. It’s not in the context switching. The actual context-switch time for the whole sequence above is maybe 50 usec on Linux! No, the inefficiency in the process is all that time that’s spent doing things unrelated to the resize. All that time spent in X and the WM servicing apps that are not the app being resized. All that time that is spent with the kernel choosing apps that have nothing to do with the resize. Indeed, its the fact that the Linux scheduler has gotten pretty good at minimizing the latter that resizing has gotten so much better on Linux, even though the window managers or X’s window handling haven’t gotten faster in maybe a decade.
So now, we can see where integration and synchronization come into play. You can speed up the above process by several factors just by colocating the window manager in either the graphics server (how BeOS does it), or in the application (how Windows does it). That whole series of X <-> WM transitions at the beginning just get folded into some intra-app function calls.
I used resize as an example, but things like this happen in many other places. Consider what happens when a menu needs to be popped up, for example. Synchronization and integration comes into play there too. The only way to achieve proper synchronization is by developing the GUI as a system, not as seperate, unrelated parts. All display systems have certain performance characteristics. X’s performance characteristics aren’t that weird. Yet, X toolkits absolutely suck at adapting to those characteristics. Hell, even Xlib sucks at adapting to those characteristics. Until recently, the kernel scheduler sucked at adapting to the characteristics of the whole X <-> WM <-> App system.
The fact that the BeOS UI toolkit was designed precisely for the app_server’s performance profile, and the kernel scheduler was designed precisely for the app_server/GUI-toolkit’s performance profile was partly why BeOS on a PII-300 was snappier than X11/GNOME is on a 2GHz Core Duo.
Edited 2006-09-11 03:03
Very nice reply rayiner. As usual, its nice to read well informed posts from intelligent posters, unlike the usual teenage drivel we usually encounter on the net.
rayiner illustrates one of the best features of Haiku – the entire system is done by a single team with a common goal. This is unlike the free *nix world where there are multiple teams working with different priorities / goals. In the end, the *nix solution is more modular / widely usable with great flexibility. This is at the expense of efficiency.
Haiku promises to be a *fast* and efficient unified solution (free OS). It will never host servers or run on a mobile phone (although there will be adventurous people willing to try). But it will fly on the desktop, and resize a window faster than what I (the user) can notice.
Great answer indeed. I think this should be kept somewhere as one can be sure other kids will burst some other day saying “X is faster” while it’s not even the point.
Nice writeup. There’s a couple problems though. One is (as you mentioned), that the symptoms are particularly endemic to gtk+/Metacity. In addition to what you mentioned, there was(is) a bottle-neck in the Pango library, that has caused resizing issues. I’m not sure if that ever got cleared up. They were looking for a fastpath for western languages, but I’m not sure if it ever made it in. This has been less of an issue with KDE, and probably even less of an issue with Windows. The Windows GUI subsystem is for obvious reasons, especially optimized in the 2d department.
I tracked down the “Optimizing XFree86” osnews article that the B.E.OS developer wrote for osnews around four years ago. http://www.osnews.com/story.php?news_id=1905&page=2. That’s an interesting read. Just that from a starting point and four years of development could have put a fast BeOS gui on top of X.
The other “problem” is that Moore’s law is working in favor of a desktop like Gnome – mostly in the way of GPU transistors these days. Vista will of course be graphically fast (unless they completely blunder and go backwards), and linux desktops will take advantage of XGL (or whatever the final solution is for X). This doesn’t solve all the issues regarding X toolkits and desktop managers, but glosses over some of them.
By the way, most of the Gnome resizing issues go away once you get to the 1Ghz level, which is pretty pervasive for desktop systems these days.
Something that you didn’t mention, but would work in favor of a heavily multi-threaded architecture like BeOS are the multicore CPUs that are coming out. The only problem is that it is notoriously difficult for programmers to debug and develop for in a language like C++. Eugenia had touched on this years ago when discussing some of the problems with BeOS. A language like Haskell or Clean would be a better choice, but there’s social issues, as well as implementation issues surrounding those.
If you skip the whole resizing issue you may want to look at drag’n’drop and a whole lot of other stuff which made BeOS very pleasant and fast (not fast as in cpu speed) to work with.
Like if windows wasn’t such a piece of big bloat soft with all the viruses and such it would apeal to me because it’s integrated, looks the same way (or similar) same conventions etc. etc.
With linux and all you get many many choices, maybe too many to filter them all for somebody who just wants to write a quick email to his grandmother abroad.
Yes and who want’s to wait if he has a ton of idea’s ready to be recorded by his or her computer?
I wish a lot of users and devs! would instal BeOS to experience and use some of it’s great idea’s and feel.
I tracked down the “Optimizing XFree86” osnews article that the B.E.OS developer wrote for osnews around four years ago. http://www.osnews.com/story.php?news_id=1905&page=2. That’s an interesting read. Just that from a starting point and four years of development could have put a fast BeOS gui on top of X.
Yes, you probably could. But it would require coordination, though. X could stay largely the same, but the kernel scheduler 4 years ago was completely insufficient for the task. The current one is a lot better, and much of the reason for that is because it was designed with X as one of its use-cases. And of course, the toolkit would have to be highly optimized for the performance profile of X. Read up on XCB vs Xlib to see the types of things an X toolkit has to avoid doing.
This doesn’t solve all the issues regarding X toolkits and desktop managers, but glosses over some of them.
It doesn’t really solve any of the issues, but papers over them quite nicely. Resizing with XGL will be slower and less efficient, because now the DRM has to get involved too in order to resize the window buffer. However, that won’t matter, because the double-buffering will eliminate the visual artifacts that accompany poorly-synchronized resize. It won’t be any faster, but it’ll look much smoother.
By the way, most of the Gnome resizing issues go away once you get to the 1Ghz level, which is pretty pervasive for desktop systems these days.
Even on my 2GHz Core Duo Macbook, the resizing issues are still there. The synchronization issues are still there.
XCB will be released on Friday, September 15th!!!
http://lists.freedesktop.org/archives/xcb/2006-September/001903.htm…
To rayiner: The BeOS kernel has no optimizations for GUI whatsoever; it just uses a priority based scheduler. Like Linux it can and will schedule unrelated threads during window resize or other heavy GUI operations.
The only argument that plays off is the window manager being part of the app_server – and that’s an argument against X server performance and design. Windows and BeOS have obviously solved this problem in a better way.
The BeOS kernel does have an optimization for the GUI. Window threads in BeOS run at a higher priority than regular threads. This is not as overtly hackish a solution as Windows’s (the foreground app gets a prio boost and a longer timeslice), and its well-subsumed into the general scheduling mechanism, but there is still a B_DISPLAY_PRIORITY that is distinct from B_NORMAL_PRIORITY.
According to an old Be Newsletter, BeOS’s probabalistic scheduler will be much more likely to choose a thread with priority 15 (B_DISPLAY_PRIORITY), than a normal one with priority 10. That means when the app_server sends a “redraw” or “resized” message to the application, it is highly probable that the next thread to be run will be the window thread in question.
On the topic of communication & scheduling, I have often wondered if it wouldn’t be possible to link the two ie instead of having ‘do system call to send message from X to Y – do system call to wait for answer – kernel schedule unrelated process – eventually schedule Y – reply, etc’, if it wouldn’t interesting to have one sytem call which would be ‘send message from X to Y and schedule Y (if quantum is not exhausted of course)’.
If Y can do its work without blocking this would allow very fast communications.
Has it been tried in some OS?
On the topic of communication & scheduling, I have often wondered if it wouldn’t be possible to link the two ie instead of having ‘do system call to send message from X to Y – do system call to wait for answer – kernel schedule unrelated process – eventually schedule Y – reply, etc’, if it wouldn’t interesting to have one sytem call which would be ‘send message from X to Y and schedule Y (if quantum is not exhausted of course)’.
A number of microkernels (such as Amoeba, QNX, and L4) do something very similar. In these microkernels, IPC is synchronous and unbuffered. If Y is waiting for IPC, X can send an IPC, the kernel will copy the data directly from X to Y, Y then gets scheduled and creates a reply, and the kernel copies the result directly from Y to X. This happens in one system call from X’s point of view. Then, at the scheduling level, you can apply mechanisms like timeslice donation (run Y for the remainder of X’s timeslice), or priority boosting (boost Y’s priority when it receives IPC), to ensure that Y gets scheduled immediately after X.
This mechanism does were very well in practice.
In one way they are. They are re-implementing the BeOS API, and user-level apps. If it’s a great design, then so be it.
They’re trying to revive what they consider to be a great platform. They’ve got to start somewhere, right?
No, because I never stated that, and it never will be a serious competitor to Windows.
I don’t think that the Haiku developers realistically expect that either. My point is this: why would or should Haiku just be a window manager on top of Linux in that case? They’re building a BeOS replacement, not a WM or DE replacement like Blue Eyed was.
Haha, now that’s funny. Linux is far from precious in my book.
I’m with ya on that one. It’s amazing how bloated and crufty it’s gotten. Remember when Linux fans used to tout how light and speedy it was?
Did OSX/Mac lose its identity because it uses Mach and FreeBSD?
No it didn’t, but I think the case is totally different here. A few thoughts:
1) The point behind the creation of BeOS was to unburden the OS. JLG wanted no legacy, even forsaking backwards compatibility if needed. Granted, Haiku itself is a replication of Be, but I think having a non-moving target for the first release is a good thing (meaning “no feature bloat”).
2) There was no gap in the availability between OS9 and OSX. Apple was able to transition users from one to the other. On the other hand, BeOS has been out of official development for years (sorry Zeta doesn’t count). Before transitioning to something new, Haiku aims to reestablish the Be platform. They’re aiming to bring something back that they love, then foster growth.
“Tight integration” is handwaving unless you care to be more specific.
Wow Rayinor knows more than I ever could on the subject. Nuff said.
A moment of silence for the lives lost five years ago today.
Edited 2006-09-11 07:35
They’re trying to revive what they consider to be a great platform. They’ve got to start somewhere, right?
And that’s the whole question of the subthread – at what level do they start at.
I don’t think that the Haiku developers realistically expect that either. My point is this: why would or should Haiku just be a window manager on top of Linux in that case? They’re building a BeOS replacement, not a WM or DE replacement like Blue Eyed was.
An OSX user might not have even heard of Mach or FreeBSD. Since BeOS is a desktop system, it is a DE and a WM replacement. Blue Eyed just chose to re-use an existing kernel and a graphical/event system in the form of X. They were going to implement the BeOS APIs, so from a user point of view it could be just as much BeOS as Haiku wants to be.
Did OSX/Mac lose its identity because it uses Mach and FreeBSD?
No it didn’t, but I think the case is totally different here. A few thoughts:
1) The point behind the creation of BeOS was to unburden the OS. JLG wanted no legacy, even forsaking backwards compatibility if needed. Granted, Haiku itself is a replication of Be, but I think having a non-moving target for the first release is a good thing (meaning “no feature bloat”).
2) There was no gap in the availability between OS9 and OSX. Apple was able to transition users from one to the other. On the other hand, BeOS has been out of official development for years (sorry Zeta doesn’t count). Before transitioning to something new, Haiku aims to reestablish the Be platform. They’re aiming to bring something back that they love, then foster growth.
The interesting thing about those two comments is that they seem to contradict each other and your previous comment regarding recreating the BeOS platform. On one hand you say that they will forsake backwards compatibility if needed, but wants to re-establish the Be platform (before transitioning to something new). What is something new, and why aren’t they going there now if they are willing to forsake backward compatibility?
Tight integration” is handwaving unless you care to be more specific.
Wow Rayinor knows more than I ever could on the subject. Nuff said.
I responded to Rayiner.
> Since BeOS is a desktop system, it is a DE and a WM
> replacement.
Oh please, there’s more than just the graphical environment in BeOS.
Its drivers plug-and-play for example has nothing to do with DEs and WMs but is as much as important in BeOS user experience. Should I go on with its file system BFS? How do you integrate such kind of file system without hacking deep into the kernel on non micro-kernels?
What about system-wide MIME sniffing and identification? What about being an OS multithreaded from top to bottom?
These does matter to the final user experience (responsiveness vs being fast) as much as the UI framework.
> Blue Eyed just chose to re-use an existing kernel
> and a graphical/event system in the form of X.
> They were going to implement the BeOS APIs, so
> from a user point of view it could be just as
> much BeOS as Haiku wants to be.
User Interface-speaking, yes. System-wide experience speaking, nope.
Plus, it’s hard to compare these two so far as none have released something for end user yet. If ever.
> On one hand you say that they will forsake
> backwards compatibility if needed, but wants
> to re-establish the Be platform (before
> transitioning to something new). What is
> something new, and why aren’t they going there
> now if they are willing to forsake backward
> compatibility?
Because 5 years ago Haiku developers didn’t know how to write a whole OS, so they decided they’re not ready to design it from scratch yet. In the process of making Haiku R1 they’ve discover what’s wrong in some BeOS design and what’s really good and should be kept as-is. After R1 milestone, R2 will focus on reworking these parts and on designing some new ones more.
Baby steps. Learn from experience.
The interesting thing about those two comments is that they seem to contradict each other and your previous comment regarding recreating the BeOS platform. On one hand you say that they will forsake backwards compatibility if needed, but wants to re-establish the Be platform (before transitioning to something new). What is something new, and why aren’t they going there now if they are willing to forsake backward compatibility?
I don’t know if you’re just pretending to be obtuse, but I’m retracting the quip about “great minds”.
Think about it. How long would it take them to finish the first release of Haiku if they added every new gizmo that shows up each year? How many software projects do we each see every year that are delayed? They’re not trying to implement the operating system equivalent of Duke Nukem Forever. Haiku’s small team has worked hard for FIVE YEARS, and I’m sure they want to release the first version before another five years pass. They’re working towards an established, focused goal instead of haphazardly adding features as they go. They’re trying to avoid feature creep at this stage and get something that works first: a solid, stable base that would serve as the foundation for future improvements (again, Glass Elevator). They’re already planning the improvements. I know it must be pretty radical in today’s fickle world of software development not to include the kitchen sink, but Haiku’s renegade plan just might be crazy enough to work.
Also note that Quartz Extreme wasn’t released until Jaguar (2002), a full year after OBOS (now called Haiku) began development. They set their target back in 2001 and got to work implementing it, not arguing about what new features to include. Bravo.
It’s unfortunate that you never experienced BeOS as it was meant to be. If you had, you’d understand that slapping a Be-like DE or WM on a Linux kernel is a far cry from what BeOS offered. Besides, you don’t sound particularly fond of Linux, so why in HADES would you think it a good idea to use Linux as the foundation for another OS? That’s the contradiction I see.
Hehe, I’m afraid that BlueEyedOS kind of experience for first-time users will result in something like that joke:
“Pavarotti singing in Aida? Ohh, thotal sh*t!”
“Did you visit Milano Opera?”
“No, my uncle sang this for me via telephone from Miami – he watched it from videotape!”
Well when I compare R5 to Zeta 1.2 I see a whole lot of new flashy icons and other gfx elements in menu’s. When I saw that I thought less is more. Experience that.
there’s nothing stopping anyone from write code to use hardware opengl acceleration to enhance/speedup the gui/desktop.
it may very well be on the developers roadmap, but obviously not for R1. In fact I’d be surprised if it didn’t get implemented later on. but in my book, getting the operating system up and running stable is pretty much a higher priority.
Haiku will be a hard sell (despite being free) towards anyone but existing Beos users and OS enthusiasts. It will never conquer the world, and at worst it will never make a splash beyond the current Beos userbase.
Hopefully though, it will appeal to users beyond this realm, with or without hardware accelerated desktop effects.
now, on a personal note. for what I need my computer to do, I don’t have to look further than my Windows 2000 installation, it runs all the programs I need, it’s fast enough on both my old 1333 AMD and my P2400.
however, when it comes to enjoying the environment I use my computer in, I’ve yet to find anything I like better than Beos.
This document lists all hardware for which there are open source 3D drivers:
http://dri.sourceforge.net/doc/dri_driver_features.phtml
Mind you, it’s not even up-to-date. The r300 and r400 ATI cards now have basic support as well. There’s no reason that a group of truly dedicated, knowledgeable developers couldn’t get the DRI infrastructure ported to Haiku if they really wanted to. That would leave out all r500+ ATI cards, and new nVidia cards.
By the way, most of the Gnome resizing issues go away once you get to the 1Ghz level, which is pretty pervasive for desktop systems these days.
No way. KDE/GNOME’s resize issues exist just as well on my Pentium M 1.73Ghz, as it does on my AMD Athlon 1600+ (which runs at 1394Mhz).
The only way I can get rid of the resize problems is by enabling Xgl. By letting the videocard join the party, GNOME/Gtk+ finally stopped tearing windows apart (save for Firefox, which tearsapart on any platform).
Browser: Mozilla/4.0 (compatible; MSIE 4.01; Windows CE; PPC; 240×320)
I don’t see why anybody would be less than pleased with this news… It looks to me like it’s brining Haiku much closer to having actual 3D support. With only a bit of work, this system will allow Haiku the same ammount of 3D support as Linux as you’ll simply be able to port to modular drivers, providing near-instant support for old-school ATI and nVidia as well as 100% support for Intel’s intergrated stuff (the newest of which ain’t exactly shabby)
The complaining about Haiku being a waste of time seems odd. I for one am pleased.
Thing to notice. BeOS has quite different from Linux driver model.
Kernel does not contain any info on certain drivers, so, so called “modules” which are totally minimalistic (pure
hardware resource publishing soft) are very independent, inspite working in “kernel space”.
And most of work may be done by add-ons which are totally user-level pieces.
I’m wondering how this can affect all that licensing (incl. GPL) hassle around drivers we see in Linux word for example.
I thought I had found the right OS for myself. I absolutely loved it. When Be closed down a few years later I swore I’d never touch a closed OS again. Well, I haven’t and I am not going to. Since then I am a happy Debian user 🙂
Haiku OS is a nice idea —
When Be closed down a few years later I swore I’d never touch a closed OS again. Well, I haven’t and I am not going to. Since then I am a happy Debian user 🙂
Haiku OS is a nice idea —
You must have Haiku mixed up with something else – it ISN’T a closed OS, it’s MIT licensed.
Unless I’m misunderstanding your point here – maybe you’re considering that Haiku IS a future option for you.
Edited 2006-09-11 23:43
Hi, I have little knoledge of all this complicated stuff but how about the directFB aproach?
Thanks!
DirectFB’s architecture is very simple compared to any of the ones described above. In DirectFB, there is a kernel framebuffer driver, and a userspace library. The window-management is done client-side. So the resize process goes like this:
DirectFB code reads /dev/mouse. Notices mouse has moved. It resizes the window buffer, and redraws the screen by banging the hardware directly.
This is great for embedded systems (DirectFB’s target), but is somewhat insufficient for a multi-user desktop. The security is not only lax, but its not really there. All apps need to be either run as root, or regular users need to be given access to /dev/fb, which can be used to compromise security.
I’m also not sure what the security is like for the window stack. Since there is no server, global data is probably unprotected, which means that apps could overwrite each other’s windows.
Put simply, DirectFB is a lot like DirectDraw. It’s very good for its intended purpose, but that purpose isn’t being a general-purpose windowing system.
EDIT: http://mail.directfb.org/pipermail/directfb-dev/2006-May/001811.htm… suggests that the window stack, and other important data structures, is actually distributed via SHMEM. This supports the conclusion that there is no protection of these curcial data structures in DirectFB.
Edited 2006-09-12 00:57