Slashdot Mirror

Sun started the ISO process over 5 years ago in 1997,Sun's ISO Process
Then in 1999 the began to standardize in ECMA
The then withdrew their application later that year. Details

If you take a look at Apple's system architecture:
OSX you can see that Apple is putting the JAVA API at a coequal level with the Classic, Carbon and Cocoa APIs - all the others being Apple products. This is exactly the kind of treatment Sun has always wanted; Sun's Java being setup as a major part of the system architecture allowing it to run cross platform with the same capacity as native apps.

Now where is Sun supporting Apple in this? Apple offers a standard set of development tools as part of the OS - why isn't Sun writing or co-writing tie-ins for interface builder and Swing? Why aren't they optimizing the JAVA Apple API for Darwin? Why when you click on Java at Sun do you see absolutely virtually nothing about the Mac OSX platform? Why doesn't Java include routines to handle files with resource forks better?

If this isn't proof that Sun has no intention against standing behind Java implementation with real resources and real money I don't know what would be.

I've desparately tried not to respond to this thread, but I feel I must.

Rick Ross may be the founder of the Java Lobby, but he does not represent all Java Developers and supporters. I find comparing Java's difficultites on the desktop to the murder of a 14-year-old girl despicable, and not worthy of any further comment.

Java has difficulties on the desktop. Not all clients, just the regular desktop (JSP, Struts, Velocity etc are great examples of serverside java making good client code in ...HTML). 5 years ago, even us die-hards would cringe at a Java GUI app. But a great deal has changed in 5 years. Java has cut it's teeth on the server, to become a major force in enterprise, server-side development.

Despite what some nay-sayers have said, Swing is much better. One can write good, cross-platform GUI's with it*. Check out, JBuilder, the latest Netbeans, Together Control Centre an many more here.(AWT was bad, Swing was better. But as good as Java is, bad programmers still write bad code.)

Client dcevelopment was a bust in 1995-98. Not any more.

We now have the advantage of the Hotspot VMs, redesigned IO (both nio and Image IO). J2ME Midlets are pretty good little GUIs for limited devices. Redesign in the Java 2D and 3D libraries as well as Swing has helped too.

I think Java could NOW become a feasable platform for desktop GUI development.

Did MS purposely design it's VM to bring about the downfall of Java? The courts seem to think so. 5 years ago there was pretty much only GUI development with Java, so that's where MS attacked. It drove Java to the serverside where it flourished (Thanks MS ;) ).I think Java on the desktop would have met the same fate even with no MS...MS just helped it along (shoot a dying man, your still guilty of murder).

Now revitalized, I beleive it's ready to come back to the desktop. (Does any of this sound familiar, Gnome/KDE hackers?)

Rick Ross, stop causing sh*t and let us get on with making good Java software, on both the client and the server, and leave the FUD to MS.

The way to beat MS is not (just) in court, but in rock solid software. Enough blubbering, more coding...

*Note: I've heard a great deal about it here, but in 5 years, I have never run into any portablitiy issues with Java, when written to spec)

Here is the list of Sun filings. You may believe this link is biased, but its what I found to be the most complete without searching for days. (AFAICT) The specific license(s) MS violated are the Technology Distribution License Agreement (TDLA) and the Trademark License Agreement (TLA).

In a nutshell, the main violations were with removing required functionality. Specifically, MS decided not to implement JNI (in favor of J/Direct). Others are likely listed in the filings, I just haven't gone through them all.

The issue is not that MS added something, but that they intentionally replaced required functionality with their own. HP has a JVM that includes things specific to HP-UX, but they still played nice and kept the required functionality. MS decided to violate their contractual agreements, and make an incompatible JVM that they claimed was "full compliant" with the licensing term.

This isn't just a case of someone (here it was MS) deciding to "be different", but of "breach-of-contract".

Or, as has been said in the past, go and download something from Sun. They've got pretty good connectivity (actually they have their own mirrors); I generally download from Sun at the full rated speed of my connection, whereas if you are downloading anything from a Linux mirror site, you may be limited by their bandwidth. YMMV. Obviously, this is an extremely unscientific exercise, but if you are seeing numbers in the ballpark (about 170-175KBytes/sec observed) it's a decent yardstick.

Don says that two years from now XML Web Services One won't happen. He's right: I've been hearing that Web Services Edge", on both coasts, has already taken over. Why else would Jonathan Schwartz be keynoting for them? Sun sees that XML's the only onion in the Web Services stew too, but he wants to speak at a show that will last for 5-7 years, not die after 2.

