Subject: Linux on the O2

From: cypher <[email-masked]>
Date: Tue, 2 Dec 1997 16:50:40 -0500 (EST)

Hey,

I've been looking for some information to start working on an O2 port and
have basically gotten the response that managmement at SGI is not willing
to release hardware specs for the O2 (a mistake IMHO). Don't get me wrong
I think it's great that they allowed the Indy hardware specs to go out the
door, even if in a limitied fashion. 

(I ran into the same problem with a Nintendo, but don't you agree that the
 64 would make a great little "Network Computer"?)

I'm guessing that they're looking at this as if an Indy running Linux
won't really be that competetive with the O2s runnning IRIX, which I can
almost understand. 

I can speak from my personal experience. I working with various research
and production departments in a university that uses UNIX heavily. I can
honestly say that we have several platforms (Alpha, Sparc, and Intel) that
are running linux in production capacity. Also we have a lot of people
using linux on there workstations (the above platforms plus a slew of
others).. I think reallity is that people like Linux because they can get
it to do usefull things on so many platrforms. 

Certain organizations within the school, who run anything from O2s to
Octanes, to a Cave/Reallity Enginge, and an Origin 2000 (ok that
probably gave away who I was talking about) are considering Linux on
high-end Intel boxes as a inexpensive replacement for a $6000 dollar O2
running IRIX. I think this is partly due to the added cost of OS licenses
and various other software packages they have to pay for. It would be
ashamed if SGI lost a share of it's hardware sales (even if it is
the only in workstation market) market becasue some freeware wasn't
available to run on it. 

I realize that SGI has a vested interest in seeing IRIX succeed, and IRIX
is probably (it hurts to say this) better than Linux when running 128 (or
soon 4096) CPUs. Linux however, is great lightweight OS for workstations
especially. There's even more value added to am SGI running Linux that can
be introduced into an evironment where multiple high-preformance platform
type are desired (ie, Sparcs, Ultras, Alphas, SGIs. HPs, etc.) but a
single operating platform is needed. 

This makes perfect sense to me, but I don't know if I'm explaining
everything in the most effecient manner. I'd be _extremely_ happy to
discuss this with someone, especially people from SGI that have some sort
of influence on getting us the specs we need.

Right now I am basically in position (not officially supported by the
university of course, but there not telling me not to do it either, if you
know what I mean) where I've been given and Indy and an O2 to work on
porting Linux while on the clock. I don't know how much better it gets,
but I'm guessing not much... I won't have the hardware forever,
unfortunately, but if I can start making some sort of progress I can
possibly convince them of the need to let me keep it. 

I hope we can somehow figure out a way for SGI to help us out on this one.
;-)

---
Todd M. Shrider				Unix Workstation Support Group
(812)855-2627				2711 E. 10th Street
[email-masked]			Indiana University,
http://www.uwsg.indiana.edu/		Bloomington, IN 47408-2671

---

From: Ralf Baechle <[email-masked]>
Date: Tue, 2 Dec 1997 23:10:09 +0100

> door, even if in a limitied fashion. 

Yes, I think the way we will have to go is to demonstrate success of the Linux
port to the Indy.  If Linux on the Indy is a success then future projects
will be alot easier.

>  64 would make a great little "Network Computer"?)

The 4mb RAM or so that the N64 has are almost rediculous in context of a
real operating system ...

> the only in workstation market) market becasue some freeware wasn't

The sad thing is many people see NT as the solution of this problem ...

> single operating platform is needed. 

Indeed, you're right and the ambiguousity of the aim IRIX has to solve is
what makes the chance for Linux.

> of influence on getting us the specs we need.

Actually aside of the Linux developers like me there are also SGI engineers
interested in Linux as well as some ties on this list, so posting here was
a right thing to do.

I can well imagine that way can be found under which an O2 port could become
reality.  It's probably most important that customers (== $$$) ask for Linux
for their boxes and that word has to spread upto the higher managment.

> porting Linux while on the clock.

I suggest to work on the Indy.  There is Indy code that just needs a bit of
polishing and debugging, but essentially we're relativly close.  Working for
the O2 would mean that you'll aside of a bigger technical task you'll also
have to solve a political problem.

  Ralf

---

From: [email-masked] (Ariel Faigon)
Date: Tue, 2 Dec 1997 14:31:26 -0800 (PST)

Ralf wrote:
:
:On Tue, Dec 02, 1997 at 04:50:40PM -0500, cypher wrote:
:
:I can well imagine that way can be found under which an O2 port could become
:reality.  It's probably most important that customers (== $$$) ask for Linux
:for their boxes and that word has to spread upto the higher managment.
:
:> Right now I am basically in position (not officially supported by the
:> university of course, but there not telling me not to do it either, if you
:> know what I mean) where I've been given and Indy and an O2 to work on
:> porting Linux while on the clock.
:
:I suggest to work on the Indy.  There is Indy code that just needs a bit of
:polishing and debugging, but essentially we're relativly close.  Working for
:the O2 would mean that you'll aside of a bigger technical task you'll also
:have to solve a political problem.
:
It is nice to see interest in Linux from big SGI customers
(and I wish there was more of this :-)

I'll second Ralf.  Once we have an Indy port that's stable,
easy to install and maybe supported by Red-Hat or other
Linux distributors. Once we have something that's actually used
by many Indy owners (rather than just a handful), and once SGI
real customers (who bring SGI real money) seem to like it and
talk to their SGI reps about their interest in Linux on SGI,
only then, management may be open to opening more HW specs
to the public.

I believe there are a few hundreds of thousands Indy's out there.
If we can make one in ten of them (10%) switch to Linux, it would be
a great achievement and one that would certainly be noted
by everyone at SGI, including those who can approve releasing
further specs.

And let's not waste too many resources on the N64 port either :-)

As Mao Zedong used to say... hint, hint, nudge, nudge.
-- 
Peace, Ariel

---

From: "William J. Earl" <[email-masked]>
Date: Tue, 2 Dec 1997 14:33:41 -0800

> On Tue, Dec 02, 1997 at 04:50:40PM -0500, cypher wrote:
...
 > interested in Linux as well as some ties on this list, so posting here was

      I am one of the SGI engineers, and I would like to be able to release
the O2 specifications.  Releasing the Indy specifications basically happened
when we had started shipping O2, and the Indy was thus obsolete as a hardware
product.  I expect it would be easy to get approval when O2 is no longer
shipping, but doing it now will take some persuasion.

 > for their boxes and that word has to spread upto the higher managment.

       This is precisely correct.  If enough large customers ask for it,
it will happen.  The problem so far has been persuading management that
very many people would consider SGI boxes with Linux.  Part of the
problem is that a simple Linux port leaves much of the special features
of the SGI system unused, and really exploiting the graphics and digital
media features is a major project, when SGI already has too many projects
underway.  

 > have to solve a political problem.

      O2 is also a bigger technical problem, even with specifications in hand.
The drivers are actually easier than for Indy, but really exploiting the
O2 capabilities in graphics and digital media required a lot of enhancements
to the memory management, since O2 is a UMA system.  You could do a dumb
port, with a fixed frame buffer size, but then most of the O2 is wasted.

---

From: Christian Reisch <[email-masked]>
Date: Tue, 02 Dec 1997 15:32:56 -0800

William J. Earl wrote:
      O2 is also a bigger technical problem, even with specifications in
hand.
> port, with a fixed frame buffer size, but then most of the O2 is wasted.

	Actually I suspect the exact opposite would happen and hence
management's fear.  There are ALOT more people in the linux community 
than we have working at SGI.  It is very concievable that if the specs
were
available linux on O2 would massively out perform irix on the O2.  This
would
be a major embarrassment to the company.  Compare and contrast as Unixes
Solaris X86 and Linux on a given x86 box or Digital Unix and linux on an
alpha.

	Quality wise free software always beats proprietary software (if for
no other reason than it has to make fewer concesions to release
schedules
and politics) often embarassingly so.

---

From: "William J. Earl" <[email-masked]>
Date: Tue, 2 Dec 1997 15:45:27 -0800

> Solaris X86 and Linux on a given x86 box or Digital Unix and linux on an

       Many of us who want to see Linux on SGI systems expect that Linux
will be substantially faster on a number of primitive functions, especially
on uniprocessor systems.  We think of this as a nice club to persuade people
that low-level performance (a cache miss here and 100 instructions there)
really matters.  

       What I was talking about in regard to O2 was exploiting the
