| gabriel rosenkoetter on Fri, 7 Feb 2003 10:03:05 -0500 |
|
On Thu, Feb 06, 2003 at 10:17:26PM -0500, Chris Hedemark wrote:
> Also, this next one doesn't come with commercial support, but Red Hat
> is unofficially sponsoring Aurora Linux (basically Red Hat 7.3 for
> sparc). Aurora runs really well, it is stable, and developed primarily
> by Red Hat employees while they are on the clock (with full blessings
> of management).
>
> Of course when I was on the phone with my Red Hat guy I suggested to
> him that he get TPTB to get spot off of Aurora and onto RHL, heading up
> the sparc architecture. If RHL were stable on sparc architecture, it
> would be a real contender for real business.
I really don't think that's true, Chris. It wouldn't stand a chance
at our workplace, for instance. ("Hello, {SAS,Group1,Oracle,Veritas},
does your product work on Sparc Linux? Yes, I know that you support
Sparc Solaris, but I'd like to use Linux. No? Okay, well, that
settles that then.")
Granted, that can't change without there existing a "sanctioned"
Sparc Linux for these companies to support, but I'm afraid I don't
see a compelling reason to ever use anything besides Solaris on
Sparc hardware, for all the same reasons I don't see using something
other than Mac OS X on Apple hardware capable of managing it, if
that hardware is to be in production. (Using a non-Apple OS on
Apple hardware not capable of running Mac OS X is a must if you want
anything vaguely POSIX, but that hardware doesn't belong in
production anyhow.)
> That's not a Linux problem, though. That problem is with all the
> people writing OSS strictly for Linux/x86/gcc and not testing against
> other platforms. You can even run into this compiling OSS on *BSD/x86.
No, you can't. Because you can install the distributed Linux
binaries and run them faster on identical hardware. ;^P
But seriously, yes. If you presume that you're going to find GNU
libc at /lib/libc and use that path directly, I'm going to be very
upset with you. I'll be even more upset with you if you're wrapping
ia32 (or ANY) assembly in your C files and expecting me to use it.
> Also many developers don't take endianess into consideration, or 32 vs.
> 64 bit integers.
Agreed, but this IS a Linux problem. Linus is totally open about the
fact that Linux was actively designed to perform on ia32 hardware
without ANY thought given to kernel portability. That's totally
reasonable starting where he did: "I want an OS that functions
quickly and behaves mostly like Unix. And I'm not having any of this
micro-kernel architecture BS."
The problem is that kind of ethic is all over the place in software
written with Linux, whereas anything derived from a real Unix source
(or any developer from the pool who worked on such a system) got
there with portability already a primary necessity, so software
developed with Solaris 9 in mind still builds and links properly
on NetBSD/sun68k, allowing for library depedencies. (Binaries,
obviously, still don't work, but we're not discussing binaries
here.)
On Fri, Feb 07, 2003 at 07:38:52AM -0500, LeRoy Cressy wrote:
> Any of you who have compiled their own kernel, used Debian will know
> that Linux will run on almost any archectecture.
Oh, really? How's it do on the two acorn platforms (26 and 32)? The
vax? The pc532? The sparc64 (in 64-bit mode)? The pmax? The
sun{2,3}? The x86_64 (that's NOT the same as ia64)? Anything based
on a StrongARM? HP 300 or 700 series workstations?
How about detecting the hardware beyond the processor on the LUNA
68k series? The NeXT? Any MIPS-based SGI? The Brains mmEye? Digital
DNARD?
> With Linux there is no company that has control over the enviroment.
> The only real control is by Linus over the kernel. Why is IBM inviting
> Linux programmers to port their applications to S390 and even providing
> them login accounts on an S390.
So... what's this have to do with Chris's suggestion that Red Hat
should officially back a sparc port?
--
gabriel rosenkoetter
gr@eclipsed.net
Attachment:
pgpYLyGqF4Dhq.pgp
|
|