Moderators, can’t we close this? I’ve got a feeling the multiple requests for hard data to back up the claims that are made are not going to be answered 
8 Likes
This is EXACTLY the kind of behavior that runs people off if the forum.
The topic I was referring to is already linked here… and the only people demanding data are putting words in my mouth.
1 Like
Why close anything? Just don’t respond or don’t read the thread. Some of us want to read, and as long as there is no threatening or harassing, just ignore it.
Various Haiku users will have various opinions. I don’t see the use in closing threads.
1 Like
You’re of course right on here, that´s what I try to do anyway.
Looking at the bigger picture, it is just slightly annoying that quite a number of threads in this forum turn into random contradiction contests, about things often not even directly related to Haiku. If you happen to enjoy that, well, good for you, most of these threads stay open anyway.
2 Likes
If you want a thread closed use the flag icon on the last message on the thread and then select “something else”
You can then write a message to the forum moderation directly.
1 Like
I think we better leave the flagging system for actual abuse and other inappropriate stuff. Which didn’t occur in this thread so far. As explained in my previous comment, I was simply questioning the usefulness of back and forth arguing without any visible progress.
But it’s all good. The community is of course free to continue as long as they want. But at least for this thread, without my further input
2 Likes
Closing a thread, splitting one is a moderator action. If you want that to happen just flag the thread.
Asking for it as a message just leads to people discussing it and moderators maybe not reading it at all.
Yes, especially because there is some automatic moderation in place: if a lot of people flag a post, it is automatically hidden without the moderators having to do anything. We can undo that automatic decision, but it is just extra work.
The best thing to do if you want a thread to stop running is… stop replying to it. Let it sink way down in the forum, where no one will find it. This one would be forgotten already if you hadn’t replied with a request to close the thread
2 Likes
You’ll find that is not the case… it definitely not random. The non-packaged folder nonsense , lack of access the filesystem at a developer level by default as was always intended for BeOS as a power user operating system, and overhead are all real things.
What you actually have is some specific people getting petty and apparently personally offended that people that some people that use Haiku dislike how things were done during the package management phase.
There are actually quit a few positive discussions and effort poured into trying to make it palatable from this perhaps as well as personal drive of the developers of course…
I think the haiku package management is one of its greatest features. Immutability is all the rage these days, haiku did it before anyone else 
2 Likes
Haiku’s packages not 100% immutable. A virus or script can extract, modify, repack and replace the packages on your system, or simply override some files with a new package.
1 Like
That is true, haikus security architecture is unfortunately more none existent than lacking, I woul highly recommend OpenBSD or qubes to anyone who is concerned about security
All dubious claims. It might be faster than the old method but other implementations of package management don’t do that at all and are also fast while being relatively simpler.
In fact my experience is that package downloads on Haiku are exceedingly slow (is this some network kit issues)? And that package installation is even slower than Linux… and prone to hanging.
A always wonder why Linux do all that stupid work on extracting a lot of small files on install that can take near a hour while Haiku installation complete with a few seconds.
It is caused by limitation of TCP implementation so window size is too small by default and can’t grow, so transfer speed decreases with ping time growth.
One would also wonder why Haiku spends the CPU cycles to extract the same files every time they are read instead of just reading them from SSD… its a trade off. And the hour long Linux installs are typically full of a lot of bloated software Haiku doesn’t have either. I tend to take Arch’s Pacman or the like as a reference for a good efficient package manager, while APT and YUM are kind of insane.
Meh, its a tired topic though… the other things discussed here so far are more interesting at least as some of them could get adopted and improve haiku.
Boot time is also slower due to the packagefs implementation.
So, that needs to be fixed right?
My ping to ping https://eu.hpkg.haiku-os.org is around 108ms which does seem fairly high but imagine how bad download speeds for Haiku packages would be on say hughsnet satellites etc… that has ping times around 600-1200ms.
Oh, so that’s why my package downloads are always at around 200-250 KB/s despite network bandwidth and conditions; I’m just always geographically far enough from the repo server for the bandwidth to never be fully saturated.
Yeah I think something is still a little wrong because even with the long pings it should still be going faster… eg I can download a Debian ISO in firefox on Windows from france or denmark at around 8MB/s while Haiku is going much slower than that around 250KB/s like you said.
I do notice the download speed ramps up to that 8MB/s over time (this is probably an effect of the windows size changing). This isn’t too big of a deal in Haiku for small packages but for like IntelliJ or other large packages it can take quite a long time just to download…
Installing a single package is an atomic operation, Installing multiple packages should not take any significant time (as in, much faster than alpine linux pkg, which I would consider a sane „traditional“ package manager)
If you have any hangs or slowdowns please do report them, I‘ve not had either so am a bit suprised by this.
(For me only the forced repo refresh pkgman does when installing local files is slowing it down for this relatively simple operation)
Yes, definitely. Iirc there is a review for this on gerrit too.
1 Like