Hacker News new | past | comments | ask | show | jobs | submit login
Haiku Now Has Experimental 3D Acceleration (haiku-os.org)
207 points by DeathArrow 5 months ago | hide | past | favorite | 71 comments



For more context, this effort is mostly lead by X512, the wunderkid, who ported Haiku to RISC-V platform singlehandedly, and a long time Haiku contributor already. The patches are not upstreamed yet, and it currently only supports Radeon Southern Islands cards, planned to be expanded for Intel and other AMD cards in the future.

If you would like to contribute, feel free to drop by the forums, and say hi!


Southern Islands? Like on those Sandy Bridge Macbook Pros?


It refers to their HD 7000 series, the predecessor of Polaris (RX 4xx and 5xx): https://en.wikipedia.org/wiki/Radeon_HD_7000_series


The RX/R designation doesn't actually say much about the underlying architecture, Polaris is GCN 4, while HD 7000 is ... a mixture. Most HD 7000 cards are first gen GCN, though some are TeraScale 1/2, which would required very different driver support.

I guess it doesn't "matter" to consumers buying a product, but it is unfortunate how confusing the naming schemes are versus the underlying architecture. The R9/R8 cards were similarly a mixture of GCN 1, 2, 3, and even TeraScale.

(similarly, the RX 5xx/4xx series has GCN 1 and GCN 3 cards mixed in, in addition to the actual GCN 4 chips)


Thanks for the clarification, much appreciated! So it is the same mess just as with their CPU names.


It's really annoying because what you said is correct most of the time, and broadly speaking "HD 7000 is southern isles".

Except for the ones that aren't. And it's not even chronological -- the HD 7510 with a TeraScale 2 chip was released after some southern isles cards.

And there's the Radeon HD 7790, which has a GCN 2 sea isles chip.

I became aware of this because my "R9 280x" turned out to essentially be an upclocked HD 7970, using a Tahiti/southern isles chip. GPU was fine, it's just a nuisance to sift through what's what...


Thanks, I’m really dabbling in the AMD nomenclature.

Trying to discern if my gpu is better supported by radeon or amdgpu gives me headaches.



Those (https://www.techpowerup.com/gpu-specs/amd-whistler.g103) are Northern Islands (GFX4), really old stuff.


Haiku would be an OS I would enjoy running every day if there were drivers for modern hardware and it ran the software I need. I stil hope it will get to that point one day. :)


Agreed, I was a huge BeOS evangelist back when Be, Inc. was still around and a while after they were bought out. I ran it as my main OS for several years and to this day I prefer its interface, multimedia back-end, and file system to anything modern. Haiku would scratch that itch if only, as you said, it supported modern hardware and current necessary software. This announcement is one step closer to the former becoming a reality, and I'm so there for it! I feel like once it's stable enough for use as a daily driver hardware-wise, the software porting side will begin to catch up.


Yeah, I think I would too. At the very least I would love to tell Windows to shove it and have an option that wasn't as horrifically terrible as Linux Desktop.

The latter issue (software) would be mitigated significantly in my case if it had a good hypervisor and a WINE port, but the former issue seems nigh-insurmountable given the amount of hardware around today. It's really sad because it's a big reason that we don't have more experimentation in the Desktop OS space.


Haiku has less of a software problem than I expected, since Qt has been ported to it, and it has some (not the majority of) Qt apps, as well as the Qt Creator IDE. I'm not sure if Qt apps are as light and responsive as native Haiku apps though.

Unfortunately I never did find supported hardware and clear out enough hard drive space to install it (despite shuffling my disks around and losing my last copy of important files). Perhaps I could try running it in a VM, but why not use the outside OS at that point?


As usual it's a matter of what you're trying to do and how closely it matches the things the devs are trying to do. My only real attempt to use it lately was on an old eeePC I only really wanted to use for remoting into my home Windows PC and I ran into a bunch of issues with the only working RDP client (commandline-run FreeRDP). Waddlesplash even had to pick up on a post of mine here on HN and take it upon themselves to update FreeRDP to get to that point. It functions, but is seemingly unable to resize or even go fullscreen despite specifying the relevant commandline arguments, which on the tiny monitor is a problem because it leaves me forcing it to run in a less-than-fullscreen resolution that accommodates the title tab and moving it to the top-left corner.

