(In)Frequently Asked Questions
Why freebsd-rustdate
in the first place?
There are a number of reasons why you might want another implementation
(to use, or to work on), but the single overriding one is simply that
freebsd-update
is slow.
Why is freebsd-update
so slow, and why not just speed it up?
Again, probably a lot of small reasons, but there’s one big one that dwarfs everything else.
freebsd-update
is a shell script
That means that fundamentally, it’s not a system upgrade utility. It’s
a fork
/exec
stress test that sometimes has the side effect of
leaving you with an upgraded system. It’d take sitting down with
dtrace
or something to get real numbers, but it’s a pretty safe bet
that you get into millions of fork
’s right quick. Or rather, not so
quick.
Really, any substantial speedup would be in the form of “rewrite in a different language” anyway. Which is why we’re here, right?
See also the speed test results page.
Why is it written in Rust?
So we can have a 300-message long thread on a mailing list about it, topics closely related to it, and topics loosely related to it. This will give us all a good chance to show other people whether we’re hip and trendy, or old and grumpy.
Does this mean we can just use freebsd-rustdate
forever now, and we don’t have to worry about pkgbase anymore?
No.
If you disagree, I suggest you pick your language of choice, pull up
mybsd-update.src
on one side of your screen, freebsd-update.sh
on the
other, and start implementing. And understand what it’s doing and how it
works.
OK, what’s wrong with the freebsd-update
process?
It’s basically trying to solve an insoluble problem. It’s trying to update your system from its current state into a new one, but it has no way of knowing what the current state is. That means it has no choice but to scan everything, make a lot of guesses, try to cram even more guesses into the upstream metadata, and in the end just arbitrarily decide some things.
None of which should be considered any sort of smear on the
implementation. If the system were built to be upgraded by a good
upgrade utility, it would include metadata about what’s installed and
what the installed files look like. That way you could know what was
outdated, and what was locally edited. FreeBSD doesn’t have that, and
when sitting down to originally write freebsd-update
, the author
couldn’t magically make that appear. So it’s an outside constraint
that it simply never has any metadata on the running system it can depend
on.
The only real solution is a system that know what it has. In the FreeBSD world, right now, that seems like it’ll be called “pkgbase”.
What’s with the colors on this site?
I confused myself too many times, so I decided I’d use
freebsd-update
for the general system, usage, server, data format, etc,freebsd-update
for the existing.sh
implementation, andfreebsd-rustdate
for this new, shiny one.
How much wood would a wood chuck chuck if a wood chuck could chuck wood?
Seven.