Is a real run-down comparison between the everything engine, j2ee, zope, and webobjects.

Yeah, so if you're just doing some random weblog, it makes sense to look at things at the unabstract, content-management-system level. But some of us find more interesting the idea of a system that allows for you to create a website by attaching abstract prebuilt website components together, defining the kinds of pages that you will have on your site as types, and then allowing the website to be created on a backend by less tech-saavy users who are shielded by the system from the raw code. This is what the above four systems basically are.. and it is much more powerful than just a simple CMS, though you can certainly incorporate CMS features into something you make with it.

The Newton group actually thought about and did user testing on their interface, then published interface standards. Unlike most OSes

Sigh. I spend so much of my professional life dealing with poorly thought out languages/systems that I look back very fondly on the Newton.

Actually I still use two of them. One is in the kitchen - I use it to keep track of groceries I need. The other sits by my desktop machine for taking notes.

There's a beta version of Netscape 7 available for Solaris. You can find it at Sun Microsystems's webpage.

Netscape on solaris is supported by SUN. The latest version available on Solaris is 6.2.3 u can get it from
Netscape On Solaris
Also solaris mozilla binaries take about 4-5 weeks before they are available on mozilla.org. And building it from source is pain in the A$$.

On the higher clockrate: This isn't necessarily a good thing. Anytime a jump is encountered in the code (i.e. GOTO), the processor, (and its lengthy pipe, something well over 20 stages last I checked, not sure about these newest Intel chips) is encounterd, all the instructions in the pipe need to be dumped and new code pulled, which = wasted clock cycles. I guess this means the processor can afford more wasted cycles. On the SPARC processors from the previous comment: Sun Micro's SPARC (Scalable Processor ARChitecture) is a 64 bit processor and in it's newest (that I'm aware) incarnation is 1.05 GHz with a 16 stage pipeline. The processor is scalable from 600 MHz to 1.5 GHz, which Sun anticipates expanding to at a later stage in development. Long and short, they're probably the best processor MHz for MHz. These things also rock for multi-processing. UltraSPARC III White paper.

For those that are particularly worried about the new clauses in the license, why not simply ask Sun (politely) about them rather than letting the paranoia build up with every reply posted here?

You could contact your Sun rep, or use the contact method listed in the the legal and licensing FAQ, or even through the Sun JAVA Forums.

Better to ask first, rather than to jump to incorrect assumptions.

Steve.

For those that are particularly worried about the new clauses in the license, why not simply ask Sun (politely) about them rather than letting the paranoia build up with every reply posted here?

You could contact your Sun rep, or use the contact method listed in the the legal and licensing FAQ, or even through the Sun JAVA Forums.

Better to ask first, rather than to jump to incorrect assumptions.

Steve.

Well, for starters, Solaris boxes are rather expensive,

Really? Apart from Solaris on x86, you can get Sun hardware for $1k now - OK, you can buy cheaper x86 systems, but by the time you factor in the usual MS stuff (Win2k, Office, support costs for another Windows box) Solaris could well be a better option.

I'd suggest a fire wall, and disabling the autoinstallers.

I'd suggest the obvious approach. Think: what exactly does your database system need Internet access for? Just don't plug it into the Net: keep it sitting on a desk, offline (or at least LAN only). That way, it cannot be compromised except locally, which isn't usually an issue (just lock the door!)

It's quite depressing how many people assume computer=networked=on-Internet-without-firewall these days. Despite all the dot-com style hype about online domestic appliances, your refrigerator, toaster and medical records server do not need (or even benefit from!) an Internet connection!

Sun pulled downloads of the Java Media Framework last week because of an undisclosed "licensing issue". Wonder if this it.

Guess there's no point promoting my open-source shoutcast/icecast support for JMF anymore. Damn. Almost topped 20 downloads.

--realinvalidname

[With a shell account,] you wouldn't need to [haul big files] very often - you do most of your work in your shell account on the remote box, right?

Much of my current work involves image editing, audio editing, and development of interactive graphical simulations. Do those work well over SSH?

The thought process is that since you have so little bandwidth and probably less power, disk space, memory, etc. at home that there's not much point in using that computer as anything but a glass terminal, and doing interesting things only on the remote system.

