Re: [cobalt-users] Have SUN stopped supporting XTR?

[Travis Ogdon <togdon@xxxxxxxxxxxxxx>]

Dave Thurman (Mailing List Email) wrote:

> 271 dependencies!! If we live under the cobalt vacuum. That is a lot of
> re-engineering.
> 
> Take a look at Debian, they have some pretty good pkg installers and diff
> programs. Debian is 150% Open Source.
> 
> I think, barring copyright/license issues it would be a great start to
> continue where PC (pre-cobalt) left off.


I've used Debian for years so I'd have no problem with that. I'm currently
running about 1/2 my non-Cobalt boxes on Gentoo (all the newer ones) and the
other half on Debian. We've already got instructions from Robert Gash on how to
turn the Cobalt's into whiteboxes running Debian. In terms of distros I'd point
to Debian as the best for this project, although they too tend toward older
packages they're always on the ball in updating those packages should a security
problem arise.

If we do that, however, we lose really the only appealing thing about them at
this point: the interface. The interface may suck, but we've already paid for
it, and free is a great price... While I'm perfectly comfortable doing things
from the command line, most customers that I know are not. If we could in any
way maintain the interface it would be a bonus. I realize that we could install
sphera or ensim or even webmin, but these are Cobalts, and we're all already
familiar -- for better or worse -- with the Cobalts.

If we were to ditch the baby with the bathwater I feel that the following items
would need to be "reverse engineered" in order for the project to be useful to
the customer base that most Cobalts are currently serving:

1. The front panel. I believe that one could conceivably take a 2.4 kernel
rpm/pkg from Sun and grab the frontpanel modules. Except I just looked and the
driver for the panel appears to be compiled in. /me wonders if they're generic
enough that some other LCD driver would work... maybe even in a more useful way.
;) I'll see if I can track info on this down.

2. We'd need to work out how to get a working bootp session going with the
latest firmware so that we could do OS Restores. As far as I can tell we'd just
need a bootp server saying the right things. We wouldn't even need it to be in a
CD bootable format to start with. I would think however that we'd need the LCD
to remain useful enough to at least get to the bootp (network boot) point.
There's no way I want to pull drives out every time I want to reinstall. For
some of us that won't even be an option. Think about it like this... telling
someone in a NOC 3000 miles away to connect a crossover cable is easy, having
them pull the drive (making sure that they've pulled the right one) and then
mailing it to you, is not so easy... Eventually if we wanted others to benefit
from our work distributing ISOs of an alternative "OS Restore CD" would be nice.

Robert Gash may have more info on the first two. I believe that the frontpanel
will work up until the point that the kernel is loaded, so we probably don't
have to worry about it much until someone feels like making it useful. At the
very least I believe we'll be able to do a netboot from it.

3. We'd need some sort of panel. Webmin may have improved significantly in the
last two years, but last time I looked at it it was awful. I believe that Ensim
requires Red Hat 7.3 with certain additional RPMS, so a Debian base is probably
out. I'm not sure what Sphera needs. In all cases we're using resources in the
form of time or money, which is why it would be nice to be able to keep the
Cobalt interface.

Whenever the SF project is up send an announcement and we can take this off
Sun's list. Those who are even remotely interested might as well get themselves
a SF account now. Thanks to Bruce for letting us babble about it for this...

-- Travis