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.
On hardware from circa 2001, BeOS had an audio latency of about 3 msec from input to output. I don't know the x86 / x64 number, but in 2014 running on the best ARM hardware available, by default, the Linux scheduler runs every 10 msec, so audio latency of 40-80 msec is pretty common. In many applications, that is quite a significant difference. There are good reasons why Linux has this latency, but it is a question of optimizing for different use cases. BeOS had a laser focused use case of Desktop performance. Linux is used on servers, desktops, embedded, super computers, and all kinds of wierd places.
-- the computer doesn't want any beer, no matter how much you think it does. NEVER, EVER feed your computer beer.
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.
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.
Linux is hardly a sensible point of comparison, because the reliance on userspace sound daemons (low-latency in-kernel sound mixing would bloat the kernel, but a web server in the kernel is fine...) means that you end up needing a lot of round trips to get audio out. On FreeBSD, for example, the mixing happens in the kernel so if you really need low latency you can pin a process to a dedicated core and have it pushing things out very quickly. Most of the time, it's fine to keep the buffers filled and allow other processes to share the core.
I am TheRaven on Soylent News