Slashdot Mirror

That said, there are over 160 languages apart from java which can be compiled to java bytecode. Jython is quite robust & can be used to create java applets w/ python. There's also a perl->java byte codes compiler under development. (Though maybe it's been abandoned? ...)

Granted, Robocode is obviously geared towards writing the bots in Java, but you can run just about any language on a JVM, and Robocode lets you use .class files from anywhere. Out of all these languages most people will find one suitable for building bots.

Someone pleeeaasse setup a site dedicated to writing really _good_ MS Word 97+ serialization routines in ANSI c.

LAOLA is a set of perl scripts that does that kind of stuff. It's a fantastic parser for the M$ OLE format. It even comes with a .doc to TeX converter.

Also of interest may be LAOLA, which is "a collection of documentations and perl programs dealing with binary file formats of Windows program documents." The link to that came from Wotsit's as well.

Exactly! Ganesh Prasad has hit the nail precisely on the head with his comments about .NET versus J2EE. Forget the marketshare issues, the meat of this article is that J2EE is here, today, and that complete OSS implementations of J2EE are achieveable this year ... as long as the open/free community stops trying to change Sun, and instead works around Sun. It would be much less effort than doing a full implementation of .NET, and much of the work is already done.

All of the myths about Java's speed (slow) are just that -- myths. I've built real-time data collection applications that run perfectly fine with Java/MySQL/Linux on Pentium 166s with 32MB of RAM -- Java was more than fast enough for our needs, and the development cycle was a lot faster than would have been possible with C++. Java is more than fast enough for server applications where JIT compilers can truly optimize the code, since it is compiled once and then kept in memory and run repeatedly. Benchmarks have shown that for typical server applications, modern JVM/JIT combinations are as fast as unoptimized C++ code. While an expert can still hand-optimize C++ to out perform Java, in reality, you'll have to ship your applications before you have time to apply those optimizations ... and Java's development cycle is (in my experience) still much faster than C/C++, simply because you can rely on the JVM to protect the OS from your code (and vice versa).

I'm also tired of hearing about how Sun's JVM only supports a single language -- Java, while .NET supports many languages. There are literally dozens of languages that can be compiled to run on Sun's JVM, even if Perl isn't one of those languages. Anyone who thinks that they'll be able to easily port existing C code to run on .NET and use .NET services hasn't looked at how virtual machines (and the CRL in particular) are implemented. Yes, the JVM is optimized for Java (and vice versa) but you can still use the JVM to allow you to write your applications in non-Java languages and deploy them on any platform that supports a JVM. Some languages, like Jython (a version of Python written in Java), allow you to create non-Java classes that inherit from Java classes, as well as Java classes that inherit from non-Java classes.

Anyone who claims that Sun's control over Java makes it impossible to build an open implementation (because Sun would just change the spec) and then in the same breath says that they won't have the same problems with .NET and Microsoft needs to wake up and smell the brimstone. While Sun does control the Java specification process, they still have to work with their partners and licensees, and the specification process is open -- and most of the reference implementations for the higher-level APIs are open as well. They can't change the Java language without breaking backwards compatibility for thousands of applications and millions of users, and Sun doesn't have any monopolies to fall back on. Microsoft, on the other hand, controls the desktop OS market, and can use that and .NET to conquer the server OS, and since the implementations for .NET are closed, Microsoft can switch the back end and the desktop without breaking applications deployed on Windows ... while simultaneously breaking non-Microsoft implementations. What more can a monopolist ask for?

And the best reason to work with Java/J2EE instead of .NET -- Java/J2EE is here, today, and has been working for years. While it isn't perfect, the bugs have been worked out, and it works. .NET is still beta code, and once it ships, it will still be a version 1.0 Microsoft product. It will take two more iterations (and who knows how many years) before .NET is truly stable, useful, and reliable. I need to build and deploy applications today -- not 3 years from now.

I would absolutely despise PPPOE if I had to manually initiate a connection every time I wanted to do something, but having your router connect on demand for your entire home network mostly eliminates the pain.

If you use RASPPPoE (the most trouble-free PPPoE software that I have encountered in the last year and a half) for initiating your dialup connection via software, then at least, for win9x and win2k you can have it dialed automatically. The readme file explains that under "advanced features".

Life isn't that bad even with software PPPoE