hardware functionality, such as the ability to use 100 MB of memory
for Photoshop, and then switch in seconds to using 100 MB of memory
for texture mapping, including real-time texture mapping of live
video.  Some of this is fairly generic library work, but some of it
requires fundamental changes to the operating system memory management
(assuming you do not impose a fixed partitioning of memory).

 > and politics) often embarassingly so.

       That is not always the case.  It is the case for GNU and Linux
software, due to the constraints imposed on the development and release
process, which tend to keep untested changes out of the main tree.

---

From: [email-masked] (Alan Cox)
Date: Wed, 3 Dec 1997 00:04:41 +0000 (GMT)

> only then, management may be open to opening more HW specs

Even if they don't its far far easier to reverse engineer the O2 working
from a stable Indy base than from a wobbly base platform. I don't personally
believe there is anything SGI could do to stop a Linux hacker making Linux
run on the O2

> As Mao Zedong used to say... hint, hint, nudge, nudge.

Yep. I don't see a big problem. Im not privy to SGI accounts but I refuse
to believe Irix itself does anything more than break even at best just by
taking published information on developer team size, and sales. In fact
I suspect its a loss maker like Solaris. If Linux sells SGI hardware Im sure it
will get us into good books 8)

Alan

---

From: [email-masked] (Alan Cox)
Date: Wed, 3 Dec 1997 00:09:26 +0000 (GMT)

> won't really be that competetive with the O2s runnning IRIX, which I can

Ah conspiracy theories abound. It could just be they didnt want anyone
cloning their hardware

> soon 4096) CPUs. Linux however, is great lightweight OS for workstations

Right now Linux scales to about 2-3 CPU's for generic stuff in 2.1.x maybe
4 if the hardware is sane (eg Ultrasparc). To go to 128-4096 CPU's really
involves changing the fundamental rules and building a sort of very tightly
interlinked multicomputer - AP1000+ on steroids as it were. There is some
interest in this from various people, notably in sticking 9 or 10 EBSA285
Digital strongarm boards in a PCI backplane and using PCI bus as the 
backbone network.

Alan

---

From: [email-masked] (John Wiederhirn)
Date: Tue, 2 Dec 1997 16:46:12 -0800

> believe there is anything SGI could do to stop a Linux hacker making Linux

As I've commented before, the problem isn't so much in getting the
kernel working (and working quickly).  The problem comes the second
you need to deal with graphics.  Given the O2's onboard multimedia
hardware, the situation only gets more complex.

Right now, there is no effective hardware abstraction mechanism in
Linux for graphics/multimedia.  With the Indy's rather simple gfx
capabilities, that isn't a tremendous hardship.  The hardship comes
when you are managing things like graphics pipelines, or hardware
that has very specific requirements for memory allocation and
alignment (and access).  Many of the necessary pieces simply do not
currently exist in the Linux kernel services.

While it would be possible to move these needs out to the X server
to some extent, not all of them can be handled that way (in specific,
the memory issues).  Further, there isn't really anything like
uniform functionality in Linux X servers for handling things such
as video I/O, genlocking, etc.  They exist in 3rd party servers,
but then the cooperation requirement rises again.

The proposal has come up multiple times to use the IRIX X server on
top of a Linux kernel.  Unfortunately, once again, that gets very
problemmatic on the more advanced gfx platforms such as O2 and Octane.
They both contain hardware-dependant sections of code which RELY on
certain kernel functionalities being present.  Factor in OpenGL and
the whole complexity level rises again.

Now, having said all that, I do believe the problem is solvable.
I think that with some modifications of the Linux kernel, it would
be quite possible to get the necessary abstraction to support
either an IRIX or customized third-party X server.  Further, it
would be nice if something equivalent to the SGI DMedia libraries
were available on Linux (with similar hardware abstraction), since
this is an area where simply put, Linux is FAR behind Windows{95,NT}
and SGI (and others).

Getting Linux on O2 probably isn't too difficult.  Getting USEFUL
O2/Octane/Onyx2 2D/3D graphics and multimedia under Linux would
be god-awful difficult with the current kernel/X situation.

My $0.02.

-- 
John Wiederhirn (DSD, Graphics Kernel MTS)        [email-masked]
    "I've always said there's nothing an agnostic can't do if he
     really doesn't know whether he believes in anything or not."

---

From: "Douglas F. Elznic" <[email-masked]>
Date: Tue, 02 Dec 1997 20:51:46 -0500

>And let's not waste too many resources on the N64 port either :-)
You must admit that the n64 would make a neat toy project.

--
Douglas F. Elznic
Email:
[email-masked]
Pager:
[email-masked]
"The tree of liberty must be refreshed from time to time with the blood of
patriots and tyrants."

---

From: Brendan Black <[email-masked]>
Date: Wed, 03 Dec 1997 15:34:16 +1300

David Chatterton wrote:
> 
> Maybe then my wife would let me buy one: "Yes dear, I'm doing real work" :)

I can imagine all sorts of 'uses' for something like this (linux on the
N64) - but one thing crops
up, I thought there WAS an N64 port.

I seem to remember something, may have been an article on IX magazine...
-- 
Brendan Black - Network Engineer, Telecom Internet Services
email:	[email-masked] (personal)	phone: +649 3555238
	                                mob:   +6425 2752667
The word "spine" is, of course, an anagram of "penis".  This is true in
almost fifty percent of the languages of the Galaxy, and many people
have attempted to explain why.  Usually these explanations get bogged
down in silly puns about "standing erect".
                -- Douglas Adams, "The Hitchhiker's Guide to the Galaxy"

---

From: [email-masked] (Richard Offer)
Date: Tue, 2 Dec 1997 18:58:25 -0800 (PST)

* $ from [email-masked] at "3-Dec: 3:34pm" | sed "1,$s/^/* /"
*
*
* David Chatterton wrote:
* >
* > Maybe then my wife would let me buy one: "Yes dear, I'm doing real work" :)
*
* I can imagine all sorts of 'uses' for something like this (linux on the
* N64) - but one thing crops
* up, I thought there WAS an N64 port.
*
* I seem to remember something, may have been an article on IX magazine...

It was a fairly obvious April Fool joke.

* --
* Brendan Black - Network Engineer, Telecom Internet Services
* email:	[email-masked] (personal)	phone: +649 3555238
* 	                                mob:   +6425 2752667
* The word "spine" is, of course, an anagram of "penis".  This is true in
* almost fifty percent of the languages of the Galaxy, and many people
* have attempted to explain why.  Usually these explanations get bogged
* down in silly puns about "standing erect".
*                 -- Douglas Adams, "The Hitchhiker's Guide to the Galaxy"

Never seen or heard that bit before.

*

richard.

-----------------------------------------------------------------------
Richard M. Offer        Widget FAQ --> http://reality.sgi.com/widgetFAQ
MTS-Core Design (Motif)
___________________________________________http://reality.sgi.com/offer

---

From: "William J. Earl" <[email-masked]>
Date: Tue, 2 Dec 1997 19:06:33 -0800

John Wiederhirn writes:
...
...

     Having implemented a good bit of the system-specific code for
Indy and O2, I agree entirely.  Without the above features, O2 is just
another, not especially distinguished, general purpose workstation,
except for having fairly fast I/O for its price.  The most interesting
thing about O2 is what you can do with graphics and multimedia, which
is otherwise possible only with far more expensive hardware.  In
different problem domains, something similar can be said of Octane and
the various SGI servers.

---

From: "Douglas F. Elznic" <[email-masked]>
Date: Tue, 02 Dec 1997 22:19:57 -0500

>I seem to remember something, may have been an article on IX magazine...
I found the article but nothing about any progress. I am looking for some
code samples or anything else on the project.
http://www.ix.de/ix/artikel/E/1997/04/036

---

From: [email-masked]
Date: Wed, 3 Dec 1997 08:01:20 +0100

> You must admit that the n64 would make a neat toy project.

Maybe - but I personally would cut my fingers off for other things like
doing the R10k port or SMP.

  Ralf

---

From: Chris Carlson <[email-masked]>
Date: Tue, 02 Dec 1997 23:46:20 -0800

> I hope we can somehow figure out a way for SGI to help us out on this one.

