OT: redhat

[Fairlight]

You'll never BELIEVE what Bill Vermillion said here...:
> 
> I've seen that too. Using 2GB+ is not unusual in Linux, but using 
> more than 100MB in FreeBSD / is unusual.  Though the 5.x has

I think Bill said that one of the latest (SuSE 9.2??) uses over 6 gigs if
you install everything, wasn't it?

> much larger defaults.  Now that 5.3 is officially released and
> 6.0 is now about two steps past the bleeding edge, well start
> seeing more people migrating to the 5.x.

What happened to 5.[012]?

> I suspect that is going to catch a few people unaware who have
> applications that depend on file system structures and expect
> such things as the long standing 128byte inode size.  And with the
> large inodes we have a create time for the first time.

That affect fP in any way?

> SCO mis-documented ctime as innode creation time instead of CHANGE
> time, and that mis-understanding has propagated widely.  So
> now there is access time, modifciation time, change time, and
> creation time.   It also means that we can have much larger files

What is it, st_rtime?

> I >>HATE<< it when backups are stale and you have to mount
> / in read-only mode and then slowly recover things a bit at a time.
> Worst was years ago when the lost+found was not large enough to be
> able save things, and answering Y to remove things would leave a
> large data loss.  So that was a mount read-only, save files
> externally, and do it over and over.

Talk about stale...I once had to take a call from a client of a client who
had their console monitor go dead, nobody ever checked root's email, and
nobody ever saw their tape backups weren't succeeding -or- verifying.  They
religiously changed tapes, but only the lady that was on the phone with me
that day seemed to notice that at least three of the tapes had actually
come off their spools entirely.  NONE of the backup tapes worked--at all.
They had to get their DBIV programmer to recover what he could from what
was left.  I can't remember exactly, but I think the fragment that was left
was about 27MB of a file that should have been over half a gig.

"Oops."

They were going to have to have temps come in and re-key the rest by hand.

They had Edge--they just never paid attention to the notifications, never
replaced the monitor because nobody ever used the console anyway, and for
whatever reason, root's mail was never redirected -or- read.

> I got an email one day with a 1/2 dozen images.  Smoke and flames
> rolling out of the building.  NOTHING was salvageable.  And his
> only backup of the Linux filePro was made from an MS machine that
> truncated all names that did not fit in 8.3 name-space.

Gack!

> 
> Quoted a lower than normal hourly rate and figured it would
> be at least $5000 to get it back to the state it was in the month
> before the fire.  In the end I think he wrote it all off, and
> actually focused on building his other businesses.

On the whole, probably wisest for all concerned.  You'd have gotten screwed
in all likelihood.  You know what a time-sink that stuff can be, especially
when they barely remember what they had in some places.

> Haveing a BE/LT daily backup to tape with at least one a week going
> off site would have meant he would have been operational in less
> then a day.

People really should replace their media once in a while, as well.  I can't
believe anyone could -miss- tapes being off the reels.  But tape just goes
bad after a while, as well.  I dunno what the rule of thumb is, but I
should guess that replacing the batch of tapes at least once a year is a
prudent move.

mark->
-- 
Bring the web-enabling power of OneGate to -your- filePro applications today!

Try the live filePro-based, OneGate-enabled demo at the following URL:
               http://www2.onnik.com/~fairlite/flfssindex.html