Slashdot Mirror
Haiku Gains Support For Current Radeon HD Cards
As reported by Phoronix, the Haiku operating system "has added (untested) support for the newest AMD Radeon graphics cards to its open-source driver for the BeOS-compatible operating system." (Specifically, that support is for the "Mullins" and "Hawaii" graphics processors.) Impressive that this project keeps the BeOS flag raised and continues to modernize; Haiku has been around since 2001 — years longer than Be, Inc. itself lasted.
Not to take anything away from the folks working on Haiku, and not that I would ever accuse Phoronix of jumping the gun on a story *cough*, but I really don't think you can claim support for new hardware before someone has tried running the code.
Beos fails to sel
Asks too much for Apple sale
now just open source
Remember, no graphics (not "No modern Radeon HD graphics" or even "No Radeon graphics" but no graphics at all) in Haiku are hardware accelerated.
The ONLY acceleration they offer at all is YCbCr scalable overlays for video on old chipsets that still did that sort of thing, which obviously Radeon HD does not. No 3D, no compositing, no blit operations, everything is done in RAM and then the whole frame is copied to the framebuffer.
Of course today's CPUs are really fast. So long as you do simple 2D graphics or you have a really poky high-end CPU, Haiku can make this look pretty good despite not using virtually any of the transistors on your $200 graphics card.
I have to give them credit. Haiku is even more irrelevant than BeOS.
That's not easy to do.
Yet another OS?
This plethora of systems
Adds to general mess
"The greatest lesson in life is to know that even fools are right sometimes" - Winston Churchill
some of the window management features seem interesting to me.
Why has nobody else implemented the Haiku version of tabs and the ability to "stitch" windows at borders? I can see convenient uses for those. Were these features in BeOS? (I never used it.)
STOP . AMERICA . NOW
Too bad a few of the late bloomers are quick to jump on her grave. Multimedia was it's strong suit, and way out ahead of any Linux distro at the time. Try that with Slak, Mandrake or Redhat 6.x .
Amiga OS4 begs to differ !
Open source OS nobody uses provides support for graphics acceleration hardware without any hardware graphics acceleration.
It's a shame too, because BeOS was doing things that even modern OSes still can't do. I remember being able to run twenty or more video at the same time without lag or do in place driver updates without interrupting anything or requiring a reboot, all on a Pentium III 450MHz.
What made this difference? Was there something magical about the scheduler and/or the graphics stack?
Indeed. Man, a frame-accurate, fully responsive, low-latency OS would be a dream. Today we have various CPU schedulers, I/O schedulers, multiple CPU cores and SSDs thrown at it, but the results are still often quite subpar.
I saw a demo at the Dallas Infomart back in the day. Like you said, it was able to display several videos without any choppiness. No other OS I had seen could come close. I suspect that Haiku can't come close either.
IIRC a lot of the OS I/O stack was coded in ASM to squeeze every drop of performance out. To see what a difference being coded in ASM you should try Kolibri sometime, a full OS with networking that fits on a single floppy,just crazy what you can do by going bare metal.
ACs don't waste your time replying, your posts are never seen by me.
If we want a similar feeling we will have to start to treat user interaction as realtime-critical. Not only is it necessary to fetch user input in a timely fashion, lost input events is non-acceptable bug, but it is also vital that any GUI or console output is processed at a higher priority than any generic calculation. Even network packetloss is preferable to unresponsiveness.
A situation where a process hogs the CPU so much that opening a console and killing it takes several seconds should never occur.
Also, if the start-time of a program is so long that it can have a splash-screen it is still in beta.
There is no reason for that. You don't need to load a gazillion small files, you don't need to initialize a bunch of data.
Everything can be cached and much can be loaded in the background.
Modern systems shouldn't have a worse response time than systems from the 90's.
The GUI toolkit made aggressive use of threading. This was good for latency, but not great for throughput because you ended up doing a lot of context switching. It was also quite hard to program, because you had to be very careful about synchonisation.
I am TheRaven on Soylent News
I'm going to go with something on the theory that after being put on a PC (single chip, with a large L2 cache) it got a free pass to do what it damn well pleased, since it'd been designed to run on a much slower multi-chip PPC solution, which gave up L2 cache entirely in order to have the second processor.
Slashdot Patriotism: We Support our Dupes!
Indeed - if anything, BSD's do much of what they claim in their FAQ that Linux does not.
At this point, it is hard to envision any OS displacing Windows/OSX/BSD/Linux without providing a radically different approach that allows users to do things not possible before
Funny, because every BeOS developer I have ever talked to has said the opposite, that BeOS is a joy to code in.
And I can tell you right now that throughput was no problem. I ran Quake II, used Gobe Productive and have done realtime video editing without any throughput issues. In fact, BeOS is still used in a number of professional studios, specifically for video and audio editing.
Basically, you don't have a clue. You're talking about something you have never even used.
Funny, because every BeOS developer I have ever talked to has said the opposite, that BeOS is a joy to code in.
Steve Jobs wasn't the only reason Apple decided to buy NeXT for ten times what Be was asking. The BeOS APIs were easy to use to write simple applications, but they had a sudden difficulty cliff. Your GUI application was a distributed system and most of the time this was fine because the parts were independent and events arrived at low enough rates that the user wouldn't notice if they were handled in the wrong order. Once you started getting complex MVC applications, the synchronisation requirements became painful and non-obvious. In contrast, the OpenStep APIs (rebranded by Apple as Cocoa) encouraged doing everything on the main thread, which increased latency for the UI but provided a much simpler programmer model because everything happened synchronously, unless you explicitly spawned a background thread for some long-running task.
And I can tell you right now that throughput was no problem. I ran Quake II, used Gobe Productive and have done realtime video editing without any throughput issues. In fact, BeOS is still used in a number of professional studios, specifically for video and audio editing.
You're arguing that throughput isn't a problem by listing a load of latency-sensitive applications?
Basically, you don't have a clue. You're talking about something you have never even used.
I remember BeOS 5 well. I remember the TCP/IP stack that could just about manage 30 minutes of consecutive uptime on a good day (good thing it was a microkernel and you could restart the network stack). I remember that the sound subsystem crashed at least once a day. I remember applications suddenly hitting race conditions under load and exhibiting very strange behaviour.
I also fondly remember BFS and the tracker, but I don't have such a rose-tinted view of the system as some people.
I am TheRaven on Soylent News
The radeon_hd work is mostly to provide reliable mode-setting and to enable the full range of resolutions on Radeon HD cards. There is talk of hardware rendering, howevever we need a pipeline to connect Mesa / Gallium to the card. DRM is very Linux centric. In a lot of ways our driver is cleaner than the Linux one, i've been careful to refacter quite a bit of messy code as I went. We're actually working with the Linux radeon developers to point out issues in the Linux kernel driver. Everyone wins.