I also would like to see Linux ported to the O2 but also don't expect it to
happen in the near future.  We have to remember that SGI is a "hardware
company" and did not get where it is because of software.  To ask them to
divulge the inner workings of their bread-and-butter product, thus allowing
competitors to reproduce and improve upon the design is asking for disaster.
SGI does not fabricate their own chips and they have done their best to
provide access to their source (as long as it doesn't compromise their
hardware investment).  The only thing they have to sell is their design.
Since MIPS is not faring very well against competitors and there seems to me
a bit of doubt that they can stay ahead, what else does SGI have to sell?
Just their internal architecture and IRIX.

Giving the Linux community access to the internal design of the O2, Octane
and/or Origin would give any competitor the information they need to put SGI
out of business.  I don't blame the company for not wanting Linux on the
newer products until the next generation is released.

--
      +----------------------------------------+
      | Christopher W. Carlson                 |
      | e-mail home:      [email-masked]   |
      | WWW: http://members.home.net/cwcarlson |
      +----------------------------------------+

---

From: Oliver Frommel <[email-masked]>
Date: Wed, 3 Dec 1997 09:21:52 +0100 (MET)

> http://www.ix.de/ix/artikel/E/1997/04/036

sorry to disappoint you, but this was an April's joke (even confirmed in the
next issue of iX). IMHO the most advanced projects on N64 in terms of hacking
it without docs are some demos (you might take a look at www.dextrose.com)

o.

---

From: [email-masked] (Alan Cox)
Date: Wed, 3 Dec 1997 10:51:27 +0000 (GMT)

> I seem to remember something, may have been an article on IX magazine...

April issue I believe ...

---

From: "Douglas F. Elznic" <[email-masked]>
Date: Wed, 03 Dec 1997 13:04:53 -0500

At 01:31 PM 12/3/97 -0500, cypher wrote:
>
>Speaking of the N64,
>
>There now exists an emulator for it. Now if one were to port the kernel to
>the emulator and then burn that to a rom.... hmmm
>
>I guess you would at least want the 8mb memory upgrade, but 4mb would be a
>nice enough for an embeded linux.
>
What are the specs on Sun's javastation? They can not be a whole lot
greater that the N64.

---

From: "David Chatterton" <[email-masked]>
Date: Wed, 3 Dec 1997 13:05:35 -0500

On Dec 2,  8:51pm, Douglas F. Elznic wrote:
| Subject: Re: Linux on the O2
| At 02:31 PM 12/2/97 -0800, Ariel Faigon wrote:
| >Ralf wrote:
| >And let's not waste too many resources on the N64 port either :-)
| You must admit that the n64 would make a neat toy project.
|

David

-- 
David Chatterton                            (61-3) 9882 8211 (Tel)
R&D Software Engineer		            (61-3) 9882 8030 (Fax)
Performance Tools Group               http://reality.sgi.com/chatz
Silicon Graphics Pty.Ltd., 357 Camberwell Rd, Melbourne, Australia

---

From: cypher <[email-masked]>
Date: Wed, 3 Dec 1997 13:28:33 -0500 (EST)

> currently exist in the Linux kernel services.

I would definately agree here, but don't get me wrong. I'm not looking for
a quick solution. I think part of what makes Linux so great is that when
it does get ported to a new platform, the kernel learns something new.
What I mean is that by porting to the 02 and allowing Linux to develope a 
good "hardware abstraction mechanism" or better memory management or the
various other internals that allow it to run well on an 02 would also give
Linux as UNIX an advantage over the other UNIXes that only run on one or
two platforms. Don't mistake what I say to mean that ever change we make
the kernel for the O2 will improve Linux on every other platform, but now
and then something will improve other code, just like some code used for
other platforms will help improve the Linux on the various SGI platforms.

> but then the cooperation requirement rises again.

If there is one thing I have learned it is never to say never or isn't or
can't when talking to a group of Linux hackers... 

> this is an area where simply put, Linux is FAR behind Windows{95,NT}

I'm glad you think it is... 

> be god-awful difficult with the current kernel/X situation.

But not impossible ;-)

---
 find my pgp public key at http://www.cs.indiana.edu/~tshrider

---

From: cypher <[email-masked]>
Date: Wed, 3 Dec 1997 13:31:09 -0500 (EST)

Speaking of the N64,

---

---

From: cypher <[email-masked]>
Date: Wed, 3 Dec 1997 13:32:45 -0500 (EST)

> I seem to remember something, may have been an article on IX magazine...

I think if you take another look at that magazine you will notice that it
was published on April, 1st. I've read the same article...

---

---

From: [email-masked] (Alan Cox)
Date: Wed, 3 Dec 1997 18:39:35 +0000 (GMT)

> What are the specs on Sun's javastation? They can not be a whole lot

The existing one is a Sun4 box with funny keyboard and other oddments. DaveM
has one if someone knows how to create time by magic ;)

---

From: cypher <[email-masked]>
Date: Wed, 3 Dec 1997 13:42:09 -0500 (EST)

Now your thinking... ;-)

I have a friend who is doing a trace of N64 as we speak... Nintendo won't
even consider talking to use, let alone supporting this, so were doing it
on our own. As soon as I have info I'll make it available... 

---

---

From: cypher <[email-masked]>
Date: Wed, 3 Dec 1997 13:49:39 -0500 (EST)

I'm really glad I got such a great response to my message. Everyone's
input is greatly appreciated. 

I'll try and summarize everyones point in another mail as soon as I get a
chance hoping that the "Big Brother" at SGI is listening... 

Until then, here I come Indy... 

(Although wouldn't it be nice to be able to have IU ask for Linux the 
 next time they decide to add more nodes to there Cray Origin 2000. I
 mean, we could always just use that Intel Paragon we have sitting in 
 the cornere)  ;-)

---

---

From: Warner Losh <[email-masked]>
Date: Wed, 03 Dec 1997 14:19:57 -0700

In message <[email-masked]> cypher writes:
: There now exists an emulator for it. Now if one were to port the kernel to
: the emulator and then burn that to a rom.... hmmm

Hmmm.  Interesting.  How much does it cost to burn a EEPROM for the
N64?  I suspect the anser is $500 for the first one, and EEPROM cost +
$0.01 for each additional one due to startup costs.

Also, do you have a URL for the N64 emulator?

If memory serves, the N64 has a VR4700 chip in it made by IDT or some
such.  I have an IDT eval board that has a R4700 on it right now,
which would be enough to get Linux running on the chip.

But one does have to ask the question of WHY?  What can you get from
an N64 that would make it worth running Linux on it?

Warner

---

From: Chad Campbell <[email-masked]>
Date: Wed, 3 Dec 1997 16:16:21 -0600 (CST)

> an N64 that would make it worth running Linux on it?
I don't know much about the N64, but it should have at least two game
controller ports for a keyboard and a mouse, and I think I heard that
there were storage devices available for it.  With an upgrade to 8 MB, it
sounds like it could possibly be made into a cheap NC or WebTV type of
product.  Of course, as others have mentioned, any kernel port is valuable
at least in the sense that we might learn something new which could aid in
the design of kernels for other architectures.

Chad

Chad Campbell
Web Manager, University of Kansas Natural History Museum

---

From: "William J. Earl" <[email-masked]>
Date: Wed, 3 Dec 1997 14:31:33 -0800

> the design of kernels for other architectures.

      I have heard of several companies using Linux as a sort of embedded
OS, as would be the case when using it on N64 to build an NC or WebTV device.
One interesting area for development, both in the embedded space, and on
the SGI workstations, would be in regard to realtime support, which is
needed for digital media.  By realtime, I mean not fast interrupt response,
but rather precisely scheduled repetitive events (such as driving the Indy
audio ports every 1 ms. with at most 0.9 ms delay no matter what else is
going on).

---

From: "Douglas F. Elznic" <[email-masked]>
Date: Wed, 03 Dec 1997 17:38:54 -0500

>the design of kernels for other architectures.
Namely the MIPS arch.

---

From: [email-masked] (Alan Cox)
Date: Wed, 3 Dec 1997 22:48:43 +0000 (GMT)

> audio ports every 1 ms. with at most 0.9 ms delay no matter what else is

This exists although not for the MIPS platform and not directly accessible
from user space. NMT have a RTLinux kernel that allows real time drivers
to hit targets well well under 0.1ms.

