When I say stubs I'm referring to having to define a class with native methods, run that through javah and then compile against the class. Then you still have a separate.class and DLL that you must ensure are both accessible.
I know it's greatly difficult - I've done JNI and JRI before it, but it's still fiddly and a pain compared with.NET. The mindset in Java is to write Java unless you absolutely can't.
In.NET you can define the interface _and_ the implementation in a single file, which is itself compiled with the unsafe C++ into a single DLL. Add that DLL to your references or register it with the GAC and you're done. With the wizards its even easier.
Sometimes pain isn't a bad thing since it can guide people along the preferred path which is to write stuff in a portable manner unless it is strictly necessary. The mindset that Microsoft seem to be promoting is that it's easy to port legacy code to.NET - just wrap and call it. Which is great if you're Microsoft, since you can expound cross-platform goodness knowing full well that very few apps will actually be so.
Sorry but it's not FUD. It is true that mono are reimplementing (again) the Windows.Forms layer but that doesn't solve the problem of all the tainted code out there. To do that they either have to link to Winelib to handle the pinvokes, the COM interop and the unsafe C++ classes or they throw an exception.
And there is lots of tainted code and therefore lots of exceptions. In fact I'd hazard to guess that the majority of non-trivial.NET applications in existence are tainted, even if its in minor ways such as calling a registry function in a certain place.
Either Mono produces something that works with most of the tainted code, or they become a seamless and better version of.NET, or they produce a compelling open source stack, or they're dead in the water. It's as simple as that.
I work for a large institution with various.NET projects, and I can absolutely guarantee you that Mono interoperability doesn't even appear on the radar. They're wrapping C++ left and right and consequently their.NET apps are stable as the legacy code underneath it.
And yes Microsoft has implied Windows.Forms is portable if for no other reason than the namespace it is in - System.Windows.Forms. Why isn't it Microsoft.Windows.Forms?
As for security. A platform which actively helps someone wrap unsafe code, invoke native methods etc. from a supposedly safe platform is clearly more unsafe than one which doesn't or makes it hard to do.
I know about Darwine (hence the for now in my original post), but this project is only a port of the Win32 API. That might help for PInvoke but it won't help you if you're invoking unsafe C++ DLLs or other x86 instructions. Phase two of Darwine supposedly integrates winelib with an x86 emulator but it hasn't happened yet.
But even if / when that occurs it's not ideal. In fact it's terrible. To run.NET apps on the PPC, not only do you need Mono but also winelib and an x86 emulator!
As a corporate entity MS must be rubbing its hands with glee about this even if some of the CLR purists are probably aghast.
Yes Java supports C++ native calls, but look at how bloody painful it is to do it. You have to define an interface, run it through a stub compiler, implement the stubs and use helpers to marshal types back and forth between C++ and their Java equivalents. It involves lots of files and lots of fiddling about.
The consequence of this is that no-one uses JNI unless they absolutely positively have to. It's a pain and life is much easier if everything is in Java. Thus with the exception of a few esoteric things such as SWT, most libraries are pure and portable.
Now contrast this with.NET. Writing native C++ and wrapping it in a garbage collection safe class involves no stub generation and can be done in a single file - the assembly info, interface and gc wrapper can all be specified in situ. Consequently it's a lot easier to pull C++ into a.NET application. MS DevStudio 2003 even has wizards to do it. It is also a lot easier to call DLLs and ActiveX from.NET since MS provide PInvoke and COM Interop to do just that.
Now on the face of it, this is all well and good, especially if you have a lot of legacy crap to port. But by the same token it means many more.NET apps are tainted than on Java. The problems this causes for portability should be obvious.
And this is called "Microsoft having their cake and eating it". They can expound portability and present the facade that.NET is cross-platform, when in reality they provide tools and wizards to ensure it remains anything but. Apps that are infested with native instructions and OS-specific calls are by definition unportable.
Mono demonstrates the problems faced in porting.NET to other platforms. Mono must literally pull in the whole winelib in order to cope with the number of tainted.NET apps that attempt to call out to Win32. And too bad if you're running Mono on a non-x86, non-Linux system since winelib is x86 only (for now).
And I don't see the situation getting any better. Perhaps if Mono gains momentum it might put the brakes on tainted code, but there is a long way for that to happen. I believe the only way Mono is going to make an impact is if ships with a cross-platform IDE with tools that default to its open source stack. This is almost a reality since ICSharpDevelop & MonoDevelop are both fairly complete IDEs but there is nothing yet which defaults to the open source stack and runs on all major platforms.
Who's jumping the gun? All I'm objecting to someone's the knee jerk reaction to any terraforming on the rather lame premise that Mars is "virgin soil".
Any attempt to warm the planet would have to be preceded by dozens of missions and meticulous research and preparation before anyone had any clue whether it would be a worthwhile undertaking. Any biological or geological evidence would surely form part of that evaluation.
My personal feeling is that it would not be worthwhile to warm Mars for hundreds of years. What's the point if there is noone living there? Let's see some people actually set foot on the surface and do the research. Let's see colonization happen with people living under plastic domes. Then we'd be in a much better position to evaluate the relative merits of warming the entire planet.
It might take thousands of years to undo that kind of damage.
Is that your best reason, that it might go wrong?
Sorry but that's dumb. Everything might go wrong. Your house might burn to the ground because of an electrical fault. Does that mean you shouldn't use electricity or that you try to minimise the risk through safety standards and certification? You might hit a wall in your car. Does that mean you don't ride in a vehicle or that you should learn to drive properly and buy a car with various safety features? You might get attacked by a dog (while walking). Does that mean we should kill all dogs or enact laws that make owners responsible for their animals? Your computer might be compromised and be used to store kiddy porn. Does that mean you should unplug all the jacks from the wall and lock the PC in a metal box, or does it mean you should be diligent and use appropriate firewall / antivirus software?
I'm not advocating any crazy experiment on Mars - but if there is a carefully reached and reasonable expectation that something will work and the rewards outweigh the risks, then it should be taken. The alternative is for mankind to collectively cower under the table waiting for the next global catastrophe to wipe us all out.
Besides, who knows what kind of fossel record would be being destroyed by exposing the planet to natural weather forces again.
Yeah right. But to apply your own risk aversion argument, how would we ever know about the "fossel" record? After all, there is a very real chance of mission failure when going to Mars. How can we possibly send people or robots to Mars if the probe could blow up? The same goes for any other human endeavour past, present or future.
Hanging around for something - anything - to be 100% certain (except death & tax) is to piss away any future that humanity might have at all.
Virgin soil = rock dust. Assuming there to be no life on Mars, I don't get what the problem is with altering it. Now naturally if there is life that's a whole can of worms in itself, but if not, then what damn difference does it make?
The "integrating more cleanly" bit is worth more exploration. Java does allow native calls via JNI but it's always been bloody fiddly to get it to work. It does work, but it's fiddly requiring you define an interface, run a tool to generate stubs and implement those stubs handling exceptions & objects via a large set of JNI helper methods. Thus the average Java programmer doesn't even *think* about writing native code unless they absolutely, positively have to. So virtually every third party lib is pure Java, and has no dependencies on native executables or platform specific features. There are exceptions of course (e.g. SWT) which hit the underlying OS but in general this is true.
Now onto.NET. C++ is fairly easy to pull into a project - write some garbage collection safe wrappers around your "legacy" code and now it runs in.NET. And via PInvoke you can call native methods easily too. And then there's COM interop which pulls in ActiveX controls. That's all good and well, but it also means that lots of projects are not "pure" - they're polluted with Win32 crap and generally not portable.
That's probably what gets to Gosling - that.NET is touted as a portable development platform but it isn't. Projects are infested with unpure, unsafe and platform-specific code. Microsoft can preach portability but they know that very few people will be disciplined enough to bother with it. Thus people are tied to Win32 even when they're using a allegedly portable runtime. Even the likes of Mono only gets around this by pulling in winelib.
Do the games come with region encoding, or could I (for example) pick one up from the US and play games sold in Europe / Japan etc.? Same question as per movies if / when they get released.
Sheet metal - the kind most PC cases are made of. The motherboard I was fitting had a different arrangement for the ports at the back than the case would allow so I had to chop out a rectangular section of the metal on the back.
Looking back I might have been better off drilling some holes and use a hack saw, but all I had at the time was a dremel. So I spent a good long while using the angle grinder bit to literally cut a slot all the way around. It was very arduous, made a huge mess (black dust everywhere) and probably totally the wrong way to do it but I eventually fitted the motherboard no problem.
It seems to happen in France, but I don't recall it happening in any other country I've stayed in. And I've been to lots of European countries - France, Germany, Czech Republic, Spain, UK, Ireland, Denmark, Netherlands, Brussels, Italy, Austria.
In France (or Paris to be precise) they photocopied my passport, but even there it's inconsistent since I've stayed places where they didn't bother, or simply jotted down the passport number.
You complain, but you offer no solution. I suggest that you are worse than the problem you complain about.
I suggest you are even worse since you blindly accept the "security" this system offers without considering it properly.
Custom officers spend more time taking a photo and fingerprints than actually looking at the person, making a behavioural assessment or asking pertinent questions. The customs officer who photo'd me was more concerned that my finger was on the scanner than the purpose of my visit.
Such fingerprints and photos form a vast, vast database containing hundreds of millions of innocent people that must be maintained at great expense.
The ratio of terrorists to innocent people is next to zero.
Thus there will be a massive number false positives that greatly inconvenience innocent people and a diminishingly small number of genuine hits.
Terrorists will simply find other ways into the country, such as entering from a point which has no customs / immigration, or by obtaining a fake US ID, or dual citizenship.
All this measure is faux security or security theatre as some call it. I'm sure the system will turn up the odd murderer, tax evader and such like, but that's not what the system was meant for.
The massive expense could have been spent in far more effective ways such as increased border patrols, more container inspections and plenty of other things that are far more pressing that turning millions of people into criminals simply because of the documents they are holding.
"Gene Roddenberry's" being shorthand for "we found a scrap of paper in Gene Roddenberry's notes with a doodle of a spaceship and / or planet which we have subsequently developed into an entire series and we intend to flog the connection to death by putting 'Gene Roddenberry's' in the title".
Switching isn't hard if the initial product sucks.
I used to use Altavista and I hated it with a passion. It would return reams of junk sites stuffed with meta keywords. As soon as I discovered Google I jumped ship immediately simply because Alta Vista stunk and Google didn't. And it still doesn't.
Of course when Google works so well, switching is going to be hard. After all, what does MSN Search (or A9.com for that matter) do that I need? Sure they might have some unique features, but to take A9.com as a site I've tried, those features are mostly gimicks and some of them are very odious - such as tying your searches to your Amazon.com cookie, and sticking a9.com search bars in annoying places on sites like imdb.com.
If MSN do the same or direct you to "partner sites", or deliver less accurate results (likely) or associate your searches with your MSN id, they may as well flush their money down the toilet since its doomed to mediocrity. Besides which other portals such as Yahoo! have established search engines, and I'd be surprised if they got a tenth of the traffic of Google, so what's so amazing about the MSN engine?
Of course its dangerous, but only when in its promiscuous settings. As I said, a control is just a DLL - it's how it gets on your machine that is the danger. If you lock down ActiveX to a whitelist, it is absolutely no different from any other kind of rich content helper, plugin, codec, 3rd party app or anything else that the user might run to play / render content from the web. Let me repeat - ActiveX controls are just DLLs. Netscape plugins are just DLLs. The differences boil down to how they get installed and API calls. Nothing else.
Extensions are not DLLs but they are very powerful objects. There is no "jail" for an extension. An extension is a chrome overlay - privileged Javascript and XUL that Firefox executes with the same permissions as the rest of of its chrome. It's not like page content where the Javascript is limited to certain DOM calls. Privileged JS can call any XPCOM object running in Firefox that has a scriptable interface and there are literally hundreds of them. Do you know what XPCOM is? Cross-Platform COM - a technology derived from COM (or ActiveX as its more commonly known). I'm not besmirching XPCOM (it's great), but you're complaining about ActiveX when Firefox is built on something very similar.
So your extension has hundreds of XPCOM objects to choose from, create and call. Want to create a file? No problem. Want to read a file? No problem. Want to grab a payload from somewhere? No problem. Want to redirect the user through your own associates links? No problem. Want to read the registry? No problem. There are XPCOM objects for all of these things and more, and Firefox won't lift a finger to stop an extension from using them.
This is the problem. People believe Firefox is inherently safe and ActiveX is inherently unsafe. Neither situation is true as will become more apparant as Firefox's popularity grows and it becomes a more inviting target.
The truth is that "secure by default" is the pressing concern. All extensions, controls, plugins etc. should be installed solely by the consent of the user, and by default not even that. I believe by default that Firefox / IE should be locked down so they only accept a small handful of well known and trustworthy plugins / controls. If the user wants to install something else they should have to go to their prefs and loosen the browser up before it will assist them in installing it. I.e. the browser should protect the user from him or herself. This might be a modest inconvenience but it minimises the attack surface - if only 1% of your users are vulnerable to attack it is still a hell of lot better than 100% being vulnerable.
Sorry you are wrong. It isn't dangerous "regardless of settings". ActiveX controls are DLLs and nothing more. If you restrict their use, they're no more dangerous or different from any other DLL, plugins or 3rd party helper apps included.
The issue is how they are installed and deployed. Assuming your browser is in a whitelist mode (as I described) they are absolutely no worse than any other means of rich content.
The rest of your issues can be applied as easily to plugins, extensions or anything else. I can *trivially* write an extension that does something bad to your system including dump out a trojan somewhere. Just because Firefox offers an uninstall option makes no odds if the extension has already delivered the payload.
ActiveX is no worse than Netscape plugins or Firefox extensions for that matter. All could equally turn your machine into sludge.
The big deal of course for ActiveX is that as you say it's not in whitelist mode which encourages sites to insist the user install utter crap and for the spyware to live in that atmosphere. However, when you do put it in whitelist mode it becomes quite useful. For example Netscape 7.1 uses ActiveX in whitelist mode to support the Windows Media Player. Thus sites get the scripting abilities of a popular control, but the user hasn't left their browser wide open.
Netscape 7.1 and 7.2 support ActiveX controls, but only for scripting the Windows Media Player.
This new Netscape 8 (for some ungodly reason) appears to supports hosting IE rendering engine in addition to Gecko so perhaps there is a more pressing need for blocking ActiveX after all.
I had to hack out a large chunk of an old Gateway case to fit a new motherboard. It took a very, very long time to do with an angle-grinder bit and covered every surface nearby in black dust.
Is there an easier way to do it with a dremel? What part number is best for this?
Not burying functionality into invisible menus is good UI design.
And it's good design on Windows / Linux too. In fact the design guidelines for GNOME & Windows say don't functionality on the context menu that you can do somewhere else.
But irrespective of that, context menus are a good thing and single button mice suck. Having to hold the button down, or the command key, or traipse up to the single menu at the top of the screen is a massive pain when you're lumbered with a single button mouse.
It's a wonder given Apple's penchant for design that they don't produce a mouse with a single button that uses software to determine if you were left or right clicking on it based on the pressure on each side of the mouse. Then both camps can be happy.
I deal with XML on a (near) daily basis as well. It is not.
Sorry, you're wrong. It is harder. Practically every change to XML data requires running it through a parser or browser just to ensure the XML is valid. Not the data - just the syntax of the XML. If you want to validate the data then you're getting into writing a DTD or schema as well which heaps on even more complexity. Even the use of a dedicated XML editor only gets you so far and if you're using MS notepad, well then you're screwed.
XSLT and RDF are much more complex than the average XML application
The average application of XML is XSLT, XHTML, RDF (or RSS), Web services or something of equal complexity. I'm sure some apps do use ad hoc xml by slapping an tag at the top of some arbitrary grammar but even that is still more complex than name=value lines if that's all that's required. The latter is easily readable and can be parsed with fscanf. The former can puke on a single misplaced angle bracket or quote and requires you to link to expat, MS XML or some other parser, set up element handlers and is much, much more complicated.
I see no basis for making that claim.
I do. Even a non-validating parser must tokenize, keep count of nested elements on a stack, resolve entities etc.. It is by definition slower than a rudimentary fscanf required to parse a.ini file. It's certainly much more powerful, but that power is wasted on simple data.
As I've said all along, I have no problem with XML, but use the right tool for the job. If a requirement of a game (and it is) is fast loading and the information is simple, there may be no point for using XML at all. If Civ decides to encapsulate something complex with these files, then there is a use for XML, but certainly not for name / value pairs. XML certainly formalises a lot of things and takes the bother out of parsing arbitrary data but it has to be justified by how complex and correct that data is to be worth the overhead.
Slashdot Mirror
I know it's greatly difficult - I've done JNI and JRI before it, but it's still fiddly and a pain compared with
In
Sometimes pain isn't a bad thing since it can guide people along the preferred path which is to write stuff in a portable manner unless it is strictly necessary. The mindset that Microsoft seem to be promoting is that it's easy to port legacy code to
And there is lots of tainted code and therefore lots of exceptions. In fact I'd hazard to guess that the majority of non-trivial
Either Mono produces something that works with most of the tainted code, or they become a seamless and better version of
I work for a large institution with various
And yes Microsoft has implied Windows.Forms is portable if for no other reason than the namespace it is in - System.Windows.Forms. Why isn't it Microsoft.Windows.Forms?
As for security. A platform which actively helps someone wrap unsafe code, invoke native methods etc. from a supposedly safe platform is clearly more unsafe than one which doesn't or makes it hard to do.
Did I? Perhaps you need to re-read what I said.
But even if / when that occurs it's not ideal. In fact it's terrible. To run
As a corporate entity MS must be rubbing its hands with glee about this even if some of the CLR purists are probably aghast.
The consequence of this is that no-one uses JNI unless they absolutely positively have to. It's a pain and life is much easier if everything is in Java. Thus with the exception of a few esoteric things such as SWT, most libraries are pure and portable.
Now contrast this with .NET. Writing native C++ and wrapping it in a garbage collection safe class involves no stub generation and can be done in a single file - the assembly info, interface and gc wrapper can all be specified in situ. Consequently it's a lot easier to pull C++ into a .NET application. MS DevStudio 2003 even has wizards to do it. It is also a lot easier to call DLLs and ActiveX from .NET since MS provide PInvoke and COM Interop to do just that.
Now on the face of it, this is all well and good, especially if you have a lot of legacy crap to port. But by the same token it means many more .NET apps are tainted than on Java. The problems this causes for portability should be obvious.
And this is called "Microsoft having their cake and eating it". They can expound portability and present the facade that .NET is cross-platform, when in reality they provide tools and wizards to ensure it remains anything but. Apps that are infested with native instructions and OS-specific calls are by definition unportable.
Mono demonstrates the problems faced in porting .NET to other platforms. Mono must literally pull in the whole winelib in order to cope with the number of tainted .NET apps that attempt to call out to Win32. And too bad if you're running Mono on a non-x86, non-Linux system since winelib is x86 only (for now).
And I don't see the situation getting any better. Perhaps if Mono gains momentum it might put the brakes on tainted code, but there is a long way for that to happen. I believe the only way Mono is going to make an impact is if ships with a cross-platform IDE with tools that default to its open source stack. This is almost a reality since ICSharpDevelop & MonoDevelop are both fairly complete IDEs but there is nothing yet which defaults to the open source stack and runs on all major platforms.
Especially seeing as millions of tonnes of CO2 gas are being released into the atmosphere every single year by burning fossil fuels.
Any attempt to warm the planet would have to be preceded by dozens of missions and meticulous research and preparation before anyone had any clue whether it would be a worthwhile undertaking. Any biological or geological evidence would surely form part of that evaluation.
My personal feeling is that it would not be worthwhile to warm Mars for hundreds of years. What's the point if there is noone living there? Let's see some people actually set foot on the surface and do the research. Let's see colonization happen with people living under plastic domes. Then we'd be in a much better position to evaluate the relative merits of warming the entire planet.
Is that your best reason, that it might go wrong?
Sorry but that's dumb. Everything might go wrong. Your house might burn to the ground because of an electrical fault. Does that mean you shouldn't use electricity or that you try to minimise the risk through safety standards and certification? You might hit a wall in your car. Does that mean you don't ride in a vehicle or that you should learn to drive properly and buy a car with various safety features? You might get attacked by a dog (while walking). Does that mean we should kill all dogs or enact laws that make owners responsible for their animals? Your computer might be compromised and be used to store kiddy porn. Does that mean you should unplug all the jacks from the wall and lock the PC in a metal box, or does it mean you should be diligent and use appropriate firewall / antivirus software?
I'm not advocating any crazy experiment on Mars - but if there is a carefully reached and reasonable expectation that something will work and the rewards outweigh the risks, then it should be taken. The alternative is for mankind to collectively cower under the table waiting for the next global catastrophe to wipe us all out.
Besides, who knows what kind of fossel record would be being destroyed by exposing the planet to natural weather forces again.
Yeah right. But to apply your own risk aversion argument, how would we ever know about the "fossel" record? After all, there is a very real chance of mission failure when going to Mars. How can we possibly send people or robots to Mars if the probe could blow up? The same goes for any other human endeavour past, present or future.
Hanging around for something - anything - to be 100% certain (except death & tax) is to piss away any future that humanity might have at all.
Virgin soil = rock dust. Assuming there to be no life on Mars, I don't get what the problem is with altering it. Now naturally if there is life that's a whole can of worms in itself, but if not, then what damn difference does it make?
Now onto .NET. C++ is fairly easy to pull into a project - write some garbage collection safe wrappers around your "legacy" code and now it runs in .NET. And via PInvoke you can call native methods easily too. And then there's COM interop which pulls in ActiveX controls. That's all good and well, but it also means that lots of projects are not "pure" - they're polluted with Win32 crap and generally not portable.
That's probably what gets to Gosling - that .NET is touted as a portable development platform but it isn't. Projects are infested with unpure, unsafe and platform-specific code. Microsoft can preach portability but they know that very few people will be disciplined enough to bother with it. Thus people are tied to Win32 even when they're using a allegedly portable runtime. Even the likes of Mono only gets around this by pulling in winelib.
Do the games come with region encoding, or could I (for example) pick one up from the US and play games sold in Europe / Japan etc.? Same question as per movies if / when they get released.
Looking back I might have been better off drilling some holes and use a hack saw, but all I had at the time was a dremel. So I spent a good long while using the angle grinder bit to literally cut a slot all the way around. It was very arduous, made a huge mess (black dust everywhere) and probably totally the wrong way to do it but I eventually fitted the motherboard no problem.
In France (or Paris to be precise) they photocopied my passport, but even there it's inconsistent since I've stayed places where they didn't bother, or simply jotted down the passport number.
I suggest you are even worse since you blindly accept the "security" this system offers without considering it properly.
All this measure is faux security or security theatre as some call it. I'm sure the system will turn up the odd murderer, tax evader and such like, but that's not what the system was meant for.
The massive expense could have been spent in far more effective ways such as increased border patrols, more container inspections and plenty of other things that are far more pressing that turning millions of people into criminals simply because of the documents they are holding.
I wonder how many terrorists this amazingly intrusive and expensive system has actually caught.
"Gene Roddenberry's" being shorthand for "we found a scrap of paper in Gene Roddenberry's notes with a doodle of a spaceship and / or planet which we have subsequently developed into an entire series and we intend to flog the connection to death by putting 'Gene Roddenberry's' in the title".
Yeah but that's too bad if no one is watching it, and by extension they must charge less for the advertising spots.
I used to use Altavista and I hated it with a passion. It would return reams of junk sites stuffed with meta keywords. As soon as I discovered Google I jumped ship immediately simply because Alta Vista stunk and Google didn't. And it still doesn't.
Of course when Google works so well, switching is going to be hard. After all, what does MSN Search (or A9.com for that matter) do that I need? Sure they might have some unique features, but to take A9.com as a site I've tried, those features are mostly gimicks and some of them are very odious - such as tying your searches to your Amazon.com cookie, and sticking a9.com search bars in annoying places on sites like imdb.com.
If MSN do the same or direct you to "partner sites", or deliver less accurate results (likely) or associate your searches with your MSN id, they may as well flush their money down the toilet since its doomed to mediocrity. Besides which other portals such as Yahoo! have established search engines, and I'd be surprised if they got a tenth of the traffic of Google, so what's so amazing about the MSN engine?
Extensions are not DLLs but they are very powerful objects. There is no "jail" for an extension. An extension is a chrome overlay - privileged Javascript and XUL that Firefox executes with the same permissions as the rest of of its chrome. It's not like page content where the Javascript is limited to certain DOM calls. Privileged JS can call any XPCOM object running in Firefox that has a scriptable interface and there are literally hundreds of them. Do you know what XPCOM is? Cross-Platform COM - a technology derived from COM (or ActiveX as its more commonly known). I'm not besmirching XPCOM (it's great), but you're complaining about ActiveX when Firefox is built on something very similar.
So your extension has hundreds of XPCOM objects to choose from, create and call. Want to create a file? No problem. Want to read a file? No problem. Want to grab a payload from somewhere? No problem. Want to redirect the user through your own associates links? No problem. Want to read the registry? No problem. There are XPCOM objects for all of these things and more, and Firefox won't lift a finger to stop an extension from using them.
This is the problem. People believe Firefox is inherently safe and ActiveX is inherently unsafe. Neither situation is true as will become more apparant as Firefox's popularity grows and it becomes a more inviting target.
The truth is that "secure by default" is the pressing concern. All extensions, controls, plugins etc. should be installed solely by the consent of the user, and by default not even that. I believe by default that Firefox / IE should be locked down so they only accept a small handful of well known and trustworthy plugins / controls. If the user wants to install something else they should have to go to their prefs and loosen the browser up before it will assist them in installing it. I.e. the browser should protect the user from him or herself. This might be a modest inconvenience but it minimises the attack surface - if only 1% of your users are vulnerable to attack it is still a hell of lot better than 100% being vulnerable.
The issue is how they are installed and deployed. Assuming your browser is in a whitelist mode (as I described) they are absolutely no worse than any other means of rich content.
The rest of your issues can be applied as easily to plugins, extensions or anything else. I can *trivially* write an extension that does something bad to your system including dump out a trojan somewhere. Just because Firefox offers an uninstall option makes no odds if the extension has already delivered the payload.
The big deal of course for ActiveX is that as you say it's not in whitelist mode which encourages sites to insist the user install utter crap and for the spyware to live in that atmosphere. However, when you do put it in whitelist mode it becomes quite useful. For example Netscape 7.1 uses ActiveX in whitelist mode to support the Windows Media Player. Thus sites get the scripting abilities of a popular control, but the user hasn't left their browser wide open.
This new Netscape 8 (for some ungodly reason) appears to supports hosting IE rendering engine in addition to Gecko so perhaps there is a more pressing need for blocking ActiveX after all.
Is there an easier way to do it with a dremel? What part number is best for this?
And it's good design on Windows / Linux too. In fact the design guidelines for GNOME & Windows say don't functionality on the context menu that you can do somewhere else.
But irrespective of that, context menus are a good thing and single button mice suck. Having to hold the button down, or the command key, or traipse up to the single menu at the top of the screen is a massive pain when you're lumbered with a single button mouse.
It's a wonder given Apple's penchant for design that they don't produce a mouse with a single button that uses software to determine if you were left or right clicking on it based on the pressure on each side of the mouse. Then both camps can be happy.
Sorry, you're wrong. It is harder. Practically every change to XML data requires running it through a parser or browser just to ensure the XML is valid. Not the data - just the syntax of the XML. If you want to validate the data then you're getting into writing a DTD or schema as well which heaps on even more complexity. Even the use of a dedicated XML editor only gets you so far and if you're using MS notepad, well then you're screwed.
XSLT and RDF are much more complex than the average XML application
The average application of XML is XSLT, XHTML, RDF (or RSS), Web services or something of equal complexity. I'm sure some apps do use ad hoc xml by slapping an tag at the top of some arbitrary grammar but even that is still more complex than name=value lines if that's all that's required. The latter is easily readable and can be parsed with fscanf. The former can puke on a single misplaced angle bracket or quote and requires you to link to expat, MS XML or some other parser, set up element handlers and is much, much more complicated.
I see no basis for making that claim.
I do. Even a non-validating parser must tokenize, keep count of nested elements on a stack, resolve entities etc.. It is by definition slower than a rudimentary fscanf required to parse a .ini file. It's certainly much more powerful, but that power is wasted on simple data.
As I've said all along, I have no problem with XML, but use the right tool for the job. If a requirement of a game (and it is) is fast loading and the information is simple, there may be no point for using XML at all. If Civ decides to encapsulate something complex with these files, then there is a use for XML, but certainly not for name / value pairs. XML certainly formalises a lot of things and takes the bother out of parsing arbitrary data but it has to be justified by how complex and correct that data is to be worth the overhead.