Wow, thanks again, esp. for the last of those, which will definitely be on my reading list. I don't particularly know either Go or Rust either (just C, C++, a smidgen of Java and Swift, PL/I and a bit of COBOL and FORTRAN and various assembler, ksh, perl, awk, SQL and some other query languages, etc), but I can see the sense of the choice of Rust for a balance of speed and safety (although were it me, I might be old school and tempted by Ada); it's obvious if not entirely true to blame at least some of the slowness on Python, although usually choice of algorithms accounts for more than choice of language.
> On Mar 5, 2023, at 11:57, Till Wegmüller <toaster...@gmail.com> wrote: > > No not quite, > > You can check my go port for formats and some incomplete server code > https://github.com/Toasterson/pkg6-go > > My C++ port attempt for sax parsing and history format implementation > https://github.com/Toasterson/pkg6 > > And my current rust port for Manifest reading code and an attempt to make > things faster > https://github.com/OpenFlowLabs/ips > > And the docs of the original for details from the Original developers fom > 2011. > https://github.com/OpenIndiana/pkg5/tree/oi/doc > > In there is a complete manual how everything works and Implementation details > and notes from the devlopers about the algorithms and the original reasons > why things are why they are. There is a t least conference 20 talks worth of > reading in there. > > -Till > > > On 05.03.23 17:47, Richard L. Hamilton wrote: >> Thanks! That covers the useful part of my questions; for curiosity details I >> can always look at the source code. :-) Unfortunately for a more than casual >> overview, I'd have to learn Python. :-( >>> On Mar 5, 2023, at 11:19, Till Wegmüller <toaster...@gmail.com> wrote: >>> >>> Hi >>> >>> IPS works on images of the OS. And it does so in an Atomic way. Speed is >>> not the main goal. Stability is. >>> >>> If you want to speed up the time it is usually good to add more RAM and >>> faster disks, as IPS consumes a lot of memory resolving dependencies. And >>> doing Catalog operation. The Actual update is alsmost instant. >>> >>> A lot of the phases during package actions are spent in internal >>> bookkeeping things which are simply slow on OpenIndiana due to how IPS was >>> initially designed with releases and not rolling release. This can be fixed >>> in the future but I did not have time to do anything there. A update would >>> require a couple months worth of work and currently nobody is paying for >>> that. It's good enough for people as it is. >>> >>> The stages you see are: >>> - Downloading and updating cached JSON catalogs of all packages available >>> (this usually takes the longest) >>> - instrumenting beadm >>> - downloading manifest files >>> - Downloading and copying files (uncomress) into place as described by the >>> manifests. (check the contents with `pkg contents -m` >>> - Creating a search index for pkg search actions (this also takes a long >>> time) >>> >>> Boot environments are created on updates that update more than one package. >>> The package can inform IPS if a new boot environment is required. >>> Installation uninstall etc. do not require a new boot environment. >>> >>> Hope this helps >>> Till >>> >>> On 05.03.23 16:41, Richard L. Hamilton wrote: >>>> Given the output >>>> ----- output begins ------ >>>> root@openindiana:~# pkg update >>>> Packages to update: 375 >>>> Create boot environment: Yes >>>> Create backup boot environment: No >>>> DOWNLOAD PKGS FILES XFER (MB) >>>> SPEED >>>> Completed 375/375 5209/5209 181.4/181.4 >>>> 878k/s >>>> PHASE ITEMS >>>> Removing old actions 1015/1015 >>>> Installing new actions 1017/1017 >>>> Updating modified actions 6585/6585 >>>> Updating package state database Done >>>> Updating package cache 375/375 >>>> Updating image state Done >>>> Creating fast lookup database Done >>>> Updating package cache 2/2 >>>> A clone of openindiana-2023:03:03 exists and has been updated and >>>> activated. >>>> On the next boot the Boot Environment openindiana-2023:03:05 will be >>>> mounted on '/'. Reboot when ready to switch to this updated BE. >>>> Updating package cache 2/2 >>>> --------------------------------------------------------------------------- >>>> NOTE: Please review release notes posted at: >>>> https://docs.openindiana.org/release-notes/latest-changes/ >>>> --------------------------------------------------------------------------- >>>> ----- output ends ----- >>>> what do the various phases mean? And what drives the decision whether to >>>> create a new boot environment, or a backup boot environment (or maybe >>>> neither)? >>>> Knowing those might be helpful if anything went badly wrong (although the >>>> simplest remedy would be to fall back to a previous boot environment!) or >>>> if one intended to create a package, and would certainly be more >>>> satisfying waiting for the slower phases to complete, being able to say to >>>> oneself what it was doing then. Oh, and why does "Updating package cache" >>>> appear twice? >>>> Updates on Solaris 11 and derivatives (OpenIndiana, etc) are certainly >>>> very robust (if packages and repositories are correct!) and provide >>>> generous means of recovery. But they do seem to be quite slow compared to >>>> e.g. either Red Hat based or Debian based Linux methods (yum or apt, or >>>> the underlying local-only facilities). That's not counting download time >>>> either (since repository servers are not all equal). >>>> _______________________________________________ >>>> openindiana-discuss mailing list >>>> openindiana-discuss@openindiana.org >>>> https://openindiana.org/mailman/listinfo/openindiana-discuss >>> >>> _______________________________________________ >>> openindiana-discuss mailing list >>> openindiana-discuss@openindiana.org >>> https://openindiana.org/mailman/listinfo/openindiana-discuss >>> >> _______________________________________________ >> openindiana-discuss mailing list >> openindiana-discuss@openindiana.org >> https://openindiana.org/mailman/listinfo/openindiana-discuss > > _______________________________________________ > openindiana-discuss mailing list > openindiana-discuss@openindiana.org > https://openindiana.org/mailman/listinfo/openindiana-discuss > _______________________________________________ openindiana-discuss mailing list openindiana-discuss@openindiana.org https://openindiana.org/mailman/listinfo/openindiana-discuss
