At least bbjimmy, who was on “your side” of the argument originally, has since come around (or at the very least, he is still around, and has not left.) So this is an exaggeration at best.
Such as? As PulkoMandy mentioned, /boot/beos is still R/W! So what else are you referring to?
Karl and Haikuware leaving was completely unexpected on our part, and still to this day makes no sense to me. Most of the software there from BeOS, or in .pkg files, still worked; and we expected they would create a package repository and start populating it with software. Instead they just up and left, and refused even our efforts to archive the site, sending us vague legal threats in e-mails if we attempted to do so.
Also this obviously the links and things are there now, but may of the problems endemic to packagefs are there:
Note: if you want to never have this conversation then we need to resolve the problems instead of ignoring them, and going lalaalala, I wont’ allow this on the ticket tracker etc. Because 5 years down the road, someone is going to go I thought this was a BeOS compatible OS why don’t these things work and start it all over again, because Haiku has strayed from it’s beginnings for virtually no reason at all.
The complexities introduced by pacakgefs in it’s current implementation are completely unacceptable.
I’m still waiting for your actual examples of broken apps so I can investigate and fix the problems. You have found one app and we have investigated it and found that the problem was not related to package management. I’m not sure what else I can do.
I don’t think we ignored the community in designing the packagefs. You can find the mailing list archives where this was discussed at length, with everyone suggesting many ideas. Of course not all ideas could be used, there was a lot of discussion and compromises.
As for haikuporter, yes, it predates the package system. And no, it was not usable before, dependencies were not managed, it would automatically install stuff in your system without asking you so if you had a bug in your recipe, it could easily result in unbootable system. I’m certainly not going back. The read-only system folder is not a bug but a feature. Now it is reasonable for me to keep using the same Haike install for years, instead of reinstalling every other month because I attempted to install something and it made a mess in there in a way that can’t be undone.
And regarding the “everyone has left” argument, let’s look at facts. Out of our top 10 contributors, everyone was at least contributing until 2016: Repostat: git repository statistics. the one who stopped contributing in 2016 is Ingo Weinhold, guess who, the person who designed and implemented packagefs. And his reasons for leaving are largely unrelated to any of this. You can also check that the number of authors per year did not significantly go down. And on the haikuports side: Repostat: git repository statistics. the number of contributors went way up from 11 in 2012 (the last year before package management work started), to 35 in 2013 (right after it was put in place), to 59 in 2019. So, we have 5 time more people working on things now. I don’t think that is an “everyone has left” situation. On the contrary it shows how the package system helped attract new contributors to Haiku and make it a quite active project.
You have also been unable to list any name in your “everyone has left” argument just as much as you have failed to list any problematic software in your “all software was broken” argument. So there is nothing I can do to help here.
It isn’t the APPs that are broken… so why continue repeating that nonsense. The death of BeOS applications by a thousand bug reports is frankly terrible.
I’m not asking you to do the impossible I’m asking.
The BeOS read/writablity of the filesystem be retained as it is central to usability. If BeFS is nt’ fast enough to do this we shouldn’t be hacking around with a complex read only files system structure but should be jotting down plans for BeFS2 etc… or whatever. As it is now Haiku completely breaks the filesystem and UI “contracts” that have been made with the end user for since the creation of BeOS.
non-packaged be changed to packaged… any new applications can be expected to update to the new location for placing new config files and be linted to inspect that they are doing so. Old packages can continue as normal.
This makes things very obvious in how they work rather than convoluted and non obvious as they are now.
Note that while I agree with some of his points I completely disagree with his attitude and actions toward the Haiku community. He’d probably still be pissed if any package management at all existed… because it deprived his websites of traffic and thus any control and or tiny profits he felt entitled to over the Haiku project.
Also he was not really a developer… nor one of the developers that pretty much got burned out over the pacakgefs fiasco.
The hpkg files are geberated for the pms and are from beginning writeprotected. Started past alpha 4.1. I think you mean old beos packages, but they dies not support the package folders add after pms included. They are automatically install to home non packaged.
With including the pms many old programs are broken, this is true. Because they write files to his own folder, there was no really good structure the developer following.
The pms give a structure, people know to install files on the right position. Old files to non packaged. Some programs are broken, this is bad but the developers need to go with the time.
I miss call to power , corum 3, inside conatructor…
Corrrect the package management system does give structure… but that structure should come from HaikuPorter not from bad assumptions in the package format.