I'm happy to rumormonger with you all for a little while...
I hear things from various people that I shouldn't hear, not often, but occasionally. These are people who are rather credible - not totally, but rather. I feel pretty confident in this particular "rumor," because I've heard basically the same set of facts from three different people with three different kinds of intelligence community experience.
What I hear is that your assertion is true. The NSA has had the ability to break RSA cyphertext "for some time." Even extremely large key sizes are said to be vulnerable, and they can do it "reasonably quickly."
This, of course, flies in the face of all accepted non-defense conventional wisdom in the field - at least until today - but, as I said, three sources. So I believe it.
This may be the result of harrowing secret advances in factoring techniques, or it may simply be brute force. This is an agency that has historically measured its computing power in acreage.
So, "reasonably quickly." The other part of this "rumor" is that reasonable is not reasonable enough to do RSA decryption on a large scale, and hence, while they can break open a particular piece of data, they haven't necessarily integrated RSA see-thru into their global signals intelligence regimine. That, for the uneducated/head-in-the-sand types, is Echelon - and yes, the NSA does listen to, and data-mine, almost all of the world's information traffic.
Final piece of this particular story: the NSA is apparently fastiduous about not sharing this technology, even with other federal agencies. Kevin Mitnick's infamous laptop, rife with PGP-encrypted documents, was impenetrable to the FBI, and despite numerous, desperate appeals for help, the NSA refused to assist them in decrypting the data. That suggests the NSA is abiding by their charter, which basically forbids them from becoming involved in domestic law enforcement (i.e. they're not supposed to spy on Americans) - a necessity if you consider consitutional guarantees about "search and siezure" applicable (by no means a universally held view, unfortunately).
The reason your entire viewing habits are available to MS is because every time you insert a DVD, WMP8 contacts an MS website with your GUID and the DVD's TOC. This is in addition to keeping a log of DVD's on your computer. The ostensible purpose for the request is to get the DVD's "title and chapter information."
This begs the question: what is a DVD's "title and chapter information," anyway?
What possible purpose does having it serve?
We all know that CD player programs call up CDDB because there's no track and album titles handy on the disc. That's fine and good: perfectly legitimate use of network callback. Note: there's no need at all for any personally identifying information (GUID, cookie, or whatever) in that transaction... but that's not my main point.
Unlike a CD, a DVD has every piece of information you already need included, along with a custom interface, etc etc. And in all the coverage I've seen of this issue, no one seems to be catching on to the fact that, as far as anyone can tell:
DVDs are not CDs. There is no justifiable need for any user to have a DVD's "title and chapter" info at all, let alone for them to give a unique identifier to MS while requesting it.
So why go to all the trouble of building a scalable web application to service a non-feature?
Sure, MS is rich, but I guess conservatively that this functionality was a low six figure outlay to start, and it creates a neverending and not inconsiderable ongoing support cost to maintain a database and a server farm. It has to be big: they're servicing every XP/WMP8 user in the world, after all.
On a final note, let's consider the infamous Windows GUID. It's generated from a variety of sources: your PIII Processor Serial Number, if available, your ethernet MAC address, and I believe several other pieces of optional identifiable hardware are potentially tapped.
Microsoft is the same company that silently attached GUID's to every Word document you produce, by the way.
GUIDs don't contain your name or email themselves, but wait...
"However, if a person signs up for the Windows Media newsletter, their email address will be associated with their WindowsMedia.com cookie."
It gets better.
"Also when subscribing to the Windows Media newsletter, I was encouraged by an email message from the Microsoft newsletter department to create a Passport account based on my email address. In theory, yet more personal information from Passport could be matched with what DVD movies I have watched."
If you are curious, the other shoe dropping will sound like this:
MS "Passport" registration (which is required for customer support) also collects GUIDs directly.
Even assuming you have a patent office staffed with geniuses gifted with eidetic memories, software patents mean that _every programmer_ must know the _entire patent base_ (6-7 figures already), and keep up (hundreds of applications per day)! Since this is obviously impossible, every piece of code ever written becomes a ticking time bomb of patent litigation. In American civil court, these cases take years (sometimes decades!) and cost hundreds of thousands, if not millions, of dollars to defend.
They are, in short, nothing other than a naked gift to large companies, with no demonstrable or even plausible public benefit. They are a versatile weapon, with which Microsoft, and a few others, can bludgeon their competitors and enemies.
I was shocked to see the EU contemplating them... but apparently things aren't so different from one hemisphere to the other.
Your comment betrays your ignorance. Using deprecated API's (like sun sound) will get you a CNFE on 1.2... but if you think it's OK for that to make the _browser_ crash, you have no idea what you're talking about.
Fuck off. If Java works flawlessly for you, that's because you haven't seriously tried to use it. There is no "workaround" short of changes in the code.
See my reply above for a list of examples, since all of you feel the need to make comments like these without doing any tests yourselves.
The installer is not the problem. And the JVM itself (i.e. appletviewer) does not exhibit the massive failures that I observe in Mozilla. The problem (aside from the broken installer) is that OJI itself is broken in some interesting way.
Manually installing the DLL doesn't fix the issue. It just lets you realize how deep a hole you're in.:)
I should have been more clear. It's not just the install glue that's broken. The OJI itself is broken even if you can manually accomplish an install. It's a much bigger problem.
I am well aware of this - the fact that I can manually install an OJI-equipped plugin is why I'm able to test anything at all.
You should try this for yourself. Once you do what you suggest, go check out some applets. Yes, the news ticker at java.sun.com works. But try almonst _anything_ more complicated. You can use any of the applet directories... Even as of a few informal tests today, the 90% rule appears still in effect with 0.9.8. Almost no applets of any substance work, and Mozilla/JVM will quickly wedge in a busy loop (in my experiences after < 3 attempts).
Obviously, the fact that the installation glue is so abyssmal is a massive problem of its own, albeit a superficial one. But the API you refer to (the OJI) apparently is itself in a state of serious disrepair.
I'm a bit of an expert at this, and I've been trying a lot of pages. Mozilla fails to support all but the most trivial of Java applets. The exact pieces of the API which are broken is unclear. In my tests, 90% of a random sampling of applets wedge, if not themselves, the entire browser, on page load.
I've been watching this situation for some time, wondering if it would improve.
When the Mozilla people started talking about 1.0, I dug up the email of the Java integration maintainer. Not easy; the OJI page on Mozilla.org is incredibly stale (April 2001!):
http://www.mozilla.org/oji/
I sent him an "are you the guy?" email - he responded, "yes, that's me." Then I sent him an email asking if I could help with efforts to get Applet support up to spec by 1.0. He never wrote back.
As of now, Java is a massive hole in Mozilla. Going to any page with an applet shows the infamous Netscape puzzle piece; clicking on it starts a process to download and install a Java runtime (whether you have one installed or not) which is exceptionally crude even by Netscape standards. You get a popup window with HTML form buttons to select your JVM - one for each "supported" platform (how hard is it to detect OS?) and an extra big empty window with [object Object] popping up above it...
For some time, and continuing in 0.9.8, if you are brave enough to get that far, once you complete the install your browser will crash, and you will still have no Java support when you restart it. This is probably preferable to one previous failure mode, which was an instant application crash every time a page contained Java.
Laugh all you want about applets - this affects a lot of web pages.
If Mozilla for some assinine reason wants to kill Applet support, they need to at least cauterize the wound. As it is now, this is a huge problem that IMNSHO undermines any credibility their 1.0 designation might have.
The two things it doesn't have that you "think" you want are multiple inheritance and operator overloading.
Multiple Inheritance: People claim that this isn't a good feature, but I disagree. I've run into times writing Java code where MI just obviously would be the right thing to do. However, A) these cases are rare, and B) there's always a workaround which is almost as good as the MI solution. In trade, not having MI has the added bonus of making your code simpler to understand, but most importantly, preventing people who think they know what they're doing (but don't) from using MI to make a complete mess of your model.
Operator overloading: I left the best for last.:) Operator overloading is, in my experience, a real nightmare. To be clear: it offers you nothing functionally. It's a purely cosmetic feature. People often like to write a String or Matrix class with a + operator. Well, I take only minor umbrage with Java's special + operator functionality for strings - it hides the underlying work too well (one simple character = potentially a lot of VM activity) - but I can live with it. Otherwise almost every case where an operator could be used is in some way or another ambiguous. This is the equivalent of picking a one-letter function name, with the added bonuses of syntactic complexity and obfuscation with existing arithmetic and logical metaphors.
I've seen and suffered through abuses of operator overloading often enough to become convinced that it's important not to have it, so that less-than-gifted programmers will never be tempted to use it.
So I say again, unless you're doing anything inordinately complex with audio or video, use Java. Or use a worse tool, and suffer like everyone else does.:)
I hope I'm not beating this to death, but you're touching on exactly what I would say the flaw is. Pointer arithmetic has a number of potential uses, but its primary advantage is speed, and you shouldn't be writing hot code in the CLR any more than you should be doing it in the JVM.
The problem as I see it, in case I didn't make it clear, is that the guarantees you get from shutting out pointer-level code are important - both to the developer and to the system as a whole - and the gains are negligble. I await a conclusive judgement on this, but as far as I can tell, unsafe code renders useless the higher-level and "java-like" security mechanisms of the system.
Since it's possible to be unsafe, people will, and then "safety fatigue" will effectively remove this protection altogether. The more easily the pieces fit together, the more rapidly it will happen, and the bigger the false sense of security.
It's a question of role. "Unsafe" code, lagnauges, and systems are necessary at a variety of levels in general purpose computing. That doesn't mean they're a good idea for.NET, which I take to be "high-level," "distributed" and "enterprise" computing platform, and one with pretensions to a modern, practical and durable security model...
What a pleasure to see such a balanced, well-written and thorough analysis of the situation. I didn't see any great evidence of Java "advocacy" - this person appears extremely well-versed in langauge design and familiar with a good variety of languages, as well as more than willing to point out Java's flaws.
The author is saying pretty much what I figured, which is that.NET is much better than what MS has been doing in the past, however it's still just a sugared-up clone of J2EE, whose "cross-langauge" benefits are ultimately dubious and primarily a marketing invention.
I would also make the case that "unsafe" mode/pointer arithmetic is a flaw, but that's not the matter at hand. The high point of the article were these two paragraphs in the conclusion:
"Playing with the.NET SDK, the cross-language support looks impressive, but the illusion holds true only until realizing that all languages in the mix are virtually identical. Microsoft has actually invented the concept of skinnable language: changing a language's most superficial aspects, and claiming the result to be a new language. There is only One True Language that is C#, and "skins" offered by Microsoft and third parties. Just like in GUIs, these skins will alter the system's look and feel, add a few features, but never compete with a fully new toolkit."
For those quick to make an ignorant response, he's not saying more radical structural departures are impossible, though many are - but more often that diverging "client languages" suffer in performance and, in many cases, have been "embraced and extended" in order to become compatible. He goes on:
"There are, actually, many successful "common language runtimes", with names like Pentium, SPARC and others. Mainstream CPUs are equally fitted to very different languages as they only do the most fundamental, low-level operations, so they cannot be biased towards particular languages. There aren't many different ways to perform a conditional branch. However, there are radically different ways to support methods and functions, or most constructs found in high-level languages. The consequence is that every language needs different compilers and runtimes to implement their features, and different libraries to support their vision of software development."
Backlashing and Frontlashing and Sideways Lashing
on
Bill Joy's Takes on C#
·
· Score: 3, Insightful
It's funny that everyone here is saying Sun is spewing FUD and joking about Slashdot being rigidly anti-MS. As far as I can see, almost everyone here is rigidly pro-Microsoft and eager to heap abuse on Java and praise on Brave Microsoft for making the "Genius" C# and.NET.
There's a tremendous amount of well-rated lies here about the article itself. It's really astounding in its volume - ranting on for pages about how Bill Joy is jealous, and C#'s pointers are totally safe, and Sun is making up lies about C#... "Insightful"! It's like some kind of geek guilt or something - we have to be hard on ourselves, and have a backlash against our backlash now?
I prefer to actually look at the objective truth on a given day. What's the article about? Joy is saying that C# doesn't force you to be safe. It lets you choose. And the problem is that if you let people choose to be unsafe, then they sometimes will be unsafe, because it's easier, or faster, or because they don't know any better.
Despite rampant misquoting here to the contrary, Joy wrote explicitly that he knows pointer-massaging code is marked "unsafe" in C#, and is recognized and treated differently by the CLR. It's right there in the article.
The point is that it just brings us back to square one security-wise - to ActiveX. Break out your digital signatures. Do you trust this code? Yes or no. If you want to run it, you better. Some of it might be "unsafe." Once you start flinging pointer arithmetic around, you can stand up and piss right over the sandbox wall.
So many choices. So much freedom..NET is going to be asking your permission all the time. Let me tell you, I just spent the day with a secretary in a law office who was just wrapping her head around loading and saving documents. If her web browser asks her whether or not she "trusts" someone's code, she's going to just click a button at random no matter how many times I try to explain what to do.
Joy's point is that in the context of network computing, certain kinds of flexibility are dangerous and ultimately destructive.
I can just see all these rah-rah-C# people making the same kind of arguments I'm hearing about pointers for being able to do powerful word macros and having IE rendering emails. It's so powerful! "Just don't open any word documents from people you don't trust!" they say. Heh.
What we've learned is that we can't dump this security dillemma on the world under the guise of "choice." We've made that mistake (MS certainly has) over and over again, and the result is the same every time. For something like.NET, without having ironclad and unequivocal guarantees - as Java can give you - you're setting yourself up to have another MS security disaster.
I mean, really, he wants to implement.NET on Linux? Great! He wants to build a whole GUI framework out of it? Knock yourself out! People are feeling threatened? Did Wine threaten them? No, let Miguel do his thing, more the merrier, yadda yadda.
On the other hand, he did make some statements about.NET's technical "superiority." That's open for debate. I'd love to see how that one goes.
I've been thinking a lot about Microsoft, though, and how they could ever hope to fight against free software in the long run... I mean in addition to marketing and sales efforts. They could try to influence key players and/or figureheads, but that's risky and unreliable... they could use lawsuits. Non-fantastically-wealthy individuals, after all, are nothing but roadkill in American civil court...
Hey... Hmm...
Wouldn't it be interesting, if Microsoft were to play a game with Miguel - to lure him, his co-developers, and his users, by following Microsoft's (often implicit) standards, into treading over a set of Microsoft patents, or a EULA/UCITA-backed reverse-engineering lawsuit? To wait say, 2 years, or 3, and then when Gnome is installed in millions of places and Sun and Dell are prepackaging it, etc., and there are a lot of juicy targets in the crosshairs, all of a sudden, bust down the door and start serving papers?
Please, reassure me. Tell me why I'm wrong about this. Any part of.NET that's not ECMA (and maybe some that are) is still Microsoft's house... and doesn't that detail about how little of.NET has actually gone to committee keep coming up?
They already have the hardware and software to do a "totally converged" XBox now; they held off on that because they want the XBox to win as a VG console first. If it loses, they haven't exactly broken with their retail partners - yet. But if it wins, or even comes in a healthy 2nd, then they're ready for converged XBox variants in the 2003-2004 timeframe.
Under the section "Allocation and Swapping Results," I assume larger numbers are higher times and therefore worse. By the numbers, 2.4.18pre2aa (the Arcangeli kernel) seems to be the fastest overall, due to the 5th run (I would consider it the common case) results. Yet Moshe says:
"From the above figures it seems that the old van Riel VM is somewhat faster (considerably faster in the case of 2.4.9) than the new Arcangeli VM..."
Is my math wrong? The RVR VM in 2.4.9 is ever so slightly faster on the 2nd run and slower on the 5th, and the slowest of all is the newer one in 2.4.18pre3rmap. What's my mistake?
Moshe's politely indicating that van Riel was an ass when asked for comments; we can conclude either that Moshe didn't have a proper recent RMAP kernel to test with (as a result), or that the recent RMAP kernels are hit and miss.
From looking at van Riel's comments here, he vehemently believes his kernel is perfect and Moshe just got it wrong... The problem is that lots of people seem to "get it wrong" with that VM, including Linus... Overall in Rik I get the sense of an aggressive person who may have trouble admitting mistakes or accepting failure; not good traits in a programmer, since it's humility and communication skills which can often be the critical factors in a team programming effort... and lack of them can cause exactly the kinds of problems we've observed.
What others have said, about attracting budding developers, is true, but it's not the real story.
The console industry represents a new revenue model for the "personal computer industry" - and it may mean the demise, or at least marginalization, of the PC in the home. You see, Playstation represents 40% of Sony's entire revenues (yes, Sony as in Sony music, pictures, VCRs, telephones, PDA's, computers, etc...). That's an enormous amount of money. And they sell those consoles at a loss for quite a while, too. How, you ask? Because every time a game get's sold, they get a piece of the action. They've used their hardware platform to become an indispensable middle-man, and it's making them filthy rich.
Microsoft, ever vigilant, realizes that a lot of their revenues come from home users, and only games really drive sales of home computers. Console game sales have been spanking PC game sales for some time - to the point where, in a few years, the PC game industry will find itself in a state of serious decline. If not for email, web browsers and word processors, not many people would buy PC's at all. And by the way, consoles, starting with the Dreamcast, are already doing email and web browsing.
It's simple economics - console? $200-300. PC? $500 and up. And for a good PC, that can play the latest games? $1500+. I'm sure you can understand why consoles have an order of magnitude more penetration than PC's.
Microsoft understands this, and that's why the XBox has a hard drive. The console is going to be able to surf and do email and IM and, eventually, do word-processing (USB/ethernet printers!), TiVO-like functionality, etc. etc. That's convergence, baby. And at that point it's replaced the home computer, and PC's are something you only see at the office or at a hobbyist's house. PC games will stop being ported to the console and start being ported from it, if at all (this part is well under way).
Sony is a threat to Microsoft - Bill earnestly wants to keep owning the "home computing" market. They want all those "home consoles" to be running Windows. They want to be the middleman for every game and application sale in the home. The XBox is a multi-billion dollar loss-leader predicated on this very notion.
Sony is a very smart company. They're savvy, they're well run. They know the score, and they have a big first-mover advantage. It's going to be a bloody fight. We know that Microsoft intends to make the XBox into a $300 home computer, based on Windows, to run "consumer applications" along with consumer games, and be waiting at the finish line when the race is over. In this round, Sony just introduced a prototype for _their_ consumer applications platform.
"One thing that C++ has that Java doesn't (yet) is the 'assert' function. This on many occasions can make C++ easier to debug than the equivalent Java."
I found it interesting that this author, an IBM researcher, chose to only test a single java-to-native compiler, the GCJ (GNU product). This is an immature open-source package that I would not expect much performance from. His paper rehashes a lot of really basic info, then gives some performance results which show IBM's JVM spanking Sun, Kaffe, and GCJ. This is no great surprise; IBM is tooting it's own horn - fine, they deserve to IMHO. But as an exercise in "the state of native compilation" it's useless. What would actually be really useful is a comparison that also included at least a half-dozen other major players in the java native compiler market. I suspect you'd see some different results.
As an aside; I see people call Java "painfully slow," but in my experience it's not that painful post 1.3. I'm not giving you benchmarks, and anti-Java people will just "no" me, but these are my experiences after a few hundred thousand lines of Java code over the past few years. Anyway, it's a good exercise to ask naysayers what _their_ basis is; they often have none.
Also, as other posters have pointed out, the speed loss must be seen in the runtime safety context, as bounds checking and garbage collection yield stability and security dividends and, at the end of the day, we almost always want those things and are willing to wait the extra few ms for the guarantees.
All these complaints about speed are especially ironic given how many massive wasters there are in the modern computer, _especially_ in Windows NT/2k/XP.
But the biggest flaw in this Java vs. C debate is that often you don't get a choice between writing code in Java vs. C/C++, since you don't have the extra 50% in your time budget to do C/C++, and your real choice is between Java and VBScript...
All the people shouting "I can write C++ 10 times as fast as you can write Java, loser" please form a line in an orderly fashion, you will be spanked in the order you arrive...
Yeah, that's pretty much exactly what I was thinking.
We take it for granted that if we could bypass these restrictions then a terrorist capable of felling the WTC certainly could. Interestingly, that's not the case. They wont, at least in some cases, be able to protect their information on computers unless we make it too easy - and the definition of too easy is probably whatever Windows does by default when you say "encrypt."
It's a screwed up state of affairs, but then, it's a screwed up world...
Yeah - that's definitely worth a 30 year vacation at a Georgia penitentiary. Those jails are kind of crowded though, so they might have to release some rapists and child murderers early to make room for him.
"How's prison going?"
"Let's just say I'm not getting the respect a sysadmin deserves!"
(What I'd like to see is 30 year jail terms for the executive corps at Enron, let alone all of the auditors at Andersen who destroyed documents instead of auditing. Funny how it doesn't work that way...)
Slashdot Mirror
I'm happy to rumormonger with you all for a little while...
I hear things from various people that I shouldn't hear, not often, but occasionally. These are people who are rather credible - not totally, but rather. I feel pretty confident in this particular "rumor," because I've heard basically the same set of facts from three different people with three different kinds of intelligence community experience.
What I hear is that your assertion is true. The NSA has had the ability to break RSA cyphertext "for some time." Even extremely large key sizes are said to be vulnerable, and they can do it "reasonably quickly."
This, of course, flies in the face of all accepted non-defense conventional wisdom in the field - at least until today - but, as I said, three sources. So I believe it.
This may be the result of harrowing secret advances in factoring techniques, or it may simply be brute force. This is an agency that has historically measured its computing power in acreage.
So, "reasonably quickly." The other part of this "rumor" is that reasonable is not reasonable enough to do RSA decryption on a large scale, and hence, while they can break open a particular piece of data, they haven't necessarily integrated RSA see-thru into their global signals intelligence regimine. That, for the uneducated/head-in-the-sand types, is Echelon - and yes, the NSA does listen to, and data-mine, almost all of the world's information traffic.
Final piece of this particular story: the NSA is apparently fastiduous about not sharing this technology, even with other federal agencies. Kevin Mitnick's infamous laptop, rife with PGP-encrypted documents, was impenetrable to the FBI, and despite numerous, desperate appeals for help, the NSA refused to assist them in decrypting the data. That suggests the NSA is abiding by their charter, which basically forbids them from becoming involved in domestic law enforcement (i.e. they're not supposed to spy on Americans) - a necessity if you consider consitutional guarantees about "search and siezure" applicable (by no means a universally held view, unfortunately).
The reason your entire viewing habits are available to MS is because every time you insert a DVD, WMP8 contacts an MS website with your GUID and the DVD's TOC. This is in addition to keeping a log of DVD's on your computer. The ostensible purpose for the request is to get the DVD's "title and chapter information."
t m
This begs the question: what is a DVD's "title and chapter information," anyway?
What possible purpose does having it serve?
We all know that CD player programs call up CDDB because there's no track and album titles handy on the disc. That's fine and good: perfectly legitimate use of network callback. Note: there's no need at all for any personally identifying information (GUID, cookie, or whatever) in that transaction... but that's not my main point.
Unlike a CD, a DVD has every piece of information you already need included, along with a custom interface, etc etc. And in all the coverage I've seen of this issue, no one seems to be catching on to the fact that, as far as anyone can tell:
DVDs are not CDs. There is no justifiable need for any user to have a DVD's "title and chapter" info at all, let alone for them to give a unique identifier to MS while requesting it.
So why go to all the trouble of building a scalable web application to service a non-feature?
Sure, MS is rich, but I guess conservatively that this functionality was a low six figure outlay to start, and it creates a neverending and not inconsiderable ongoing support cost to maintain a database and a server farm. It has to be big: they're servicing every XP/WMP8 user in the world, after all.
On a final note, let's consider the infamous Windows GUID. It's generated from a variety of sources: your PIII Processor Serial Number, if available, your ethernet MAC address, and I believe several other pieces of optional identifiable hardware are potentially tapped.
Microsoft is the same company that silently attached GUID's to every Word document you produce, by the way.
GUIDs don't contain your name or email themselves, but wait...
http://www.computerbytesman.com/privacy/wmp8dvd.h
"However, if a person signs up for the Windows Media newsletter, their email address will be associated with their WindowsMedia.com cookie."
It gets better.
"Also when subscribing to the Windows Media newsletter, I was encouraged by an email message from the Microsoft newsletter department to create a Passport account based on my email address. In theory, yet more personal information from Passport could be matched with what DVD movies I have watched."
If you are curious, the other shoe dropping will sound like this:
MS "Passport" registration (which is required for customer support) also collects GUIDs directly.
-David
I realize you probably just haven't thought about this very much and are trying to be fair.
8 378
Please read my comments on this:
http://slashdot.org/comments.pl?sid=28274&cid=303
Even assuming you have a patent office staffed with geniuses gifted with eidetic memories, software patents mean that _every programmer_ must know the _entire patent base_ (6-7 figures already), and keep up (hundreds of applications per day)! Since this is obviously impossible, every piece of code ever written becomes a ticking time bomb of patent litigation. In American civil court, these cases take years (sometimes decades!) and cost hundreds of thousands, if not millions, of dollars to defend.
They are, in short, nothing other than a naked gift to large companies, with no demonstrable or even plausible public benefit. They are a versatile weapon, with which Microsoft, and a few others, can bludgeon their competitors and enemies.
I was shocked to see the EU contemplating them... but apparently things aren't so different from one hemisphere to the other.
Your comment betrays your ignorance. Using deprecated API's (like sun sound) will get you a CNFE on 1.2... but if you think it's OK for that to make the _browser_ crash, you have no idea what you're talking about.
I have applets that run in appletviewer but will crash Mozilla, so I would disagree with you.
Fuck off. If Java works flawlessly for you, that's because you haven't seriously tried to use it. There is no "workaround" short of changes in the code.
See my reply above for a list of examples, since all of you feel the need to make comments like these without doing any tests yourselves.
Idiot.
The installer is not the problem. And the JVM itself (i.e. appletviewer) does not exhibit the massive failures that I observe in Mozilla. The problem (aside from the broken installer) is that OJI itself is broken in some interesting way.
:)
Manually installing the DLL doesn't fix the issue. It just lets you realize how deep a hole you're in.
:)
I should have been more clear. It's not just the install glue that's broken. The OJI itself is broken even if you can manually accomplish an install. It's a much bigger problem.
I am well aware of this - the fact that I can manually install an OJI-equipped plugin is why I'm able to test anything at all.
You should try this for yourself. Once you do what you suggest, go check out some applets. Yes, the news ticker at java.sun.com works. But try almonst _anything_ more complicated. You can use any of the applet directories... Even as of a few informal tests today, the 90% rule appears still in effect with 0.9.8. Almost no applets of any substance work, and Mozilla/JVM will quickly wedge in a busy loop (in my experiences after < 3 attempts).
Obviously, the fact that the installation glue is so abyssmal is a massive problem of its own, albeit a superficial one. But the API you refer to (the OJI) apparently is itself in a state of serious disrepair.
I'm a bit of an expert at this, and I've been trying a lot of pages. Mozilla fails to support all but the most trivial of Java applets. The exact pieces of the API which are broken is unclear. In my tests, 90% of a random sampling of applets wedge, if not themselves, the entire browser, on page load.
I've been watching this situation for some time, wondering if it would improve.
When the Mozilla people started talking about 1.0, I dug up the email of the Java integration maintainer. Not easy; the OJI page on Mozilla.org is incredibly stale (April 2001!):
http://www.mozilla.org/oji/
I sent him an "are you the guy?" email - he responded, "yes, that's me." Then I sent him an email asking if I could help with efforts to get Applet support up to spec by 1.0. He never wrote back.
As of now, Java is a massive hole in Mozilla. Going to any page with an applet shows the infamous Netscape puzzle piece; clicking on it starts a process to download and install a Java runtime (whether you have one installed or not) which is exceptionally crude even by Netscape standards. You get a popup window with HTML form buttons to select your JVM - one for each "supported" platform (how hard is it to detect OS?) and an extra big empty window with [object Object] popping up above it...
For some time, and continuing in 0.9.8, if you are brave enough to get that far, once you complete the install your browser will crash, and you will still have no Java support when you restart it. This is probably preferable to one previous failure mode, which was an instant application crash every time a page contained Java.
Laugh all you want about applets - this affects a lot of web pages.
If Mozilla for some assinine reason wants to kill Applet support, they need to at least cauterize the wound. As it is now, this is a huge problem that IMNSHO undermines any credibility their 1.0 designation might have.
The two things it doesn't have that you "think" you want are multiple inheritance and operator overloading.
:) Operator overloading is, in my experience, a real nightmare. To be clear: it offers you nothing functionally. It's a purely cosmetic feature. People often like to write a String or Matrix class with a + operator. Well, I take only minor umbrage with Java's special + operator functionality for strings - it hides the underlying work too well (one simple character = potentially a lot of VM activity) - but I can live with it. Otherwise almost every case where an operator could be used is in some way or another ambiguous. This is the equivalent of picking a one-letter function name, with the added bonuses of syntactic complexity and obfuscation with existing arithmetic and logical metaphors.
:)
Multiple Inheritance: People claim that this isn't a good feature, but I disagree. I've run into times writing Java code where MI just obviously would be the right thing to do. However, A) these cases are rare, and B) there's always a workaround which is almost as good as the MI solution. In trade, not having MI has the added bonus of making your code simpler to understand, but most importantly, preventing people who think they know what they're doing (but don't) from using MI to make a complete mess of your model.
Operator overloading: I left the best for last.
I've seen and suffered through abuses of operator overloading often enough to become convinced that it's important not to have it, so that less-than-gifted programmers will never be tempted to use it.
So I say again, unless you're doing anything inordinately complex with audio or video, use Java. Or use a worse tool, and suffer like everyone else does.
I don't think so. Not if something essential requires unsafe privileges to run. Or if a hundred things do.
Of course, maybe nothing will - but then the feature would be effectively ignored - because it's a bad feature, yes?
So which is it? Are you wrong? or are you wrong?
Yeah, I was aware of that.
I hope I'm not beating this to death, but you're touching on exactly what I would say the flaw is. Pointer arithmetic has a number of potential uses, but its primary advantage is speed, and you shouldn't be writing hot code in the CLR any more than you should be doing it in the JVM.
The problem as I see it, in case I didn't make it clear, is that the guarantees you get from shutting out pointer-level code are important - both to the developer and to the system as a whole - and the gains are negligble. I await a conclusive judgement on this, but as far as I can tell, unsafe code renders useless the higher-level and "java-like" security mechanisms of the system.
Since it's possible to be unsafe, people will, and then "safety fatigue" will effectively remove this protection altogether. The more easily the pieces fit together, the more rapidly it will happen, and the bigger the false sense of security.
It's a question of role. "Unsafe" code, lagnauges, and systems are necessary at a variety of levels in general purpose computing. That doesn't mean they're a good idea for .NET, which I take to be "high-level," "distributed" and "enterprise" computing platform, and one with pretensions to a modern, practical and durable security model...
What a pleasure to see such a balanced, well-written and thorough analysis of the situation. I didn't see any great evidence of Java "advocacy" - this person appears extremely well-versed in langauge design and familiar with a good variety of languages, as well as more than willing to point out Java's flaws.
.NET is much better than what MS has been doing in the past, however it's still just a sugared-up clone of J2EE, whose "cross-langauge" benefits are ultimately dubious and primarily a marketing invention.
.NET SDK, the cross-language support looks impressive, but the illusion holds true only until realizing that all languages in the mix are virtually identical. Microsoft has actually invented the concept of skinnable language: changing a language's most superficial aspects, and claiming the result to be a new language. There is only One True Language that is C#, and "skins" offered by Microsoft and third parties. Just like in GUIs, these skins will alter the system's look and feel, add a few features, but never compete with a fully new toolkit."
The author is saying pretty much what I figured, which is that
I would also make the case that "unsafe" mode/pointer arithmetic is a flaw, but that's not the matter at hand. The high point of the article were these two paragraphs in the conclusion:
"Playing with the
For those quick to make an ignorant response, he's not saying more radical structural departures are impossible, though many are - but more often that diverging "client languages" suffer in performance and, in many cases, have been "embraced and extended" in order to become compatible. He goes on:
"There are, actually, many successful "common language runtimes", with names like Pentium, SPARC and others. Mainstream CPUs are equally fitted to very different languages as they only do the most fundamental, low-level operations, so they cannot be biased towards particular languages. There aren't many different ways to perform a conditional branch. However, there are radically different ways to support methods and functions, or most constructs found in high-level languages. The consequence is that every language needs different compilers and runtimes to implement their features, and different libraries to support their vision of software development."
It's funny that everyone here is saying Sun is spewing FUD and joking about Slashdot being rigidly anti-MS. As far as I can see, almost everyone here is rigidly pro-Microsoft and eager to heap abuse on Java and praise on Brave Microsoft for making the "Genius" C# and .NET.
.NET is going to be asking your permission all the time. Let me tell you, I just spent the day with a secretary in a law office who was just wrapping her head around loading and saving documents. If her web browser asks her whether or not she "trusts" someone's code, she's going to just click a button at random no matter how many times I try to explain what to do.
.NET, without having ironclad and unequivocal guarantees - as Java can give you - you're setting yourself up to have another MS security disaster.
There's a tremendous amount of well-rated lies here about the article itself. It's really astounding in its volume - ranting on for pages about how Bill Joy is jealous, and C#'s pointers are totally safe, and Sun is making up lies about C#... "Insightful"! It's like some kind of geek guilt or something - we have to be hard on ourselves, and have a backlash against our backlash now?
I prefer to actually look at the objective truth on a given day. What's the article about? Joy is saying that C# doesn't force you to be safe. It lets you choose. And the problem is that if you let people choose to be unsafe, then they sometimes will be unsafe, because it's easier, or faster, or because they don't know any better.
Despite rampant misquoting here to the contrary, Joy wrote explicitly that he knows pointer-massaging code is marked "unsafe" in C#, and is recognized and treated differently by the CLR. It's right there in the article.
The point is that it just brings us back to square one security-wise - to ActiveX. Break out your digital signatures. Do you trust this code? Yes or no. If you want to run it, you better. Some of it might be "unsafe." Once you start flinging pointer arithmetic around, you can stand up and piss right over the sandbox wall.
So many choices. So much freedom.
Joy's point is that in the context of network computing, certain kinds of flexibility are dangerous and ultimately destructive.
I can just see all these rah-rah-C# people making the same kind of arguments I'm hearing about pointers for being able to do powerful word macros and having IE rendering emails. It's so powerful! "Just don't open any word documents from people you don't trust!" they say. Heh.
What we've learned is that we can't dump this security dillemma on the world under the guise of "choice." We've made that mistake (MS certainly has) over and over again, and the result is the same every time. For something like
I mean, really, he wants to implement .NET on Linux? Great! He wants to build a whole GUI framework out of it? Knock yourself out! People are feeling threatened? Did Wine threaten them? No, let Miguel do his thing, more the merrier, yadda yadda.
.NET's technical "superiority." That's open for debate. I'd love to see how that one goes.
.NET that's not ECMA (and maybe some that are) is still Microsoft's house... and doesn't that detail about how little of .NET has actually gone to committee keep coming up?
On the other hand, he did make some statements about
I've been thinking a lot about Microsoft, though, and how they could ever hope to fight against free software in the long run... I mean in addition to marketing and sales efforts. They could try to influence key players and/or figureheads, but that's risky and unreliable... they could use lawsuits. Non-fantastically-wealthy individuals, after all, are nothing but roadkill in American civil court...
Hey... Hmm...
Wouldn't it be interesting, if Microsoft were to play a game with Miguel - to lure him, his co-developers, and his users, by following Microsoft's (often implicit) standards, into treading over a set of Microsoft patents, or a EULA/UCITA-backed reverse-engineering lawsuit? To wait say, 2 years, or 3, and then when Gnome is installed in millions of places and Sun and Dell are prepackaging it, etc., and there are a lot of juicy targets in the crosshairs, all of a sudden, bust down the door and start serving papers?
Please, reassure me. Tell me why I'm wrong about this. Any part of
Oh yes, absolutely.
They already have the hardware and software to do a "totally converged" XBox now; they held off on that because they want the XBox to win as a VG console first. If it loses, they haven't exactly broken with their retail partners - yet. But if it wins, or even comes in a healthy 2nd, then they're ready for converged XBox variants in the 2003-2004 timeframe.
Under the section "Allocation and Swapping Results," I assume larger numbers are higher times and therefore worse. By the numbers, 2.4.18pre2aa (the Arcangeli kernel) seems to be the fastest overall, due to the 5th run (I would consider it the common case) results. Yet Moshe says:
"From the above figures it seems that the old van Riel VM is somewhat faster (considerably faster in the case of 2.4.9) than the new Arcangeli VM..."
Is my math wrong? The RVR VM in 2.4.9 is ever so slightly faster on the 2nd run and slower on the 5th, and the slowest of all is the newer one in 2.4.18pre3rmap. What's my mistake?
Moshe's politely indicating that van Riel was an ass when asked for comments; we can conclude either that Moshe didn't have a proper recent RMAP kernel to test with (as a result), or that the recent RMAP kernels are hit and miss.
From looking at van Riel's comments here, he vehemently believes his kernel is perfect and Moshe just got it wrong... The problem is that lots of people seem to "get it wrong" with that VM, including Linus... Overall in Rik I get the sense of an aggressive person who may have trouble admitting mistakes or accepting failure; not good traits in a programmer, since it's humility and communication skills which can often be the critical factors in a team programming effort... and lack of them can cause exactly the kinds of problems we've observed.
What others have said, about attracting budding developers, is true, but it's not the real story.
The console industry represents a new revenue model for the "personal computer industry" - and it may mean the demise, or at least marginalization, of the PC in the home. You see, Playstation represents 40% of Sony's entire revenues (yes, Sony as in Sony music, pictures, VCRs, telephones, PDA's, computers, etc...). That's an enormous amount of money. And they sell those consoles at a loss for quite a while, too. How, you ask? Because every time a game get's sold, they get a piece of the action. They've used their hardware platform to become an indispensable middle-man, and it's making them filthy rich.
Microsoft, ever vigilant, realizes that a lot of their revenues come from home users, and only games really drive sales of home computers. Console game sales have been spanking PC game sales for some time - to the point where, in a few years, the PC game industry will find itself in a state of serious decline. If not for email, web browsers and word processors, not many people would buy PC's at all. And by the way, consoles, starting with the Dreamcast, are already doing email and web browsing.
It's simple economics - console? $200-300. PC? $500 and up. And for a good PC, that can play the latest games? $1500+. I'm sure you can understand why consoles have an order of magnitude more penetration than PC's.
Microsoft understands this, and that's why the XBox has a hard drive. The console is going to be able to surf and do email and IM and, eventually, do word-processing (USB/ethernet printers!), TiVO-like functionality, etc. etc. That's convergence, baby. And at that point it's replaced the home computer, and PC's are something you only see at the office or at a hobbyist's house. PC games will stop being ported to the console and start being ported from it, if at all (this part is well under way).
Sony is a threat to Microsoft - Bill earnestly wants to keep owning the "home computing" market. They want all those "home consoles" to be running Windows. They want to be the middleman for every game and application sale in the home. The XBox is a multi-billion dollar loss-leader predicated on this very notion.
Sony is a very smart company. They're savvy, they're well run. They know the score, and they have a big first-mover advantage. It's going to be a bloody fight. We know that Microsoft intends to make the XBox into a $300 home computer, based on Windows, to run "consumer applications" along with consumer games, and be waiting at the finish line when the race is over. In this round, Sony just introduced a prototype for _their_ consumer applications platform.
It's Linux.
"One thing that C++ has that Java doesn't (yet) is the 'assert' function. This on many occasions can make C++ easier to debug than the equivalent Java."
1.4 baby!
I found it interesting that this author, an IBM researcher, chose to only test a single java-to-native compiler, the GCJ (GNU product). This is an immature open-source package that I would not expect much performance from. His paper rehashes a lot of really basic info, then gives some performance results which show IBM's JVM spanking Sun, Kaffe, and GCJ. This is no great surprise; IBM is tooting it's own horn - fine, they deserve to IMHO. But as an exercise in "the state of native compilation" it's useless. What would actually be really useful is a comparison that also included at least a half-dozen other major players in the java native compiler market. I suspect you'd see some different results.
As an aside; I see people call Java "painfully slow," but in my experience it's not that painful post 1.3. I'm not giving you benchmarks, and anti-Java people will just "no" me, but these are my experiences after a few hundred thousand lines of Java code over the past few years. Anyway, it's a good exercise to ask naysayers what _their_ basis is; they often have none.
Also, as other posters have pointed out, the speed loss must be seen in the runtime safety context, as bounds checking and garbage collection yield stability and security dividends and, at the end of the day, we almost always want those things and are willing to wait the extra few ms for the guarantees.
All these complaints about speed are especially ironic given how many massive wasters there are in the modern computer, _especially_ in Windows NT/2k/XP.
But the biggest flaw in this Java vs. C debate is that often you don't get a choice between writing code in Java vs. C/C++, since you don't have the extra 50% in your time budget to do C/C++, and your real choice is between Java and VBScript...
All the people shouting "I can write C++ 10 times as fast as you can write Java, loser" please form a line in an orderly fashion, you will be spanked in the order you arrive...
Yeah, that's pretty much exactly what I was thinking.
We take it for granted that if we could bypass these restrictions then a terrorist capable of felling the WTC certainly could. Interestingly, that's not the case. They wont, at least in some cases, be able to protect their information on computers unless we make it too easy - and the definition of too easy is probably whatever Windows does by default when you say "encrypt."
It's a screwed up state of affairs, but then, it's a screwed up world...
Yeah - that's definitely worth a 30 year vacation at a Georgia penitentiary. Those jails are kind of crowded though, so they might have to release some rapists and child murderers early to make room for him.
"How's prison going?"
"Let's just say I'm not getting the respect a sysadmin deserves!"
(What I'd like to see is 30 year jail terms for the executive corps at Enron, let alone all of the auditors at Andersen who destroyed documents instead of auditing. Funny how it doesn't work that way...)