LinuxWorld: Business, Business and More Business

Clarkson University wins a server from IBM. Sun is bringing embedded Linux to its UltraSparc IIe processors. Wired has an overview of LinuxWorld, talking about how it's all business and the joy is gone; and so does Internet.com; and so does Newsforge, which also has a story about LinuxWorld in Paris. The Register has a lengthy interview with Miguel de Icaza, in which he notes "Gnome 4.0 should be based on .NET".

Comments

A few random points:

[Otter]

I spent a couple of days working in the KDE booth, way in the back with the rest of the non-profits. Personally, I had a great time -- it's the first computer event I've attended (except for 'Geek Pride Day' back when Andover.net was flush with cash) so I'm probably a lot less jaded than most.

I also got to experience the feel of the old days, having brought my TiBook for a demo system. There were quite a few Apples in evidence, and I proabbly spent more time talking PPC Linux than I did KDE. The PowerPC Linux crowd continues to have all the community feeling that Linux as a whole lost when the gold rush started. Curiously, the Apple guys who stopped by the booth seemed completely uninterested as all the Linux guys drooled over the TiBook.

• The Linux on PS2 demo was gorgeous. The Linux on Dreamcast demo (way in the back, with the .orgs) was given by one of the hackers and had hardcore authenticity. And they gave me a boot CD, elimiating the problem of burning the crazy Sega format.
• I think the iPlanet demo was supposed to be a tongue-in-cheek satire of cultists, the humor of which was lost on the attendees.
• I spoke with a number of indivduals known for their inflammatory viewpoints. I won't mention names, since I insisted on speaking off the record with them, but they walked up to the booth and launched right into their monomaniacal rants. I'd have thought they'd be better rounded in real life.
• I got to thank David Korn for answering my question in his Slashdot interview. He was really nice, down to earth and an excellent teacher.
• On the whole, the level of social grace was higher than I had expected, but there was still a large population of weirdos. Mind you, it's not like I normally associate with supermodels - compared to scientists it's a weird bunch.
• Oh, and this Mono thing? You know how everyone's always complaining about duplication of effort from KDE and GNOME? It sounds like Miguel wants to take GNOME into a direction that KDE won't be touching, so I suppose that's good. As long as X-chat and grip keep working.

Re:More Mono Trolling, Don't You Folks Get Tired?

[wowbagger]

Answer the following questions, truthfully:

1) If Microsoft changes the spec for C# or CLI, can ECMA deny the changes?
1a) If they can deny the changes, can Microsoft still call C# "C#"?

2) Are C# and the CLI completely free of patents?

If the answer to 1) is false, then at any time MS can change the spec on what C# is, and leave Miquel to play catch-up.
If 1) is true and 1a) is true, again MS controls the table.
If 2) is false (it is, by the way...) then at any time MS can jerk Miquel up short and deny everybody the right to use the code without paying them a royalty (think Unisys and LZW).

I assure you, I am neither a troll nor an idiot - rather I am a person who can see beyond "that's cool" and ask myself what the downsides are.

C# and .NET is just Java

[Anonymous Coward]

MS has been giving out free 2-day seminars on .NET to Universities, so I attended.

I'm a modest VBScript ASP programmer, with reasonable experience in Java (and PERL, C, BASIC). I'm a "do-all" type network admin (jack of all trades, expert at none) that writes programs (web to database mostly) when I need the functionality of a universal client.

Back to the seminar. Lots of marketing hype, but we did get good insight into how .NET works (from programming to system administration).

The model is one of Java, where the programmer creates an Intermediate Language (IL) file that is complied "just in time."

Server-side applications (web to database for example) get complied and cached the first time they are run. Code changes trigger an automatic recompile. The overhead for the one-time compile was minimal, but we didn't get an answer on how the system senses that the code needed to be recompiled (multiple file touches for each request?).

Client-side applications use a required browser object called the Common Language Runtime (CLR). The CLR, likely feed to the client via Windows Update (or an Office service pack, etc.) is the program that converts the IL byte-code into native code. Caching applies here too.

Sounds like Java, works much like Java.

C# is just like Java --we felt sorry for old-hand VB programmers because MS seems to be tossing them over because of the need to only have object oriented classes talking to .NET.

We couldn't understand why Java wasn't supported. If MS is changing to a services model, and hopes to make their money this way, then why don't they have Java as a valid language to ensure wide acceptance?"

A lot of the functionality available (XML) seemed geared toward business and to ensuring that MS would have a way to leverage Passport. The "business to business" XML seemed interesting, but likely long in coming because use requires that businesses adopt standards (nobody would willingly choose XSL transforms unless they had to). The "business to MS" XML seemed ready to go, suggesting that MS will spend most of it's XML efforts on making it easy for MS to act as a broker for a business wanting to leverage Passport as a way to bill customers.

The big concern I and several others had was the seeming reliance on Visual Studio for the creation of code. Yeah, MS had a list of 20 odd languages that could interface with it (except Java), but it became apparent that .NET was so complex that getting it all working properly was going to be almost impossible for anything but MS's IDE. Realistically, this means VS code generation, being served to (IE?) web-clients running the MS CLR. Both ends of the wire would seem to be under MS's control.

System administration also looked complex. A fully fleshed out .NET infrastructure would have no less than 7 servers. It seems that MS knows their applications can't scale to handle tens to hundreds of thousands, so they solved the problem by splitting functions across machines. Maybe a good idea, and possibly functions can be collapsed to a single machine (like Active Directory), but the number of different parts was daunting.

I know this sounds a bit cynical and bashes MS a bit, but this is pretty much the feeling a lot of us had. The tools seemed geared to large companies needing to interact with hundreds of thousands of customers. They were not geared toward the small-market usage that a College webserver might need for a Conference Registration Webpage.

Having to use VS to write, edit, and publish programs is going to make it much harder to train people on writing web to database code. Maybe this is good, but I doubt it. The virtually unreadable HTML code, coupled with the complexity of the paradigm just piles on what is already difficult enough to teach.

Miguel floats off into Never Never Fairy Land

[bryanbrunton]

"With .NET once an API is published it's available to all programming languages at the same time."

With comments like these, Miguel has really lost it. Perhaps he never had it to begin with.

He appears to have this entirely fantastical idea that when Mono reaches 1.0, we will be able to just plug in the existing C, C++, Perl, etc code bases into it and, WAMMO!, instant cross language, cross platform code. I can understand his frustration with updating Gnome language bindings. However, I think his mind has snapped from doing that kind of work.

He has bought into the central .NET MYTH: that you can just willy-nilly plug in existing languages in the CLR nirvana. He has become one of those .NET fan boys who show up touting that .NET supports over twenty programming languages.

Note to Miguel: the cross languages promises of .NET are a pile of large stinking COW dookey!

Programmers don't like half assed solutions to problems. And that is just what Perl, Python and name-your-favorite-language are inside the world of .NET. What are the hard realities:

(1) Languages evolve. The .NET support for the .NET versions of languages do not. Programmers don't want to work with 80 percent of the features of their chosen language simply because the .NET version of the language doesn't support it. They also don't want to deal with compatibility problems arising with FunctionA() acts differently when run under the C++.NET as opposed to the native C++ environment.

(2) The Common Type System and Common Class Libraries of the .NET universe impose straight jackets on languages that no programmers will want to deal with. Programmers don't want to be confined to using a limited set of types and classes just so their program can function in the CLR. Should I even mention the compatibility problems that existing code will have within the .NET sandbox?