Announcing freebsd-rustdate

Do you enjoy using freebsd-update to keep your systems fresh, but not
so much enjoy the vacations you go on while waiting for it finish
doing its thing?  Ever wished there was something faster and way less
widely tested you could use instead?  Well, today's your lucky day!

The performance of freebsd-update.sh has bothered me a number of
times, so over the past few months I've been working on a
re-implementation of it in Rust.  It's fairly feature complete now,
and seems to be working OK.  I've been using it on multiple systems,
and they're all still working.  So, it's time for other people to see
it now.


I've setup a small site:

https://rustdate.over-yonder.net/

that has a download of a current tarball (a pretty vanilla cargo
workspace), a lot of information on usage, the differences from
freebsd-update.sh, and some deeply unfair speed comparisons.  It
awaits your examination, and I await your feedback.


Here's some quick summary points; see the site (or the built-in help)
for more details:

The basic commands (fetch/cron/upgrade/install) are roughly the same.
There's fairly extensive built-in help for the commands and arguments.
A number of parts can make use of multiple cores, so you can get some
nice speedups if you have them.  There are progress bars for most
long-running operations.  Manual conflict resolution and showing the
details of pending upgrades are separate commands, so 'fetch' and
'upgrade' don't have any interactive elements.

Just for a quick taste of the speed difference, with warm caches on my
fairly powerful workstation, upgrading from 13.2-RELEASE to
14.0-RELEASE-p9 with the full source tree included takes under 2
minutes with freebsd-rustdate (well under 1 minute, if you disable
fsync), compared to about half an hour for freebsd-update.


I'm sure there's lots more testing it needs, so I'd be cautious about
grabbing this and running straight ahead to upgrading your whole
production fleet with it.  But I'd love to know about what's missing
or broken, so I can add or fix it.  Or about what's working right, so
I can break it.

It's worked well for me, so it's probably not _completely_ broken.
I've done my best to make it roughly equivalent to the .sh, but
tracking through some the logic in there is kinda twisty.  I don't
have any insight into how it's all expected to work except for what I
could glean from those sh-spelunking trips, so I expect there are
still surprises lurking somewhere.


In any event, I definitely want to thank Colin Percival and everyone
else who's worked on the existing script and infrastructure over the
years.  I'm sure I'm not the only one who appreciates it.  And I very
much don't intend anything in this mail or on the site as any sort of
slight against them; shell scripts are just slow.  Of course, while
I've done my best to work from the contents of the .sh, all the code
in this is mine, so nothing in it is in any way Colin's fault, or
anyone's but me[0].



[0] It's probably not my fault either.  There's a small family of
    elves living in an old ATX case in my closet, who regularly put
    bugs into my code.  So, really, just blame them.



-- 
Matthew Fuller     (MF4839)   |  fullermd@over-yonder.net
Systems/Network Administrator |  http://www.over-yonder.net/~fullermd/
           On the Internet, nobody can hear you scream.