Reading posts like this makes me really want to learn driver/kernel development.
I’ve collected about a dozen of random laptops and computers,where I could test all types of different hardware and make sure that all of them work perfectly fine with Haiku.
Unfortunately I know nothing about drivers,so those laptops that don’t already work good enough with Haiku are just collecting dust here
Maybe the day will come that I start doing something with them…
No, and some people have succesfully done that. The people who got banned were banned because they were insulting, accusing the Haiku developers of incompetence, and getting in the way of any discussion to improve the performance of package management. Indeed, once they were gone, developer could focus on the actual problems, and memory usage for package management has been greatly reduced.
It is not that much different from regular application development. If you are familiar with the api to access a file (open, close, read, write, ioctl), a driver is essentially implementing these. Then there is the hardware interface side. The hardware will typically be memory-mapped, so you just get some pointers to its data structures and read and write things there. Iterrupts are just callbacks that are called when the device has finished some task and needs some attention.
The hard part is finding accurate documentation on how to program the device. Some vendors do better than other.
And then there’s hours of headscratching when things doesn’t work, because the device can be a bit of a blackbox. What did you do that it didn’t like? Is it a bug in your code, or is it an error in the documentation?
I’m probably misunderstanding you, but you can load the hpkg into Expander and extract the contents to /boot/config/settings/non-packaged. Everything there will be writable and automatically get precedence over the packages in /boot/systems/packages and you can customize and experiment to your heart’s content. Dunno if that would work with the really basal packages like haiku-r1~b5_hrevXXXXX, though.
Getting this possibility as a one-button option in HaikuDepot would be cool, though we’d probably have to hide it under an Advanced setting to avoid confusing newbies.
Disadvantages of a virtual file system compared to direct writing to BFS:
-
Reduced flexibility — everything is read-only; repackaging is required for any modification.
-
More complex and slower startup — many packages need to be mounted, increasing CPU and RAM usage.
-
Limited BFS attribute and index functionality — query and attribute searches work only on real files.
-
Less transparency — virtual files can confuse older tools and users.
-
More complicated update management — even minor fixes require rebuilding the entire package.
-
Compatibility issues with older BeOS applications.
-
Potential security risks if someone gains write access to the packages directory.
-
Additional complexity in the system directory structure.
-
Disk space duplication — While .hpkg saves space centrally, native non-packaged applications duplicate libraries because they cannot modify system packages.
At least half of these arguments are false.
Slower startup: not true because compressed, linear packages reduce disk io compared to random access to many tiny files.
Attributes and queries: fully supported by packagefs. Otherwise the system wouldn’t boot.
Update management: the package manager ensures consistency and makes sure you won’t completely brick your installation with a misguided change. Non-packaged directories are available if you need to change just one file.
Compatibility issues: I have yet to find a single example of a BeOS app that would have a problem with this. Remember most of them install in /boot/apps, not /boot/system/apps, so they are completely outside of package managed directories. Despite people repeating this complaint over and over again, no one has actually eâer reported one single BeOS app affected by this.
Security risk: I don’t even know what you mean. People who have write access to your disk can install stuff there. It doesn’t make a tiny bit of difference wether there are packages or not. In fact, one of your previous points says packages make the system harder to modify, so you are contradicting yourself.
Duplicated space is also wrong because non-packaged apps can use packaged libraries just fine. If they ship duplicate versions, it’s a problem of badly set up software that, coincidentally, chose not to use the package system. So, this point actually says packaged apps are better.
Because LLMs can quickly fall into making things up if they lack information on the topic asked.
As far as I remember, there was someone who did exactly this, a few years ago. I can’t remember how the project was called, but you should be able to find here on the forum.
My first Haiku install only used the onboard CPU and Graphics card. The rest including Haiku was all on USB. If you can put up with that (and lesser performance than high performance internals) it lets you use most machines and without any real smarts. Often you get the USB equiv for a few $.
Driver Kernel development is wizardry, so if you can learn how to do that it would be brilliant. IMHO it is hardware drivers that will hold Haiku back for general purpose adoption. You are right, I must try out my printers and scanners to see what Haiku does with them, otherwise I have been lucky in getting devices operational, that a 1990s OS would recognize (touch screen was unexpected). The low performance cheap AliExpress USB devices are often just that
No, it is not. It is not harder than any other area of software development. The exact same rules and knowledge apply. The “wizardry” myth is pushed by elitist people who for some reason want to feel superior to other with their knowledge, or justify obsolete software practises under the false pretext that their case is special and different, and software engineering best practices somehow don’t apply to it.
I think that is not acceptable. If your driver code is well architectured, documented and commented, it reads like a book and is very clear. Just as any piece of software should.
There are tricky parts for example when the hardware is not documented or misdocumented, but that can happen with anything else as well (file formats, RESA APIs, …). There is no reason driver developers should accept that as a fatality inherent to this specific task. They should instead complain to hardware manufacturers, just as other people do when the API they use does not behave as expected.
I checked out the links @s40in Hakilo. and everything seems to be dead. Shame as there was other stuff @s40in had made available also. His themes looked nice.
I do not think HUPE is something I would need, nor to restart that interesting thread here
I think if you look into more fancy parts of a kernel, you might find a combination of concurrency + careful resource management + shared mutable state + realtime requirements, and this combo is not exactly easy to work with.
This said, drivers should be much more straightforward to write.
Maybe that repo could be mirrored into HaikuArchives, just in case?
Heh, I can attest to that! Even a dummy like me has had moderate success writting some (admitedly simple) drivers for some of my (admitedly not too complex) hardware. And my brain is not even that fully functional
Sure… the more complex stuff can feel quite overwhelming though. Being patient and persistent helps a lot. Wish I was more of both of those things.
My point is… I pretty sure many people on this forum could do great job in kernel/driver development, if they just gave it (and themselves) a (persistent) try.
Even if you don’t become a “wizard of driver development”… you still can help fix bugs in (or otherwise help improve) existing drivers. Again… even I’ve done a bit of that. I bet lots of you can do much better if you just tried!
IMO, Haiku is one of the easiest OSes where to get started with “drivers hacking”.
Edit: having said the stuff above… man… some skilled driver programmers DO look and feel like wizards to me!
I could not get that repo to load in HaikuDepot (maybe I just didn’t do it right). There are direct links elsewhere dead also, so I think unless there are existing copies or @s40in re-engages it is one for Haiku/BeOS archaeologists. Most developers here will probably say that is a good thing if you read the thread
Personally I was interested in seeing how he had “improved/updated” the look and feel of Haiku, but there was Free Pascal stuff also.
Thanks @Michel for that hint. I will use it to see if I can work around the Community sound_community.hpkg issue being in /system/data/sounds/ , and make them readable by like Sounds expects
Initially I was frustrated by being unable to mess about and fix it where it was. This thread has helped me “see the light” and why I don’t want to be doing that