Personally, I am not a fan of the reliance on ported-from-unix packages. Especially considering that there is currently no autoremove for the mountains of dependencies that they bring with them. If Haiku had containerization this could be more easily mitigated, but as far as I'm aware it doesn't.

> Perhaps I could try running it in a VM, but why not use the outside OS at that point?

My feeling as well.


The thing that i always found puzzling with Qt, Java, etc on Haiku is that if you are going to rely on those instead of taking advantage of Haiku's uniqueness and integrated UI approach, then why not just run Linux with a BeOS-like theme?


Haiku has good native software not available in other OSes.

Also, the performance can be much faster on Qt software. I remember some QT5 based video player playing 4k videos on an old Celeron in software while Linux wasn't able to do so even with GLX/DRI/XV acceleration.


Talking about supported hardware, I always select hardware that will run the software I want, not the other way around. When I build my desktop PC last year, it was all AMD hardware. Haiku works great on it, and with X512’s vulkan driver, I’ll even have 3D acceleration. I’m buying a laptop in 2 months, again, it will be all AMD hardware. And Haiku will run great on it. As will Linux.


>as horrifically terrible as Linux Desktop.

Obligatory defense: I refuse to believe this snipe extends to KDE on a rolling distro (e.g., Arch or Manjaro), where it's objectively a better UX than Windows.

(I stress rolling since new versions of DEs seem paradoxically better than old versions, so the versions point release distros like Ubuntu use are always crashier and buggier.)


Could it be possible to shove the linux kernel under the Haiku userland? This would give access to all drivers available in linux. You could sacrifice compatibility with the linux or POSIX userland. A bit the same thing as WSL1, but from Linux tu Haiku.


This is why I dislike Linux. Some of the policies regarding drivers may make sense, but the net result is that rather than having a lively ecosystem of free operating systems with all of them sharing decent hardware support, we have a Linux monoculture with it being the only operating system with any type of hardware support and the rest being terrible compared to it (even Windows is bad).

In part I guess it's because there is no Linus-enforced requirement to have sane specifications, rather than only code. In fact, they seem to encourage having Linux-specific drivers to the detriment of other OSes. Having non-upstream "generic" drivers is not only heavily frowned upon but also rather hard due to the constant breaking API changes. And for upstreamed drivers, you basically have to make your kernel code all but Linux-specific in order to have any chance; generic code or code that doesn't use all the specific Linux infrastructure is basically forbidden everywhere except staging/.

The lack of stable API/ABI should in theory prevent "write-once-and-forget" drivers, as well as discourage proprietary ones, but in practice we have both of these. I would really like to see how the world would look like if there was one stable, open, popular API for drivers.


This issue is not the fault of Linux but manufactures who REFUSE to release datasheets and programming manuals. Instead these manufactures "embrace" Linux (Which to them == open source) by writing undocumented drivers for undocumented hardware. So OS devs play reverse engineer and cargo cult the undocumented Linux driver bit twiddling dance routines into their driver code and pray it works.


> In part I guess it's because there is no Linus-enforced requirement to have sane specifications, rather than only code.

i.e. Imagine they just enforce that in order to submit a driver upstream you have to actually document it, so that problems can be fixed in the future.


Its a nice idea but it wont happen. A. those manufactures have zero incentive to give away their work and B. Linux is mostly used as a server/mobile OS so most people using it just want hardware to work.


It's a bit strange you blame this on Linux, instead of e.g. Microsoft.

The PC (more or less accidentally) started out as standardized hardware. Everyone could write an OS for it. Then things like sound cards, network cards, advanced video were added on top, but standardization here was incomplete to nonexistent.

All kinds if programs had drivers, e.g. games for sound cards etc. As an example, I had to install a printer driver in wordperfect 5.1, a word processor under DOS.

