Re: Gentoo on Sun Ultra 5
- From: Chris Croughton <chris@xxxxxxxxxxxx>
- Date: Thu, 27 Oct 2005 14:55:28 +0100
On Wed, 26 Oct 2005 11:30:21 +0100, Nix
<nix-razor-pit@xxxxxxxxxxxxx> wrote:
> On Sun, 23 Oct 2005, Chris Croughton spake:
>> Indeed, where hardware is concerned if it hasn't failed after 10 years
>> or so then the probability of it failing is rather higher.
>
> ... and this is why I run backups (after ten years of not being able
> to because the only backup device I had only worked in DOS and didn't
> work well even then; damn cheap QIC tape drives).
Yup.
>>> Well, at the Tottenham Court Road fair you can get rewritable CDs and
>>> DVDs for amazingly little (a stack of 100 for a tenner, sort of thing)...
>>> mind you writing to them is so slow that your initial backup will take
>>> just short of forever, and you'll have to be there to swap disks all
>>> the damn time.
>>
>> And by the time you've done it the data on the disk has been erased and
>> replaced several times (or at least the interesting data that you wanted
>> backed up; the OS binaries which you could restore anyway haven't
>> changed).
>
> Do you really change your mail spool and data you worked on last year
> but which might be useful later *that* often? :)
Have you ever tried restoring from incremental backups when there are
more than a couple since the last full backup? Especially since most
backup software doesn't handle moves, renames (and even deletions) well.
I don't even want to think about trying to restore from a 10 year old
full backup and all of the incremental backups since.
Doing rsync once a day over the whole disk takes a bit of time, but at
least it has the effect of being a full backup (modulo any files which
were changing at the time, but that's true of all backup systems).
>> And even 100 DVDs is only 470GB, a sixth of the storage on my
>> Win2k 'media' machine, and takes up a lot more space than a couple of
>> USB2 250GB drives...
>
> Well, yeah, the media stuff is also relatively incompressible so it'll
> eat a lot of space. But then we knew that; there's a reason why you need
> a whole CD to store, well, a CD's-worth of music, for instance :)
Yup. And a whole hard disk to store a hard disk's worth.
>>> Alternatively you might want it if you're using multiple filesystems for
>>> whatever reason (I have ext3, xfs and reiserfs in use here: they all
>>> have different strong points...)
>>
>> I use reiserfs on my fileserver
>
> *shudder* rather you than me. From all I've seen the reiserfs guys have
> made entirely too many dumb design errors to be trusted with my
> significant data. (The oops-we-can't-distinguish-between-data-and-
> metadata idiocy in reiserfs 3's fsck was only the most *notable*.)
It was the recommended choice at the time (everyone was saying that ext3
was obsolete). Now it's swung back. But with daily sync of an ext3
partition to it there isn't much that can change.
> reiserfs is in use for my news spool and wwwoffle cache: i.e., stuff
> which can be restored easily or is relatively unimportant when (not if)
> reiserfs blows up again.
Actually, my news spool can't be easily regenerated, not past about a
month old.
>> (backed up using rsync to another
>> machine which uses ext3fs), otherwise I pretty much only use ext3 (or
>> ext2 on some machines still running 2.2 kernels).
>
> I used to be the same, but I've found myself using xfs more and more.
> It's nifty. (Look out, though: Tim Haynes used xfs and we've not seen
> him on this group for months: the implication is that the filesystem
> ate him).
Hmm, I still think of xfs as 'experimental'...
> (You still run 2.2? Wow, and I thought I was a stick-in-the-mud ;) )
On a couple of machines (including this one). It's a big pain to
upgrade, with the dev/devfs/whatever changes. I tried, the resulting
mess was so unstable that I reverted to a stable version. When I ever
rebuild this machine it will be Gentoo rather than Debian and so will be
a 2.6 (or later) kernel.
>>> If you're NFS-exporting things it's also a good idea to export things
>>> in whole-filesystem units --- but the failure mode there is obscure
>>> enough that hardly anyone does this.
>>
>> Oh, I do that anyway (two 120GB drives, I should upgrade those
>> sometime). Called, unimaginatively, /export/home1 and /export/home2.
>
> I dunno, I've only got one drive that large myself :)
2x 160GB on my backup machine.
>>> Yes, it's easier to manage if you're dealing with a few huge files: I
>>> tend to fill up disks with massive quantities of diverging source trees
>>> and big databases and things like that (although I guess the root unit
>>> of management for that is `an entire project').
>>
>> Probably. Since my idea of a database is an ASCII file that I can
>> process with awk
>
> Most of mine are like that, too, but there are a few for which
> high-speed joins and bisections really mattered, so I used PostgreSQL
> for those, and they just grew. :)
I'm not a database version, I have little idea of what "joins and
bisections" are <g>. I can guess at the first, the second sounds
painful...
>> I don't have very big ones <g>. I did at one time have
>> 5 complete gcc trees (with full build objects in them) on one system, I
>> think I pruned that down to one <g>.
>
> cp -al is your friend in any case; it significantly reduces the space
> used by similar trees. (svn cvs and patch all take care to unlink() at
> appropriate times, so you've got little danger of overwrites as long
> as your text editor acts similarly.)
I generally just get the tarball so it's all 'new' files. And it's the
object files -- which /are/ all different -- which take up most of the
space, because gcc builds itself several times (3 or 4, I lose count).
>>> (OK, so maybe you're tied to Win2K for some reason, but still I'm not
>>> sure there's any Win2K filesystem I'd actually trust for bulk data
>>> storage. VFAT is a joke and NTFS is just too damn overcomplex for me to
>>> trust. Its data structures are more complex than many databases yet
>>> it's astonishingly slow despite that.)
>>
>> Applications are available and usable for Win2k, they aren't for *ix.
>
> Danger, excessively quotable-out-of-context line :)
Yup <g>.
Unfortunately, where all too many applications are concerned it is still
true for the ordinary user (and where things using graphics are concerned
I'm a 'user' -- heck, it's 20 years since I last wrote a text editor or
even looked inside one, these days I use vim on every platform).
>> Audio and video editing software is still nowhere near as usable in
>> 'free' versions as it is for Win32 (yes, Audacity is getting there,
>> perhaps in several years it will approach the functionality and
>> usability of nTrack, and then try to catch up with Cubase; none of the
>> scoring programs are vaguely near Noteworthy Composer and their user
>> interfaces are nowhere near, they are either in the TeX "edit it with
>> vi" school or they use only GUI point and drool).
>
> Yeah, well, the only such tool I've ever used has been Lilypond.
> Actual mixing/audiovisual editing stuff isn't remotely my forte...
I tried Lilypond. I'd rather write in straight MusiTeX. Linypond is
still nowhere near the usability for the ordinary user (if one can call
musicians 'ordinary' <g>) that is needed.
Yes, it would be nice if the apps were available on *ix, but I don't
have the hundreds of thousands of pounds to pay someone to write or port
them, I don't have the skills to do it myself, and I'm not going to sit
around for another decade or so until someone does write or port
something decent. I'll pay the 50 quid or so shareware fee for the Win
version and use that.
> NTFS is the canonical one-critical-sector example, although in fact it's
> worse as the data structure in question spans several sectors and any
> damage to it is irrecoverable (shoot the MFT, oops, goodbye fs), but FFS
> has similar problems; even ext*fs does if you don't know where your
> backup superblocks are located when the first one gets vapourized by
> Murphy.
As I recall FAT32 needs at least two blocks (or with big disks complete
cylinders) to fail, because it always is known where the backup block
is (and it can be calculated knowing the partition size). OK, vaping
the first few cylinders will get it, but as you say that's true of any
fs if you pick the right areas.
Of course, nuking the partition table will work on virtually any drive
no matter what the filesystems...
>>>> tmpfs will push things out into swap, which slows them down being
>>>> swapped back in. I would like the reverse (I've seen it on a *ix,
>>>> Solaris possibly?) where /tmp is used as swap when needed.
>>>
>>> Errr, both Solaris and Linux tmpfs are very similar: data written to that
>>> is considered equal to other pages in the (using Linux terminology) page
>>> cache: if they age, they'll get swapped out: if other stuff ages, it'll
>>> get swapped out. (As usual, paging is preferred over swapping, but you
>>> can't page out tmpfs :) )
>>
>> Hmm, it was some *ix system, I don't remember which. Effectively like
>> Linux swap files but they shrank and expanded as needed
>
> Oh, right, that's *very* different. You could do it on Linux with an
> mlock()ed realtime-priority daemon that watched /proc/swaps and
> mkswapped more swapfiles as needed; it's been discussed on l-k but I
> don't think anyone's ever done it. (The DoS potential is... high.)
You'd need it to come in when memory was needed (i.e. on the request).
Shrinking can be done with a daemon, it's less critical.
>> (they didn't
>> have to be on /tmp, although that was a favourite place for them, they
>> could even be on NFS but that would be silly).
>
> Swap-over-NFS? That's *hard* without deadlocks. Hell, even block I/O
> over the network is hard to do without deadlocks: witness the deadlock
> potential in NFS, NBD and the iSCSI layer now causing intermittent
> flamewars on l-k...
Yes, swap over NFS is pretty silly anyway, far too much can go wrong.
>>> Trying to second-guess the mm layer is generally a waste of time:
>>> entrust everything to it and then tune the result. (You're entrusting
>>> everything to it in the end *anyway*.)
>>
>> In most of my machines it only uses real memory anyway. I don't want it
>> swapping out things that I want to use (code and data) just because
>> something writes a large temporary file.
>
> If it's temporary-as-in-soon-needed, this was the right decision. If
> it's vast it's likely *it* will land in swap instead...
If it's needed soon enough it will go into cache (and swapping disk
cache memory is another silly thing, I hope no modern systems do it!).
However, things which write a 1GB file in /tmp should put it on disk,
not push everything else out of memory...
>> (Hmm, this machine has got 1.5GB of swap used plus its 512MB of RAM, I
>> wonder what the blazes is using it? Glunk, it's mozilla which is using
>> 1.6GB all by itself. killall mozilla. Yup, that dropped total memory
>> usage to about 400MB...)
>
> Another fun one is gtk-qt, which is a very nice engine if you have a
> nice Qt theme and want to make your Gtk apps look similar... but the
> last released version has a huge memory leak that eats ~5Mb/min in the X
> server. (The copy in CVS HEAD is reliable, but not released...)
Ouch. Opera tends to run away with both memory and CPU sometimes (if I
look at the load -- I have xload on the desktol -- and it's sitting at
over 1 for a long time I suspect Opera).
>>> No X client libraries on the rest? Wow.
>>
>> Not usually. I make sure I compile vim without the X stuff, that's te
>> only thing which usually wants them.
>
> ssh wants xauth if you want to keep X connection forwarding working.
It's only recently that I've had X forwarding on at all. Virtually
everything I want to do on a remote machine is text/console based.
>>>> -- I use fvwm,
>>>
>>> Err, I use fvwm *and* KDE and much prefer it to either on its own
>>> (mainly thanks to the joy which is tabbed konsoles, admittedly). They're
>>> not mutually exclusive :)
>>
>> Do you mean you use KDE apps under fvwm, or you use bits of KDE window
>> manager as well?
>
> Nah: if you start KDE like this:
>
> KDEWM=/usr/bin/fvwm2 startkde
>
> then you get a full session-managed KDE desktop with the window manager
> used being fvwm. If you use fvwm-2.5.12+, the only bit of KDE which
> doesn't work as a result is the bit of the control center which controls
> kdewm (not even remotely surprising, that).
Ah. But then you get the big KDE desktop.
> I mean, I do things like this:
>
> Style "kicker" NoTitle, Layer 7
>
> AddToFunc Partial-Max I Maximize growonlayers 3 5 grow grow
> # then use Partial-Max as my maximizing function
>
> Style "ProcMeter3" Slippery
> Style "ProcGlobal" UseStyle "ProcMeter3"
> Style "ProcGlobal" Layer 6, Sticky
> Style "ProcRightmost" UseStyle "ProcGlobal"
> Style "ProcRightmost" Layer 5
>
>
> # Flip procmeters and pagers to the background
> AddToFunc "BegoneProcmeter" "I" All (ProcMeter3, Layer 6) Layer 0 2
> + "I" All (ProcRightmost, Layer 5) Layer 0 3
> + "I" All (FvwmPager) Layer 0 2
>
> # Flip them back into the foreground again
> AddToFunc "ReturnProcmeter" "I" All (ProcMeter3, Layer 2) Layer 0 6
> + "I" All (ProcMeter3, Layer 3) Layer 0 5
> + "I" All (FvwmPager) Layer default
> + "I" All (FvwmPager) Lower
>
> and then I can have a set of procmeters started with the -name option,
> some of which obscure the rightmost part of maximized windows by
> default, but upon one keystroke (bound to BegoneProcmeter) they sink out
> of sight, to be restored with another keystroke; the panel obscures them
> at all times. Maximized windows stay out of the way of the rightmost
> procmeter (started with -name ProcRightmost), which gives info on the
> local machine.
>
> (Layers are a *very* nice idea.)
Hmm. In general I don't like things 'hidden', I'd rather just have them
on another desktop.
> The other KDE-as-your-desktop undocumented trick I've noticed is that if
> you're starting stuff on remote hosts, the session manager by default
> tries to restart them on session startup using xon. Now xon, not to put
> too fine a point on it, is not widely used and doesn't work on most
> sites.
>
> Fortunarely it's easily fixable to use ssh once you know what to do. In
> /usr/share/config/ksmserverrc:
>
> [General]
> xonCommand=/usr/libexec/kssh
>
> where /usr/libexec/kssh reads
>
> #!/bin/sh
> #
> # kssh --- Helper SSH invoker for KDE session manager
> #
>
> exec ssh -f "$@"
Ah. I do 'interesting' things with ssh to force environment variables
through to make sure thatthey are properly set.
> I'll admit to using links -g quite a lot (the font it uses is lovely),
> and emacs-w3m for most of the rest of the non-cartoony stuff. (Not
> Dilbert, though, I get enough of that at work: Schlock Mercenary. :) )
Actually, I usually only read Dilbert at work in lunchtimes Talking of
lunchtime...
>> As I said, I don't use bloatware and that includes (X)emacs <g>.
>
> It's exactly as bloated as any other operating system. :)
>
> (xemacs is much larger than emacs because of the package system: you can
> choose to install the lot and there are far more things packaged for
> xemacs than there are in the emacs lisp tree. xemacs is much smaller
> than emacs because of the package system you can choose *not* to
> install hardly anything...)
And I do choose to install none of it <g>. (In fact when some package
manager 'helpfully' installs it for me -- thank you dselect! -- I have a
tendency to do find / -iname '*emacs*' -exec rm {} \; (as root).)
>>>> Admittedly gcc is getting somewhat big...
>>>
>>> That's probably thanks to libgcj...
>>
>> And the ISO C++ stuff.
>
> That's true, when compiled with debugging that comes to 25Mb, and if you
> include the huge precompiled headers that adds another 40Mb or so.
> (Myself, I've never found a use for a set of pre-precompiled headers
> that includes a random subset of libstdc++, so I just delete those
> monsters.)
Indeed. It's worse since they made the libc++ properly ISO compliant.
> I posted about it instead. (Call me an old-schoolist, but I greatly
> dislike HTML and all that jazz.)
I wrote a page the other day. It has two images on it and a bit of
text, and took me about 2 minutes (half of which was looking up the
format of the <img> tag!).
>>> Agreed, once I've written this mount hack. I'll try to get it accepted
>>> upstream but I suspect Adrian will say `urgh'. (But I haven't asked
>>> or indeed written the patch yet so this is pure supposition).
>>
>> Heh. And goodness knows how long it would take to get into distros.
>
> A couple of years seems to be typical for near-complete coverage ---
> although it would probably hit some within days.
And Debian would accept it about 3 years later...
>>>> Heh. I like the AMD K6-2/500 processor, it just goes on and on whatever
>>>> I do to it. Not the fastest, but the most reliable of any of my
>>>> machines.
>>>
>>> I think that's about the highest of the AMDs that'll run fanless, too.
>>
>> It will, although a hot summer day will knock it out if it's fanless.
>
> That's running very close to the edge!
Yup. I had one where the fan got stopped (a wire got into it), the chip
ran happily for a week or so and then crashed. The kernel halted (thus
lowering the power consumption), and when I freed the fan and powered on
againit all worked fine (even the fan!).
>> However, unlike the later AMD chips it will recover happily once it has
>> cooled down again, it doesn't go into thermal runaway and melt down like
>> the early Athlons did.
>
> i.e., mine. (But note that it only melts if you take the heatsink off
> as well, which a) takes some doing and b) is really bloody stupid.)
True. But I had one of the early 1GHz ones and once that overheated
it burned something out in the chip even though it didn't melt anything
else.
>>> (The box up north is, don't laugh, a 486.)
>>
>> Nothing wrong with that. Except that it's getting hard to find ISA
>> cards now and few 486 motherboards had PCI.
>
> It's a 486 laptop. No slots except for PCMCIA.
Not so bad.
>> I've never run links with graphics support seriously (I did it once just
>> to se what it was like).
>
> links-2.1pre* is the only version with decent graphics; it's pretty
> nice, and probably displays graphics on more platforms than any other
> non-mobile-capable web browser (Opera probably beats it on that front).
Hmm. How's it's Javascript these days? Last time I tried it seemed to
barf on most sites.
>>> Babbage's Difference Engine? ;)
>>
>> I don't /think/ there's a Linux port for that <g>. (Was it actually
>> Turing-complete?)
>
> Definitely not. It would have been amazing if it was really, given that
> it was designed a century before Turing...
The human brain was designed rather a long time before Turing as well
<g>. It wouldn't surprise me if earlier designs were Turing-complete,
after all no one actually thinks about running a Turing engine on modern
processors to prove it.
>> I also constrain it to not only fit in my house but
>> also to be able to go through the doors without modifying the doorframe,
>> which tends to eliminate really nice machines like Elliott 4100s. Using
>
> *wah*
As my mother used to say when I wanted something: "Where would you /put/
it?"
> (It also would probably eliminate my desk: we had to take the door off
> its hinges to get it in the room...)
My things have to go up stairs and round corners as well.
Have I mentioned that I hate DEC AlphaStations? They bite. Yesterday
one bit my arm when I was unpacking it, and then tripped me at the top
of the stairs when I was carrying it. It's still working, though
(emerging a load of things I need on it at present).
>> less power than the rest of the street is also a Good Thing(TM) <g>.
>
> The traditional mad scientist's computer dims the *city* when you
> flip the Big Red Switch. (Sort of like modern Intel CPUs.)
Heh.
Chris C
.
- Follow-Ups:
- Re: Gentoo on Sun Ultra 5
- From: Nix
- Re: Gentoo on Sun Ultra 5
- References:
- Gentoo on Sun Ultra 5
- From: Chris Croughton
- Re: Gentoo on Sun Ultra 5
- From: Ian Rawlings
- Re: Gentoo on Sun Ultra 5
- From: Nix
- Re: Gentoo on Sun Ultra 5
- From: Ian Rawlings
- Re: Gentoo on Sun Ultra 5
- From: Nix
- Re: Gentoo on Sun Ultra 5
- From: Ian Rawlings
- Re: Gentoo on Sun Ultra 5
- From: Ian Rawlings
- Re: Gentoo on Sun Ultra 5
- From: Nix
- Re: Gentoo on Sun Ultra 5
- From: Ian Rawlings
- Re: Gentoo on Sun Ultra 5
- From: Chris Croughton
- Re: Gentoo on Sun Ultra 5
- From: Chris Croughton
- Re: Gentoo on Sun Ultra 5
- From: Nix
- Re: Gentoo on Sun Ultra 5
- From: Chris Croughton
- Re: Gentoo on Sun Ultra 5
- From: Nix
- Re: Gentoo on Sun Ultra 5
- From: Chris Croughton
- Gentoo on Sun Ultra 5
- Prev by Date: Re: Oddities with PCI serial cards
- Next by Date: Re: alternative to gimp recommendation?
- Previous by thread: Re: Gentoo on Sun Ultra 5
- Next by thread: Re: Gentoo on Sun Ultra 5
- Index(es):
Relevant Pages
|