What does Microsoft putting .NET on Linux mean to us?

Posted 13 Mar 2001 at 19:52 UTC by seek3r Share This

I dont think it means much to the community at all.
If anything, it might be used against us, and make us lazy. Lets not let that happen!

As far as I can tell from all my investigations of Microsofts .NET, most of which by the pro-Microsoft developers in my office.
The only thing of true value to the open source/free software community is SOAP. The rest is all server side code for processing requests. So I dont see much value to us in what they are doing.

In fact, there is a threat involved in what they are doing.
Since none of that server side stuff will be open in any way, we will simply be users. On top of that the Linux versions of these services will be feature incomplete so as to "encourage" users to switching to the fully featured services that will run on the W2K .NET services.
This is the problem for us. If we use their services, then it could have the effect of limiting our focus in developing open versions of the useful ones. We need to stop poo pooing .NET because its a Microsoft initiative. Its actually a useful stratagy for deploying distributed applications, and in fact its is not Microsofts idea. As usual they are mearly marketing it better than those in the past (I still hear faint echos of "The network IS the computer").

Rather than getting excited about Microsoft bringing their .NET services to us, we need to bring the fight to them. It will be better for us to focus on developing the service processing code in our familiar and favorite languages that are so popular in our community and borrow interesting ideas from Microsoft, as well as doing our best to duplicate/support any worth while service specs they develop. Having our own version of these services in our own languages will allow the dynamics of this community to beat out the commercial competition.

Finally, we need work together. For example, we need all those interested in building groupware services (Evolution, OpenOffice, pphGroupWare, GNU GLUE), to all get behind the OGS Project to build a single standard for everyone to use. This does not limit choice, but instead increases choice. If all of the various service specs that get drafted are brought in the open and can get as much concensus as possible, then the better we will be able to compete.

We have a great opportunity to beat the commercial world at something they are just starting with, and we on the other hand are old hack at. So lets show ourselves and our talents.

