I think on similar approach. Haiku already has (please, forget my ignorance) some sort of virtual file system, which presents *.hpkg file content as regular files in read-only directories. If there is a clear 1-to-1 mapping between old pre-packagefs directories (which are read-only now) and new ones under non-packaged, and if the system already treats the new writable places with greater priority than read-only ones, then Haiku can treat this non-packaged directories as some sort writable extension for read-only packagefs folders at system level. I mean, any application which tries to write files to packaged read-only directory will be redirected to corresponding non-packaged writable directory.
That was the initial plan, but we could not implement it without a big performance drop on filesystem access. This is why we introduced the non-packaged directories.
the game Robin Good demo doesnāt work
haiku beta 2, 32 bit, 117
~/apps/Games/RobinHood> cd lib
~/apps/Games/RobinHood/lib> ls -la
total 24
drwxr-xr-x 1 user root 2048 Jul 25 19:10 .
drw-rār-- 1 user root 2048 Jul 26 14:17 ā¦
lrwxrwxrwx 1 user root 42 Jul 25 19:10 libfreetype.so -> /boot/system/lib/x86/libfreetype.so.6.16.1
lrwxrwxrwx 1 user root 41 Jul 25 19:08 libSDL.so -> /boot/system/lib/x86/libSDL-1.2.so.0.11.4
lrwxrwxrwx 1 user root 32 Jul 25 19:07 libstdc++.r4.so -> /boot/system/lib/libstdc++.r4.so
lrwxrwxrwx 1 user root 35 Jul 25 19:06 libz.so -> /boot/system/lib/x86/libz.so.1.2.11
~/apps/Games/RobinHood/lib> cd ā¦
~/apps/Games/RobinHood> robin
runtime_loader: /boot/system/lib/x86/libgcc_s.so.1: Could not resolve symbol āpthread_cancelā
resolve symbol āpthread_cancelā returned: -2147478780
runtime_loader: /boot/system/lib/x86/libgcc_s.so.1: Troubles relocating: Symbol not found
You mixed GCC2 and GCC4+ (located inside x86 folder) libraries that have incompatible ABI. You probably should not use libraries from x86 folder.
ok, changed libraries
~> cd /boot/home/apps/Games/RobinHood
~/apps/Games/RobinHood> cd lib
~/apps/Games/RobinHood/lib> ls -la
total 22
drwxr-xr-x 1 user root 2048 Jul 26 15:08 .
drw-rār-- 1 user root 2048 Jul 26 14:17 ā¦
lrwxrwxrwx 1 user root 38 Jul 26 15:08 libfreetype.so -> /boot/system/lib/libfreetype.so.6.16.1
lrwxrwxrwx 1 user root 37 Jul 26 15:06 libSDL.so -> /boot/system/lib/libSDL-1.2.so.0.11.4
lrwxrwxrwx 1 user root 31 Jul 26 15:04 libz.so -> /boot/system/lib/libz.so.1.2.11
~/apps/Games/RobinHood/lib> cd ā¦
~/apps/Games/RobinHood> robin
runtime_loader: /boot/home/apps/Games/RobinHood/robin: Could not resolve symbol ā_t24__default_alloc_template2b0i0._S_free_listā
resolve symbol ā_t24__default_alloc_template2b0i0._S_free_listā returned: -2147478780
runtime_loader: /boot/home/apps/Games/RobinHood/robin: Troubles relocating: Symbol not found
~/apps/Games/RobinHood>
default_alloc_template seems to be non-standard STL extension: https://www.rpi.edu/dept/acm/packages2/stl/stl_alloc.h.
// Default node allocator.
// With a reasonable compiler, this should be roughly as fast as the
// original STL class-specific allocators, but with less fragmentation.
// Default_alloc_template parameters are experimental and MAY
// DISAPPEAR in the future. Clients should just use alloc for now.
Does RobinHood works on BeOS? It was released for Zeta, as far as i remember.
I see, thanks.
Please give me Feedback if it is not running any more.
non-packaged already broke many thingsā¦ better to unbreak it with some interim breakage.
A read only packaged directory makes infinitely more sense than a non-packaged read writeā¦ and would have been forwards compatible with all BeOS software and paths.
Sighā¦ in any case Iād have preferred no packagefs at all. And a frontend for Archās pacmanā¦ instead of insisting that we could fix package management with something ārevolutionaryā that has instead segregated developers and users of Haiku.
That said the original BeBox PPC hardware can in theory handle up to 1GBā¦ of ram. Probably 256MB without too much issues. So, it should be possible to get Haiku workingā¦ even if its slow.
Iāll think of this statement every time I have to update any computer that isnāt running Haiku.
Given that Linux distros have only in the last couple years started getting into immutable systems, Haiku has actually been well ahead of the curve!
Why that dislike against packagefs?
Maybe itās not perfect and also has its negative effects,but Iāve used a lot of different operating systems now and on Haiku,installing and updating packages is the fastest and the most reliable solution Iāve seen so far.
Yes,Solaris IPS is also quite good and the BSDs universal āpkgā command is worlds better than the endless mess that is Linux,but none of them can compete with the speed and reliability of Haikus packagefs/pkgman.
3 Likes
Not sure how to interpret that, Iāve had just as many package management related problems and breakages on Haiku as anywhereā¦ and the others at least donāt also have a runtime overhead too.
Last I used pacman on Archā¦ it was at least as fast as Haiku (acutally iāve used a fork of Arch recently and it still appears to be just as fast). The main drawback with arch based distros is they dontā have a stable tree.
What Iād have like to have seen is ZFS or a ZFS like FS on haiku optionally for heavier hitting PCs , and retain the ability to use BFS or the like on slower PCsā¦ with snapshots so you could roll back updates. And a simple conventional package maanger.
Haiku has installations that are atomic, take no time, and system updates are just reboots without the possibility of an inconsistent system state.
After destroying my system countless times with āconventionalā package managers Iām really sick of them. (especially apt-get, dpkg)
ZFS is nice, but unsuited to Haiku with itās RAM requirements. Haikus packagemanager achieves the same as FreeBSDās boot enviromemts in a much simpler way, which is fine.
Why do you need snapshots for BFS? you can already roll back updates, or more precisely just boot an eatlier state.
4 Likes
ZFSās ram requirements are really no different than Packagefsāsā¦ youāll find recent versions of ZFS sip ram. Comparatively at leastā¦ and the point was to retain the ability to run on conventional FS.
You mean software that expects to run from /boot/beos? Because we stopped using that path YEARS before we did any package management work. I think you are blaming problems on package management that it, in fact, didnāt create.
So, you can try this:
ln -s /boot/system/non-packaged /boot/beos
and happily move on with your BeOS apps. If they are not broken by other problems, that isā¦
In any case, I will once again renew my offer to personally investigate problems in BeOS apps that have stopped working because of PackageFS. I think I got exactly 0 reports so far where the problem was actually packagefs. You may instead find one of these:
- The way keyboard events are handled has changed, meaning some apps will lose keystrokes because they did not forward BMessage to the BWindow default handling code
- BBitmap::ImportBits was changed, to fix the BeOS app spirograph, but in doing so it broke several other apps
- We donāt implement BeOS R5 style net_server, so you have to find apps built for Bone instead if there is any network involved (not so moch of a problem, pretty much everyone had migrated to Bone when it became available)
- Apps hardcoding paths to /boot/beos (NOT /boot/system, which didnāt exist on BeOS)
- Your app is actually not working on BeOS either, it is built for an older version of Haiku or for Zeta
- The app is just broken and the bug also existed on BeOS or it worked there by accident (for example, use after free or buffer overflow, that on BeOS happens to not overwrite anything important but on Haiku it crashes)
Anyway, I donāt think we should re-have the debate about the package manager AGAIN. We did that a thousand times already. We know no one will change their mind. We know you say āusers vs developersā but in reality it is āa small number of users vs everyone else who is very happy with the current situationā. We also know that despite threats and heated debates and so on, no one actually ever started an Haiku fork removing the package manager, or the people who did did not actually maintain it for very long, showing, I think, that there isnāt that much demand for it.
5 Likes
There are significant difference that with packagefs packages are not extracted, but mounted. It ensure package contents integrity and reduce file system pollution.
1 Like
And instead you incur runtime overheadā¦ for a feature that shouldnāt be needed with properly packaged packages.
Haikuās ports system itself should be preventing that at package built timeā¦ not at installation or runtime like we currently do with packagefs.
This is the sort of mind set that resulted in garbage collected language like Java (being terrible) and most of that getting backtracked with modern compile time checks in safe languages.