[geeks] Solaris resiliency to crashing w/full root partition?

[Jonathan C. Patschke]

On Thu, 29 Sep 2005, Scott Howard wrote:

> Yes, and massively increases the chances of any one partition filling
> up, given the same amount of disk (due to your free space being spread
> between all of the partitions).

That's a minor inconvenience, and can be helpful in catching runaway
writes before / (and, by extension, /var if they're all on one slice)
fills up.  Also, should you want to mount /usr read-only (which used to
be possible with only a bit of work on Solaris), it's essential.

>> When Sun stops shipping Java installers for things that will ONLY
>> ever run on a specific platform of Solaris[1], or they start tidying
>> things
>
> Sorry?  Just because you don't want cross-platform you shouldn't use
> Java?

Sounds great to me (or someone should convince Sun to develop a javac
that generates native object code).  Most of the places that Sun deploys
Java utilize none of its strengths (portability, runtime extensibility,
easy refactoring) and all of its weaknesses (resource utilization,
reduced performance, painful platform abstraction).  Look at the two
prominent (to the systerm manager) uses of Java in Solaris: the
installer and SMC.  Both stink and neither reaps significant benefits
from Java's costs.  They certainly don't inspire any sort of endearment
to Java as a platform, and they go a long way to reaffirming the
impression that "written in Java" means "next day service in exchange
for all your available memory".

> I will agree that the Java/webstart/etc installers can be slow on
> smaller machines

"Slow" is an understatement.  They're sluggish on Blade 1500s and
downright painful on an UltraSPARC-II system--64bit systems with clock
rates above 300 million cycles/second.  That doesn't strike you as
wasteful and suboptimal when the tools that -ship with the OS-
accomplish the same job in a small fraction of the time?

Let me put this a different way:  A 400MHz US-II is not current, but
it's also not "slow".  It's no slower than it was when it was
introduced.  Adding featureless bloat to the system just because 1.5GHz
US-III chips are current smacks of the planned obsolescence that
dominates the PC world.

> -but if that's a problem for you then just don't use them.  For
> anything that uses webstart (which is most products) you can use the
> text-based version instead of the GUI, and in almost all cases you can
> just use pkgadd.  (In fact I think it's one of Suns "big rules" that
> you must be able to install all software without X)

The text-based installer is still Java and still rather slow at doing
what it does.  And, at least in v8 of the compiler suite, the
documentation says "DO NOT USE pkgadd".  So, as part of my Jumpstart
setup, I wait 45 minutes for it to populate a 475MB /opt/SUNWspro on a
US-II system.

> Agreed with catman (a long-standing issue, which has had some recent
> action on it). Not sure what you mean by 'labelling' a disk?

Toss an unlabeled disk into a machine and try to run suninstall:  "No
Disks Found".  That's been a misfeature since the BSD SunOS days.  I
-think- that Jumpstart doesn't care (either that, or I've been lucky to
always toss prelabeled disks in my JS candidates) if you give explicit
labeling instructions, but the interactive installer just drops the user
to OpenWindows after running system identification.

>> -static- binaries in /sbin), or they produce some sort of desktop
>
> Static binaries are pointless.

Well, I guess if Sun's position is that Unix systems only need one
slice, they are.  But, I rather enjoy being able to start systems in
single-user and fix things when /usr won't mount or things are otherwise
sideways, rather than needing to fetch an installation CD or boot from
the LAN.

> Eventually you'll come to realise this (Static librarys are even worse
> - not just pointless, they are dangerous and cause more problems than
> you could imagine)

Please, give me a scenario.  Static rescue binaries are a long-standing
feature of nearly every other commercial Unix, and, for some reason, Sun
still thinks that root's shell needs to be statically-linked, even if
none of the binaries he needs to recover the system are.

>> box.  It doesn't have nearly the cohesion that, say, AIX or the BSDs
>> do, and with v10, it's as bad as Linux.
>
> Well I think that's a first.  You would have to be the first person
> I've spoken to (and I've spoken to hundreds) who thinks that Solaris
> 10 is a step backwards...

My main problems with it stem from a lack of cohesion and polish; it
feels like beta-quality software as there's so much (useless) legacy
stuff hanging about with all the new stuff.  The documentation is
incomplete, and, in many cases, flat-out wrong.  Try to figure out,
completely from the documentation, how to set up a Xinerama
configuration; that's actually what made me wipe my Solaris 10 test
system, as the /usr/dt and /usr/openwin configuration stuff was all
there, and the documentation still pointed at it, but the scripts
themselves said (quite rightly) that editing them was deprecated.

I'm going to give it a fair shake on a server once the contractors
finish up with my computer room at home, since zones and svcadm (wordy
though it is) and dtrace seem like genuine advances over Solaris 9.
However, it's just not the level of quality and clarity and transparency
that I'm used to seeing in a new Solaris release.

-- 
Jonathan Patschke   )  "When we are young, wandering the face of the
Elgin, TX          (    earth, wondering what our dreams might be worth,
USA                 )   learning that we're only immortal--for a limited
                    (    time."                              --Neil Peart