ATTENTION! All this is done only for developers and hardcore users! You can use all this at your own risk! No one is responsible for the loss of information due to this. Team Haiku does not provide technical support for this outrage!
HAKILO (ex HUPE) v.2019019 by s40in
HAKILO is a common name for a set of programs and scripts that make Haiku more similar to BeOS: it disables the package system and unpacks them into the system.
If you don’t need it, you can close this web page
Components
hakilo_installer4anyboot-1.0.1.zip - scripts for make Haiku anyboot image
hupe_engine - Outdated scripts, but it works. It will be replaced by HakiPKG (coming soon…)
Why do you need it?
Full disk access and all system files (easy to remove/replace libs, drivers, kernel !)
Easy run old BeOS software with old path (you can easy create needed folders and symlinks)
Consumes less RAM, useful for virtual machine
You kernel developer
You crazy haiku user
Is it a Haiku fork?
No. Not planned soon. But it is planned to improve and increase functionality. If you have any ideas what to add or change - write to me.
HAKILO are just addons and tools for OS Haiku that change its work. It’s like Norton Utilities for DOS: D
Can I install Haiku packages? This is the old way, but it works. Soon to be new
Yes. Manual only. See scripts in Terminal “hupe_*”
hupe_package_install.sh - for install one HPKG
hupe_package_installall.sh - for install all HPKG from folder
Can I use HaikuDepot for install application?
No, only manual install from terminal
Can I convert my Рaiku to a HUPE?
Yes, but you will need another Haiku (on another disk or usb flash drive) to run the script. See the script hupe_convert_Haiku2hupe.sh
How to install?
Easy unpack hakilo_installer4anyboot-1.0.1.zip to Haiku anyboot image.
When unpacking, no files are replaced with the ISO image. This was made possible thanks to the excellent Haiku package manager with ‘blacklist entries’!
Install use USB flash disk
Write Haiku anyboot image to USB flash
Unpack hakilo_installer4anyboot-1.0.1.zip to USB flash
Install use ISO image (for VirtualBox or burn to CD disk)
Register Haiku anyboot ISO in diskimage (Terminal app).
Mount Image in Tracker (default path /Haiku1)
Unpack hakilo_installer4anyboot-1.0.1.zip to to /Haiku1
Unmount image in Tracker
UnRegister image in diskimage
See pictures about it.
So, this essentially “locks” your Haiku system at a specific hrev, and makes it impossible to upgrade, downgrade, install, or uninstall packages (well, I guess you could install packages, but you would have no way at all to upgrade and certainly not to uninstall anything.)
Maybe it’s useful for certain development or testing purposes; otherwise I don’t know why it’s useful…
This distribution violates the Haiku trademarks. Expect the Haiku Inc. asking you to remove them from your image.
Maybe you could offer a script that transforms a regular Haiku ISO into this unpackaged state instead.
Great work…
Maybe some hard core developers can use it?
For me l am a Hardcore User… I need HaikuDepot and its unique install/uninstall feature to become happy…
But amazing to see someone is bringing back old BeOs feelings…
ahm… I dont miss them…
So, this essentially “locks” your Haiku system at a specific hrev, and makes it impossible to upgrade, downgrade, install, or uninstall packages (well, I guess you could install packages, but you would have no way at all to upgrade and certainly not to uninstall anything.)
Not very difficult to make a script to remove the package. Also with online updates.
This distribution violates the Haiku trademarks . Expect the Haiku Inc. asking you to remove them from your image.
Maybe you could offer a script that transforms a regular Haiku ISO into this unpackaged state instead.
Did not think about it. I will delete the link. Let someone need it - he will do it himself.
Yes, humdinger is correct; distributing builds with the Haiku logo and name is indeed a trademark violation. You would have to re-brand the system in a similar way to what Haikuware did for “Senryu.”
No, it would be indeed difficult to make such a script. There are a variety of files/folders that “conflict” with the current PM model, e.g. the mime type folders, in which one package provides the real directory attributes and the directories from the other packages are not used, only the files they contain are.
Thus when one uninstalls the package that is providing the directory attributes under the present model, the “next highest priority” package will now provide those directory attributes. But you would have to re-evaluate all packages, or store some database, without the filesystem-based PM system in order to do the same; and this would either be impossible or extremely inefficient.
This is only one example of problems that our PM model solves that you would not be able to handle with a file-based system. Not to mention the other features: old states + blacklisting from the bootloader, etc.
Well, the only possible use I see is as a benchmark to see how much work we still have to do on making the packagefs faster. I don’t want full access to the disk, being able to reboot my system to a sane state no matter what I try saved my life several times (and I missed the feature a lot in the past). I’m not looking back
The technical experiment is still great and shows the modularity of Haiku
Cool effort! Soon as I saw this I thought of BeOS Max, BONE, or the other cool stuff of the past.
But, I totally agree with the others in the thread. To make a ‘legal’ distribution, you will need to remove the Haiku name and logo to make the distribution. Namely, the logos and wherever it says Haiku in the image, including the Haiku leaf logo. I’ve created a distribution of Haiku before, and would be willing to help you with this if you have a hard time navigating C++.
Once it’s ready to present, send me a link, and I’ll review it on the OS Voyager (as part of the current BeOS series I’m doing).
I’m struggling to find a reason as to why I would need to use this except for running very old closed source BeOS apps (Might be useful for some but not me). But I just disagree with this reason:
What do you do when a critical component (kernel, runtime_loader, libroot) prevents the OS from booting to the desktop?
There doesn’t seem to be a way to ‘roll back’ anything with HUPE apart from booting the live USB and copying the affected files back again, which in my opinion is less intuitive than the packagefs solution. Many times I have to test certain wifi drivers or replacing libroot when doing porting work or even using the package blacklisting feature does the trick. I agree with PulkoMandy on this.
While your efforts in creating HUPE for other developers are really appreciated, I don’t think I’m convinced on this.
This is more BeOS like Haiku!
This is must be the option in main Haiku!
I hope main Haiku developers will accept this great work.
If not, then distro already can have a name, the name OBOS (OpenBeOS).