I'm still unclear on some of the uses of a shell account. Let's cross-check your thought process against your list of applications:

You can run servers, read mail, send mail, transfer files around, develop software, and so on.

Not according to the AUPs of most of the free shell providers I've seen. (Free shell providers are the subject of this Slashdot article.)

You can run servers, read mail, send mail, transfer files around, develop software, and so on.

Which is limited by the speed of the eyeballs and fingers. How is reading mail over SSH any better than reading mail over SSL'd IMAP? And unless you run a mailing list, why would sending mail need a lot of server bandwidth?

You can run servers, read mail, send mail, transfer files around, develop software, and so on.

To what? To other people's shell accounts? Transferring big .jpg files using a shell account doesn't get them to my screen any faster.

You can run servers, read mail, send mail, transfer files around, develop software, and so on.

I assume you're just talking about logging into a remote machine to maintain a CVS repository such as on OSDN's own service. Otherwise, doesn't a fellow who develops software want a fast connection from the box where the application runs to the box where the application's display runs? That's likely to be a lot faster on localhost than on dial-up. In addition, using a programmer's text editor such as GNU Emacs or Vim over a network connection with a 200+ ms ping is a pain in the donkey.

The shell account is the network pc taken one step further, and is effective even with fairly slow networks.

Unless you want to run anything that's image or audio based and interactive. Take too much intelligence off the client, and you run the risk of having the cumulative effects of long-haul latency (speed of light across a big country such as the United States) and last-mile latency (slow dial-up connection) ruin the interactive experience. Has X11 been optimized to run efficiently over 48 kbps down, 24 kbps up?

Still, if you didn't think thin client computing was a good idea, you probably don't find shell accounts useful either.

Makers of modern network computers recognize that thin client does not mean as thin as a teletype machine's paper. They try to achieve a compromise between the shell account setup (all intelligence on the shell server; client is just a terminal or X server) and the PC setup (all intelligence on the client; only data is shared across the network) by using applets compiled to a cross-platform bytecode and run across the network. For more about this approach, look at Java(tm) technology or its competition.

Now that the latest offerings in the Mac world are upon all of us (iMac, Titanium Powerbook, OSX, etc.) - I thought it was time to take one more look. Nope, pretty new "candy coating" but same old proprietary, over-hyped core.

Just from the whining posts of "OS X is cool but Apple is a big, mean, evil proprietary hardware manufacturer", you can see that O'Reilly is completely wrong in suggesting Linux users are a perfect niche target

What you are saying might be true for Linux hobbyists, but it doesn't apply to corporates who might be considering a Unix desktop, especially one to unify their former Mac and Windows users. Only one of those groups is willing to spend money on an operating system. Apple could well enjoy much greater success than Sun on the desktop of non-technical users.

> Which innovations? And how have they hobbled them?

Client-side Java for one.

As a Microsoft document stated:

> the "strategic objective" is to "kill cross-platform Java by grow[ing] the polluted Java market."

See: http://java.sun.com/lawsuit/051498.unfair.html

As a result of Microsoft's polluting the Java standard, "cutting off Netscape's air supply", and including a non-standard JVM with IE, a situation was created where businesses and web developers were reluctant to use Java, because they could not count on visitors being able to run Java in their browsers.

If web developers had been able to count on client-side Java during the last four years, can you imagine the innovative and interactive websites, including e-commerce sites, that would exist by now?

Microsoft's act of sabotage cost the economy billions of dollars.

Telstra deal + Sun does linux = Telstra does linux

Telstra deal + Sun does linux = Telstra does linux

Indeed, the only proprietary software code anywhere in my computer is that which lives in the BIOS.

This is true of most x86-based computers, but perhaps less so of other architectures. Could a push to commoditize the SPARC architecture go further, where open implementations of the firmware could be used? According to Sun's OpenBoot documentation, the firmware is an IEEE standard interface.

Perhaps an implementation of this firmware could be adopted to x86, as well, to help break the ugly history of the x86 BIOS?

They just signed on with Sun for their back-end infrastructure, so UNIX on the desktop might make more sense. Sun press release

Sun Microsystems just released a Storage Area Management (SAN) management application based in part on Tomcat. Information is available here. Other technologies used include Postgres, Apache, and SLP. Almost qualifies for LAMP...

What the hell are you talking about?

You didn't mention what spec you mean but I think you meant that Tomcat implements Servlet, JSP etc. specs poorly?