Get over it. You just set the connection to start up when you boot and reconnect automatically on disconnect (not that that ever happens with the SBC (Snet) PPPoE I've experienced). And yes, the software they supply (for windows) does suck, that's why there's alternatives (that rock).

Assumption 1: Mono will have good performance

I am labeling this as an "assumption", because for some strange reason Mono's expected performance is not discussed here, even though there are multitudes of people consistently bashing Java for being slow.

Since the CLR is essentially identical to a Java VM in terms of high-level design, the execution of CLI code would be performed by using much the same approaches that are used for executing Java bytecode. If you look at Ximian's CLR implementation roadmap, you will see that it follows exactly the same path that the Java implementations took, except that it stops short before the last step -- runtime optimization. (Just to note that this last step is the most difficult one, but it is exactly what allowed Java to get close to C/C++ in terms of performance. JIT helps, but it simply does not cut it -- it is not enough).

Now, it took more than 5 years of intensive work for the JVMs to reach their current level of performance. How long will it take for Ximian's CLR impelementation to become fast enough and not be branded by the people on /. as slow? Obviously they can benefit from some of the Java work, but personally I feel that it would be very unlikely if that happens within less than 3 years. (although it would be nice if it did)

Assumption 2: .NET is standardized, so we can do multi-platform development

By now we all know that C# and the CLR have been submitted for ECMA standartization. What is important to realize is that while the C# language may be standardized, most of its libraries would not be. if you look at the list of libraries that are submitted for standartization, you can count 257 entities (classes, interfaces, delegates, etc.) defined in there. On the other hand, if you count the entities provided by the libraries in .NET beta1, and exclude the server-specific stuff, the OS-specific stuff, and even WinForms, you will get a number that is very close to 2000. So in effect Microsoft is standardizing at most 13% of the libraries it provides to Windows developers (the figure would be even lower if we include WinForms and other libs that might also be of interest).

What are the implications of this fact? The standardized libraries might allow OSS developers to build more extensive libraries base on pure CLI (w/o native code) and thus create an environment for multi-platform development. The suggestion to use the .NET libraries for this purpose, however, would fly in the face of everything that we have learned about Microsoft in the past -- as long as they have a monopoly, they will play games with the API, and will turn the whole endevour into a perpetual tail chasing.

It seems to me that Ximian do recognize this fact, but I am not very clear how they plan to counter the problem. In the article Nat said "I hope it doesn't happen" in reference to Microsoft changing the API, and that an open source version would "reduce the chance that Microsoft will be able to do that". If that is their strategy, well... good luck.

Assumption 3: You need .NET (Mono) to implement or use Web services

This is one of the reasons given in the article as to why Mono is necessary, and I am sorry to say this, but it is complete bull. The Web services that MS is advocating are based almost entirely on SOAP and XML, which are completely platform-agnostic and language-agnostic -- that's what MS has been touting as an advantage all along. You can communicate to a Web service using C and a set of SOAP libraries if you want to. If Ximian wanted to have a safe development environment to implement and use Web services, there is already a very mature one in existence that provides superb SOAP and XML support -- Java.

There is only one objective reason that I see for selecting .NET over Java, and it is not mentioned in the article at all: the CLR is designed to support multiple languages, unlike the JVM. The catch here is that the JVM already supports a hell of a lot of languages other than Java and that languages have to be bastardized to be used on the CLR, but still, I guess it does hold some marginal advantage.

Finally, as you can see above, the whole supposed licensing advantage of .NET vs. Java is a complete red herring. In fact, Java holds some practical advantages in that respect: In Java concrete specifications are provided not only the main libraries, but also for many optional ones. Changes in the Java API must be approved via a fairly democratic process as part of the Java Community Process, of which OSS groups such as the Apache foundation are also members, and is open to entry by others as well. All this has allowed a lot of implementations of the various Java libraries by a lot of independent vendors. Will this happen with .NET? Anyone willing to bet money on that one?

This FAQ suggests using the built-in Linux PS/2 mouse drivers for the trackpoints on IBM Thinkpad laptops. You could do this of course, but there is a much better open source driver that allows you to take advantage of some of the enhanced capabilities of the trackpoint, such as the hardware sensitivity control and z-axis control. If you have a thinkpad, you might want to check out this driver if you haven't already.

Java is a nifty platform, but unfortunately it requires that you do all of your programming in Java the language.

Err, not really. See:

• Programming Languages for the Java Virtual Machine
• Other Languages For The Java VM on WikiWikiWeb

Several languages already compile to the JVM, including Smalltalk, Python etc. Someone is nice enough to keep an updated list of them. The advantage the CLR does have is that you have cross-language inheritance, that is your C# class can extend a Java (when the binding is ready) class and so on.

C# is also cleaner than Java to many.

Um, have you actually read the language spec? Any language that uses goto in such ways is evil.

Ostensibly standards-based and open.

Which standards are those? XML? Java has it. SOAP? Java has it. Microsoft has delivered C# to ECMA (here are HP's notes on it), but since the object model is COM/DCOM, what else than their Windows will ever use it?

These two things, plus MS's monopoly, may well be enough to convince or coerce people into dropping Java completely.

Especially the single vendor approach. For Java, there are a huge number of vendors competing with mature tools and libraries. For C#, there is Visual Studio.NET, currently in beta.

for reference, this is the full big ugly string:
set prompt="%{\033]0;%n@%m:%~\007%}%{\033[0;30m%}%B%n% b@%{\033[0;34m%}%B%m%b%{\033[0;37m%}:%~ %B>%b "

The first escape sequence sets the window title to user@host:/path
%{\033]0;%n@%m:%~\007%}

