I guess because people feel that suggestions must be shot down or something, rather than discussing the pros and cons of them
You have a tendency of talking down to people and playing this “everyone just shoots down my ideas for no reason” thing a lot, and then when people point this out, you tell them it was “uncalled for”. Can you just like… not do this for once, please? Thanks.
You said “the point was not to suggest actually using ZFS AT ALL.” but you keep continuing to talk about every feature that ZFS has.
You say queries don’t help the end user, yet you talk about things from ZFS a normal user would never care about, because normal users don’t use enterprise filesystems, lol.
You never use snapshots for uninstallation. You can also have per package snapshots for revisions rather than global snapshots alone. Anyway Just delete the files… COPY ON WRITE!
packagefs tries to solve problems that don’t exist… and brain damagingly complicated due to that.
Snapshots are mainly for rolling back to a previous working state just like you can do from the boot loader today.
No they should go into a “packaged” folder not overwriting anything… optionally asking the user to check and merge changes like every other modern OS does. Unlike “non-packaged” we have today, having a “packaged” folder actually makes sense.
The irony of this was that the BFS in version before 4 I believe did store things in a database (or something much closer to what we consider a database)… and it was so non-performant (I think in indexing), they moved it to the file attributes.
Yes, the original idea was to do a database with a filesystem-like layer on top of it. It had herformance issues, but also corruption problems and compatibility with other OS issues. In the 90s it was already a bit late for such a change, file-based operating systems had already “won” and were in use everywhere.
So, this was replaged with BFS which is a lot more traditional (it has path and directories, inodes, file permissions), but retains the ability to index filesystem attributes and query them. It also use 1990s state-of-the-art filesystem design, with journaling, B-Trees, and such, avoiding some of the problems of UFS (from BSD) or EXT2/3/4 (from Linux).
It indeed does not have much of the newer developments of ZFS or btrfs, which push things in a different direction with snapshots, copy-on-write, and a few other innovations. However, I personally don’t feel a pressing need for those, I’m not used to working with them, neither on Haiku nor on other systems
The issue with OFS was that the interface to the file system was not designed to allow foreign file systems to be plugged in. This made supporting other file systems non trivial. One of the big things BFS brought with it was a properly abstracted VFS interface that allowed foreign file systems to be accessed on the same level as the native file system.
That NIH… which is a plague on software everywhere and exactly part of why BFS was so advanced at the time. It’s an attitude that is diametrically opposed to the ideals that lead to BeOS.
Note… I don’t actually feel this way about packagefs… I feel its bad because has many bad side effects. I think something like packagefs would be fine maybe not my preference but I’d be open to it as long as it didn’t suck.
Good news! It doesn’t suck. At all. Hunderds of people use it everyday without any problems.
We can accept that it is not your preference, sure, but I don’t see why we are making so much drama about it on this forum. Ok, you don’t like it. Now, can we move on with our lives?
NIH (Not Implemented Here) is usually employed to mean there is a perfectly good, already existing solution, but people chose to reimplement something from scratch (usually in a worse way) just because they didn’t want to use someone else’s work.
This is not at all what I said here. I said that I’m used to work without these tools (snapshots in ZFS and btrfs, to be specific) and, in my particular use cases, I don’t need them. Not that we should reimplement them badly.
I have also given a more technical reply on why snapshots wouldn’t work to handle package uninstallation (they will do rollbacks, but not package uninstallation). Therefore, on their own they are not a replacement for packagefs. Sure, they solve one of the many problems packagefs does handle. What else would you combine them with? At the end, is your solution made this way really simpler to wrap your head around than packagefs? I don’t think so.
Hundreds of Millions of people use windows every day… it sucks right? Lets move on from playing games here ok?
And as I already said package deletion is just file deletion, if you make it more co Just complex that that its just stupid and end user unfriendly. Just wow, the NIH is strong with you. Haiku can continue on the path it is, and claim packagefs is good when in fact its not, the only thing good about it is that it gets packages onto Haiku, beyond that it frankly a very sore spot and unusable where I want to use it.
Someone tried that awhile back and the problem is that the Haiku build system isn’t setup to make that easy currently… if it were just a matter of changing the package format to some kind of tarball and pacman someone already would have done so.
If you were to do so you’d have to implement a few things to make it work correct in additional to what is done now (I think this mostly relates to localization if I remember correctly).
Also… as I have pointed out, the problem isn’t having a packagefs, its the implementation. Also if I remember correctly originally it was thought at or at least floated that you’d be able to unpack packagefs just like a regular unix package if you wanted to do so.
Localization is completely unrelated to packagefs, how could they possibly be entangled??
Have you even tried?
Doing it manually is as easy as booting the built Haiku system, and copying everything except for /system/packages to a new unpackaged partition. @s40in documented it very well in the thread where they experimented with it.
Scripting it would also be reasonably easy.
Finally you could study the changes to the buildsystem for introduction of packages, and remove those, reverting the logic to an older version. Which shouldn’t be too hard, because all the rules to put files directly in the filesystem are still there in Haiku
None of that is particularly difficult. But I guess it’s easier to complain on the forum and continue to do nothing about it.
They are… its buried here somewhere on the forum but the discussion am amounted to you had to do extra things at package install that packagefs doesn’t do. Honestly didn’t make sense to me at the time but that was why whoever was working on that script gave up back then.
I wasn’t the one working on that, but I was looking forward to it at the time I forget now who was doing it… but they rand into the roadblocks as I mentioned.
Looking back it appears that Haiku can once again boot on my p2120 theoretically but it would have about half as much free ram (256MB system memory) Haiku + packagefs usign 192MB, so around 64MB left… whereas Unpackagefsed Haiku probably still uses around 120-130MB leaving over half of ram free. Packagefs using some 30-40MB less than it was then… granted I think its usage still increases as you install packages but I haven’t checked that.
Also if you could loose the attitude I’d appreciate it.
I don’t think the problem with localisation was with apps. Only things that are difficult to localize are mime types, because you don’t know what app people will install, and attributes names, because people can use whatever they want to i.e make a database. I don’t see how packagefs make things more complicated there.