---

From: Lige Hensley <[email-masked]>
Date: Thu, 4 Dec 1997 00:39:07 -0500 (EST)

> Just their internal architecture and IRIX.

I was under the impression that MIPS was doing pretty well.  Someone
correct me if I am wrong, but I remember reading that the vast majority of
MIPS chips wound up in things other than SGI computers (i.e. Sony
Playstation, Nintendo 64's, etc.).  

>From what I read about the R12K, MIPS would appear to be near the top of
the CPU game as far as raw procesing power.  When compared to a Pentium-II
350 MHz, a 300MHz R12K was about equal in integer ops and nearly 5 times
the speed with floating point ops.  It's not an Alpha, but it far better
than anything cooked up at Intel.  (ok, maybe I am a little biased, but
real men use RISC).

-lige

----------------------------------------------------------------
Slam Foot Neck!  Ride the wave.  Touch Touch Touch.  I'm cereal.
e-mail: [email-masked] 
www: http://www.iusd.iupui.edu/~henslelf
  o__            
  ,>/'        Network Coordinator.  Compression, Inc.
 (_)\(_)  	http://www.carpediem.com

---

From: "David S. Miller" <[email-masked]>
Date: Wed, 3 Dec 1997 21:48:53 -0800

Date: Thu, 4 Dec 1997 00:39:07 -0500 (EST)
   From: Lige Hensley <[email-masked]>

   than anything cooked up at Intel.

Isn't R12K pre-production still, out in a few months or something like
this?   Anyways, if this is the case you might as well compare in the
predicted Ultra III figures in your analysis as well if this is a
vapor ware cpu performance comparison ;-)

   (ok, maybe I am a little biased, but real men use RISC).

Indeed.

Later,
David S. Miller
[email-masked]

---

From: Lige Hensley <[email-masked]>
Date: Thu, 4 Dec 1997 09:06:11 -0500 (EST)

On Thu, 4 Dec 1997, David Chatterton wrote:

> On Dec 4, 12:39am, Lige Hensley wrote:
> | >From what I read about the R12K, MIPS would appear to be near the top of
> | the CPU game as far as raw procesing power.  When compared to a Pentium-II
> | 350 MHz, a 300MHz R12K was about equal in integer ops and nearly 5 times
> | the speed with floating point ops.  It's not an Alpha, but it far better
> | than anything cooked up at Intel.  (ok, maybe I am a little biased, but
> | real men use RISC).
> |
> 
> But the best we have right now are 200MHz R10Ks, so we are relying on our
> server architecture to compete with everyone else. We all hope that MIPS can
> continue to produce chips that are competitive (and the R12 looks great on
> paper), but Intel has a lot more engineers and R&D budget to leap frog ahead in
> the long run. That's life.

As someone mentioned earlier (and what I am lead to understand) the R12K
is in pre-production now, which is much more than a concept on paper.  Is
this correct? 

As far as Intel being able to leap-frog ahead in the long-run, I wouldn't
count on it.  I've always believed that money can't buy everything,
especially in engineering.  

Or maybe I like to root for the underdog :-)

-lige

---

From: "Greg Chesson" <[email-masked]>
Date: Thu, 4 Dec 1997 08:51:26 -0800

Mips does quite well with cpus in the embedded systems area: about
35 Million components/year at recent count.  This area accounts for
good revenue for Mips and its vlsi partners.

The R12000, which is an improved R10000, and its planned shrinks
and process upgrades are competitive with other processors in all areas
except for extreme floating point.  Mips had a best-of-breed raw floating
point cpu project that was cancelled because it was deemed not competitive
enough in integer performance to serve in all but a few platforms.

Mips processors tend to be employed with more powerful cache and memory
and io subsystems than equivalent Intel parts.  This natually leads
to differences in cost/price.

Another little-appreciated factoid: in order to comply with Intel specs
for system transceiver components used with high-performance Intel cpus,
one needs to use a $25 component.
Nearly all cheap/fast motherboards use a $2 component that works
"most of the time."

g

---

From: "Greg Chesson" <[email-masked]>
Date: Thu, 4 Dec 1997 08:55:14 -0800

First silicon R12Ks exist and are being tested in the lab.
It is premature to make any predictions about eventual clock rate.

Production manufactured systems are usually available about 12 months
from first silicon of the processor chip.  In the case of the R12K
this time will probably be reduced because the chips are going into
the "stable" R10K hardware/software environment.

g

---

From: "Greg Chesson" <[email-masked]>
Date: Thu, 4 Dec 1997 09:03:53 -0800

I've been reading the O2 thread with great interest.

It seems to me that a "vanilla" port of Linux on the O2 is quite feasible.
Several writers have agreed.

But full support in Linux for extremem platform-dependent multimedia
hardware is problematic.  This has also been mentioned by several writers,
some of whom developed the OS code.  The problems are twofold: it would
be a non-trivial task even with full documentation to provide complete
support for O2 hardware since the job would require as much new invention
as it would require porting, and second- full disclosure
of the inner workings is viewed as too much of a giveaway to present
and future competitors.

Makes me wonder whether the Indy port of Linux could be ratcheted into
a vanilla port for the O2, and then perhaps SGI could produce binary
loadable drivers for the missing bits.

g

---

From: "William J. Earl" <[email-masked]>
Date: Thu, 4 Dec 1997 09:22:12 -0800

> loadable drivers for the missing bits.

      For IRIX, most of the O2 work was really in areas which, in
linux, would be reasonably general purpose.  In particular, being able
to allocate large pages (64 KB tiles on O2) at any time, no matter how
long the system has been running, was a major change, and would be
useful for performance reasons on any system with variable page size,
since it helps ordinary programs with large address spaces on
large-memory systems, as well as supporting the O2 graphics and
digital media.  Similarly, having solid time-scheduled realtime
support is broadly useful.  For digital media, one needs a reasonably
portable API, and applications on top of it, which supports high
performance.  With those facilities in hand, doing the drivers is not
all that difficult.  Providing those facilities, however, is a substantial
project, and not especially tied to SGI hardware.

     In graphics, if linux winds up with an IRIX-compatible kernel
graphics driver on some SGI boxes, the IRIX Xsgi, libgl.so, and
libGL.so platform-specific binaries could run on linux.  Note that
each of our systems comes with a license for the then-current version
of these components, so loading linux does not preclude using the IRIX
components, although, at present, they may not be shipped in a linux
distribution.  Since they are only useful on SGI hardware, perhaps SGI
could make arrangements to permit "stable" binaries to be included in
linux distributions for selected platforms.

---

From: [email-masked] (Alan Cox)
Date: Thu, 4 Dec 1997 18:54:18 +0000 (GMT)

> loadable drivers for the missing bits.

If that is SGI's attitude to the thing then theres an Indy on my desk waiting
for someone to ship it back.

Actually Ariel there sort of is - unless anyone knows why the monitor would
have decided to fold the middle third of the picture in really oddly ..

Alan

---

From: [email-masked] (Alan Cox)
Date: Thu, 4 Dec 1997 18:59:33 +0000 (GMT)

> to allocate large pages (64 KB tiles on O2) at any time, no matter how

I assume you mean physical tiles. 64K tiles on Linux is actually quite tricky
- creating them and allocating them is ok its the fact theres no current
vm way to say move this and make me a tile.  (the kernel allocated objects
arent a problem as the kernel can allocate drawing from tiles itself)

> libGL.so platform-specific binaries could run on linux.  Note that

This is certainly a very good starting basis but its not a "complete" 
answer. Also of course one day Indy + IRIX always together wont be an
automatic fact - I dont actually believe it is in the EEC right now anyway

Alan

---

From: Alex deVries <[email-masked]>
Date: Thu, 4 Dec 1997 14:41:14 -0500 (EST)

> have decided to fold the middle third of the picture in really oddly ..

Not to be too critical, but my monitor only sort-of works. Everyonce in
awhile it'll black out, and I won't see anything until I give it a whack.
I think there's a wire loose in there. It's not too troublesome, but my
neighbours are starting to wonder.

Anyway, I'm still happy for free hardware.

- A

---

From: [email-masked]
Date: Thu, 4 Dec 1997 23:01:22 +0100

> project, and not especially tied to SGI hardware.

