[rescue] Oracle making just a little harder to keep old machines in use

[der Mouse]

>> Why won't (GNU) tar work?  It does everything that you say you are
>> wanting.

> Well, yes and no.

> Tar doesn't have code to cope with filesystems that are changing as
> they're being read.

> It runs in userspace instead of reading the raw device.

It's not GNU tar, but I taught my tar to do the latter and in the
process fixed the former.  However, it's at most a starting point for
this, because it's FFS that it understands, not ext*.  (They're
similar, but not nearly similar enough to not need work to adapt the
code for the one to the other.)

For all I know GNU tar might have such code by now, though; I don't
follow its development.

> While it has some incremental backup capabilities, it's not readily
> usable in the same way that dump's incrementals are.  Yeah, you can
> wrap some shell around it and get close, but it's awkward.

GNU tar's incrementals are actually pretty close, though probably not
as close as dump's.

My tar, while specifically designed as a backup tool, does not do
incrementals all that well; that was a relatively minor issue for its
target use case.

> Tar's "catalog", if you will, is spread throughout the archive and
> not at the beginning.

I think this is not nearly as true if you use GNU tar's
incremental-backup mode, though I admittedly haven't looked at it in
detail.

> It does have the merit of creating archives that are very portable.

Significantly less so if you use GNU-tar-specific features such as
incremental mode.  Possibly no worse than dump, though, and, if you're
using Linux, quite possibly not enough so to matter.

> What I'll argue that we (FSVO "we") need is [...]

...and a pony. :-/

/~\ The ASCII				  Mouse
\ / Ribbon Campaign
 X  Against HTML		mouse at rodents-montreal.org
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B