I could not get that repo to load in HaikuDepot
I’ve linked to a source code repository, not to something one can add as a Haiku Pakage repository. (“repo/repository” can mean many different things in different contexts, causing confusion ).
I meant to link it as “not all is lost, here’s (some of) the code still” (and apparently there’s even a recipe on HaikuPorts for hakidecors, but not .hpkg available on repos ATM… haven’t looked further at it yet).
Awesome @ BiPolar. All was going well following Building packages with haikuporter | Haiku Project until my cloning of HaikuPorts kept crashing
~> error: RPC failed; curl 56 Recv failure: Connection reset by peer
error: 2078 bytes of body are still expected
fetch-pack: unexpected disconnect while reading sideband packet
fatal: early EOF
fatal: fetch-pack: invalid index-pack output
url 56 Recv failure: Connection reset by peer
error: 2078 bytes of body are still expected
fatal: fetch-pack: invalid index-pack outputing sideband packet
It repeats at the same point. I suspect it is my terrible and slow WiFi connection, so will try again later.
I still have some of @s40in decors (binaries) working on a VM of Haiku nightly if anybody wants them:
These are the window decorators that are working for me:
- Haki2
- HakiCDE
- HakiNSDecor
- HakiWarp4Decor
- HakiWin16
‘HakiWinXDecor“ is not working for me.