Indeed - and you're pointing to what I consider _the_ problem with
current Linux kernels.  Linux uses the ``buddy system'' described by
Donald Knuth's ``Algorithems And Data Structures'' to maintain it's
free pages.  This algorithem results in massive fragmentation even
after a short uptime.

On a Linux box you can press <shift> + <scroll-lock> and the kernel will
print some memory statistics to the console or syslog.  For the
purpose of illustrating things I've appended those numbers from a
couple of systems.  As it is easy to see Linux doesn't do a good job
at all.

As a result certain kernel subsystems that need large buffers may fail
on a loaded machine.  Typical example is the floppy driver allocating
a track sized buffer.  Much worse - the networking code sometimes does
atomic allocations.  Atomic means it cannot sleep for swapping etc.
On machines that have sufficiently fragment memory as a result network
services like NFS using >=4kb blocks (results in allocation of 8kb
blocks) are stalling.

For my 8mb PC this may mean it will sometime stop NFS serving when
nothing else is running at the same time just because the compile I
was running before resulted in completly fragmented memory leaving
no chunks bigger than a single 4kb page.  Unfortunately there is nothing
that 100% prevents this to happen under all circumstances on machines
with more memory.  I've seen reports of machines with >128mb of memory
having 2mb of free memory left all in 4kb chunks.

> linux distributions for selected platforms.

This sounds like a possible way to go.  From the technical point of view
I'd prefer to rebuild those binaries - if possible - as native Linux
binaries.  It'd reduce memory usage significantly.

As far as technical documentation about the O2 goes - does a model like

 - full disclosure of documentation under a NDA to some Linux developers
 - the NDA would contain an expiration date, maybe one or two years, after
   which the covered information can be disclosed because SGI does no
   longer consider nondisclosure a vital for it's bussines.
 - disclosure as binaries:
   Parts that are considered to be based on information that SGI thinks
   should not be disclosed could be made available as binaries.
 - disclosure as source code:
   This would be drivers for disk/network (as I understand SGI doesn't
   consider this part of the O2 to be too valuable) and a part of the
   technical details about GFX that allow to implement a reasonable ASCII
   console, maybe a simple X server and to spread these components as
   source.

sound acceptable?  While I believe we should currently not try to go for
an O2 port because we still have same homework to do, I also think it's
important that we find a solution that allows Linux to be used on SGI
boxes before they can be considered old iron like the Indy.

Another important thing to consider is that porting Linux to the O2 takes
time.  So until we Linux developers have produced an acceptable O2
implementation an NDA wouldn't even hurt the idea of Free Software very
much.  It's also time during which the value of the non-disclosed
information for SGI decreases, so why shouldn't we - unlike for the
Indy port - try to overlap time of non-disclosure of technical information
with working on the port?

Another argument for or port to current SGI hardware - many people
want to prototype their embedded applications on a desktop using the same
operating system and CPU type.  For many embedded applications Linux is
one of the operating system of choice, after all Linux has many points
where it beats IRIX.  Most important the price per license.  For many
embedded applications MIPS is the CPU of choice.  So for developers of
such appliances running Linux, not IRIX, on an O2 could well be the OS of
choice even at the price of loosing IRIX's advantages.

One of the people interested in Linux for such an MIPS based appliance
being prototyped on a UNIX system was Kevin Kissel ([email-masked]).
So I guess even for SGI having a Linux desktop should be interesting.

  Ralf

---

From: "David Chatterton" <[email-masked]>
Date: Thu, 4 Dec 1997 17:08:05 -0500

On Dec 4, 12:39am, Lige Hensley wrote:
| Subject: Re: Linux on the O2
| On Tue, 2 Dec 1997, Chris Carlson wrote:
|
| >
| > I also would like to see Linux ported to the O2 but also don't expect it to
| > happen in the near future.  We have to remember that SGI is a "hardware
| > company" and did not get where it is because of software.  To ask them to
| > divulge the inner workings of their bread-and-butter product, thus allowing
| > competitors to reproduce and improve upon the design is asking for
disaster.
| > SGI does not fabricate their own chips and they have done their best to
| > provide access to their source (as long as it doesn't compromise their
| > hardware investment).  The only thing they have to sell is their design.
| > Since MIPS is not faring very well against competitors and there seems to
me
| > a bit of doubt that they can stay ahead, what else does SGI have to sell?
| > Just their internal architecture and IRIX.
|
| I was under the impression that MIPS was doing pretty well.  Someone
| correct me if I am wrong, but I remember reading that the vast majority of
| MIPS chips wound up in things other than SGI computers (i.e. Sony
| Playstation, Nintendo 64's, etc.).
|

That's the point, MIPS is making a healthy profit from _non-SGI_ products
though like Windows CE, N64, Playstation as you suggested. Not that I have a
problem with that...

David

---

From: Eric Kimminau <[email-masked]>
Date: Thu, 04 Dec 1997 17:28:55 -0500

> Anyway, I'm still happy for free hardware.

To both Alex and Alan: Both of those systems "should" be under SGI
support. If you will run netstat -ia and give me the serial numbers
(08:00:69:xx:xx:xx) Ill look them up to make sure. If they do, you can
just call 1-800-800-4SGI (4744) and have them ship you brand new
monitors.

Eric.

-- 
Eric Kimminau                           System Engineer/RSA
[email-masked]                     Silicon Graphics, Inc
Voice: (248) 848-4455                   39001 West 12 Mile Rd.
Fax:   (248) 848-5600                   Farmington, MI 48331-2903

                 VNet Extension - 6-327-4455
              "I speak my mind and no one else's."
       http://www.dcs.ex.ac.uk/~aba/rsa/perl-rsa-sig.html

    When confronted by a difficult problem, solve it by reducing 
    it to the question, "How would the Lone Ranger handle this?"
	
         "I am the great supportfolio, do you have http?"

---

From: [email-masked] (Alan Cox)
Date: Thu, 4 Dec 1997 22:44:49 +0000 (GMT)

> just call 1-800-800-4SGI (4744) and have them ship you brand new

Ok I'll chase your UK office. Firstly it might be something dumb I can do to
make it come back right 8)

---

From: "William J. Earl" <[email-masked]>
Date: Thu, 4 Dec 1997 15:33:01 -0800

[email-masked] writes:
...
 > free pages.  This algorithem results in massive fragmentation even

     Are you saying that linux uses the buddy system for all of memory,
or just for the kernel heap?  (I would be surprised if it were used
for other than the kernel heap, although that is bad enough.)  

...
 > having 2mb of free memory left all in 4kb chunks.

      One thing we do in IRIX is to always allocate kernel heap buffers
of 1 page or larger as an integral set of pages, mapped into kernel
virtual space, but not part of the main kernel heap (which is used only
for smaller buffers).  Except for fragmentation of the kernel mapped
space pool (a pool of address space, not real memory), this guarantees
you can always get large buffers if pages are available.  Fragmentation
of smaller buffers of course requires a better heap manager, although
using zone allocation (where a zone has blocks all of the same size,
and there are zones for most popular sizes) helps a lot and is also
faster than using the regular heap manager.

...
 > boxes before they can be considered old iron like the Indy.

      We (the SGI people on the list) will have to talk with the
general manager for the O2 platform.  I personally think that would be
ok.  As I mentioned in my earlier message, a lot of the IRIX value
added for O2 is in essentially generic facilities, not in the
device-dependent drivers, and we already tell customers in high level
terms about the overall architecture (such as the unified memory for
graphics and I/O), so there is not much in the hardware documentation
which needs to be treated as a trade secret.  Conceptually, the O2 graphics
pipeline is fully described by the OpenGL reference (software) implementation
and specification, so the hardware value added is in the internals
of the implementation, not in the interface (which is essentially
a large part of the OpenGL pipeline).

---

From: [email-masked]
Date: Fri, 5 Dec 1997 01:17:45 +0100

> for someone to ship it back.

Actually I think there is a lot that can be negotiated.  In one of my
previous postings I've already gone a bit into this.  Some people at
SGI are *alot* more Linux-friendly than you think.  Furthermore given the
fact that way more UNIX systems run Linux than anything else definately
has impressed a couple of people in the higher levels at SGI.

Given that the way the Free Software comunity and the world of the
proprietary software think is radically different we have to accept
that a big company like SGI doesn't take make the way from proprietary
software to Free Software in one big jump.  Between black and white
there is grey ...