Windows centralized these drivers. Games could talk to the sound API. Word processors to the printer API. Hardware vendors could stop writing drivers forceach program. But note a fundamental shift here: No more standard hardware spec, only a standard driver spec.

Microsoft didn't ask for this, but didn't fight it too hard either. History accidentally gave them a moat, and they liked it. They could easily have pushed hardware specs harder, like they did for USB with HID and Mass Storage.

There is no sane need for individual printer driver, for example. A standard way to push a bitmap, to read some specs( DPI), to control buttons, toner levels and lights gets you mostly there. We would have 1 stable high quality printer driver for each OS instead of the crappy mess we have now. In fact, IPP getsvus partially there. But you need a big player pushing for it, and Microsoft has everyone working for only them right now, so why would they change anything.

Linux wrote its own drivers until it got big enough to get some love from some big hardware vendors. But I see no way for it to push hardware standardization.


Yes, that is right; Microsoft needs a lot of the blame.

But today Linux has the mantle. In fact a shitton of the Linuxisms that we have today in the embedded space (e.g. "BSP"s) come directly from Microsoft.


You're 100% correct. I'll add to that the fact that GPL drivers can't be used as-is in non-GPL kernels. It's a one-way street leading to Linux.


The GPL is a virus, by design. I'd go so far as to say if Linux didn't exist, the GPL wouldn't be so common, and we'd prefer less restrictive licenses such as those from the BSD world.


If anything, the open source movement (or the free software movement, tak your pick) would be much poorer for it, and see open source relegated to a library and infrastructure layer of the IT world. As is, with GPL at least there's a chance of having a vertically FOSS stack for hardware that's within most people's reach.


I think that perhaps pushing for drivers in userspace wherever possible would improve this situation significantly. Userspace drivers for Linux would still be built with various Linuxisms, but at least you get all the kernel specific bits disentangled which improves portability a lot and makes writing compatibility layers for other operating systems more feasible.


The alternative would be to have drivers that work against a fixed common ABI (or API, if you just want source level compatibility). Good lucking trying to get operating systems to agree on this ABI.

Linux is constantly breaking these internal APIs for a reason: to keep adding new (hardware) features, while preventing each driver from implementing large amounts of would-be-common code each in their own non-standard and slightly broken way.

That's why some types of drivers tend to be huge on Windows: they're offering functionality that the (relatively stable) driver API doesn't support. This approach requires drivers with user interfaces. Good luck doing that cross-platform.

What you're asking for is highly impractical.


There is a defunct project which did exactly that called BlueEyedOS. http://blueeyedos.com/


> Could it be possible to shove the linux kernel under the Haiku userland?

One of the joys of the BeOS kernel is that it is optimised to be extremely responsive to interactive, graphical workloads.

The Linux kernel is not.


And it's so much easier to write several hundreds of drivers for the Haiku kernel instead of one 'desktop user' scheduler for Linux.. /S


The problem isn't just a "desktop user" scheduler (in fact, I'm pretty sure that compiling the kernel with a 1000Hz tick might address that).

The problem is that the Linux GUI stack is largely corrupt beyond recovery:

- the UI is largely awful. Most distributions adopt GNOME or resort to writing their own DE if they want to achieve a particular UX end-to-end.

- the graphics stack is largely awful. X11 is bad, and Wayland is less bad but I want to see something that doesn't leave me wanting if it's the "end-all and be-all" of modernised UI stacks.

- the audio stack is bad. PulseAudio should be replaced, IMO, but Pipewire may fix this

- the graphics toolkits are bad. GTK still has the proverbial thumbnail picker missing, and QT has commercial licensing issues.

- packaging is a mess. There are at least 3 "new" packaging formats (AppImage, Flatpak, Snap), and countless traditional packaging formats. It's a nightmare for independent software vendors, who only need to produce 1 (maybe 2) binaries per any other platform.

- binary compatibility is capital-B BAD. Windows 10 can run GUI binaries compiled for Windows 95, and meanwhile Ubuntu 8.04 binaries will refuse to run on Ubuntu 20.04 unless they were statically compiled. "Don't break the userspace" begins and ends at the Linux kernel - literally everything above it, including core GUI libraries and the C runtime itself has broken old userspace usages.

