On Sat, 13 Jan 2024 at 16:18, Goetz T. Fischer <[email protected]> wrote: > no, such a comparison would of course be pointless.
On Sat, 13 Jan 2024 at 16:30, Goetz T. Fischer <[email protected]> wrote: > On Sat, 13 Jan 2024 15:36:40 -0800, Bill Sommerfeld via openindiana-discuss > wrote: > > don't assume the SAT solver is eating it all > i would assume I think this thread has achieved all it's likely to achieve. If people want to work on IPS, there are any number of productive avenues -- but it's going to be _work_, not endless mailing list threads, and not guessing at or assuming things. If you want things to be better, you should: - look at what OmniOS are doing with their IPS fork - look at the IPS changes Alan pointed to and see how many can be made to work here - profile your system to see why it's actually slow, not just assume or guess, and make the slow parts go faster The original question that started the thread is obviously very reasonable: in theory much of the bulk data that IPS stores should not need to be tied to a particular boot environment -- provided it is stored in a long-term stable format, or it can reliably be destroyed and recreated from upstream sources when that format needs to change. I don't think it's ever going to be wise to try and mount datasets from outside the boot environment on top of subdirectories for arbitrary system components, IPS included. Instead, if you would like it to work that way, it would be best to get IPS to directly support doing this. If you want inspiration, Oracle appear to have introduced "rpool/VARSHARE", a dataset that gets mounted as "/var/share" but which is common to all boot environments. Data that need not be BE-managed can live there instead of being duplicated in each BE. Either this, or something like this, would seem to be pretty reasonable for a number of things in the core OS and in IPS. But that's going to take work, which anybody who wants that feature can do! Interminable list discussion is unlikely to help. Cheers. -- Joshua M. Clulow http://blog.sysmgr.org _______________________________________________ openindiana-discuss mailing list [email protected] https://openindiana.org/mailman/listinfo/openindiana-discuss
