💾 Archived View for dioskouroi.xyz › thread › 29390689 captured on 2021-11-30 at 20:18:30. Gemini links have been rewritten to link to archived content
-=-=-=-=-=-=-
________________________________________________________________________________
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.
https://en.wikipedia.org/wiki/Radeon_HD_7000_series
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?
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.
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.
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.
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.
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.
> 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
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.
Why linux advocates are like "Oh, here is a nice alternative OS, lets tamper it with linux, because everything is better with linux!"?
Stop wishing others to change, start change linux instead. And yes, you can use Haiku kernel with gnu userland, so there is no big roadblock there. Good luck.
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.
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?
Which is relevant because?
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 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
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.
Anecdotally, when I tested it on an old ThinkPad last year, it worked fine. I was really impressed.
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.