Just my 2 cents. 

I've used Solaris, and while there isn't anything wrong with it, I find
the lack of decent GNU developer tools out of the box to be a definate
annoyance. 

As for Solaris not being rebooted in years, that's really not a good
description of stability anymore.  I've run FreeBSD, Solaris, and Linux
at one time or another - as well as dabbled with VMS/VAX (ugh) and
Tru-64.  They are all pretty stable.  Once you get one in place, they
can all have uptimes stretching into years. 

Not to sound contrary, but I'd rather be forced to reboot now and then. 
The reasons are two:  every now and then they change the kernels, so
upgrades require a reboot (just to make sure it's clean) - and the
second reason, which we can argue until the end of time - I have yet to
meet a single OS in existance that hasn't leaked memory due to poor
daemon designs or lazy programmers writing crappy apps. This reflects
nothing upon the OS.  It's the applications or daemons that force a reboot.


If you are concerned about leaving Solaris, and losing your drive
slicing, try the Linux LVM2 on Linux 2.6, it's not exactly the same, but
you'll be right at home.



On the topic of X and a dead mouse, I'd bet when you upgraded one or
both of two things happened.  The package provider for the kernel didn't
update or install the dynamic driver (modules) dependencies so that the
proper mouse drivers load on startup.  You can probably correct this by
listing the modules you want to force load in /etc/modules.

The second possibility is that when you upgraded, it probably decided to
be "helpful" and overwrote your X config file.  You can create your own
by shutting down X, and then running the -configure option on the X
server to create a new file to match your hardware, ie Xorg -configure.
Then move it into place over the old file when you are satisfied with
it.  I _always_ backup my X configs against the fact that upgrades do
strange things.  This is especially the case if you are playing with
Beryl/Compiz/AIGLX/Xgl. 

Personally, I'd be happier if they finished making the hardware support
on X more generic, so that you wouldn't have the majority of these
configuration issues.  Fortunately, they have recognized the wisdom of
that, and are moving in that direction, abeit slowly.

A third, and perhaps less common problem is that the gpm mouse daemon
can cause some X installs to stop using the mouse.  It's rather unlikely
these days though, unless some device packager was an idiot, and didn't
configure the /dev nodes properly.


Laters!

-- 
T.J.



====================================================
"I believe C++ instills fear in programmers, fear that the 
interaction of some details causes unpredictable results. Its 
unmanageable complexity has spawned more fear-preventing tools 
than any other language, but the solution _should_ have been 
to create and use a language that does not overload the 
whole goddamn human brain with irrelevant details."
-- Erik Naggum

-------------- next part --------------
A non-text attachment was scrubbed...
Name: tj.vcf
Type: text/x-vcard
Size: 117 bytes
Desc: not available
Url : http://mailman.mn-linux.org/pipermail/tclug-list/attachments/20070122/4f8bfeda/attachment-0001.vcf