And after all - resistance is futile.  "You can't outrun Penguin from
Borg.  You can't destroy him.  If you damage him, the essence of what
he is remains ...  he regenerates and keeps coming.  Eventually you'll
weaken.  Your reserves will be gone.  His is relentless"
                                             - Q, Star Date 42761.3

 ;-)

  Ralf

---

From: [email-masked]
Date: Fri, 5 Dec 1997 02:33:16 +0100

> for other than the kernel heap, although that is bad enough.)  

The buddy system is only used to maintain the pool of free pages.  The
buddy system has the advantage that it is very fast.  On top of this
lowest level we've got additional layers:

 - The ``slab allocator''.  It's basically what Jeff Bonwick from Sun
   describes in his USENIX paper from '94.  Miguel has the paper on his
   homepage.  The slab allocator has been added during the Linux 2.1.x
   series.
 - The ``simp allocator''.  Yet another memory allocator for cached objects
   that has been added during 2.1.x.  Pretty fast and still under
   development.
 - kmalloc() is the kernel equivallent to malloc(3).  It's mostly used
   for allocations smaller than a single page but can be used to allocate
   upto 128kb.  For Linux 2.0 kmalloc() is getting it's pages directly from
   the free page pool.  For Linux 2.1.x kmalloc is implemented on top of
   the slab allocator.
   Both implementations are directly or indirectly getting the memory from
   the pool of free pages (that's KSEG0 on MIPS), therefore have to
   live with the advantages and disadvantages of the buddy system.

> faster than using the regular heap manager.

Actually we also have this type of kernel virtual memory in Linux.  On
MIPS the address space >=KSEG2 is being used for that purpose.  The
functions vmalloc(9) and vfree(9) are used for that purpose.  However
vmalloc is rarely being used in the kernel.  Among the reasons is that
vmalloc() is slower than other types of memory allocation.  Furthermore
the primitive PC-style DMA hardware often does not have the required
support to use vmalloc'ed memory as scatter/gather buffer.  Finally
accessing vmalloced memory may result in TLB reloads on some architectures
while pages allocated from the pool of free pages don't.  So accessing
vmalloced memory may imply a performance penalty.

> a large part of the OpenGL pipeline).

Well, sounds good.  You're making the differenciation between the interface
and the implementation of the O2, something that so far people I've been
discussing with haven't done.  As a software guy all need is the
interface and maybe a peek into internals for a better understanding of
the interface.

  Ralf

---

From: Chad Campbell <[email-masked]>
Date: Thu, 4 Dec 1997 21:25:47 -0600 (CST)

This is my second to last semester, and I'm now in the OS class.  I have a
question about page miss resolution.  Does the kernel use a global or 
local strategy to determine which pages get swapped out?  My teacher,
Victor Wallace, has done research on using global resolution strategies,
and has found it to be supperior, but he didn't know of any OS that
actually uses it.

Chad Campbell

---

From: [email-masked] (Alan Cox)
Date: Fri, 5 Dec 1997 09:06:55 +0000 (GMT)

> > for someone to ship it back.

Ok before this goes too far let me point of that there were a certain number
of invisible humour/sarcasm tags on that comment as a lead in to the monitor
info.

To start with if Dave can figure out an ultrasparc and we can crack the 
Macintosh 68K nobody in SGI could stop us 8)

Alan

---

From: [email-masked] (Ariel Faigon)
Date: Fri, 5 Dec 1997 10:27:22 -0800 (PST)

[One of my filters just hit this on  comp.os.linux.misc
 I think the guy has a point and I thought it was interesting]

  Subject: M$'s strategy against Linux: nightmare scenario 
  From: [email-masked] (Louis-David Mitterrand) 
  Date: 4 Dec 1997 19:06:27 GMT 
  Message-ID: <[email-masked]> 
  Organization: Aparima inc. 
  Newsgroups: comp.os.linux.misc  , comp.os.linux.advocacy  

  Using Linux every day, one never ceases to learn and be amazed at the
  creativity and cleverness of Linux contributors worldwide. This platform
  is seriously coming of age: some major institutions are starting to rely
  on it for production work. 

  Like Microsoft software at some time, Linux entered the enterprise
  through the back door right under the nose of IT staff sometimes. Now
  network admins are discovering its reliability, "suits" never had a
  chance to veto it because it never was a budget item, engineering likes
  to work with it at home. Then one day you wake up and you realize Linux
  has become ubiquitously present in your enterprise without having been
  officially invited. And everybody learns to like the Penguin: friendly,
  never raises a fuss, does its job, doesn't eat much.

  OK, now what's next? Linux means business, *is* business. The coming of
  age is very real: RedHat 5.0 is winning rave reviews for its ease-of-use
  and idiot-proof installation "even easier than NT", the  Wine project
  (windows emulator) is starting to make serious progress and some major
  win32 apps are beginning to work. It won't take much more than another
  year to see comprehensive support for Win95/NT apps under Linux. Next
  thing, people will ask "why shell out $800 for NT Server, when I can get
  the same more reliable services from a $50 RedHat CD? These MS support
  people never answer the phone anyway, and I can run Office97 with Wine."

  Hmmm.. I see a pattern there. NT 5.0 delayed (again..) and RedHat is
  there today. Anyway the next question I have is a major one (two): 

  - now that Linux is starting to appear on MS's radar screen what is MS
    going to do about it? 

  - How should the Linux community ensure Linux's future, freedom and
    copyrights against a big, greedy, powerful corporation whose central
    product (NT) is threatened by a free unix clone?

  I want to rely on Linux for everything I do in my little consulting
  operation. "rely" means I want to be sure nobody will be able to
  highjack Linux. 

  Bill Gates is not a fool and he is certainly not one to underestimate
  the power of grassroots movements. I'm sure he already has a strategy to
  deal with Linux at some point. Or he is seriously thinking about one.
  The problem is: I bet this strategy doesn't rely on fair competition in
  open markets and feature-to-feature comparisons. Why? Simply because it
  is impossible to compete against the Linux community's talent pool on
  the basis of performance and features. And I'm deeply concerned. What is
  the man preparing? Call me a paranoid and I'll answer "only the paranoid
  survive" (dixit Andy Grove, 95% market share).

  One main concern I have is Transmeta, inc., Linus Torvalds' employer.
  This company is more or less controlled by Paul Allen, the Seattle
  billionaire and Microsoft founder. Mr Allen is still a MS board member
  and 10% (?) shareholder. Mr Allen is also one of Bill Gates' closest
  friends (is he has any) and confidants. Weren't they together on Fortune
  Magazine's cover less than a year ago? It is of public knowledge that
  they consult regularly one a variety of subjects, especially on the
  Microsoft Corporation strategy. Now in my nightmares a conversation
  between the two of them often recurs:

  - B.G: "Hey Paul, this guy Linus Torvalds is finishing his studies out
    there in Finland, the stuff he's making - this Linux OS - looks pretty
    neat, why don't you make him an offer he can't refuse?"

  - P.A: "No problem Bill, I'll park him at Transmeta, they're making hot
    stuff and I'll give him plenty of free time to keep developing this
    Linux thingy, under our watchful eye."

  - B.G: "Right. Then if it gets out of control we can buy you out and put
    our stamp on the stuff. After a couple years we can claim all this was
    developed on company time. Then we'll just merge it into NT."

  - P.A: "I'll give you an option to take over at $xxx,xxx,xxx."

  This is a nightmare scenario of course. I have a deep respect for Linus'
  work and way of managing the kernel development. But isn't he a bit
  young and inexperienced against the West Coast's big guns? Hasen't he
  fell into a huge trap?

  Imagine Microsoft taking over Transmeta at some point in the (not so
  distant) future and saying that Linux code is tainted with MS
  copyrighted code because Linus worked on it while at Transmeta (now an
  MS affiliate)... Imagine RedHat, Caldera, Debian obliged to take down
  their FTP servers because of the legal tangle about Linux... Even if MS
  is rebutted in court and Linux comes out clean as *truly free* software
  it will take at least two years (or more) to clear out the smoke.
  Meanwhile NT will have made major inroads everywhere. And the Linux
  threat will be seriously diminished.

  I hear people yelling "how about the GNU license you dork?". Hmm.. and I
  answer: has anybody challenged the GPL in the courts? Has the FSF ever
  had to defend it against a mean, influential and deep-pocketed
  corporation? Like Stalin asking "The Pope? How many armored divisions?"
  I ask "GNU? How many lawyers, lobbyists, cash-on-hand at the bank? Up to
  now nobody cared about GNU software. No software company saw it as a
  threat. These bearded, suspender-wearing UN*X idealists didn't bother
  anybody. Today GNU software is becoming essential and a competitive
  threat. SUN should be even more worried than MS on that count.

  Please somebody tell me this nightmare scenario is just plain stupid,
  impossible and I'll be happy and go away and sleep better...

  Cheers.

  -- 
                          
  Louis-David Mitterrand  
  [email-masked]

-- 
Peace, Ariel

---

From: Mike Acar <[email-masked]>
Date: Fri, 05 Dec 1997 16:31:02 -0500

[Snip: Linus works for Transmeta, which Microsoft might buy in order to
"acquire" Linux. Legal or not, the legal fight might hamper Linux's spread well
enough to significantly reduce the threat to NT.]

This isn't a particularly big worry to me. The GPL aside, Linus's contract with
Transmeta almost definitely states specifically that Transmeta has no rights at
all to software Linus wrote before he was employed there; similarly, it almost
definitely excludes rights to software Linus writes on his own time. Further,
I'm not sure how much of the kernel Linus actually "owns" anymore; my
understanding (flawed it may be) is that he's primarily coordinating kernel
release and design, and not actually writing nearly as much code as he did. If
this is the case, Linus himself might not be able to claim ownership of the
kernel anymore.

Of course, I'm not a lawyer, so I speak from a position of significant
ignorance; handfuls of salt all round. But I really don't think that MS is going
to be able to use intellectual property to attack Linux.

What does worry me, however, is that Intel, MS and others are making significant
progress in taking control of the PC architecture. With the patented Slot-One
and Slot-Two, Intel is putting serious pressure on its competitors in the
motherboard markets; between Slot-One, Slot-Two, and buying the Alpha, I expect
the threat to Intel's dominance of the PC CPU market to virtually disappear.
The I2O SIG will control access to the hardware docs on the next generation of
fast PCs, and the licensing terms - let alone the SIG member's veto power over
membership applicants - are in fundamental conflict with Linux and the other
free PC Unices. Microsoft might not need to try to crush Linux directly; there's
a distinct possibility that Linux simply won't run on the next generation of
PCs.

But maybe that's just my negativity speaking. I doubt that even a large part of
the PC industry would like to see the architecture grow proprietary; perhaps SGI
could lead the way in providing a design for a new PC-class architecture which
is Open Hardware compliant/approved.

Along those lines, are there any plans for providing Linux drivers for the
Wintel hardware SGI's announced for next summer?
-- 
Mike Acar - [email-masked] - "This autumn is sad beyond belief." - Kafka

---

From: [email-masked] (Ariel Faigon)
Date: Fri, 5 Dec 1997 14:20:36 -0800 (PST)

Mike wrote:
:
:[Snip: Linus works for Transmeta, which Microsoft might buy in order to
:"acquire" Linux. Legal or not, the legal fight might hamper Linux's spread well
:enough to significantly reduce the threat to NT.]
:
:This isn't a particularly big worry to me.
:
Just to make it clear, I just forwarded the piece and I don't necessarily
agree with the poster on most points.

To me the day MS starts using legal threats and acquisitions in order
to stop Linux can be declared the day Linux has won.  Unfortunately
for us Linux lovers, before Wine can run _all_ the Win32 apps without
_any_ problem (not so close IMHO) and before Linux has a dumb-user GUI
that really hides all the incredible (for the average Windows user)
Unix complexities from the majority of the user base it doesn't have
a chance of world domination, not even in the enterprise servers
low-end space.

:
:What does worry me, however, is that Intel, MS and others are making
:significant progress in taking control of the PC architecture.
:
Excellent and valid point.  Note that there are new forces on the
rise which directly clash with Intel interests.  I'm refering to
both the existing National-Semiconductor + Cyrix merger and AMD,
and to the (about 9 at last count) startups working on x86 compatible
designs.  The next few years will be interesting and Intel might very
probably not emerge as the winner.

:
:Along those lines, are there any plans for providing Linux drivers for the
:Wintel hardware SGI's announced for next summer?
:
I can understand the curiosity and interest.  Please note that SGI
future products and plans are highly confidential and are not supposed
to take place on this public forum.

-- 
Peace, Ariel

---

From: [email-masked] (Alan Cox)
Date: Fri, 5 Dec 1997 22:43:26 +0000 (GMT)

> a distinct possibility that Linux simply won't run on the next generation of

I2O is in hand, most I2O vendors I've talked to are very determined to see
the spec become open and the general public vendors are taking from all
sides - including where it counts with the "We wont buy i2o boxes as it ties
us to unsuitable OS's". The SIG may also move in that way given time. If not
we'll just break it. The fact they erroneously published the spec helps a lot

You arent watching hard. The microsoft strategy is NT for servers, and Windows
CE embedded in everything from your TV, telephone to toilet. CE is on ROM..

Alan

---

From: Warner Losh <[email-masked]>
Date: Fri, 05 Dec 1997 15:46:19 -0700

In message <[email-masked]> Ariel Faigon writes:
: To me the day MS starts using legal threats and acquisitions in order
: to stop Linux can be declared the day Linux has won.  Unfortunately
: for us Linux lovers, before Wine can run _all_ the Win32 apps without
: _any_ problem (not so close IMHO) and before Linux has a dumb-user GUI
: that really hides all the incredible (for the average Windows user)
: Unix complexities from the majority of the user base it doesn't have
: a chance of world domination, not even in the enterprise servers
: low-end space.

Keep in mind that there are other free unix implementations that are
also likely starting to appear on the radar screen of Microsoft.
FreeBSD has made significant inroads in many places, for example.

The only reason that I have Win95 on my laptop at all is to run
quickbooks, quicken and the odd Word or Execel thing.  Wine can't run
quicken well enough yet for me to be able to rely on it for my day to
day activities.

: Excellent and valid point.  Note that there are new forces on the
: rise which directly clash with Intel interests.  I'm refering to
: both the existing National-Semiconductor + Cyrix merger and AMD,
: and to the (about 9 at last count) startups working on x86 compatible
: designs.  The next few years will be interesting and Intel might very
: probably not emerge as the winner.

The whole effort to gain control of the architecture reminds me of the
micro channel fiasco that IBM did.  Granted, the I2O stuff is less
restrictive than that, but if Intel goes too far on this, they might
find themselves w/o a market.

Also, there are people on the FreeBSD mailing lists who claim to have
unencumbered access to the I2O specs.  I don't see that the free
unixes will be locked out of that area for very long, even if the SIG
folks want them to.  There is just too much vested interest in having
them run on the next generation of PCs to hold back the tide for long.

BTW, there are some folks around here getting rid of Indigo's with a
fair amount of disk/memory on them (2G disk, 64M memory) with
monitors.  They are currently up for bid.  How different are these
beasts than the Indy?  Would Linux run on them?  What would be a fair
price to bid on them?

Warner

---

From: Eric Kimminau <[email-masked]>
Date: Fri, 05 Dec 1997 18:08:07 -0500

> beasts than the Indy?  Would Linux run on them?  What would be a fair

There are several models of Indigo. If it is an R4000, its fairly close
to an Indy without the multimedia things. The problem you will find is
that there were also several levels of graphics.

Bid price 64MB ram, 2GB disk, 19-20" monitor, R4k - $500.00

---

From: Chad Campbell <[email-masked]>
Date: Fri, 5 Dec 1997 17:44:58 -0600 (CST)

On Fri, 5 Dec 1997, Ariel Faigon wrote:

This is not a reply to Ariel, but how I would respond to the author of
Ariel's forward.

>   - P.A: "I'll give you an option to take over at $xxx,xxx,xxx."
Keep in mind that all of Linus' work and the whole kernel is GPL'd.  Also,
M$ would have to prove that Linus was on company time to assert copyright
on any code.  From what I have read, Linus has a contract with TransMeta
which specifically allows him some amount of time to work on Linux, so
they would not only have to prove Linus was on company time, they would
have to prove he was working out of bounds of the time specifically
allowed by his contract.  This would be tough to say the least.  Also,
remember that all kernel code is not by Linus, so even in the worst case
we would just have to remove whatever code was truly TransMeta copyright
and re-implement Linus' contribution some other way.

