3 ms·
> It took years to make the package manager. You honestly believe it was worth it for this? It took about two years. The rest was largely getting HaikuPorts in
by waddlesplash 7y ago
> It took years to make the package manager. You honestly believe it was worth it for this?
It took about two years. The rest was largely getting HaikuPorts into shape and making it behave the way people expected. Few (if any?) major changes to the package manager itself occurred after the initial development and then merge. So the main time was actually getting stuff ported for the most part.
> But depending on support for bind mounting, in particular read-only bind mounting, chroots might be.
Bind mounting is supported. It does not appear to support read-only binding, but I only looked at it for about 10 seconds just now.
> Though personally I'd have just put them in a compatibility environment, like WINE but translating from Linux to Haiku.
If we are going to have to tolerate ported apps, we want that to be on our terms, not theirs. Part of that is having them be actually integrated with the system as much as we can do -- i.e. clipboard, native file dialogs, icons, look and feel, etc. Otherwise, people will just feel like they're using a shoddy recreation of Linux (which is what it would be) and not an OS in its own right.
> Of course, I'd have built on top of the Linux kernel anyway and got that compat for free by just creating a new namespace.
One of Haiku's main goals is the holistic integration of the complete system, which would be seriously compromised if we used the Linux kernel. There are a good number of instances where we made changes to the entire stack that would simply have never been possible on the Linux or even a BSD kernel.
> Then why not just include QT in the base system?
Why not just admit defeat and surrender to Windows? They have 90% of the market-share, anyway.
Adding Qt to the base system wouldn't just be a compromise on our principles, it would essentially be a complete abandonment of them.
> How is spending years to develop a package manager better?
For all the reasons I already iterated...
> Unless, and I realize there are a whole lot of people out there simply unable to grasp the concept of this, they don't have an internet connection.
Yes, probono remarked about this, and (quite literally today) there has been discussion about how to better facilitate this. It seems we have more or less reached a concensus on starting with "pkgman export": collect a package and its dependencies inside a .tar, and then support reading these in "pkgman install" (and eventually in the GUI by some mechanism.) So, support for this should be merged before too long.
- AnIdiotOnTheNet 7y ago> Adding Qt to the base system wouldn't just be a compromise on our principles, it would essentially be a complete abandonment of them. And I guess this is where our priorities on principles differ. To me, the simplicity of singe-file or single-folder applications is much higher. Let's say Haiku starts to take off in the next few years --and honestly I'd like to see that just so Linux Desktop isn't the only non-proprietary choice--, I'll bet that you'll still be dragging around that QT dependency for the foreseeable future. People will wonder why it isn't just installed by default because of its ubiquity. That's ok, you'll say, because the package manger takes care of it and so users don't have to think about it. But at that point the distinction between being part of the base system and just being a nigh-mandatory package is pretty moot.
- waddlesplash 7y agoHuh? There are quite a number of users who can get by without it. My main 32-bit development VM has no Qt package installed; I'm using native apps for code editing, git manipulation, file transfer, IRC, and so on. It isn't an imperative.