Updated #pkgsrc bootstrap kits now available for macOS, available as usual from https://pkgsrc.smartos.org/install-on-macos/
These include the new and improved #pkgin 23.8.1.
No need to install new bootstrap kits if you already installed an older one, but you may want to run:
$ pkg_add -U pkg_install pkgin
prior to running "pkgin upgrade" so that the upgrade is performed using the latest tools.
It's a pity that Mastodon lacks quote tweets, but in addition to the post I boosted yesterday, I just wanted to say my own thanks for #DTrace reaching 20.
I use it all the time, and struggle when working on other systems that do not have it. Only yesterday I wrote a quick script to verify a code path that lead to this fix: https://github.com/NetBSD/pkgsrc/commit/def71d1c1f988e3a2cf3bb86716a2937ce6f48fc.
It has found significant performance wins in #pkgsrc and #pkgin, fixed numerous bugs, and helped me understand systems.
Thanks @bcantrill and @ahl!
Ok, with a boatload of fixes and a performance improvements of up to 2,500x I've released #pkgin 23.8.0!
https://github.com/NetBSDfr/pkgin/blob/master/CHANGES.md#version-2380-2023-08-16
There's still a bunch of things to do, but they can wait for future releases.
I've updated the #pkgsrc package and will be rebuilding binary package sets over the coming days.
As part of my recent #pkgin work I came across another optimisation for "pkg_admin rebuild-tree" using #DTrace that makes it a further 12x faster on my test system.
http://mail-index.netbsd.org/tech-pkg/2023/08/07/msg027952.html
This is in addition to the 13x speedup I committed a few years ago:
https://gist.github.com/jperkin/98550d5bd07f4179ebfeea825fc3ec20
#pkgin #dtrace #pkgsrc #netbsd
Not only was #Manta v1 awesome for having jobs, the marlin image provides a superb environment for testing the new #pkgin code, given there are over 12,500 packages installed.
I'd say the results are looking pretty good:
$ time ./pkgin-22.10.0 -n ug
real 54m10.021s
user 53m42.252s
sys 0m21.575s
$ time ./pkgin-current -n ug
real 0m1.241s
user 0m1.086s
sys 0m0.145s
Under 1 second would be cool, and I think there are still some areas where improvements can be made.
Another solution is to install #pkgsrc and either use that to compile what you need, or use #pkgsrc to install #pkgin and download pre-compiled binaries supplied by @jperkin if memory serves well.
I have done that in the past, and I was very happy with the amount of goodness pkgsrc brings to MacOS X.
It does involve installing XCode and its command line tools, but that is a minor problem - read the documentation at https://www.netbsd.org/docs/pkgsrc/ and you will be in business pretty quickly.
So grateful for investing time into writing the #pkgin test suite.
Required adding and rearranging code in pkgin itself to support various environment variables that allow us to run alternative packaging tools, as well as writing the test suite itself, which all took quite a bit of time.
But being able to write complex upgrade scenarios, and go quickly from hypothesis to fix, has paid off hugely. Plus the added confidence that all of the regression tests ensure I haven't broken anything.
Finally for this week I've fixed package ordering during install/upgrade. This resolves issues where install scripts run programs that depend on libraries that haven't been upgraded yet.
As an added bonus the streamlining improves performance quite a bit (upgrading 1,700 packages from 2020Q4 to 2022Q4):
$ ptime pkgin -y upgrade
real 41:06.80
user 28:52.80
sys 12:59.15
$ ptime ./pkgin-current -y upgrade
real 36:09.76
user 24:32.55
sys 11:58.56
Reworked the recursive dependency discovery to make the code a lot more readable, as well as improve performance.
$ ptime ./pkgin-22.10.0 -n upgrade
real 3:29.880475370
user 3:29.329552124
sys 0.353450635
$ ptime ./pkgin-current -n upgrade
real 12.324068349
user 11.972102324
sys 0.166771212
I'd say we're making progress!
After some more #DTrace analysis and code reading, found another easy optimisation win in the pattern matching code, for a further 2x speedup.
Next up some database optimisations which will hopefully get us to around 8x combined speedup, as well as helping with future development work.
After maintaining #pkgin for a few years, there's still a bunch of low-hanging fruit for cleanup and optimisation.
While working on SUPERSEDES support, I was curious as to why the dependency calculation takes so long.
Re-ran it with #DTrace, saw break_depends() taking up 55% of the runtime. What does it do?
Turns out, nothing. Various changes over the years, notably refresh support, have made its calculations obsolete.
Nice easy 2x performance win and much easier-to-understand code path.
Replaced old #ThinkPad T41 broken hinge. With 2GB of RAM and a 1.6Gz Pentium M, realistic software options are... limited
Installed the latest #NetBSD 10_BETA, then used #pkgin to see about basic web browsers
#netsurf - fastest way for basic webpages
#ArcticFox - hits the sweet spot for older/constrained machines
#Firefox - 92 is almost usable in 2G, 102... not so much. I stopped there :)
For its time (2003) the T41 is an amazing laptop. Plus that screen ratio #chefskiss
#thinkpad #netbsd #pkgin #netsurf #arcticfox #firefox #chefskiss #retrocomputing
Upgrade packages with pkgin to netbsd 9.0 #pentium3 #netbsd #pkgin #vintagecomputer
#vintagecomputer #pkgin #netbsd #pentium3
I, alas, don't get the luxury of using #netbsd as much as I'd like. Some of that is most certainly down to personal preference, and others are due to the overall slow-pace of change, relative to its cousins #openbsd and #freebsd.
But when I were using #netbsd, I really did love #pkgin (https://pkgin.net/). I did contribute to this many moons ago -- and to this day, it represents the simplicity and thoughtfulness that any package manger should. The #ui is the important thing here -- and #pkgin gets that right, especially for its primary target audience of #netbsd.
I know that #freebsd has #pkg -- which does a very good job, but something always keeps me looking at #pkgin -- even though, I also have code in #pkg.
#openbsd is the real outlier here -- their pkg_* tools are still perl-based, but like the dark horse they are, are maintained well, and really functional.
I've heard it argued that in the #linux world, the different distros keep people apart due to how they handle package management, even as far as to suggest that the programming language is a key factor here.
I say, "eh?", but even then, I'd still gravitate toward *BSD...
#netbsd #openbsd #freebsd #pkgin #ui #pkg #linux
Pues me ha costado trabajito pero ya tengo #xfce4 instalado en mi #pinebook #pine64 #aarch64 #arm64 con #netbsd via binarios precompilados con #pkgin porque si tuviese que compilarlo con #pkgsrc me llevaría más de una semana compilando con la potencia de cálculo del pinebook 😅😅😅
#xfce4 #pinebook #pine64 #aarch64 #arm64 #netbsd #pkgin #pkgsrc