Try this font:
I just like the font…
Try this font:
about the icons written in the source file /data/artwork/ReadMe
Unless specified otherwise, the other graphics (for example, cursors/,
icons/, boot_splash/splash_icons*, …,) are released under the MIT license.”
But now it is not so important I can use almost any font, for example PT Astra Sans
I wonder how much code needs to be change and how much compile time it would take to run a test on this. As in having to recompile all the OS source, one core package, or… what.
Because I’m always interested in less ram usage, even if you have more to spare, may be brave enough to test in vm machines without consequences if crashing the system.
Great work with the new name, styling, and font change… but maybe not all capitals would be a suggestion? Personally (just my opinion) I think it still looks similar to the HAIKU boot splash — just trying to be helpful
Again, if you need help changing your visible labels over to Hakilo over the original let me know. From experience, I can say that part is harder done than said; for example, the disk label defaults to “Haiku” in DriveSetup and the mount dialog, appearance preferences, boot manager, etc. all reference Haiku directly as well.
If you are using the HaikuDepot, that’ll need to be changed over as well. Probably packages should still retain the Haiku in them though for package compatibility reasons if you’re keeping packages in Hakilo. Hope this helps!
I like the name HAKILO, but remove the icon AX, is my opinion.
I think Hakilo means ax in Esperanto; it’s most likely where the ax comes from.
This is indeed true
I remember your proposal and I will be very glad to any help in this work.
It is not yet time for a separate distribution, a little later.
There are a few ideas that I want to test before this. Not just a package manager
This is what I thought, but didn’t have time to double check. Just making sure bases are covered.
I changed the first post according to the new name and ideology.
Added package to create an installation disk. Now it is very simple and easy. No files are replaced. Thanks to the blacklist features.
Download hakilo_installer4anyboot-1.0.1.zip for make your installation boot image
Read the details in the first post.
Any possibility to uninstall the packages in HAKILO?
The point of the whole package management system is to handle uninstalling packages cleanly. So if you remove the package management, you are on your own. You need to manually track the file (from package list) and delete them, making sure that none of the files are also provided by another package. This is scriptable, if you really want to do it.
Not now, but soon to be possible.
Already now during installation, hakilo script save information about installed packages and files list.
You’re right. A new script for installing (unpacking), removing packages will be made soon.
Before unpacking there will be a check for the presence of already installed files with the same name.
So you, @s40in, try to recreate the package management in Linux way - with resolution of dependences, functionality providers, auto-installs and auto-removals, different versions of the same library and so on, which is named “dependency hell” in short.
When the package management was developed in Linux, its complexity was under-estimated and it took several years to create fully working infrastructure. If I remember correctly, it was
.deb packages with
dpkg as installer / uninstaller and
apt as dependency resolver, they were developed from 1993 and something working appeared in 1996. I wish you all the best.
Not certainly in that way. It seems to me that Haiku / BeOS does not need a package manager. It’s easier for me without it. I want to control everything that is installed. Dependencies are not always good.
A simple example: I can’t remove the noto_sans_cjk_jp package from Haiku. The package weighs 100MB and I do not need the support of these languages. Does Haiku suggest I just remove everything? I don’t need such dependencies!
The delete list is even bigger, it just did not fit!
I like installation:
- through zip archives (just unpacking to a folder)
- maybe install.sh script
- your graphical installer
- unified package (with a choice of options) like PKG type from BeOS
- installation by moving the app folder, as in MacOS using a dmg disk image, or in RISC OS
If I wanted a completely different package system, I could port deb, rpm, etc. But it seems to me that this is not necessary.
I do not need Haiku as “other linux”.
Therefore, what I will do for myself will be simple installation / removal of Haiku-HPKG packages.
Maybe the dependencies will be “optional”, only to make downloading easier.
Asli it will be necessary for someone other than me - great.
If it will be necessary only for me - also good
I also wonder why noto_sans_cjk_jp is a hard dependecy on haiku package and not just a supplement which is installed by default but still can be removed.
AFAIK, there is only one possibility to “uninstall” some package without package manager if you already lost track of all its files: reinstall the OS and all software you need.
Basically this was the BeOS way, only each “package” was actually a folder with all its files inside. This way there is difficult to reuse the functionalities of one package in other (dependency).
Linux way of packaging differs from one distribution to another.
- Slackware way is basically to use
*.tgzarchives for files necessary for some package and simple unarchive them. Removal and dependencies are at your own.
- The next generation is
*.rpm, which keeps track of installed packages and files they own and can remove them as uninstall process. Again, no dependency resolution in any way.
- The true package manager with resolution dependencies was firstly provided by
I understand you are not going to implement the 3rd solution, but which of the first two are you going to provide?
I have written simple scripts to install, remove, and list packages.
There is no check for package versions yet. Files are overwritten during installation if they exist.
I will add features later.
Already now it can be used.
The main script -
Info about installed packages saved in folder
If interested, then look at the screenshots.
List installed packages