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.
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.
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:
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.
There are significant difference that with packagefs packages are not extracted, but mounted. It ensure package contents integrity and reduce file system pollution.
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.
“just don’t build broken packages”
Hold on, threats? Developers got threatened over a package manager?
See the nasty bebits/haikuware battle history… that is probably what he is referring to. (or save yourself the mental strain and don’t lol).
For system that installed for a long time, it is unavoidable that some package contents corruption will occur for various reasons. System will degrade and bitrot as packages get installed/uninstalled/write config files etc… packagefs ensure that package contents will remain consistent and allow long life of single OS installation.
System degrade over time is real problem for Windows and Linux. System become slower and various errors accumulates. Also malware may alter installed package contents.
A threat to fork the OS, not a personal threat.