Posted 5 Jul 2001 at 20:00 UTC by advogato
While it won't be formally announced until Monday, reports of the Mono
project are starting to leak to the
press. The question of how to respond to Microsoft's .NET initiative
is a sensitive one, with many complex and subtle issues. Thus, this
cat predicts a spate of uninformed articles in the technical press,
followed by lots of flamage on the message boards.
The goal of the Mono project, briefly, is to create an independent,
free software implementation of the various languages, protocols, and
interfaces making up the .NET platform. Much to Microsoft's credit,
they seem to be taking the open standards process quite seriously.
Draft ECMA standards for C# and other components are available on a page Microsoft has set
up for the task. Additionally, they've generally played well in the
process of defining SOAP. There's already a free implementation: soup.
The C# language itself looks quite appealing. It may well present a
sweet tradeoff between language richness and complexity, well suited
to writing applications. Certainly, Microsoft seems to have learned
from the mistakes made with Java. The progress of the free software
Java community has been disappointing to me. Perhaps C# will be
considerably more vital.
Finally, it is very much in the spirit of free software to
interoperate. Many projects, including Wine, Samba, netatalk, wv,
various filesystems for Linux, are dedicated to this goal. It is often
in the interest of authors of proprietary vendors to put up barriers
so that various combinations of software won't work. A great strength
of free software is the absence of any such incentive.
That said, there are definitely concerns about implementing the .NET
protocols. It will certainly help Microsoft, and certainly help the
adoption of .NET itself. Whether that's a good thing or not is a very
good question. Certainly, there are aspects of the broader .NET vision
that are scary from a security and privacy standpoint, especially
As the title of this essay suggests, I believe we face the danger of a
monoculture. While monocultures clearly have some advantages (or they
wouldn't exist), they also have many weaknesses. They are much more
vulnerable to attack, for one, and also close off many avenues for
innovation that would be present in a more diverse environment. Today,
free software is one of the few forces actively resisting such a
monoculture (Apple being one of the others).
Whether free implementation of .NET will aid or impede such a
monoculture is a very good question. Having more diversity within the
.NET world will be helpful. Further, it will probably help with the
implementation of gateways between .NET and other free projects.
There has definitely been concern expressed about Mono drawing
attention away from other worthy free software projects. However, this
cat is not very worried. Matching up free software talent to worthy
projects has always been a chaotic process. It's possible that some
projects will feel the loss as people's attention is captured by the
shiny new thing, but the chance of the free software community moving
en bloc to .NET is about as much as, say, all Perl hackers suddenly
switching to Python (or vice versa!).
As the excellent editorial in
Linux Weekly News points out, it is disappointing that we don't have a
large-scale system architecture comparable in scope to .NET. "The
community needs to act here," but what is the best way to do so? Mono
provides one potential answer.
Open Standards, posted 5 Jul 2001 at 20:34 UTC by jlbec »
Micro$quash certainly seems to be playing nice with C# and SOAP. They
are working the standards committees properly, and apparently interact
well with competing implementations.
However, it appears that they view the recent court of appeals decision
as "The gloves are off!!!" While I don't think anyone can know
that they are going to pull the embrace and extend trick with
SOAP/C#/.NET, there is certainly no reason to think they couldn't. It
would be a waste of a lot of time to spend all energy working in the
.NET world, only to find it doesn't work.
I'm not saying that .NET work is bad, but it needs to be thought out.
The problem with the "Object Web" (which has been predicted for years,
but never happened) is that it requires some centralized way to list all
the services available, and it requires actual useful services
in the first place. Micro$quash is in the proper position for these
requirements. In general, the only true client these days is IE on
Windows. We can talk about Mozilla, but 92% of the world's client
machines are Windows. If these clients automatically have convenient
access to .NET services, they will choose to use them. They will not
even regard security or quality as an issue.
As soon as .NET is an integral part of the Windows application landscape
(essential to using Office, say), it becomes easy for Microsoft to
extend it to the proprietary things that make life hard for non-Windows
users. Windows extensions to your website are a neat idea when you know
that 92% of users can view them. Windows extensions to your .NET
services are an even neater idea if you know it results in sales. The
browser wars proved that proprietary extensions may not defeat an
existing competitor, but that doesn't mean they can't make an effective
lock-in against new competitors.
These are, of course, merely cautionary thoughts. I don't know what the
future may hold. But watch WMP kill RealVideo. And think.
CLI, C#, posted 5 Jul 2001 at 20:44 UTC by atai »
What is the plan for CLI and C# ? Will you guys implement a virtual
It would be advantageous to "tie" the Free Software implementation to
existing Free Software infrastructure, like
Apache, GNU/Linux, gcc, Kaffe, gtk, GNOME (Bonobo), CORBA, KDE, etc. It
helps distinguishing the Free implementation from the Microsoft
implementation and helps negating the possible "help" to Microsoft to
make .NET popular. Basically this takes away the 100% control
Microsoft would enjoy over .NET. and makes the Free Software community
a player in
steering .NET's future. Or at least, hopefully....
Embrace, extend, and extinguish Microsoft. That's the plan.
The Software Wars are
really heating up...
As much as I hate "solution providers," there is something to be
said for a well-architected, cohesive platform. .NET and J2EE both
seem to be addressing this. Both are development platforms that let
you add network services pretty easily, and the APIs are extremely
consistent. I don't think that can really be said of any existing
development environment in the GNU world. I think that Ximian is smart
in trying to develop either a clone, or an answer to .NET for free
A number of people probably find something like this against the
UNIX ideal - small applications that do 1 thing really well. But I
would argue that things like component systems and extensive consistent
APIs are in the same vein. These are just architectural building
blocks to make powerful applications. In UNIX-land, the wheel is
reinvented too often. We're too interested in rolling our own. I
don't even want to know how many different projects have implemented
their own string classes, or other relatively basic data structures.
This is just a waste of time.
That all said, I would like to voice some concern over just
implementing the .NET apis as they stand. I don't want to use Passport
or go through Microsoft for any transactions or data storage. I
frankly don't trust them. I *am* interested in that odd "net services"
term though. I'd like my configuration data backed up somewhere, so no
matter where I log in, my apps are all set up as I like. I'd like to
be able to seemlessly back up some of my files. My calendar, todo
list, and other work-related things should be available from wherever I
am. Little things like that would be nice to have. I can come up with
any number of other small things that would be cool. And I'm willing
to pay a reasonable amount for such services. But, I do want my
applications to be useful when I'm not connected to the network. And I
want to know that my data is secure, wherever it is stored. And I
don't want to pay a Microsoft tax.
The free software community should work to develop a "services" API
that is vendor-neutral. I should be able to search for the best vendor
for each service, and not have to recompile my app when I switch
vendors. We can get real competition there. The Eazel folks were
working on "Reef" towards the end there - it seemed like a really
promising project. I would love to see something like that take off as
a part of a larger application development framework. We even have
readily-available systems that we can use as free "service providers" -
Themes.org could be Reef-ified, and theme preview/update systems can be
built into theme switchers. There are a number of digital libraries
that have a wealth of information and resources for us to take
advantage of, and make readily available within applications. How cool
would it be if your word processor let you do a quick quote cross-
reference? Little things like that would be very useful, and very
feasible to program with the proper framework in place.
The idea of providing an infrastructure that makes it easier to
interface disperate languages such as Smalltalk and Haskell is in my
opinion a step in the right direction. Currently making these languages
talk together in a portable way across platforms is very difficult...
which makes most people standardize on C or some subset of C++. If
Microsoft delivers on this one, they'll have made a real contribution to
Secondly, supporting .NET is an opportunity for Linux to suceed in the
embedded IA market: currently plugins are Windows executables, which
could only possibly be run on Linux using Wine (or CodeWeaver's
cross-over embedded Wine product). If I understand it correctly, .NET is
essentially the output of the compiler before it emits assembly. The
"JIT compiler" thus performs the last compilation phase, allowing
cross-platform portability, but ensuring C-like speeds. I see no reason
to do all this work, if you are going to tie the result to the x86
Windows platform. Instead I expect plugins will be written for .NET so
that Microsoft can gain a presence on all the handheld devices,
internet fridges, whatever of the future than run whatever OS and .NET.
In the mean time Linux can become the "whatever OS".
Let me preface this message by saying I'm not terribly interested in web
services, however in .Net it seems partially what they want to do is
make clients go beyond what is possible with the hyper text transfer
This seems good to me, except why would we, the free software community,
suddenly adopt Microsoft's protocols and start implementing the very
Microsoft-centric infrustructure needed to support them?
In long run it seems better to stick to the standards and protocols
specified by the World Wide Web
Consortium. They seem fairly independent, and much more trustworthy
than the Microsoft Corporation.
Project naming, posted 6 Jul 2001 at 08:34 UTC by khazad »
If you're going to start another project related to .NET, please call is
Poly. I can hardly wait until we have Mono and Poly
around. Oh, no, wait...
My personal viewpoint is that we need one good high level programming
language on linux in order to develop good (i.e. featurefull and not
buggy) applications in an easier way. Java could have been that except
that it's 1/ not standardized 2/ there is no good free softare
implementation (Kaffe never reached taht goal and the compiler with gcc
don't include enough of the virtual machine) 3/ linking with native
libraries is an horrible problem. C++ is for the moment the best option
it seems, python seems nice too but I don't think people can implement
an office suite in Python realistically. C++ has its own problems, and
is not garbage collected which seems to become a requirement for the new
generations of programmers (sigh ...).
The C# language looks nice, it seems to solve the main technical problem
I have with Java, and I hope the standardisation at ECMA will complete
in a reasonable time-frame. Then that standard is an useful piece to
implement, assuming that there isn't too many holes in the specification
(Bruce Perens seems to have raised a problem there). Similary, the SOAP
specification is being standardized at W3C (check the XML Protocol activity page if
you are interested).
All this is nice and great because this means this common ground for
developping applications and services gets standardized, so a lot of
things comes along (stability, documentation, books, mindshare,
examples ...) and I think implementing such a framework makes sense
because it will reduce the cost of entry in the Linux programming world
for the masses of programmers from the other side. it may also provide
a good language and framework for the application develpper community in
However developping the framework up to a stable and reusable
stage will take time. I expect that it won't divert application
developpers from their current focus (it should not, that's a very
diffferent effort than writing application and requires very different
skills), we should also not bet too much on this because well this may
very well not succeed for various reasons. I also hope that the
implementation will stay strictly within the scope of 1/ the pieces
standardized 2/ the glue needed to allow easy access to the existing
libraries from the new framework. Trying to engage in a race with
Microsoft developers pool on possible extension is not a productive use
of free software programer time and would at the end provide a
justification for such extensions, we should not go there. Hence the
title "Standards, only standards"
Good luck Miguel, but it will be a long road.
microsoft has a policy - as we all know from the leaked halloween
documents - of pushing technology to a level where it is difficult to
pick up and follow in their footsteps. the typically quoted lag-time is
now, what happens when microsoft develops some technology, off we go,
yes, been there, done that... now what? okay, well, we have some
well-established services, we know they work, oh, yes: i know, we'll do
Something New, and, well, we can use our existing services, right?
so, here's the timelines of where i think (these may be wrong) microsoft
has 'stacked up' their house of cards, along with estimates on number of
man-years to completion:
- NetBIOS gone into the NT kernel, NBT - netbios over tcp/ip -
is an RFC from 1983. (rfc1001/1002). implementation of Network
Neighbourhood: 18 man-months. implementation of WINS Service: probably
about 1 man-year. implementation of NetBIOS at Kernel level (it's
horrible, horrible code): probably about 1 man-year.
- SMB SMB runs over NetBIOS, and has been developed over a
number of years, initially first by IBM funnily enough, then adopted by
X-OPen as a standard in 1986, then embraced and extended by Microsoft,
CIFS 1.0 spec released in 1997 because even _they_ realised it was
getting beyond them. Estimated number of man-years of development:
approximately 15. Estimated number of man-years to catch up with an
NT-only compatible SMB implementation: approximately... two to four.
- DCE/RPC DCE/RPC was originally developed by Apollo as NCA
1.0, handed over to The Open Group as a standard (NCS 2.0 -> DCE/RPC) in
about... 1990 or so? Microsoft adopted it, ran with it, embraced and
extended it, re-implemented it to over-wire compatibility level, made it
possible to run over SMB (as an authenticated transport - you can do
that with DCE/RPC, it's very cool). Estimated number of man-years for
microsoft to have re-implemented DCE/RPC once for NT 3.5 and NT 4.0 and
then again in 1997 for NT5 when i started reporting so many security
problems they freaked out and fixed them all: about... [well, TOG's dce
1.1 code, aka freedce is 250,000
LOC...] five to ten man-years? this could be an underestimation.
- NT DOmain Services Designed as DCE/RPC services, these
provide core-level critical functionality such as SAM, NETLOGON, LSA,
SRVSVC etc. these went into NT 3.1 back in (urr... 1991?) and are still
in NT 5 aka Windows 2000, now. Estimated man-years of development of
these critical services: approximately 20 to 30. [there _are_ about 15
of them :)]
- DCOM DCE/RPC is all very well, except it's not
object-orientated. so MS added an object-layer, called DCOM. ever
looked at a DCOM IDL file and compared it to a DCE/RPC IDL file?
they're exactly the same. I have absolutely _no_ idea how long it took
to design DCOM, however it's pretty big, well established, it was
fighting CORBA back in, um... 1993 blah blah, there are LOADS of things
using it, now. estimated development time of DCOM: 3 man-years? at a
stack all of that up, and you have about 50 or more man-years of
development over a _full decade and more_ to play catch-up.
so _why_ am i telling you all this? [begin flame mode]
well, we have a load of whining, bitching open source developers, who in
their arrogance say things like, *begin-nasal-voice* 'eeeew, i don't
liiike that microsoft stuufff, it's realllyy bloaated and it's not open
souuurce and i don't have to deeeuuw iiiiit it's all teeew cooomplicated
for liitttle meeeee' *end-nasal-voice*.
in other words, they can't _deal_ with layered complexity. they like to
live in their little world, where everything is nice, and clean, and
simple, and open, and limited to about 100,000 LOC *max*.
[end flame mode]
yes: i _know_ that most open source developers are working in their own
time, give me that much credit: i _do_ understand the realities.
it's just that people bitching on the one hand about microsoft and how
they can't get a word in edgeways into their technology but at the same
time aren't prepared to pull their fingers out and actually catch up
just pisses me off.
the number of dedicated open source developers on large complex projects
of greater than 100,000 LOC is actually quite small (less than 10?
apache, linux-kernel, worldforge, samba, samba tng, perl, python,
freedce) hence the main reason why the TNG architecture
advocates subdividing into small, clean projects that are manageable by
individuals, to give them a fast feed-back loop to worthwhile
achievement, to keep them actually interested and part of something
to the point, then: my concern is that all you wonderful open source
developers out there, who don't like to get your hands dirty by
distastefully following someone else's footsteps (not that you can, any
more, because of microsoft's latest SDK licensing trickery, except under
a BSD license), are going to get left behind.
make the decision NOW. are you going to doggedly keep up with
microsoft's initiatives, or are you going to wait for a decade, when it
will be approximately one hundred to five hundred man-years too LATE.
choice is yours, guys.
C# vs. Java?, posted 6 Jul 2001 at 12:10 UTC by kagedal »
I wonder what people feel are the advantages of C# over Java, as a
language? There is the easy C/C++ binding, which I agree is a great
thing. But what else?
One thing that would be great if it could get worked on in the free
software community is a common runtime for Python, Perl, Java, C# and
such. This doesn't neccessarily have to be done in a ".NET
compatibility" mode, but if CLR and the .NET IL are found open and good
specifications, why not.
Big Projects, posted 6 Jul 2001 at 16:50 UTC by samth »
While I appreciate your points overall (and generally agree), you vastly underestimate the number of large Free Software projects. A
list (and there are many more):
- emacs (I think)
This just scratches the surface.
I seriously question the wisdom of naming a product Mono. I just don't
think of banner ads saying "go get mono now!!!" to be terribly
compelling. Especially among the college crowd.
hiya samth, oh darn, yes of course i knew about openoffice, mozilla and
emacs, but not the others. good call. still, that brings the total up
to... maybe fifty? one hundred tops? ... [oh, there's AFS as well, of
i read the references from the article. very interesting to note that,
well, basically, they say the same thing as i did but in a nicer, more
friendly, more readership-acceptable manner but with no real-world
me, i seem to be turning into some sort of open source Nemesis / Devil's
passport.com, posted 7 Jul 2001 at 11:38 UTC by lkcl »
in order not to have people fall foul of the unbelievable arrogant
licensing terms of passport.com (see older advogato article pointing to
the TOS agreement) implementing passport's functionality - a clean-room,
wire-compatible implementation - is more than a simple good idea, it's
atai: it's Ximian Mono, not GNOME Mono. The GNOME Project hasn't even
been presented with the idea yet (and in any case this is a much
broader-scope initiative than GNOME, I don't think GNOME Mono makes any
more sense than GNOME C++ or GNOME X Window System).
But I hope it will fall under the umbralla of GNOME or GNU. It shall
get more support that way. Hopefully it also gets the support of Red
Hat, so there can be cooperation on the virtual machine technology (as
you (HP) proposed similar things before)
information on Mono.
I'm gonna go read all the docs now.
The GNU Project has announced two initiatives to replace
Microsoft .NET. They are dotGNU and GNU Mono. GNU Mono is the Mono we
are talking about here. The FSF press release is here.
It is not clear how dotGNU and Mono will cooperate. Probably it is ok
compete, since the two developer communities (GNU Telephony and GNOME)
are disjoint, at least at this time.
However, the GNOME Project may be extended too thin. How much resource
does Xiaman have, to put into GNOME and Mono at the same time?
<person>atai</person: My impression was that there wasn't really
competition between dotGNU and Mono - they are attacking different areas
of the problem space. Mono is focusing on the development environment,
whereas dotGNU is working on the actual web services end - like a
passport.com clone (but it seems like it will be distributed), and other
web infrastructure issues. So they are pretty much 2 prongs on the same
As for GNOME spreading itself too thin, this isn't really a GNOME
project. Ximian is working on it, and some GNOME developers are
probably going to be involved, but I think it is more of a GNU effort.
Also, I think Ximian hopes that Mono will be something of the future for
a nice integrated development platform for GNOME, so it isn't really a
waste of effort - it is more of an investment in the future of the
platform (as Miguel sees it).
The press released linked from my previous message appears to be
incorrect. The correct one, obviously, can be found on GNU's web page.