then the rest of the prompt sets the colors for the text on the console (user@host:/path > ).
%{\033[0;30m%}%B%n%b@%{\033[0;34m%}%B%m%b%{\033[ 0; 37m%}:%~ %B>%b

%B and %b are bold, not bold, and the %{\033[0; m%} parts denote a change in color. this page has a listing of the color codes (and lots of other fun stuff!): http://pdv.cs.tu-berlin.de/MinMax/vt100codes.txt

incidentally, if you're logging into the console of a machine you can just use the second part for the prompt without the window title escape. i do that through a switch statement that checks the $TERM variable, but i'm sure there are better ways.

chris

Part of my curiosity comes from the fact that Java already gives us a virtual machine (for compile-once-run-anywhere), Enterprise already gives us CORBA (as opposed to COM), and the Java language at least gives us XML tools. Also, there are already several languages ported to JVM, including Perl and Python. So, from my eyes, everything that .NET/Mono offers seems to already be present for Java. The only thing missing would be a decent set of GUI components (Swing is bloated and slow!), and Microsoft's marketing.

Is there something I'm missing here? Is there some way in which .NET/Mono is not just a reproduction of Java's efforts?

--

You can find it here.

I wouldn't have described purchasing TSR as "cherry picking." TSR was clearly on its way out and without Wizards of the Coast (WotC) would have gone under. WotC had previously failed to turn a profit on role-playing games, and TSR's sad state was more evidence that role-playing games were a bad idea. It took alot of faith to buy TSR.

I was working for Evermore Entertainment in 1997. Evermore was developing for TSR the concisely named Advanced Dungeons & Dragons Core Rules CD-ROM 2.0. I met a number of TSR and WotC employees over the course of my employment. I got to hear, first and second hand, about the problems inside the company. I visited TSR's headquarters in Lake Geneva during the WotC purchase. I even met, as part of a larger group, with Peter Adkison.

I can vouch that Peter was still a huge gaming geek in 1997. It was clear that he wanted TSR because he loved it too much to let it die. Whenever Evermore met with him, he reinforced that he wanted our software to support as many quirk home-brew rules as possible, after all, it needed to work with his game. I got to hear about his plans for the Game Centers, a gamer's home away from home. It would have computers built into the tables to store and refernce notes; projector screens to show maps and monster pictures. While he hoped to make a profit, it was clear that he just wanted to share great things with all of the gamers of the world. (I also discovered that he is the most aggressive driver I have ever riden with, and that he likes lots of ketchup on his burgers.) He would be completely welcome at my gaming table, and I suspect most gamers would be happy to game with him.

Just before the purchase, TSR looked doomed. The previous owners had run the company into the ground. I later learned that the previous owners had detested gamers and the entire hobby. They had simply bought in for the money. They viewed gamers as cattle to be milked and treated as poorly as possible. Garbage like Spellfire (A tarted up version of the card game War with badly recycled art) was released with the belief if you make it, gamers will buy it. Games were kept bland and safe. Older gamers felt abandoned by the company and stopped purchasing products. No real effort to draw new blood was made, so new gamers ended up playing hipper, newer, edgier games like Vampire: the Masquerade. There was no new blood. Sales were dropping every quarter. Debts were piling up, thier printer refused further work until existing debt was paid. After the buyout, employees openly cursed the previous owners.

TSR's continued existance was an embarrassment. I would never had guessed that it could be saved, that its bad name could be salvaged. It was brave of WotC to purchase it under these conditions. Beyond the initial buyout of the company, WotC had to pay off TSR's creditors. Significant time, effort, and money were spent revitalizing the TSR product lines. The rescue of Dungeons & Dragons was amazing. D&D went from a has been contender that gamers looked down their noses at to relatively new and hip. Suddenly friends who haven't played D&D in years were back and enjoying the heck out of it. It was alot of effort to recover the D&D name, and I believe Peter Adkison's love of the game was responsible.

The Georgia Tech design uses the IP Tables firewall functions in the latest Linux kernel to provide the packet-filtering operation. When a client joins the wireless/walk-up network, the firewall/router hands out a DHCP address. To authorize access, the client must open a Web browser. The HTTP or HTTPS (HTTP Secure) request from the client triggers an automatic redirect to an authentication page from the gateway, and the authentication request is passed to a Kerberos server. If authentication is successful, a PERL script adds the IP address to the rules file, making it a "known" address to the IP Tables firewall process

Wind Plants can produce the energy and at not much more than the cost of fossil fuels. Long term it's actually a good idea, at least it would help avoid rolling blackouts!

You want bind-8.2.3-0.6.x.i386.rpm
bind-devel-8.2.3-0.6.x.i386.rpm and
bind-utils-8.2.3-0.6.x.i386.rpm

1. Any Language. [...] I know the Java bytecode isn't tied to Java the language, but realistically, that's the way Sun as limited it.

The other purported advantages you list for C#/.NET/CLR/MSIL are similarly specious. Large-fraction-of-native-speed, cross-platform, secure distribution is already available with the Java-the-platform, and the other advantages you mention are at least as easy with Java (Java-the-language and Java-the-platform) as with .NET. Further, free Java/JVM implementations are mature and widely available (from, for example, IBM, Blackdown, TransVirtual (Kaffe), and Sun, for varying definitions of "free").

.NET is not an example of Microsoft "getting it." .NET is an example of Microsoft continuing not to get it -- reinventing the wheel, rather than building on perfectly good existing systems.

--

If Microsoft can deliver on a *cross-platform* solution.

.NET relies on standard Windows APIs. Only a "compact" version is designed to be portable.

If .NET handles the 30 odd languages they claim to support, with easy extendability for more.

See Microsoft's use of future tense and this list of JVM languages.

If they make .NET a standard, ... What motivation does MS have to lose control of their market? I don't have links readily available, but all I have heard is of MS planning to take the C# specification to ISO, which has nothing to do with standardizing their whole platform. Even if they did, any takers on rewriting Win32? Ask the WINE people how easy it is.

If they can make sure .NET really is vendor neutral, so shipping the .NET foundation is not like shipping the JVM which is little more than a commercial Sun product.

And .NET won't be a commercial MS product. I have not seen MS even try to claim that anything they produce for .NET won't be owned by them. Read carefully.

Then HECK YEAH, I'll take an open, free, extendible, cross-platform platform any day, especially if it ships with millions of Windows machines...

Aha. Windows machines. That's right. .NET is supported on Windows machines. It should make doing Windows network development nicer, with a compact version in various devices acting like embedded Java. MS supports Windows. They make Windows. What motive do they have for changing that? When did they say they were changing that?

I think from a technical perspective the .NET platform...

Try reading the technical documents. Here's one on SOAP. Read it. It's not that exciting. It specifies that you can use normal XML Schemas with a few extra rules and an envelope that mimics HTTP functionality.

You can do little new with SOAP and .NET from a non-Windows computer that you couldn't do with normal HTTP and CGI. SOAP provides almost nothing on top of standard XML. There's nothing new under the sun.

If you want open and exciting, try Linux or FreeBSD. If you want cross-platform software, try something open like C, Perl, Python, PHP, Ruby, or anything else on the list. They also interoperate just fine. Unix had cross-language interoperation working in the 70s. It's called pipes, and it's at least faster than SOAP.

- Tom

No more DLL hell!!!

If this is really true, how can you list it as point #7?

Also, realistically, there are a ton of languages for the Java VM.

Microsoft makes a big deal out of the universality of their runtime, but it isn't significantly more universal than the JVM. They claim they compile C++ into their runtime, but it isn't C++, it's a "safe subset" (full C++ is compiled into native code and linked in--useful, but not a feature of their runtime). In fact, more than 100 languages have been implemented on top of the JVM, including C; there are also semi-automatic translators for C++.

.NET is about not just C# and the runtime, but also about XML. Of course, that's a big thing with Java as well, with several excellent XML projects in Java, perhaps most notably the Apache efforts.

I wouldn't actually care much about whether Java or C# ultimately "wins" in the market, if it weren't for the fact that C# is years behind and has the wrong motivations behind it. Java is, by now, fairly mature and it has an excellent set of APIs and libraries behind it, both from Sun and from other sources. There are numerous compilers to the JVM for languages like Python and Smalltalk. And there are several third party implementations. Java's implementation isn't particularly tied to any one platform, and it actually runs better on Windows than on Sun's own Solaris. And it will take a C#/.NET implementation at least as long to mature as the JVMs--building these kinds of runtimes is hard and requires a lot of benchmarking and user feedback to get the bugs and performance bottlenecks out.

If Slashdot readers care about open source and open standards, rather than complaining about Microsoft, there is a much more effective thing you can do: support open source Java efforts like Kaffe, Intel's Intel's Open Runtime, GNU GCJ (now part of GCC), and GNU Classpath. By "support" I mean: use them, consider them for your next open source project, submit bug reports, and maybe contribute code. GNU GCJ, in particular, should be a good basis for you to write Linux applications: it compiles to executables that start up quickly, it lets you use native code almost as if it were written in Java, and you can even write native Gtk/Gnome applications in it.

But perhaps most importantly, educate yourself about Java rather than complaining about it; Java is really a pretty decent engineering effort. Give it the benefit of the doubt, and wher it needs improvement, help it along. C/C++ will not make it in the long run. It's Java or C# or something else similar to those languages.

Not sure about the first two points:

If Microsoft can deliver on a *cross-platform* solution.
Java is cross-platform, there are VMs for about any system you could imagine.

If .NET handles the 30 odd languages they claim to support, with easy extendability for more.

You can run tons of languages on a Java virtual machine.

You're right, there are quite a few other languages available you can use to produce Java Bytecode, such as Scheme, Eiffel or Lisp (more here).
However, having a VM run inside the browser (with the Java plugin or not), consumes much resources and the startup time is a little long (several seconds on even a decent computer).
That's right, I don't really mind about what language to use, it could either be Python or Flash script, but it should be lightweigtht, portable and ideally should come with a bunch of standard "advanced" components (formatting fields, tables, trees,...).
I know it's tough requirements, but there must be a damn product/project down here that meets them, isn't it ?

.NET is language independant. You can use PERL, Java, Python, C#, VB, whatever the hell you want

Same with Java technology. It's not limited to the Java language; any language that can be preprocessed into the Java language (covers Basic, C, and COBOL), compiled into JVM bytecode (covers Java, JVM assembly language, ML, C, Ada, Eiffel, Python, Smalltalk, and Haskell), or interpreted easily (covers Tcl/Tk, Forth, Perl, Lisp/Scheme, EcmaScript, Logo, Prolog, and Python) can be used with the Java platform. And there are many more.

- clear 1X1 pixel gifs used for spacing with alt tags that say "spacer" - doing typesetting with 1X1 pixel transparent gifs is a kludge that adds a lot of excess html to your docs

There's more to this than you mention. The important thing is that HTML is no TML. People keep trying to make it into things it isn't.

- more than 2 frames in a page - on rare occasion, I can stomach two frames.

What's worse is when frames aren't optional; When you need a frame to navigate a site. This makes life really hard when you're trying to order a part for your whoosiewhatsit when you're in bumfuck nowhere, all you have is packet radio and a text interface, and no phone.

- websites that play music - saw a sig on /. that said "If I wanted your site to make music, I'd have turned on the radio"

This is something that should be optional and OFF BY DEFAULT. It is *trivial* to carry a session variable in coldfusion or php (harder in IIS/ASP; I suggest you use a cookie there) which will remember a simple true or false. Give someone a radio button (oddly appropriate) or a link or SOMETHING to turn ON music if they want it. Most of us won't, because music on webpages is stupid and unncessary.

- websites that have all info in non-html or text formats like doc, xls, pdf, ps - Thanks for nothing - just post the info and use html or text. More info and file formats are nice, but put the info in text first.

A good site search engine can search through PDFs as well, so you can find data. PDF is a reasonable place to store data, because it's insanely cross-platform these days. Admittedly, some people can't view it, but some organizations are very picky about the appearance of their documents; If a document can't be presented a certain way, then it doesn't make it into the medium. I think it's better to have the data available as a PDF than not available at all, or only available via snail or fax.

- websites that try to determine your browser type and give you messages about needing a different browser - deal with what I have. You're in no position to require me to do anything.

Au contraire. They're in a fine position to require you to do something. If you won't do it, you're probably going to cost them money, or at least they'll make less money off of you; You of course are welcome to go find someone else who doesn't have restrictions.

- more than one animated gif on a page

Amen.

Poor choice of words on my part, sorry for the confusion. See http://grunge.cs.tu-berlin.de/~tolk/vmlanguages.ht ml for a great list of languages that compile to the JVM.

--Nathan Torkington

Where Microsoft betters Sun is that while Java is the only real language that compiles to the JVM, Microsoft intends IL to be cross-language. That is, Perl, Visual Basic and C# can be compiled down to IL.

Microsoft may be better on public relations there but no on substance. Perl could easily be compiled into Java byte codes (in fact, there is a project around to do just that), just like Python, Smalltalk, Scheme, Basic, Modula, Pascal, and lots of other languages are. While the JVM is most natural as a target for a Java compiler, it is a pretty universal runtime for safe languages, and most of them can be compiled into it without major problems.

And when it comes down to the one area where Microsoft could genuinely differ, compilation of C++, they fail to deliver what they promise: only a restricted subset of C++ is compiled into their intermediate language; you could do the same for compiling a restricted subset of C++ into the JVM.

If you want more information on language for the Java VM, look here. It lists about 130 systems that implement existing languages based on the JVM.

"Not Real" languages: Tcl, Haskell, Lisp, Scheme, BASIC, LOGO, Eiffel, Smalltalk, COBOL, Ada. More at Programming Languages for the Java Virtual Machine

In the case of .NET, what MS is really saying is "we do the Java VM better than the Java VM." The core of .NET is a virtual machine which is supposed to provide all the benefits of the JVM with less focus on a single language - and therefore not subject to that one language's limitations.

If you consider the fact that the JVM has been used as a target for an enormous number of other languages, the .NET approach actually makes a lot of technical sense. Interoperability between languages - for example, between a server-side web scripting language and a more heavy-duty back end language - becomes trivial when both languages execute in the same virtual machine. People are already doing this sort of thing to some extent, using things like Rhino (Javascript on the JVM) or Jacl (Tcl in Java) as a scripting environment to invoke heavier-duty Java objects.

This approach isn't completely mainstream at the moment, but it has a lot of benefits. Microsoft has paid attention to these possibilities and is betting their development strategy on it, in the same way as they bet on COM/ActiveX previously.

I suspect this will be very successful amongst loyal MS developers. True, you'd have to be drinking serious amounts of Kool-Aid to be willing to devote development resources to developing in a brand-new language like C#, which because of its origins has little likelihood of gaining the kind of multi-independent-vendor popularity that Java has. But if you already use one of the other languages that support .NET, there's little risk in taking advantage of it if you develop only for MS platforms.

I look forward to seeing open source projects compete in this arena. The JVM opened the door to this, but Sun's proprietary attitude to Java has caused many problems. Either the JVM must be freed from its proprietary roots, or an open source alternative must arise. Either way, open source just makes an incredible amount of sense for such a strategic base platform - as with Linux, it becomes much easier for vendors of any stripe to commit to it.

There is already GSM coverage over much of the US, but it is far from complete, and presents problems to international visitors, who cannot use global roaming on their dualband GSM phones. While not exclusive to GSM networks, SMS is an extremely useful facility (nine billion SMS were sent around the world in August) that many users of non-GSM networks often miss out on (you can send SMSes to phones from many web sites for free). GSM ties in with the other popular acronyms at the moment - GPRS, WAP and Bluetooth (but not iMode - iMode is something specific to DoCoMo and their phones, while the rest of the world uses WAP).

There is more information on GSM at GSM World and the North American GSM Alliance.

• there are opensource implementations of the JVM
• You can download the java spec from suns website, perhaps not as open as it could be but try to get document describing win32 in full
• JSP has a freeware implementation
• there are a lot of other opensource projects based on Java.
• there are multiple vendors selling Java development tools as well as opensource projects providing such tools
• there are dozens of other languages implemented on top of the JVM (check this site for a good overview. JPython is cool BTW!)

Gah! Let's not fight inaccuracies with inaccuracies. That way madness lies.

The .NET platform is an improvement for Visual C++ and Visual Basic programmers, but it is yet another proprietary Microsoft platform which will tie the developer to Windows, albeit possibly a .NET-ized notion of Windows.

I love Java, but this is simply bullshit. The main purpose of .NET is the exact opposite. It's purpose is to allow developers to actually use COM and the Windows API without being shackled to VB and Visual C++.

You haven't contradicted the quoted statement. In fact, it seems that you agree with it. If using COM and the Windows API isn't being tied to Windows, I don't know what is.

Currently there are plans for .NET to support the following languages APL, CAML, Cobol, Haskell, Mercury, ML, Oberon, Oz, Pascal, Perl, Python, Scheme, and Smalltalk.

Obviously this scares Sun and that's why they are publishing this propaganda because it begins to show the truth that Java shackles developers by forcing them to use the Java[tm] platform for all development in all three tiers of a client-server application if they plan to use the Java[tm] language for any aspect development (yes, I know about JNI, but it is currently subpar).

I'm not sure where you get this idea. Certainly, if you want to use the full-on J2EE platform then you need to use Java, just like you need to use .NET if you want to use .NET. But nobody said that you need to program to J2EE to write a client-server application. You can use CORBA in Java. You can use SOAP if you really want to.

Want Java applets that talk to CORBA services written in Haskell that talk to an RDBMS? You can have that. Want Perl CGI scripts that use SOAP to talk to a JAVA middle tier application? You can have that, too.

It looks like .NET is promising this as well, which is all well and groovy, but just because Sun published someone's opinion that you don't agree with is no reason to try to spread misinformation.

I agree, BTW, that the article is heavily slanted in favour of Java, but what did you expect?

Regards,

Toby Allsopp.

(To quote myself)
You can in fact write (and compile) code for JVM in Eiffel, Fortran, LISP, Visual Basic, Ada 95, Python, PERL, C, any language that GCC supports, and a whole slew of other languages (170 or so).

See the comments to cid 135 and this page.

BS! You can in fact write (and compile) code for JVM in Eiffel, Fortran, LISP, Visual Basic, Ada 95, Python, PERL, C, any language that GCC supports, and a whole slew of other languages.

In the future, keep your uninformed ramblings to yourself.

See the comments to cid#135this page.

This is how. Not much on Lisp, but quite a bit for Scheme. There are also many other languages listed at that site that have been made to work inside of Java. I know that JPython is very popular!

Look here.

What part of that doesn't apply to Crystalspace? It's a very nice piece of software, but just as there are lots of libcs out there, there's no shortage of 3D engines.

I'm not suggesting that Stallman's right or wrong, just that he judges Jorrit's choices a bit more harshly than he does his own.

You can buy the Java VM specification or read it for free on-line. So there is a de jure standard. As for de facto, there are over 130 languages that can be compiled to JVM bytecode. There's even a GCC *backend* for Java (no, not the gcj *frontend*), which seems like it would obsolete this "Internet C++" project in short order.

~wog

A Dick and a Bush .. You know somebody's gonna get screwed.

And those languages are C# (copy of Java), C++ (ugh) and VB (no comment necessary).

10. With Java, you have to learn Java. Plus, statistics show that 70% of all Java developers target APIs that are native to their platform.

That doesn't sound right, do you have a source? Most server-side Java is very portable.

With .NET, you can write in *any* of over 15 already-announced languages.

Languages for the Java VM.

If you actually want to speak intelligently about this, you really owe it to yourself to try it out.

Which I can't do, since I don't own any Windows systems.

The sad thing is, you'll be talking it down, when in fact, it's one of the coolest things I've ever seen in this industry.

It very well may be. But, at this point I don't see how anyone can trust Microsoft to put stability and sound architecture ahead of marketing concerns. Microsoft talking about standards compliance and cross-platform technologies has about as much credibility as Al Gore talking about campaign finance reform. Maybe in a year

Another thing, unrelated to service...

DO NOT, repeat, DO NOT get a USB modem. If you can avoid it, don't get an Alcatel modem. They are known to have problems with sync.

If your provider insists that you use PPPoE, try to get a router. Netgear RT-314 and RT-311 as well as the Linksys BEFSR41 or BEFSR11 seem to be pretty popular.

If you use PPPoE, and you don't want a hardware solution, try RASPPPoE instead of Enternet.

The advantage to the Linksys BEFSR41 and the NetGear RT-314 is that they are 4-port switches plus the DSL/CableModem router.

A good list of programming languages for the JVM can be found at http://grunge.cs.tu-berlin.de/ ~tolk/vmlanguages.html.

Tetris Tetris Tetris Pacman Asteroids Centipede

And for you people that grew up on the kaypro, cloned Ladder! (Shameless self plug)

I'm sure you can any of the most popular games just with a quick search on google. :

• Lisp
• Scheme
• ML
• Eiffel
• Sather
• Smalltalk
• Ada
• Pascal
• Oberon
• Python
• COBOL

• Haskell
• Mercury

"Real FORTRAN programmers can program FORTRAN in any language." --Allen Brown

There is a lot of confusion here about whether or not the .DOC format has been documented, because there are two layers to the file format. First, there is the Word document format itself, which Microsoft has published in some MSDN CD versions. It also available from places like www.wotsit.org. This specification is inaccurate in places but close enough to make Word document conversion possible. Caolan McNamara has a very good start on a Word-to-HTML converter at www.wvware.com. The Word document format changed in the transition from Word 6 to Word 97, and is the same in Word 2000.

However, Word documents since version 6 are wrapped in OLE Compound Documents, which Microsoft also uses for .XLS files. The Compound Document format is not officially documented anywhere in Microsoft documentation, as far as I can tell. (But see below for a patent that might disclose this structure...) The MSDN library samples invariably use Windows system calls to access data in Compound Documents, and reveal nothing about the file format.

There have been some efforts to reverse-engineer this format:
http://arturo.directmail.org/filtersweb/ and
http://snake.cs.tu-berli n.de:8081/~schwartz/pmh/guide.html,

A Compound Document contains a tree structure of data streams, which seems like a simple enough structure but it is implemented using a very complex file format. The lack of complete documentation of this format is a major impediment to development of robust open-source code that will access the Microsoft Office file formats.

A second potential impediment is a nest of patents that Microsoft has built around the Compound Document format. These are just a few:
US5467472: Method and system for generating and maintaining property sets with unique format identifiers
US5715441: Method and system for storing and accessing data in a compound document using object linking
US5506983: Method and system for transactioning of modifications to a tree structured file
US5706504: Method and system for storing data objects using a small object data stream

There are a fair number of patents (IBM seems to have some possibly related ones as well). You can find them here: http://patent.womplex.ibm.com/home. A search for "((compound document) and microsoft)" lists 24 patents. It would not be surprising if a serious effort to provide open-source access to Microsoft Office documents ran into legal threats because of these patents.

Interestingly, the last one looks like it might disclose the Compound Document format, which Microsoft would have to disclose to satisfy the patent office. The description looks right, but the diagrams do not seem to be available from the IBM site. Looks like I'll have to dig some more -- anyone know how to get the full text and images for U.S. Patent 5,706,504?

LAOLA looks like a good solution.
___

Here is a link to download a Lossless Predictive Audio Compression encoder for Linux (and the page I found it on).

PAC is very likely to be avalible for some other Unix, so it would (with a little work) probably work on Linux.

Here is a link to download a Lossless Predictive Audio Compression encoder for Linux (and the page I found it on).

PAC is very likely to be avalible for some other Unix, so it would (with a little work) probably work on Linux.