The problem is not reworking a scheduler, it's reworking large parts of the desktop stack and the culture surrounding it. At this point, I'd surrender Linux to the servers and wait another 10 years for another OS to have its Year of the "X" Desktop.


Most of your points are about the Linux-distributions issues. If Haiku was built on top of the Linux kernel, Gnome/Qt wouldn't matter but Wayland and the Limewire stack would probably be reused though.


>binary compatibility is capital-B BAD. Windows 10 can run GUI binaries compiled for Windows 95, and meanwhile Ubuntu 8.04 binaries will refuse to run on Ubuntu

That doesn't matter because you can recompile all the crap you want.


Nope, you cannot. Closed-source software is as important as open-source, because some things will simply never be possible to make with an open source business model. We'll never get an open source edition of Photoshop or AutoCAD, so Linux will remain simply unusable as a daily driver to people who depend on it, hurting OS adoption.

Even if you could theoretically recompile, compiling old unmaintained code on new distributions is a huge pain. Broken/removed API calls for every external library you include will be a huge pain, because they will need to be fixed manually. That's assuming the library still exists, and you don't have to port your software to some entirely new library that suddenly means you have to restructure or refactor the entire codebase to use it.

That's not trivial. You need a programmer to do that, which is outside of reach of most average users.


Even heard of pkgsrc and the rest of the ports of BSD's?

Huge pain? You know near nil. Most patches are not that big.


Several people have tried on the scheduler front. Sometimes for more than a decade.

What it gets them is relentless hostility, contempt, and eventually deciding that it's easier to give up.

If you knew anything about Linux history you'd know that, but I guess smart-alec retorts are easier than learning.


I didn't say that it was easy, I said that it was easier than supporting all the hardware than Linux support in another kernel.. That said, there are quite a few people working on 'realtime' Linux, it has some commonalities with a 'responsive' desktop..


Well I would like to know which Linux distros I need to support and test for my GUI software to be consistently guaranteed to be ‘officially supported’ like Windows, and Mac.


So you'd be OK with no login password on your daily driver? Personally that gave me a little bit of pause when trying it out. Still haven't decided what I think about it.


It's a single user system...just like dos.


You can want a lock screen (optionally paired with data encryption) even on a single user machine for privacy reasons.


So I guess just like I did with DOS, I should design my own "FBI" faux login screen in Lazarus, or some other RAD equivalent of QuickBasic? :-)


You could help integrating full disk encryption, and a login screen. :)


I'm curious, is a native login screen desired by project developers? I was under the impression that it wasn't, so much.


It's just that no one got around to that yet, also a login screen without disk encryption does not mean much. For reference, there's a drive encryption[1] implementation on alpha status, but it needs to be merged and reworked into the system.

[1] https://github.com/axeld/driveencryption


I have to wonder how supporting RISC-V and amdgpu does not count as modern hardware.


The goalposts of ‘modern hardware’ and ‘modern web browser’ will be moved forever with HaikuOS on HN, even when it can apparently run on real RISC-V hardware with a GUI, has a Chromium-derived Web-browser and now is about to get 3D HW acceleration via amdgpu.

When compared with other certain unified hobby OSes out there written in C++ or Rust, they don’t even come anywhere close to being useable. Not even a complex browser or office app running. They are still stuck in a VM and yet celebrated here even when this OS is able to run all of that on real hardware after installation.

If RISC-V is not modern hardware, then I don’t know what is.


In that case you better start lobbying your software vendors for Haiku supports.


> drivers for modern hardware

How well does Haiku work on bare iron nowadays? Any tested laptops - better, any repository of tested brand/models, or of tested hardware in general?


I've had the best luck with older "office PCs" like HP EliteDesk/ProDesk series and Dell Optiplex machines. They tend to standardize around the most common denominator components like Intel or Realtek Ethernet NICs and Intel iGPUs and nothing too esoteric. Laptop support has gotten better recently, with many Thinkpad models from the past decade working more or less 100% out of the box in my experience.

