4 ms·

> Managing the abstraction in userland only gets too tedious after a while Can you elaborate on what you found tedious? Thus far, I feel like that part works r

• waddlesplash 7y ago
  > Can you elaborate on what you found tedious? Thus far, I feel like that part works reasonably well. Most of it revolves around update states, i.e. if I update 100 packages at once, the number of kernel calls to de-activate the previous 100 and activate the new 100 is probably in the tens of thousands, and there is a lot of inefficiency here because the kernel does not really know "what" you are doing (just unmounting, moving files, remounting, adding links, etc. etc. etc.) Whereas on Haiku with packagefs, the package_daemon gives the packagefs the new state description, and it can update all of its internal states and re-bind everything internally with a lot less overhead, because both ends of the system know exactly what is going on. > Why is resetting the package store contents to an earlier state not sufficient? What does the kernel need to do? Or do you mean to avoid a reboot? I mean if you e.g. take a bad update, and now your system does not boot, how are you going to revert to an older one? All distros today store older kernels so if that was the problem it's easy to revert that, but if the problem was some package, you have to pull up a recovery shell and mess around in it. If you manage all of the package mounting in userland, how are you going to handle booting from an older "state" if the package management tools themselves, which must be outside the packaged area in your model, got broken? So then you still have to drop into a recovery shell. On Haiku, you just get into the bootloader menu, and then you choose to boot from the previous "state" (which includes the kernel, init system, etc. etc.) because the bootloader itself speaks "packagefs", and can load the kernel out of a package. > In distri, you can just rebuild any package and forcefully install the result onto your system, if you really want to and can live with the consequences. But you miss the point: Of course you can do the same on Haiku, or use the "non-packaged" directories, etc. We have convinced the Haiku "power users" to go this route. But it is very ingrained into a lot of people, and getting them to switch to it is a large cultural problem. Especially if the package manager itself feels "bolted on" and not part of the system, which it virtually always will be in Linux. > Yeah, distri doesn’t attempt to do this, for the reasons you outline :) Well, then the "Linux desktop usability" people who complain that Linux is unsuitable for $average_user will remain correct...
  • secure 7y ago
    Thanks for elaborating! > Whereas on Haiku with packagefs, the package_daemon gives the packagefs the new state description, and it can update all of its internal states and re-bind everything internally with a lot less overhead, because both ends of the system know exactly what is going on. That sounds reasonable. Thus far, my implementation is quick enough for the number of packages I’m dealing with, but perhaps I run into similar limitations down the road :) > because the bootloader itself speaks "packagefs", and can load the kernel out of a package. Understood, cool. I haven’t actually explored how to revert to older systems in the most user-friendly way in distri. Currently, in the rare cases where I actually brick my system, I just boot distri from a USB stick (takes 20s to write), mount my disk and run “distri reset /var/log/distri/update/<latest>/before.txt”. I’m thinking retaining old kernel/initrd combinations and mounting an older set of packages from the initrd might be a viable path. > people who complain that Linux is unsuitable for $average_user will remain correct Possibly, but that’s not what my project is trying to achieve :)