I wonder what is your standard for poor but you can't get any better compliance than what you get with Tomcat namely it happens to be the official, Sub-blessed reference implementation of these very specs. If you're in doubt, then check these URLs: Java Servlet technology - Implementations ja Specifications at java.sun.com and Front page of Tomcat site. Thank you.

The problem seems to be that it is extremely difficult to benchmark such servers. Greg Wilkins, one of the primary authors of Jetty, explains the issues fairly clearly in a response to the Jetty Benchmark thread on the jetty-discuss list.

In addition, experience shows that J2EE application optimization is not as straight forward as other Java applications, so it is easy to get radically different performance results from a servlet with only minor tweaks. There was a wonderful presenation at JavaOne 2002 San Francisco about servlet optimization (link for atendees only). Among other things, the author demonstrated. a simple 6 line "Hello World" servlet that is written in standard style, yet can be made to run 3x faster with only minor tweaks. He also shows that testing under load reveals that servlets can behave much differently under load and that the only way to really write fast and reliable servlets is to write them as you normally would and then test them mercilessly.

My conclusion is that you can't believe any of those published bechmarks, they're mostly biased marketting crap (everybody's benchmark seems to show their product is fastest). What you really need to do is load up multiple servers and configure them to do what you need them to do and test them under load to see how they perform in your environment. I know it's not what you want to hear, but since there are so many features that have varying performance, it's the only way to really find out.

I know that you are probably looking for an open-source solution, but Sun has promised to release a free version of their application server this fall.

Sun "basic" application server

It will run on Linux.

There are also Java User Groups going up all over as well, and have been for several years. I'm not sure if they were founded by Sun or are funded by them, but Sun does have a website listing info about them, and it seems there are currently 954 of them.

There are a bunch of open projects that implement bits and pieces of the Java platform

Right.

there is no standard or agreement on what constitutes an implementation of a core Java feature set.

Wrong.

J2ME, J2SE and J2EE are very well defined in public specifications. These are backed by comprehensive conformance test suites, the use of which was a significant source of revenue for Sun, and which they are now offering to open source developments to under their "Scholarship Fund".

Are you slashbots sure other companies haven't tried things like this before? Don't you find it funny that a lot of the colleges in that Google search have gotten funding and done collaborative work with Sun Microsystems and -- strange! -- some of their courses are taught in Java?

Do you really, really think other companies don't do this? Do you seriously think it's bad just because it was Microsoft and C#, and not Allegro and Common Lisp?

And I defy any of you to tell me why it should matter that some students are taught C# as their introductory programming courses, whilst others are taught Java, C++, or C. They're supposed to be learning the fundamentals of programming, not learning how to write a fuckin' application. Why the fuck does it matter what language a college finds this easiest to teach in?

Grow up, people.

- A.P.

Good to see that Sun believes in Linux enough to put some hardware effort behind it. I wasn't so sure, when I read this Sun article a ways back.

Linux on the Mainframe--Not a Good Idea

For those with nothing better to do this afternoon... you can watch Sun's presentation via a webcast at 1pm EST here

I think so. I mean, it's this just the whole thin-client ideology? Sure, sounds great, but not realisting in today's desktop environment. One can take a look at Sun's Java station to remember how well the Java thin-client fared.

Sun[tm] LX50 Server Press Conference Press Kit here (photos, datasheets, documents)

:-D

Yes, this is one special feature 4U and welcome to my universe :-D

well, Solaris 9 for SPARC can be d'loaded for free (as in beer), so I hope similar treatment for x86 is in store. See http://wwws.sun.com/software/solaris/binaries/get. html

Sun Microsystems announced the Sun LX50 today at LinuxWorld. They also are again shipping Solaris 8 for x86, the cost is $45 for the CD or $20 to download the CD image. They have not yet released Solaris 9 for x86 for general availability, as far as I can tell.

The LX50 is intended for edge computing. For example as a web or proxy server. It runs "Sun Linux 5.0", although I can't find out much about what that distro is. It appears to be based on the UltraLinux distro.

Since Solaris 8 for x86 was one of the fastest and most stable UNIX releases for Intel platforms I would venture to guess that the 9 release will be also. The usual problem will be the lack of ISV applications for the product. Although numerous open source packages will be available, making it a great web server or email server.

Sun Microsystems announced the Sun LX50 today at LinuxWorld. They also are again shipping Solaris 8 for x86, the cost is $45 for the CD or $20 to download the CD image. They have not yet released Solaris 9 for x86 for general availability, as far as I can tell.

The LX50 is intended for edge computing. For example as a web or proxy server. It runs "Sun Linux 5.0", although I can't find out much about what that distro is. It appears to be based on the UltraLinux distro.

Since Solaris 8 for x86 was one of the fastest and most stable UNIX releases for Intel platforms I would venture to guess that the 9 release will be also. The usual problem will be the lack of ISV applications for the product. Although numerous open source packages will be available, making it a great web server or email server.

Not only will Solaris 9 run on x86, but Sun's new LX50 server is x86 based. And the really cool thing is you can get it with either Solaris or Sun's new Linux distro. This marks an interesting turn for Sun, throwing support to both x86 processors *and* linux.

Not only will Solaris 9 run on x86, but Sun's new LX50 server is x86 based. And the really cool thing is you can get it with either Solaris or Sun's new Linux distro. This marks an interesting turn for Sun, throwing support to both x86 processors *and* linux.

Beside the anouncement of Sun Linux, Solaris x86 is back at Sun, with Solaris 9 and 10 apparently in the Pipe. After struggling with the Solaris x86 community since the beginning of january, when Sun looked like they were killing the x86 version, Sun's Graham Lovell revealed the hopefully bright future of Solaris on x86 hardware.

The Solaris x86 community is cheering over in alt.solaris.x86 and on the Solaris x86 mailing list.

Solaris x86, now offered side by side with Sun Linux on the new BigBear line of Intel based servers at Sun is quite useful, even on generic x86 hardware.

Companies can add cheap edge servers based on commodity x86 hardware to complement their Solaris/SPARC installations which integrate well with each other and offer essentially the same administration tools. If the need for power grows, existing software is easily transferred to bigger, expensive SPARCs. This makes Solaris x86 unique, since this way a commercial grade Unix is available across the whole scale from small cheap x86 boxes up to 106 processor SPARC SMP machines.

For students and developers Solaris x86 is great, since they can use existing x86 hardware to dip their toes in the waters of Solaris without having to shell out for SPARC hardware.

Having to develop and support Solaris on more than one architecture forces Sun to keep Solaris portable, and that may be very useful if the SPARC architecture might prove to be a dead end, with only a small niche market left that actually needs and affords it.

It's also quite nice to have the usual Solaris envionment available on normal x86 based laptops.

While I personally use mostly Linux and Mac OS X it's nevertheless great to see other Unices alive and kicking. Competition in the x86 Unix market is good, and having the commercial versions competing with the free versions keeps everyone on their toes.

Beside the anouncement of Sun Linux, Solaris x86 is back at Sun, with Solaris 9 and 10 apparently in the Pipe. After struggling with the Solaris x86 community since the beginning of january, when Sun looked like they were killing the x86 version, Sun's Graham Lovell revealed the hopefully bright future of Solaris on x86 hardware.

The Solaris x86 community is cheering over in alt.solaris.x86 and on the Solaris x86 mailing list.

Solaris x86, now offered side by side with Sun Linux on the new BigBear line of Intel based servers at Sun is quite useful, even on generic x86 hardware.

Companies can add cheap edge servers based on commodity x86 hardware to complement their Solaris/SPARC installations which integrate well with each other and offer essentially the same administration tools. If the need for power grows, existing software is easily transferred to bigger, expensive SPARCs. This makes Solaris x86 unique, since this way a commercial grade Unix is available across the whole scale from small cheap x86 boxes up to 106 processor SPARC SMP machines.

For students and developers Solaris x86 is great, since they can use existing x86 hardware to dip their toes in the waters of Solaris without having to shell out for SPARC hardware.

Having to develop and support Solaris on more than one architecture forces Sun to keep Solaris portable, and that may be very useful if the SPARC architecture might prove to be a dead end, with only a small niche market left that actually needs and affords it.

It's also quite nice to have the usual Solaris envionment available on normal x86 based laptops.

While I personally use mostly Linux and Mac OS X it's nevertheless great to see other Unices alive and kicking. Competition in the x86 Unix market is good, and having the commercial versions competing with the free versions keeps everyone on their toes.

Beside the anouncement of Sun Linux, Solaris x86 is back at Sun, with Solaris 9 and 10 apparently in the Pipe. After struggling with the Solaris x86 community since the beginning of january, when Sun looked like they were killing the x86 version, Sun's Graham Lovell revealed the hopefully bright future of Solaris on x86 hardware.

The Solaris x86 community is cheering over in alt.solaris.x86 and on the Solaris x86 mailing list.

Solaris x86, now offered side by side with Sun Linux on the new BigBear line of Intel based servers at Sun is quite useful, even on generic x86 hardware.

Companies can add cheap edge servers based on commodity x86 hardware to complement their Solaris/SPARC installations which integrate well with each other and offer essentially the same administration tools. If the need for power grows, existing software is easily transferred to bigger, expensive SPARCs. This makes Solaris x86 unique, since this way a commercial grade Unix is available across the whole scale from small cheap x86 boxes up to 106 processor SPARC SMP machines.

For students and developers Solaris x86 is great, since they can use existing x86 hardware to dip their toes in the waters of Solaris without having to shell out for SPARC hardware.

Having to develop and support Solaris on more than one architecture forces Sun to keep Solaris portable, and that may be very useful if the SPARC architecture might prove to be a dead end, with only a small niche market left that actually needs and affords it.

It's also quite nice to have the usual Solaris envionment available on normal x86 based laptops.

While I personally use mostly Linux and Mac OS X it's nevertheless great to see other Unices alive and kicking. Competition in the x86 Unix market is good, and having the commercial versions competing with the free versions keeps everyone on their toes.

It was Sun SparcStations 20 (117) and a SPARCserver 1000. You can read more from SUN's press release:

Disney's "Toy Story" Uses More Than 100 Sun Workstations to Render Images for First All-Computer-Based Movie

Besides, people in CG know that Tom Duff is an authority and knows what he is talking about. There are many reasons why realtime CG won't do Toy Story class rendering in the near future. Have to consider the hype from the graphic card manufacturers. The demos and presentations at SIGGRAPH are neat and impressive but film CG has a lot of requirements. The same thing was mentioned when both the PS2 and GSCube were announced and we still haven't seen a Toy Story type rendering in real time.

Here are a few more threads from the RenderMan newsgroup regarding the matter:

What does GSCube do?
Playstation 2 and "Toy Story"
Real-Time RenderMan?

Actually the Sun Blade 100 workstations start at $995.00.
The new iMacs start at $1,399 and the eMacs start at $1,099.

For those who have never heard of WBEM, it was an initiative to provide a framework for cross-platform management of machines.

• WBEM = Web Based Enterprise Management
• CIM = Common Information Model
• DMTF = Distributed Management Task Force

• SBLIM = IBM's "Standards Based Linux Instrumentation for Manageability" (Open-Source)
• WMI = Microsoft's "Windows Management Instrumentation"

Each implementation of WBEM consists of services which expose some core set of platform/application/host-specific objects via a (theoretically) platform-independent CIM object.

M$ had some sample scripts in the resource kit at one time, but the best link I can find is this. (One of these scripts found its way into Knowledge Base article Q271362; it gives you the short names of services so that you can start and stop services from a W2K command line or script; my version is here).

There seems to be a WBEM implementation for Solaris as well in JIRO, but my guess is that it's a small subset of CIM for managing storage devices.

I would recommend seeing what SW is out there from Computer Associates, Tivoli, and similar places that is "cross platform", particularly ones that might be MMC-based, or best yet that say they use WBEM/WMI/..., and get a trial version to see how interoperable it really is. Then decide how much functionality you need, and whether it's already hardwired into the implementations for your platforms or whether you want to buy something or implement it yourself.

I'm beginning to wonder if I should invest the time in learning FORTRAN.

My philosophy is that another language (programming or natural) is always of benefit. It allows one to think about problems in different directions.

Although it is, arcane it seems to be the best tool when it comes to demanding optimization tasks and heavy computations. C/C++ does not cut it for me - it is simply too easy to make mistakes and I find myself using half of my time hunting bugs unrelated to the problem at hand.

It is extremely popular for scientific applications. However, many scientific applications are not done by computer people, but chemists, mathematicians, or physicists.

If you have frequent bugs in your program, that may be a sign of using the wrong tool for the job. It may also be assign of improperly using the correct tool. With such vague references, though, it is hard to determine.

As to demanding optimization, several libraries are available to help with that. Some are C interfaces (with or without C++ wrappers), but many are heavily optimized. For example, Sun offers several optimized libraries for Fortran or C (http://docs.sun.com/source/806-3568/index.html) or the Performance Library (http://docs.sun.com/db/doc/816-2463). Commercial C++ libraries tend to make a matrix into a class and overload all the operators so that it is easy to work with a matrix in a manner akin to a primitive. Combine this with newer semantics like the restrict keyword and some optimization and significant optimization is possible.

Additionally, although tools like Matlab exist they don't provide the power that justify the huge price tag they carry. I find any script based language (Matlab, Numeric Python, Scilab) to be inadequate as soon as it is necessary to use loops to describe a problem and using such tools for recursive systems can be a real pain.

I hate to break this to you, but Fortran77 will not solve some of these problems either. Many Fortran77 compilers add extensions, like REPEAT or WHILE. However, raw Fortran77 has very little loop control, no GUI interfaces, and no real recursion capability. In other words, Matlab (which you claim is a pain) is far more capable of solving your problem than Fortran77 because it has these constructs. Unfortunately, Matlab is single threaded.

Where Fortran77 wins is its internal matrix operations, relatively high performance numerical optimization capability, and wide number support (INTEGER*8 or the like).

I'm beginning to wonder if I should invest the time in learning FORTRAN.

My philosophy is that another language (programming or natural) is always of benefit. It allows one to think about problems in different directions.

Although it is, arcane it seems to be the best tool when it comes to demanding optimization tasks and heavy computations. C/C++ does not cut it for me - it is simply too easy to make mistakes and I find myself using half of my time hunting bugs unrelated to the problem at hand.

It is extremely popular for scientific applications. However, many scientific applications are not done by computer people, but chemists, mathematicians, or physicists.

If you have frequent bugs in your program, that may be a sign of using the wrong tool for the job. It may also be assign of improperly using the correct tool. With such vague references, though, it is hard to determine.

As to demanding optimization, several libraries are available to help with that. Some are C interfaces (with or without C++ wrappers), but many are heavily optimized. For example, Sun offers several optimized libraries for Fortran or C (http://docs.sun.com/source/806-3568/index.html) or the Performance Library (http://docs.sun.com/db/doc/816-2463). Commercial C++ libraries tend to make a matrix into a class and overload all the operators so that it is easy to work with a matrix in a manner akin to a primitive. Combine this with newer semantics like the restrict keyword and some optimization and significant optimization is possible.

Additionally, although tools like Matlab exist they don't provide the power that justify the huge price tag they carry. I find any script based language (Matlab, Numeric Python, Scilab) to be inadequate as soon as it is necessary to use loops to describe a problem and using such tools for recursive systems can be a real pain.

I hate to break this to you, but Fortran77 will not solve some of these problems either. Many Fortran77 compilers add extensions, like REPEAT or WHILE. However, raw Fortran77 has very little loop control, no GUI interfaces, and no real recursion capability. In other words, Matlab (which you claim is a pain) is far more capable of solving your problem than Fortran77 because it has these constructs. Unfortunately, Matlab is single threaded.

Where Fortran77 wins is its internal matrix operations, relatively high performance numerical optimization capability, and wide number support (INTEGER*8 or the like).

Whether it changes the text of the EULA or not is only sort of an interesting question - it doesn't change the code that you're installing. The provisions of the EULA don't matter until they're inplemented in code (such as the Windows Update feature) that performs the functions that the EULA grants MSFT permission to run.

If there's code in W2K SP3 or XP SP1 that implements this, and you install it, then you've given MSFT the keys to your machine, whether you agreed to the EULA or not. If you didn't agree to the EULA and MSFT installs stuff on your machine, then it becomes a question of who has better lawyers and more patience to deal with a lawsuit.

I think a more interesting question was whether this conflicts with HIPAA: organizations that are regulated by HIPAA might be caught on the horns of a dilemma... Run software with known security holes, which HIPAA frowns upon, or enter into a contract allowing a third party (MSFT) access to a machine with sensitive data on it, without being able to hold MSFT to the data protection and privacy terms that HIPAA demands.

Of course, when you're on the horns of a dilemma, you can always leave the situation through one door or another.

Pete

According to the JVM Spec classfiles already have a version number:

ClassFile { u4 magic /* 0xcafebabe */; u2 minor_version; u2 major_version; ... }

The version is major_version.minor_version, and at JDK 1.0.2 it was 45.0.

Note that the VM executes first and only checks the version number when it actually loads a class.