My biggest issue running Haiku bare metal has persisted across hardware and form factors though: Stability. I can't seem to keep a machine running for more than a few days without a kernel panic or a frozen GUI. I haven't tried the latest snapshot on my "newest" acquisition, a Haswell era HP EliteDesk castoff from work, it's my project for this coming weekend and I'm looking forward to seeing how long I can keep it running.


If you can so consistently reproduce kernel panics, it would be good to open a ticket. However, that has been less and less of a problem in recent years, and a lot more panics were squashed in the past few months, especially USB related ones. So you might try a nightly build and see if things are improved; if not, please do open a ticket.


It was indeed on older official releases on those older machines, I never got into the nightly builds that much. I will try both the latest release and latest build this weekend when I work on the new hardware, and I'll report any showstopping bugs.

Now that I think about it, it definitely could be USB related on those other machines too. I've used the same cheap USB KVM for years and it has polling issues in Windows 10, I didn't even consider that might be the source of my issues elsewhere. I'll try it without the KVM and see what happens. Thanks!


I tested R1/beta3 on an old NUC. I can't remember if BlueTooth worked, but everything else was supported, including the wireless NIC.

Note that the wireless only works if you do an install, the live-cd won't be able to use the wireless driver for some reason.


I ran it briefly on a laptop (thinkpad) and it worked remarkably well; the only real issue was that Haiku really needs mouse and that model's inputs were kind of awful


Anecdotally, when I tested it on an old ThinkPad last year, it worked fine. I was really impressed.


BeOS is older than Win 95 so I have my doubts.


Minix is even older than Windows 95. Does that mean Linux does not run on modern hardware?

So Linux is Minix then?Where does it say that Haiku is BeOS?


Still no Raspberry Pi images, though. Massive missed opportunity, I think.


While I understand the disappointment regarding new platforms and hardware support, current number of Haiku contributors is relatively small considering the list of things to attend to. Please consider contributing, every small bit counts: https://www.haiku-os.org/community/getting-involved/


It's opensource though, I'm certain they would accept your contribution if you port it.


I wonder if a Raspberry Pi port would be a "low effort" way to attract more developers.

I'm not claiming that such a port would be easy, but that the Raspberry Pi represents a relatively stable platform. Rather than having people turn away when they discover that component X of their PC is unsupported, they have a path where they can boot the image, try it out, and learn how to develop software for it. While this probably wouldn't address the issue of kernel/driver development, it may help to address application development.


Current ARM porting effort can be tracked from this forum thread: https://discuss.haiku-os.org/t/my-haiku-arm-uefi-port-progre...


Don't complain. Send patches.


I don't interpret parent's post as a complaint so much as an observation: Raspberry Pis are incredibly affordable little computers that are seemingly a good fit for Haiku since they have relatively little diversity of hardware to deal with (outside USB devices of course), would benefit from a less bloated Desktop, and little otherwise is expected of them. Lots of people have various Pi models laying around in want of something to do with them, and lots of people would like to play with Haiku outside of a VM, so I agree with parent that it seems like a missed opportunity.


I think its very disingenuous to call the lack of hardware support a "missed opportunity". There is a Pi port in progress but the Pi as a platform outside of Linux is a mess. Its not a well documented SoC and does weird stuff like boot via the GPU using a binary blob and other proprietary crap. It also has a different DMA architecture so drivers developed originally for PC hardware need to be modified. Ironically its a not very open source friendly SoC.


As both a Haiku and RPi fan, I agree they would be a great combination. RiscOS has run on the Pi since the first model, and if that combination's performance is anything to go by, Haiku would likely run circles around Linux on Pis.

The problem, as others have said, is the lack of dedicated manpower. This is one of those situations where I wish I was a developer, I'd dive right in and try to get Haiku to daily-driver stability on the platform. There is work being done on porting to ARM already, and my hope is that as the X86/64 platform matures, focus can shift to ARM and the Pi specifically.


Not everyone is a programmer.


They're smarter by focusing on RISC-V imho.

The future, rather than the past.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: