Microsoft/Novell Partnership

[ted leslie]

On Fri, 2006-11-03 at 10:40 -0500, Lennart Sorensen wrote:
> On Thu, Nov 02, 2006 at 10:20:18PM -0500, ted leslie wrote:
> > As a programmer who doesn't want, "write once, write anything***,
> > deploy anywhere"? and not recompile, and don't have ifdef's from hell.
> > (where *** is  scripting, web apps, GUI apps, browser plugins, and c#
> > isn't to much of a departure away from C, so you can stay in the loop if
> > you have to write any linux kernel stuff, which will be C for probably
> > another 20 years at least). 
> 
> Lets see: people writing code for embedded systems don't want that.
> They want something small and efficient.  People writing games don't
> want that.  They want something efficient so they can make their game
> run faster and have more effects so it looks better than that other
> games.

With quad cores being norm in 1 year and 8-core maybe in 2?,
and such a pathetic use of this technology by all involved,
the extra cores will take a CLI system and make it perform 
better then most things that are not under active development.
If we were still in a single core world, i'd agree,
but since (with cell, amd dual/quad core), its just simply not
going to happen. The days of efficient languages on a single core, even
down to assembly are coming to a quick end. The extra 3 cores that are
just sitting there idle, will be able to optimize and cache the 
CLI to a efficient form. For calls to do shading , poly draw, etc,
those are going to be C/asm , and mostly in the card HW anyways.
CLI on 8 cores is plenty to get whatever game your going to need.

And in time C# will compile down to what C does anyways (down to native
compiler) , so as far as parking your "programming time" in front of one
language/platform, Mono still (will) have everything C will have
anyways. So you just get the best of everything in one place. all be it
if you choose to use C# native comp'd you will not get x-platfrom
independance. but atleast a recompile will be relatively easy on the
other platform.

> 
> > At the end of the day , for a classically trained programmer, Mono  (C#)
> > just  works, its the holy grail.
> 
> Until someone invents the next one.
> 
> > I see Mono (and this SUSE deal), and the trojan horse we are pushing
> > into the Microsoft fortess, and in time we are going to jump out and do
> > some serious head kicking :)
> > Not sure about the High Level issue, to me c# is high level, how much
> > higher does one need?
> > I guess by high level you mean what you give a highschool student to
> > learn programming in school? in which case VB on Mono will do, until
> > they learn c#.
> 
> If it becomes a problem, microsoft will change the rules.  They are used
> to doing that when things bother them.
> 
> > Also moving drivers into CLI will allow HP, Epson, Canon, and small
> > shops, to write once and deploy drivers on Linux and Windows, which will
> > give Linux much needed driver support for little odd ball peripherals,
> > as well as get the full features of the drivers put out by the HP's and
> > Canon's etc, who right now treat the Linux drivers as a bit of a 2nd
> > class priority. Might be tricky gluing a User space CLI driver (part) to
> > a kernel space C part. However, the things like the HP's all-in-one
> > applications, like fax viewer, printer status, etc,etc, if HP could
> > write that puppy in c#/.Net and that would bring the best of the HP
> > printers abilities to the Linux and Windows users, due to that common
> > CLI (.Net & Mono), that goes a long way to making Linux become
> > dominant.
> 
> A print driver for windows needs to tie in to microsofts GDI (or
> whatever it is called now) print system.  On Linux and MacOS they want
> drivers that can output based on postscript instead.  Not sure how much
> it would be worth trying to combine those into one bloated driver.
> Maybe for some of the other features of an all-in-one device, but not
> for the printing.  besides does mono have access to raw USB or scsi?
> 
> Interesting illusion though.
> 
> --
> Len Sorensen
> --
> The Toronto Linux Users Group.      Meetings: http://gtalug.org/
> TLUG requests: Linux topics, No HTML, wrap text below 80 columns
> How to UNSUBSCRIBE: http://gtalug.org/wiki/Mailing_lists
> 

--
The Toronto Linux Users Group.      Meetings: http://gtalug.org/
TLUG requests: Linux topics, No HTML, wrap text below 80 columns
How to UNSUBSCRIBE: http://gtalug.org/wiki/Mailing_lists