Seek3r (aka Dan Kuykendall) Open Source Advocate
phpGroupWare Project Leader (http://www.phpgroupware.org)
OGS Project Leader (http://www.ogsproject.org)


Interesting, posted 13 Mar 2001 at 20:40 UTC by nymia » (Master)

But...

How can anyone prevent MS from playing on this space. They can assemble and deliver any type of software on Linux/Unix.

The only thing I can think of is come up with a specification duplicating .NET on Linux/Unix. Then use that to invite developers to code for it.

Samba should be our model, posted 13 Mar 2001 at 21:03 UTC by dlc » (Apprentice)

Samba should serve as a model here. We (the Free Software community) need to begin to co-develop our own .NET style servers and services in tandem with Microsoft, as far as it is possible. Since client software will be distributed, it should be relatively simple to write server pieces that comply with the client's API.

nymia:

How can anyone prevent MS from playing on this space. They can assemble and deliver any type of software on Linux/Unix

We don't need to; we shouldn't be preventing anyone from doing anything. We need to present complete, stable, extensible, and, most importantly, open .NET platform, that can be used by whoever wants to use it, on whatever platform they choose. Making these services available early on in the game and bringing them up to speed as quickly as possible is our best hope of keeping the playing field level.

The only thing I can think of is come up with a specification duplicating .NET on Linux/Unix. Then use that to invite developers to code for it

Absolutely! Those of us who have our hands in both the Unix world and the Windows world need to be vigorous in our testing.

Seek3r:

It's actually a useful stratagy for deploying distributed applications, and in fact its is not Microsofts idea. As usual they are mearly marketing it better than those in the past (I still hear faint echos of "The network IS the computer")

We should be able to bring together disparate distributed platforms, and create .NET interfaces. Stuff like JINI.

(dlc)

.net is at least 4 things, posted 13 Mar 2001 at 22:00 UTC by graydon » (Master)

  1. Applications whose central data structure is a DOM tree, and hence are (theoretically) more readily transmitted, styled, edited, scripted, etc. than plain-old C/C++ data structures. Runs in/as a browser. Eats lots of CPU. This is mozilla. We're a little behind, but not irrecoverably behind.

  2. Servers which expose a soap interface. 2 sub-parts:
    1. Servers. We have many servers, for many services. Not quite the same level of polish or sophistication as some of theirs.
    2. Soap. It's just another protocol, we have adaptors.

  3. A stable binary in-process componentware interface. XPCOM (or some relative) is not absurdly difficult to target; we really ought to have perl, python, scheme, java, etc. bindings by now.

  4. A Very Big Runtime Library (the "CLR"). Sandboxing, component lookup and dynamic activation, portable IL and a JIT, file staging, access control, reflection, garbage collection. We have many disparate parts providing each of these concepts, but lack the cohesiveness (or homogeneity, if you want to call it a bad thing).

Is any of this a problem, or is it just a ruse? It would be good to have unity in language runtimes. Otoh, we are performance fanatics. I'd suggest that the C-- people are taking the correct approach to their runtime, and that we should avoid the JITs and ILs if possible. You can do exceptions, FFI, GC, etc. in native code, so we shouldn't be shy about it. We have source code for our components. The other big issue is tight integration with directory services, so that you can securely and reliably publish and find appropriate services and components. X.509'ed or kerberized LDAP is the supposedly-scalable solution, perhaps distributions should really consider tighter integration of system services with openLDAP.

re: Interesting, posted 13 Mar 2001 at 22:15 UTC by seek3r » (Master)

> How can anyone prevent MS from playing on this space. They can assemble and deliver any type of software on > Linux/Unix.

I think you missed the point of what I was saying completely. We cant, shouldnt and wont stop them. What we need to attept to do is not USE their code.

> The only thing I can think of is come up with a specification duplicating .NET on Linux/Unix. Then use that to invite > developers to code for it.

Exactly. Thats the point of the second half of the article

Seek3r

re: openLDAP, posted 14 Mar 2001 at 04:24 UTC by taj » (Master)

I couldn't agree more about the integration of LDAP. AFAIK no free software project is targeting the centralization of enterprise authentication and access control. One of my utopian visions is centralized, role-based authentication and access control to various computing resources at a company - everything from NT domain logins and shares, shell access to Linux machines, authentication and access control on intranet and extranet web applications, email, code repositories etc. It seems to me that LDAP is the only way to achieve this in a flexible way.

I want to be able to plug a new machine into the network and tell it "you are a shell server for XYZ development group", or tell a web application, "allow access to anyone who is of role department manager or higher and part of company XYZ". The application can then access role information about the authenticated user to dictate eg site workflow.

Day dreaming, I know. There are ways to set this up at a site with much hard work using NIS and the like, and most people end up writing custom scripts and libraries to achieve it. If a better way exists, I'd love to hear it, it would make my day.

Apache, posted 14 Mar 2001 at 20:15 UTC by Malx » (Journeyer)

SOAP by Apache already 2.0 release.

The usefulness of CLR, posted 15 Mar 2001 at 06:21 UTC by wmf » (Master)

Not to tarnish graydon's excellent post, but it seems odd to advocate C-- but not IL. I think a free software implementation of an IL static native compiler for Unix would be a good thing, because it would allow Windows programmers to more easily port C# and VB.NET apps to Unix. It might also allow Unix users to use binary-only IL apps that were intented to run on Windows with less hackery than WINE entails. Supporting CLR can also be a hedge against Sun's Java licensing.

CLR, posted 15 Mar 2001 at 07:03 UTC by nymia » (Master)

The CLR is the center of it. If there is a runtime out there that can easily be retrofitted to the OS then the language grammar will follow naturally.

TNG project, posted 30 Mar 2001 at 08:14 UTC by lkcl » (Master)

the TNG project advocates splitting down the core ms technology into manageable portions that make it less daunting a task to provide alternatives to the halloween strategy's current successes.

start small, think big. with patience, it _is_ easy to get this stuff.

the only thing to _really_ conquer is the fear of quite serious reprisals in some form or other. for that, you have to make yourself worthwhile to them. and on _that_, personally, i chose to give a full, detailed report - including test code [yes, they accept redhat-compiled binaries as well as instructions on how to compile from source] of every single security issue i found - *without* going public about it. until they had it fixed / nailed in a service pack release.

...the only amusing thing was, that of the TNG services i was implementing, _they weren't even documented publicly inside ms!_ [what do you mean, Samr user info level 21?? surely you mean _net_ user info level 3???] the reason for that made it clear that they wanted - even amongst their own developers - to stick to public APIs so that they wouldn't end up with some everybody-and-their-mother's favourite spiffy tool to have to backwards-compatible support [along with the costs of telephone support etc. [oo my favourite spiffy user mangler tool dunna wuurk nooe more well who wrote it uhhh, i did well why are you bitching at _us_ then? piss off, don't waste our time and money], when if everybody-and-their-mother had used the _public_ api...

one of the few instances where there is a sound _technical_ reason for not revealing info, instead of a restrictive business practice one.

----- Luke Kenneth Casson Leighton -----

"i want a world of dreams, run by near-sighted visionaries"
"good. that's them sorted out. now, on _this_ world..."

"the open source ethic: tell everyone what you think,
and someone is bound to tell you what you _need_ to hear..."
~

New Advogato Features

New HTML Parser: The long-awaited libxml2 based HTML parser code is live. It needs further work but already handles most markup better than the original parser.

Keep up with the latest Advogato features by reading the Advogato status blog.

If you're a C programmer with some spare time, take a look at the mod_virgule project page and help us with one of the tasks on the ToDo list!

X
Share this page