Re: Announcing freebsd-rustdate

On Thu, Aug 22, 2024 at 8:41 PM Matthew D. Fuller
<fullermd@over-yonder.net> wrote:
>
> 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.

This looks awesome!  I can't wait to try it out.  I too get painfully
bored by those long freebsd-update sessions.  But it needs a couple of
things:
* Revision control.  Are you going to commit it to Github or some
other public repository?
* Tests.  One of the things I like best about Rust is its testing
infrastructure, and one of the things that scares me most about
freebsd-update is its total lack of tests.  It has me afraid to change
anything.  We need to figure out how to get some test coverage here.
I might be able to help.

-Alan