>   young and inexperienced against the West Coast's big guns? Hasen't he
Maybe, but Linux does not live or die by its creator.  I think that if M$
messes with Linus, every other developer will be so pissed, that the
kernel and maybe every other part of Linux will improve at an even faster
rate..  That would certainly give me motivation to burn the midnight oil,
if only I wasn't burning too much trying to graduate.

>   threat. SUN should be even more worried than MS on that count.
I've read the GPL and it seems very secure, if it actually applies to the
code Linus rights.  I don't think M$ would even try to argue against
the GPL, they would simply argue that since Linus was on company time that
he did not have the authority to place his code under the protection of
the GPL.  Also, I don't think GNU would have any difficulty getting
support from the rest of the industry in testifying against M$ and in
support of the GPL were M$ to actually challenge the authority of GPL'd
code.

>   impossible and I'll be happy and go away and sleep better...
No way, it's a very valid point, but I think that Linux is now strong
enough to function without Linus if it has to, so while your nightmare
could be real, you may be overestimating the danger.

One other point.  I don't think M$ could support any claim of being an
innovator of any new methods of OS design.  They simply bark the loudest
when they finally figure out how to implement 20 year old ideas.  So
even if they succeeded in copyrighting Linus' code, we could just
rewrite it in a different way and then they would have to prove either
that the new code was a more or less direct copy of their code or a
result of disassembling Windoze.  Of course no self respecting Linux
developer would even consider copying or disassembling an inferior OS.

All the same, It might not be a bad idea to keep old kernel sources lying
around just in case this nightmare happens.  I would guess that this has
always been the case anyway.

Chad

Chad Campbell

---

From: "William J. Earl" <[email-masked]>
Date: Fri, 5 Dec 1997 15:54:59 -0800

Warner Losh writes:
...
 > beasts than the Indy?  Would Linux run on them?  What would be a fair

      The Indigo R4000 is pretty close to the Indy in many respects,
although the I/O and graphics are earlier generation in the same family.
The Indigo (R3000) has similar graphics and I/O, but is of course an
R3000, and the memory controller is a different design.  Linux could
run on either, but more porting would be required.  Many of the drivers
could be shared, with some adjustments, but the graphics would definitely
require significant work.

---

From: Chad Campbell <[email-masked]>
Date: Fri, 5 Dec 1997 18:15:01 -0600 (CST)

> Bid price 64MB ram, 2GB disk, 19-20" monitor, R4k - $500.00
If it'll run Linux, I'll give that much too, maybe a little more.  That
bid seems real low to me though, so if it was a joke, I'll be a stupid
little undergrad now and go sit in my corner. :)

Chad

---

From: Michael Neuffer <[email-masked]>
Date: Sat, 6 Dec 1997 10:35:44 +0100 (CET)

> we'll just break it. The fact they erroneously published the spec helps a lot

Unfortunately the spec got updated to 2.0 and from my sources I hear
that it is not exactly upwards compatible. 

We will surely be able to break it given time, since somene somewhere
will surly leak it at some point, but time is unfortunately also all that
Billy Boy needs to gain an unfair advantage.

---

From: Lige Hensley <[email-masked]>
Date: Sat, 6 Dec 1997 07:42:27 -0500 (EST)

>   people never answer the phone anyway, and I can run Office97 with Wine."

Even more important than Linux being easier to install than NT is 
reliability.  I am in the middle of a project to remove about $200,000
worth of NT servers and replace them with Linux boxes.  Of the servers
installed thus far, we've seen our incidence of problems go from about 2
a week to zero (and peformance boasts out the wazoo).

I'm currently working on an article for LJ about our project and how to do
it yourself.  The possibly of Linux as an NT replacement is not only real,
it's happening. 

-lige

"Live Free Or Die"

---

From: "Greg Chesson" <[email-masked]>
Date: Sat, 6 Dec 1997 11:06:40 -0800

LJ is not as widely read as one would hope.

I'd suggest sending the article to Red Herring, Upside,
and the Wall Street Journal.  It would probably not be accepted
in the same form that is appropriate for LJ, but it might very well
be excerpted.

g

---

From: cypher <[email-masked]>
Date: Sat, 6 Dec 1997 18:16:13 -0500 (EST)

> find themselves w/o a market.

Actually this would probably put the companies using I20 specs in a very
similar position that many of the big unix workstation vendors find
themself in now. What more, if Linux did (it will I'm sure) run on this
architecture it would put itself in a great position, espiecially if
Microsoft stop supporting the old architecture while other companies
continue to produce them. (How badly does Bill Gates want it to go his
way?)

---

---

From: cypher <[email-masked]>
Date: Sat, 6 Dec 1997 18:26:41 -0500 (U)

> a chance of world domination, not even in the enterprise servers

Does this need to be some kind of project then? (Not that I haven't
thought of this already). I realize the KDE and Gnome people are out 
and making fairly decent ground on the WM problem, but maybe this type of
effort should go deeper into the kernel, kinda like BeOS or Rhapsody... 
These are UN*X like oses that are trying to cater to the "I don't give a
shit" crowd of users who don't want to learn anything too indepth about
there computers or who don't have time to deal with stuff because there
trying to work on higher level problems (many academic people, etc.).

What would it take to come up with a Linux distribution in this sort of
flavor that could still use kernel patches and old legacy apps, but also
might have a more standarized GUI/development environment. All this of
course still with a GPL/FreeSoftware attitude...

I know Linus talked about the usability of linux in atlanta this past
summer, so your average joe wouldn't have to deal with such a steep
learning curve, compared to MacOS and Windows... 

> probably not emerge as the winner.

On these lines what about the stuff that Digital is now doing with Intel.
Digital has been pretty good to the linux community... maybe thats our
"in".

---

---

From: cypher <[email-masked]>
Date: Sat, 6 Dec 1997 18:32:21 -0500 (EST)

> Snip: Linus works for Transmeta, which Microsoft might buy in order to
> "acquire" Linux. Legal or not, the legal fight might hamper Linux's spread 
> well enough to significantly reduce the threat to NT.

Isn't this the point where anarchy ensues? Think of it this way: How many
linux boxes are out there. Basically for every linux box out there we have
a backup of the code. If the M$ people got legal rights to Linux they
couldn't possibly enforce a NDA agreement on the most current version of
Linux. So then there would be MS Linux product line, and we would still
keep developing Linux, at worst witha different name. Not that this
wouldn't piss us off, but we would overcome and continue... right!

So, the point is that Linux has this subtlety about it that it can't ever
really die. It's sort of taken on it's own life. 

---

---

From: [email-masked]
Date: Sun, 7 Dec 1997 00:35:44 +0100

> Digital has been pretty good to the linux community... maybe thats our

Which reminds of a discussion with Jon "Maddog" Hall (introduction
superfluous, I guess).  He said Linux the best thing of having Linux on
the Alpha was that is was actually helping Digital helping to sell
more Digital UNIX systems.  He explained the effect by users starting
with Linux on their Alpha systems but then finding that they're actually
in the need of the advanced capabilities of Digital UNIX.

  Ralf

---

From: cypher <[email-masked]>
Date: Sat, 6 Dec 1997 18:37:13 -0500 ()

> Billy Boy needs to gain an unfair advantage.

Actually, all linux needs to win is for Billy Boy to get enough unfair
advantages... then by by Microsoft... ;-)

---

---

From: Eric Kimminau <[email-masked]>
Date: Sun, 07 Dec 1997 13:26:30 -0500

> little undergrad now and go sit in my corner. :)

It won't run Linux yet, but an R4k will run IRIX 6.5 when its released,
and is therefore, still a useful system. If its an R3k, it isn't worth
that much unless you want the monitor (which is probably 80% of that
bid)

-- 
Eric Kimminau                             System Engineer
[email-masked]                       Silicon Graphics, Inc
Vox:(810) 848-4455                        39001 West 12mile Road
Fax:(810)848-5600                         Farmington, MI 48331-2903
            "I speak my mind and no one else's."
    http://www.dcs.ex.ac.uk/~aba/rsa/perl-rsa-sig.html

-----END PGP PUBLIC KEY BLOCK-----
http://bs.mit.edu:11371/pks/lookup?op=vindex&search=Eric+A.+Kimminau&fingerprint=on