I didn't say we should give up, I agree that would be wrong, but the whole issue of binary drivers boils down to a fundamental question:
Should we try and force people to GPL their work against their will, or should we try and convince them via strength of argument and let them make their own decision
I'm hoping the answer is obvious - it should be the latter. Yet imagine a situation in which desktop Linux has 50% market share. What kind of hardware vendor would be able to to exclude themselves from 50% of the market by keeping their drivers closed and yet still be competitive? Effectively, the market and the policies of the kernel people would force them to GPL their drivers.
Now you could say, well nobody is forcing them to make hardware. But this is just dodging the point: if I wish to sell an AwesomeWidget which needs a driver, and I write that driver, it should be my decision whether to release that code under the GPL or not. The right way for the free software movement to achieve victory is to convince people that free software is superior to closed development, both pragmatically and ethically. The wrong way is to say "Shut the fuck up, just give us your damn code already" - this sends a message like "we don't care about you, all we want is what you have made". Not a message an enlightened society should be encouraging!
Look at nvidias drivers on linux! Always well behind other drivers, and filled with bugs because we have to wait for nvidia to get off thier asses and fix the damn thing.
Uh, yes. Because everybody knows that being open source is a magical recipe for never having any bugs.
Writing video drivers is hard dude, and nVidia employ several experienced people who do it full time. I've seen them discuss technical issues in public before and have no doubt in my mind that they are experts.
Given how many open source drivers are buggy as hell (i810 audio, hello) there must be another explanation. Here's one try.
I hypothesise that what determines the quality of a driver is the number and quality of developers working on them. Closed source drivers sometimes suffer because the quality and/or quantity of developers writing those drivers isn't good enough. Being open source means that theoretically the quantity and quality of developers is unbounded. However, note that this is theory - being open doesn't actually imply that you will suddenly get legions of experts in video hardware writing your drivers for you. It merely makes it possible.
To be honest, I have serious doubts that we'd have such good drivers if nVidia GPLd them tomorrow and simultaneously fired all of their Linux developers. Being closed doesn't mean you can't have good people working on it, and being open doesn't mean you will. It simply alters the bounds of the possible.
Sorry, I used to agree with this line of reasoning a few years ago when I was first getting into Linux. But these days I think differently.
The fact is, that a driver is only one part of the openness puzzle. Sure, so you can patch a driver. Great. But drivers don't do much, they're just glue, not very interesting pieces of software. Now, if you could fork the designs of your hardware and go add features as you see fit, that would be useful. And in fact some pieces of hardware have firmware, which is basically software-on-hardware that is possible to change if you have the source code and can recompile/reflash it, but firmware is usually closed and nobody really cares about that. I never hear people (outside of a few kernel developers) saying things like "You know, I thought about buying an iPod but decided not to because it didn't have an open firmware".
But let's say that firmware was in fact open. Now what? Well, maybe you want to fork the iPod and add some new features to it. Great. But what if you need new features in the chips themselves.... chips can be open source. Actually many chips these days are synthesised by machine from VHDL/Verilog sources which looks like code and can be changed by people who know the system. But I never heard anybody, not even the most extreme kernel developers, refuse to buy a piece of hardware on the grounds that the Verilog wasn't available.
But even then, even if you could fork and redesign the iPod in any way you saw fit, it would still be controlled by Apple because at some point thoughts in your head and designs on paper have to actually be manufactured, and Apple have big honking factories which churn out their iPod design all day and not yours. So how are you actually going to get this to people? You need a factory too.
So, basically, you can keep going and going until you reach some bottleneck at which point you aren't in control anymore and are reliant on other people to get things done. It's tempting to think that the transition line is at the boundary between software and hardware, but this line isn't all that clear - hardware is hard to "fork" because it exists physically and has duplication cost, yet the purpose of copyright is to allow you to make something with a zero copy cost have non-zero copy cost so it can fit into our economy. Even when that privilege is not used, like with GPLd software, it doesn't stretch down the whole stack because that GPLd software still requires controlled things like hardware and electricity to be useful.
Put simply, there is no black/white open/closed divide. There are only shades of grey between one end of the spectrum and the other. We should strive for openness as it has several properties which help our society Get Things Done, but at no point should openness overrule getting things done as that's putting the cart before the horse.
That's incorrect, he has said he doesn't mind binary-only drivers but he won't go out of his way to help them. So, if he sees an improvement that would break the module API, he'll do it. That's a LONG way from "I do this so people can't write binary drivers" which is clearly not the case (many companies do, successfully).
Also a lot of people mix up the issue of "binary vs C" with "closed vs open". You can have open source binary drivers, and that's often a convenient thing for end users to have (because the user experience of installing binaries is generally better than that of installing things from source code).
In his blog he states that a binary closed source driver would be illegal. Isn't this exactly what NVidia does now?
Yes, that's exactly what they do, and people like Greg hate it. In fact Mr Kroah-Hartman has said before that he makes a sport of deliberately sabotaging binary drivers people rely on. He is the worst kind of free software zealot - apparently incapable of thinking in anything other than black and white.
The kernel project is, to put it mildly, a fucking disaster zone when it comes to messaging here. Some developers like Linus say binary modules are OK but he won't go out of his way to help them. Other developers say they're illegal. Still others say "well Linus says it's OK but I disagree, so I reserve the right to sue you for infringing my copyright". And Linus sits by and does nothing to rectify this ridiculous situation.
One asshole (I'll leave you to guess who) decided that by putting functions inline into headers he somehow gained to right to force any USB drivers to be GPLd - apparently he never heard of "clean room re-implementation". He apparently also believes that you don't need to convince people licensing their work under GPL is good through logical reasoning and strong argument, it's enough to try and force peoples hand through dumb sleight of hand. Guess which is more convincing dude! If the GPL is so great, why do you try and force people to use it instead of letting them decide for themselves? Yes Greg, I'm looking at you.
For many companies, there are no benefits to going open source, and only downsides. The pragmatist recognises this economic reality, the zealot (and Greg KG is a notorious one) doesn't want to hear it. For instance, let's say nVidia GPLd their driver and got it accepted into the main tree. This gives them a competitive disadvantage because ATI or other companies can now look at how their drivers work with much less effort. It doesn't save them any work, because the community would still expect them to maintain the drivers and add functionality to them (and indeed, for cards that are new to the market or in development, they'd be the only ones who could). And there's no guarantee the drivers would be accepted anyway - simply using the wrong coding style is enough to cause problems in the kernel project, let alone doing the sort of things the nVidia drivers do (for instance they used to use a custom TLS scheme).
Because of this, I'm 100% not convinced making binary driver developers lives harder changes anything. Are large businesses (the type who make hardware that's difficult to reverse engineer) likely to say, hey, gosh, you know this Greg KH guy kind of doesn't like closed drivers, maybe we should open them up to please him? Nope. They'll just work around the difficulties or not provide drivers at all.
It's not "impossible" to debug binary software. Please. This is a crappy excuse kernel developers regularly pull out of their asses to confuse people who haven't done much software development. What they actually mean is, "I don't really want to" (and if unloading the driver makes the crash disappear, that's a pretty good way to shift the problem onto the driver manufacturers anyway).
I've been a Wine developer for years and have spent many hours doing this impossible thing of which you speak, and your average copy of MS Word or Steam is a LOT larger than your average driver. Yes, it's hard. No, it's not impossible. I've heard various excuses as to why kernel development is just different!! to userland software development, and don't buy it. Yes, having to reboot when a crash occurs is a royal pain in the ass, but so is not being able to get a backtrace because the game you're investigating treats any attempt at attaching a debugger as an attempt to hax0r its copy protection. Different space, different challenges. It's still possible.
A stable binary module interface would help open source developers too (even if it only existed for a single 2.X series at a time), as new software which relies upon kernel modules or drivers would become much easier to distribute and install for non-technical end users. Take for instance ZeroInstall. The main developer, Thomas Leonard, since abandoned the original (imho quite elegant) approach of using a networked VFS because it required users to install a kernel driver, a task which proved hard to impossible for many non-developers. So the whole thing was rewritten to do things a different way and avoid the kernel, despite that coming with some disadvantages. We've also looked at using a kernel module to fix various speed issues for Wine in the past, but the difficulty of getting even minor patches accepted into the kernel let alone major new subsystems nixed that. If there had been a stable module interface we could have skipped all that and gone straight to improving things for end users without having to worry about what kind of indenting or list structure we should be using.
I think pretty much by definition if people have to write long rambling articles "explaining" why it's so much easier to install software on Linux than Windows, it probably isn't.
Sterling engines don't exploit water/surface temperature differences, you're thinking of a different scheme. Sterling engines are a type of solar power based on focussing the suns rays on a central spot.
Take the recent DCOM work we did. This is what I'm going to talk about because it's what I know - myself (CW) and Rob Shearman (CW), along with some help from Marcus Meissner (Novell) and Huw Davies (CW) reimplemented large parts of DCOM mostly for one application. The work took many months - starting from a pre-existing codebase written by Marcus years earlier, we were "finished" ~135 patches later.
What was that one application which was so important?
InstallShield.
Now perhaps you see the problem - sure, not every API is used by every app. But there are hundreds of thousands of APIs, many extremely complex, and many millions of applications. All it takes is ONE popular application to use a single API that was not yet reimplemented and you have months of work ahead of you.
This is especially true of something like DCOM where the supporting infrastructure for 4 or 5 functions can run to 10,000+ lines of code.
I know about the embedded JIT VMs, and I also know about Jazelle. Thanks for assuming I don't know what I'm talking about. I do not care about what is theoretically possible on the latest hardware (assuming manufacturers actually go for the highest performance option and not the cheapest). I'm interested in what European mobile handsets are actually doing, and most still use KVM. Therefore I can and will use that as a point against mobile Java.
Java is reasonably easy to develop for, I'll give you that. But, wait until you start trying to write large, real world apps or games. You will suddenly find yourself knowing more about the internals of garbage collectors than you thought.
Maintainability - nearly all widely deployed Java apps are riddled with #ifdefs done using a custom pre-processor, because phones vary so wildly in bugs and capabilities that you have to produce many JARs from the same source code. Java the language provides zero help with this real world problem.
Porting between what? With Java you write to specifications, not a single implementation. While this can be great when it works, with J2ME it doesn't work. You end up spending your time porting apps between different phones, except instead of obvious API differences the problems are more like "Nokia 6680 uses 40x20 icons whilst SonyEricsson use 16x16 and the exact sizes aren't documented anywhere obvious". OK I forget the exact pixel sizes but you get the idea...
A series of very cheap phones like the ones you propose are being prepared by major manufacturers for use in the third world. That said, there's a lot of cool stuff you can do with modern mobiles - really we've only started to explore this space. Java gaming is not the best mobile developers can do. Many useful, dare I say.. killer?.. apps can be written that exploit the varied nature of mobile phones. Just wait and see.
Most phones use the "KVM" micro virtual machine which does not do JIT compilation (imho a very stupid thing to do on a phone anyway), instead relying on a pure interpreter approach. It does practically no optimisation and has a very simplistic garbage collector. It is by no definition of the word fast. Sun now provide a JIT micro VM that implements HotSpot but even then, as we saw in an earlier Slashdot story basic optimisations like stack allocation are beyond it and most phones don't seem to use it anyway.
Unfortunately the javac compiler doesn't do any optimisation either. So you're left running unoptimised code exactly where you need it most. One of the things I want to experiment with next time I have some spare hours is using GCJ instead of JavaC to produce class files for phones. I suspect there would be an improvement.
It would have been smarter IMHO to embed a static compiler into phones (like GCC) and then use that to produce native ARM/whatever binaries at install time using the full range of optimisations possible. It would take longer to install apps, but this is a one time cost, and you could mostly eliminate the startup overhead of the VM and the speed penalty of bytecode interpreting.
To be fair to your friend, many phones (Symbian, BREW) don't use Java but provide their own C++ API. Many people who have used Java on mobile phones have found that performance and memory management are extremely poor and not really competitive next to C++ (though this is the technology I'm talking about rather than the footprint).
Motorola now use the "JUIX" operating system which is a combination of Linux and Java so while he was definitely wrong, his mistake was simple enough - assuming that technological superiority would win out over mass-market/buzzword appeal.
It's supported by MIDP2, but isn't quite so useful while most GCs do nothing about fragmentation as there's no guarantee free memory over time won't simply drop and drop (unless you are very careful to ensure object sizes tesselate).
It's not entirely a joke, but I'd agree with the majority of comments expressed above. I recently started doing some mobile phone programming, and come to the conclusion that Java on mobiles has only one redeeming: namely the type safety/code access security system. The rest is junk.
Not only are the J2ME specs incredibly loose and full of optional material, but nearly every phone has bugs in their implementations. Apparently Suns engineers have never heard of "conformance tests" - even basic stuff like drawRGB to negative co-ordinates doesn't work right on most phones.
Worse though is Java itself. The Java compiler provided by Sun is an absolute waste of space. It does virtually NO optimisation itself, relying on the JVM to do it all, which is great except the micro-edition "kvm" runtime doesn't do any optimisation either because they didn't have space to make it do more than the very basics. Worse, all the usual flaws it has are still there - an asinine insistence on treating unreachable code as a fatal error, lack of a pre-processor (which you need for mobile development as phones are so different), etc.
Javas runtime performance is atrocious. Only the very newest phones run it anywhere near acceptable speeds if you're doing anything graphics "intensive" (like basic animation). Instead of pre-compiling the code to native at install time, which would seem to be the obvious solution, the KVM still seems to use just-in-time compilation.
The biggest difficulty though tends to be heap fragmentation. Most phones do not use a compacting GC, with the result that it's very easy to make an app that runs fine for a few minutes then barfs because the heap has become fragmented. Java desperately needs manual memory management extensions, stack allocation or the ability to run multiple heaps but instead Sun are simply pushing a micro-edition of HotSpot - apparently waiting for the hardware to catch up so they can cover up what a useless hunk of junk Java is. It's alright for the article to talk about escape analysis - a technique that isn't actually implemented in any shipping desktop or server JVM yet, but how many years would it be until such a basic thing as allocating objects on the stack instead of the heap runs on mobile phones?
There are only two reasons to use Java on mobile phones - the security, and the number of people who know Java. Unfortunately although there is a huge market of (cheap?) Java programmers, people who know Java but not C++ are likely to screw it up because they don't really understand what's going on underneath the hood and so don't understand how to write efficient code.
Actually, I mostly use Linux, but when I have used Gimp on Windows it annoyed me too.
Re:GIMP is becoming a real threat for Photoshop
on
First Look at GIMP 2.4
·
· Score: 2, Insightful
Probably it'd be a threat today if the Windows version supported a containing window (to work around the lack of good WM in Windows) - Photoshop is easy to pirate but there are still lots of people who would happily use a free alterntive rather than pirate a commercial program. I for one haven't used Photoshop in years, as a simple web designer/software developer the combination of the Gimp and Inkscape easily meet my needs. Why would I pay for Photoshop, a program that I'm not familiar with, when the Gimp has every feature that I want already?
Re:Maybe an OSS future isn't that bright afterall
on
Nessus Closes Source
·
· Score: 1
I don't think it was that rude or off-base (by Slashdot standards).
Anyway. The point was that people are focussing on "what is the business model for open source" when the real question to ask (thanks to Nat Friedman for this) is "what is the business model for software".
Software isn't like food or water. It's not something we need and die if we don't get. It's a set of tools that make life easier - software is written to solve a problem. Most programmers are already paid to solve specific problems for specific clients. Comparitively few work in the retail software industry.
The "open source trend" if you like is that groups of people who happen to be working on solving the same sorts of problems for their clients co-operate on the tools they use. In the case of Nessus, the "open source trend" would have been that security consultants who know code worked together on an open source scanner adding features as and when they were needed. The mistake (?) Tenable seems have to made is a pretty basic one - their business model was not "solve the problem" ie making clients networks more secure, but rather "sell tools to those solving the problem" which is great unless you give the tools away like they did. The net result is that as they put lots of funding into developing the tools but didn't use those tools themselves. If Nessus is really an indispensable tool used by paid professionals in the network security field (I have no idea) then presumably they'll either decide to pay Tenable for the product or fork it and start work themselves. Which is chosen by the specialists will probably depend on things like how much it costs, how responsive Tenable are, what happens with development etc.
Fundamentally there's no iron law that says people will develop open source tools to solve their problems rather than buy a commercial product, but in some cases this does happen - for instance, many embedded chip vendors choose to extend the GNU toolchain rather than write their own. Why? Because their problem (how do people compile software for my new chip) is easier solved by working with others than going solo.
Because they're trying to claw back the money they spent on wireless licenses for 3G data services. They can't do that unless they make a fat margin on data, so it's very expensive. I'm also annoyed by this: transferring about 1.5mb of data has cost me recently about $22
I'll have to disagree, we don't do anything with/etc/mailcap or Firefox files in autopackage yet our.package file association works just fine. Possibly the version you're using doesn't have the GNOME integration built in.
Slashdot Mirror
I'm hoping the answer is obvious - it should be the latter. Yet imagine a situation in which desktop Linux has 50% market share. What kind of hardware vendor would be able to to exclude themselves from 50% of the market by keeping their drivers closed and yet still be competitive? Effectively, the market and the policies of the kernel people would force them to GPL their drivers.
Now you could say, well nobody is forcing them to make hardware. But this is just dodging the point: if I wish to sell an AwesomeWidget which needs a driver, and I write that driver, it should be my decision whether to release that code under the GPL or not. The right way for the free software movement to achieve victory is to convince people that free software is superior to closed development, both pragmatically and ethically. The wrong way is to say "Shut the fuck up, just give us your damn code already" - this sends a message like "we don't care about you, all we want is what you have made". Not a message an enlightened society should be encouraging!
Uh, yes. Because everybody knows that being open source is a magical recipe for never having any bugs.
Writing video drivers is hard dude, and nVidia employ several experienced people who do it full time. I've seen them discuss technical issues in public before and have no doubt in my mind that they are experts.
Given how many open source drivers are buggy as hell (i810 audio, hello) there must be another explanation. Here's one try.
I hypothesise that what determines the quality of a driver is the number and quality of developers working on them. Closed source drivers sometimes suffer because the quality and/or quantity of developers writing those drivers isn't good enough. Being open source means that theoretically the quantity and quality of developers is unbounded. However, note that this is theory - being open doesn't actually imply that you will suddenly get legions of experts in video hardware writing your drivers for you. It merely makes it possible.
To be honest, I have serious doubts that we'd have such good drivers if nVidia GPLd them tomorrow and simultaneously fired all of their Linux developers. Being closed doesn't mean you can't have good people working on it, and being open doesn't mean you will. It simply alters the bounds of the possible.
There's a big difference between your average driver and a clone of something 35 million lines long.
My mistake, thanks for correcting me (politely ;)
The fact is, that a driver is only one part of the openness puzzle. Sure, so you can patch a driver. Great. But drivers don't do much, they're just glue, not very interesting pieces of software. Now, if you could fork the designs of your hardware and go add features as you see fit, that would be useful. And in fact some pieces of hardware have firmware, which is basically software-on-hardware that is possible to change if you have the source code and can recompile/reflash it, but firmware is usually closed and nobody really cares about that. I never hear people (outside of a few kernel developers) saying things like "You know, I thought about buying an iPod but decided not to because it didn't have an open firmware".
But let's say that firmware was in fact open. Now what? Well, maybe you want to fork the iPod and add some new features to it. Great. But what if you need new features in the chips themselves .... chips can be open source. Actually many chips these days are synthesised by machine from VHDL/Verilog sources which looks like code and can be changed by people who know the system. But I never heard anybody, not even the most extreme kernel developers, refuse to buy a piece of hardware on the grounds that the Verilog wasn't available.
But even then, even if you could fork and redesign the iPod in any way you saw fit, it would still be controlled by Apple because at some point thoughts in your head and designs on paper have to actually be manufactured, and Apple have big honking factories which churn out their iPod design all day and not yours. So how are you actually going to get this to people? You need a factory too.
So, basically, you can keep going and going until you reach some bottleneck at which point you aren't in control anymore and are reliant on other people to get things done. It's tempting to think that the transition line is at the boundary between software and hardware, but this line isn't all that clear - hardware is hard to "fork" because it exists physically and has duplication cost, yet the purpose of copyright is to allow you to make something with a zero copy cost have non-zero copy cost so it can fit into our economy. Even when that privilege is not used, like with GPLd software, it doesn't stretch down the whole stack because that GPLd software still requires controlled things like hardware and electricity to be useful.
Put simply, there is no black/white open/closed divide. There are only shades of grey between one end of the spectrum and the other. We should strive for openness as it has several properties which help our society Get Things Done, but at no point should openness overrule getting things done as that's putting the cart before the horse.
Also a lot of people mix up the issue of "binary vs C" with "closed vs open". You can have open source binary drivers, and that's often a convenient thing for end users to have (because the user experience of installing binaries is generally better than that of installing things from source code).
Yes, that's exactly what they do, and people like Greg hate it. In fact Mr Kroah-Hartman has said before that he makes a sport of deliberately sabotaging binary drivers people rely on. He is the worst kind of free software zealot - apparently incapable of thinking in anything other than black and white.
The kernel project is, to put it mildly, a fucking disaster zone when it comes to messaging here. Some developers like Linus say binary modules are OK but he won't go out of his way to help them. Other developers say they're illegal. Still others say "well Linus says it's OK but I disagree, so I reserve the right to sue you for infringing my copyright". And Linus sits by and does nothing to rectify this ridiculous situation.
One asshole (I'll leave you to guess who) decided that by putting functions inline into headers he somehow gained to right to force any USB drivers to be GPLd - apparently he never heard of "clean room re-implementation". He apparently also believes that you don't need to convince people licensing their work under GPL is good through logical reasoning and strong argument, it's enough to try and force peoples hand through dumb sleight of hand. Guess which is more convincing dude! If the GPL is so great, why do you try and force people to use it instead of letting them decide for themselves? Yes Greg, I'm looking at you.
Because of this, I'm 100% not convinced making binary driver developers lives harder changes anything. Are large businesses (the type who make hardware that's difficult to reverse engineer) likely to say, hey, gosh, you know this Greg KH guy kind of doesn't like closed drivers, maybe we should open them up to please him? Nope. They'll just work around the difficulties or not provide drivers at all.
I've been a Wine developer for years and have spent many hours doing this impossible thing of which you speak, and your average copy of MS Word or Steam is a LOT larger than your average driver. Yes, it's hard. No, it's not impossible. I've heard various excuses as to why kernel development is just different!! to userland software development, and don't buy it. Yes, having to reboot when a crash occurs is a royal pain in the ass, but so is not being able to get a backtrace because the game you're investigating treats any attempt at attaching a debugger as an attempt to hax0r its copy protection. Different space, different challenges. It's still possible.
I think pretty much by definition if people have to write long rambling articles "explaining" why it's so much easier to install software on Linux than Windows, it probably isn't.
Sterling engines don't exploit water/surface temperature differences, you're thinking of a different scheme. Sterling engines are a type of solar power based on focussing the suns rays on a central spot.
Of course "search" is pretty broad, it doesn't mean 70% of their people work on PageRank.
Crossover uses a different (nicer, I think) colour scheme which is more reminiscent of Windows XP or 2000.
Take the recent DCOM work we did. This is what I'm going to talk about because it's what I know - myself (CW) and Rob Shearman (CW), along with some help from Marcus Meissner (Novell) and Huw Davies (CW) reimplemented large parts of DCOM mostly for one application. The work took many months - starting from a pre-existing codebase written by Marcus years earlier, we were "finished" ~135 patches later.
What was that one application which was so important?
InstallShield.
Now perhaps you see the problem - sure, not every API is used by every app. But there are hundreds of thousands of APIs, many extremely complex, and many millions of applications. All it takes is ONE popular application to use a single API that was not yet reimplemented and you have months of work ahead of you.
This is especially true of something like DCOM where the supporting infrastructure for 4 or 5 functions can run to 10,000+ lines of code.
I know about the embedded JIT VMs, and I also know about Jazelle. Thanks for assuming I don't know what I'm talking about. I do not care about what is theoretically possible on the latest hardware (assuming manufacturers actually go for the highest performance option and not the cheapest). I'm interested in what European mobile handsets are actually doing, and most still use KVM. Therefore I can and will use that as a point against mobile Java.
Maintainability - nearly all widely deployed Java apps are riddled with #ifdefs done using a custom pre-processor, because phones vary so wildly in bugs and capabilities that you have to produce many JARs from the same source code. Java the language provides zero help with this real world problem.
Porting between what? With Java you write to specifications, not a single implementation. While this can be great when it works, with J2ME it doesn't work. You end up spending your time porting apps between different phones, except instead of obvious API differences the problems are more like "Nokia 6680 uses 40x20 icons whilst SonyEricsson use 16x16 and the exact sizes aren't documented anywhere obvious". OK I forget the exact pixel sizes but you get the idea ...
A series of very cheap phones like the ones you propose are being prepared by major manufacturers for use in the third world. That said, there's a lot of cool stuff you can do with modern mobiles - really we've only started to explore this space. Java gaming is not the best mobile developers can do. Many useful, dare I say .. killer? .. apps can be written that exploit the varied nature of mobile phones. Just wait and see.
Unfortunately the javac compiler doesn't do any optimisation either. So you're left running unoptimised code exactly where you need it most. One of the things I want to experiment with next time I have some spare hours is using GCJ instead of JavaC to produce class files for phones. I suspect there would be an improvement.
It would have been smarter IMHO to embed a static compiler into phones (like GCC) and then use that to produce native ARM/whatever binaries at install time using the full range of optimisations possible. It would take longer to install apps, but this is a one time cost, and you could mostly eliminate the startup overhead of the VM and the speed penalty of bytecode interpreting.
Motorola now use the "JUIX" operating system which is a combination of Linux and Java so while he was definitely wrong, his mistake was simple enough - assuming that technological superiority would win out over mass-market/buzzword appeal.
It's supported by MIDP2, but isn't quite so useful while most GCs do nothing about fragmentation as there's no guarantee free memory over time won't simply drop and drop (unless you are very careful to ensure object sizes tesselate).
Not only are the J2ME specs incredibly loose and full of optional material, but nearly every phone has bugs in their implementations. Apparently Suns engineers have never heard of "conformance tests" - even basic stuff like drawRGB to negative co-ordinates doesn't work right on most phones.
Worse though is Java itself. The Java compiler provided by Sun is an absolute waste of space. It does virtually NO optimisation itself, relying on the JVM to do it all, which is great except the micro-edition "kvm" runtime doesn't do any optimisation either because they didn't have space to make it do more than the very basics. Worse, all the usual flaws it has are still there - an asinine insistence on treating unreachable code as a fatal error, lack of a pre-processor (which you need for mobile development as phones are so different), etc.
Javas runtime performance is atrocious. Only the very newest phones run it anywhere near acceptable speeds if you're doing anything graphics "intensive" (like basic animation). Instead of pre-compiling the code to native at install time, which would seem to be the obvious solution, the KVM still seems to use just-in-time compilation.
The biggest difficulty though tends to be heap fragmentation. Most phones do not use a compacting GC, with the result that it's very easy to make an app that runs fine for a few minutes then barfs because the heap has become fragmented. Java desperately needs manual memory management extensions, stack allocation or the ability to run multiple heaps but instead Sun are simply pushing a micro-edition of HotSpot - apparently waiting for the hardware to catch up so they can cover up what a useless hunk of junk Java is. It's alright for the article to talk about escape analysis - a technique that isn't actually implemented in any shipping desktop or server JVM yet, but how many years would it be until such a basic thing as allocating objects on the stack instead of the heap runs on mobile phones?
There are only two reasons to use Java on mobile phones - the security, and the number of people who know Java. Unfortunately although there is a huge market of (cheap?) Java programmers, people who know Java but not C++ are likely to screw it up because they don't really understand what's going on underneath the hood and so don't understand how to write efficient code.
Actually, I mostly use Linux, but when I have used Gimp on Windows it annoyed me too.
Probably it'd be a threat today if the Windows version supported a containing window (to work around the lack of good WM in Windows) - Photoshop is easy to pirate but there are still lots of people who would happily use a free alterntive rather than pirate a commercial program. I for one haven't used Photoshop in years, as a simple web designer/software developer the combination of the Gimp and Inkscape easily meet my needs. Why would I pay for Photoshop, a program that I'm not familiar with, when the Gimp has every feature that I want already?
Anyway. The point was that people are focussing on "what is the business model for open source" when the real question to ask (thanks to Nat Friedman for this) is "what is the business model for software".
Software isn't like food or water. It's not something we need and die if we don't get. It's a set of tools that make life easier - software is written to solve a problem. Most programmers are already paid to solve specific problems for specific clients. Comparitively few work in the retail software industry.
The "open source trend" if you like is that groups of people who happen to be working on solving the same sorts of problems for their clients co-operate on the tools they use. In the case of Nessus, the "open source trend" would have been that security consultants who know code worked together on an open source scanner adding features as and when they were needed. The mistake (?) Tenable seems have to made is a pretty basic one - their business model was not "solve the problem" ie making clients networks more secure, but rather "sell tools to those solving the problem" which is great unless you give the tools away like they did. The net result is that as they put lots of funding into developing the tools but didn't use those tools themselves. If Nessus is really an indispensable tool used by paid professionals in the network security field (I have no idea) then presumably they'll either decide to pay Tenable for the product or fork it and start work themselves. Which is chosen by the specialists will probably depend on things like how much it costs, how responsive Tenable are, what happens with development etc.
Fundamentally there's no iron law that says people will develop open source tools to solve their problems rather than buy a commercial product, but in some cases this does happen - for instance, many embedded chip vendors choose to extend the GNU toolchain rather than write their own. Why? Because their problem (how do people compile software for my new chip) is easier solved by working with others than going solo.
Because they're trying to claw back the money they spent on wireless licenses for 3G data services. They can't do that unless they make a fat margin on data, so it's very expensive. I'm also annoyed by this: transferring about 1.5mb of data has cost me recently about $22
I'll have to disagree, we don't do anything with /etc/mailcap or Firefox files in autopackage yet our .package file association works just fine. Possibly the version you're using doesn't have the GNOME integration built in.