it could be smart enough to notice that only one block of the file changed, and share the remaining blocks with the old version.
That would then mean that the kernel needs to incorporate much or all of CVS (note that ID3 retagging may shift all the blocks).
And that's something you can only do efficiently with kernel help; if you want userspace libraries doing that kind of thing, you end up reimplementing most of the filesystem innards yourself.
Quite to the contrary: functionality for copy-on-write and for sharing ranges of bytes among files is generally useful. It is bad design to spend so much effort implementing that for versioning and then only make it available for that one complex and questionable function.
Instead, there should be a minimal API for composing files from shared blocks or even shared byte ranges in the kernel, together with support for copy-on-write functionality, but the versioning itself should be provided in user code.
That feature doesn't need to be in the kernel, since it can easily and transparently be provided in user space.
If you like, you can enable this right now using a simple hack on top of PlasticFS or your own, custom LD_PRELOAD hack.
Providing file versioning in the kernel or enabling it globally in some other form has not caught on because it is a huge hassle and causes lots of problems, even in systems that know about it.
For example, when you retag one MP3, do you want to keep an old version? What about if you retag your entire 50G collection of MP3s?
The default of not versioning files in UNIX works better. Versioning and its implementation is highly application and implementation dependent. Emacs, OpenOffice, cvs, and other tools do the right thing, and they do it much better than anything the kernel could ever hope to do.
And what, pray tell, is your definition of an "open source company"? One that owns no intellectual property? Could you give an example?
Defining what is an open source company is hard. But a company whose officials refer to open source software like Linux and Gnome as "open source crap" and that tells programmers "not to worry about licenses" does not qualify as far as I'm concerned. Furthermore, Sun's business interests clearly are not aligned with the overall success of open source: Sun's value proposition is their proprietary software, Solaris and Java.
Sun is using open source software to harm competitors (e.g., with OpenOffice), and sometimes the open source community benefits. But Sun's business model is solidly rooted in proprietary software.
Yeah, so Java ain't GPL'd. Big effin' deal. The specs are freely available to anybody who wants to implement 'em.
No, the Java specs are NOT "freely available to anybody who wants to implement 'em". First of all, many aspects of Java are covered by Sun patents and even if the specs were free and unencumbered, you could still not implement them without infringing on Sun's patents. But I suggest that you actually read the license to which you have to agree when you download many of the Java specs: it explicitly prohibits you from just going off and implementing them; there are very specific conditions and obligations attached to implementing Sun's specs, which are incompatible with open source licenses. That is one of the things that makes Sun such a bad citizen. And it is even worse that they (apparently succesfully, judging by your comments) try to confuse people about it.
If Sun weren't trying to play legal games with the Java specs and patents, then I think they would be acceptable from an open source point of view.
Yeah, they're a publicly-traded company, just like IBM or RedHat. They do what's in the best interest of their stockholders.
Yes, and don't you forget it: that is exactly what makes their interests and the interests of open source developers and open source users different. After all, that is just what Microsoft is doing as well.
Among other things, the FTC recommends that the burden of proof on parties challenging patents in court be lowered from the current 'clear and convincing' standard, to the easier 'preponderance of the evidence' standard.
Given the exceptional nature of patents--extending a government enforced monopoly on ideas and entire markets for decades--one should perhaps even demand that the person defending a patent should provide "clear and convincing evidence" that the patent is valid.
However, just changing the standard to "preponderance of the evidence" sounds like a good change and something that is long overdue.
Sorry, but taking pictures of your company's loading dock and posting them to the web is just stupid. That has nothing to do with Macintosh or anything like that, it has to do with rules against taking pictures at work. Companies are justified in being worried about leaks of proprietary information. People pictures at the company picnic may be tolerated, as may be outside shots of the building, but taking pictures of what gets shipped to or from a company definitely crosses the line.
Sun is using open source to fill in big gaps in their software offerings, but what they sell also has a significant proprietary component. In particular, a lot of the Java-related products are proprietary.
On balance, this is probably still good for open source and open systems. But we have to be wary of Sun: they are not an open source company, and many of their efforts are not in the best interest of the open source community.
Devices such as this are a far cry from a plain vanille desktop PC -- notebooks present similar challenges. Getting power management working is bound to be hassel.
People run Linux on laptops all the time.
The biggest challenge I've faced is handwriting recognition.
Well, if that's the "biggest challenge", then the challenges are indeed not very great. xscribble and Qtopia are both as good (or as bad) as any of the other PDA input solutions.
Nothing in the PDA/Slate form factor beats the Newton there.
By definition, plenty of things "beat" Newton because Newton is a dead product (in addition to a dead physicist). And, frankly, I never cared for the Newton's handwriting input anyway.
The Tiqit actually has a little thumb keyboard and explicitly supports Linux, so it seems like a good choice on all counts.
"It's going to get us away from C-drive computing,"
Gee, people got away from that many years ago, but MSFT just didn't notice.
UNIX and Linux already have a single, unified, global namespace. With mountable WebDAV directories, you can even extend the UNIX/Linux namespace to the web (= simpler, user-mode servers, instead of NFS).
There are lost of ahead-of-time compilers for modern languages which produce programs with large memory footprints. Among them: GCJ. So if the GNU compiler can't work miracles with Java, there's no reason to assume it'll work miracles with C# (+ the runtime and huge class library) either.
A huge memory footprint is an issue with the runtime, not the compiler. Using a batch compiler is necessary to simplify the runtime to the point that executables have a small runtime footprint and start up quickly (having an entire JIT operate at runtime will consume lots of memory), but it is not sufficient by itself. The gcj implementation obviously does not do a good enough job, but that's not the fault of the gcc compiler, it's a problem with the runtime.
There are effective approaches to reducing footprint that have nothing to do with when the bytecode is turned into native code. Tree-shaking is one that worked for Lisp and similar systems. (That does require static ahead-of-time program *analysis*, but that's different.) Sharing VMs for different programs is another.
Tree shaking didn't really work well in practice, and large memory footprints and slow startup times were one of the things that killed Lisp (the other were its bizarre type system and lack of value classes, some of which Java inherits and C# fixes).
The downside is that you may lose some of the dynamic capabilities of the language.
C# still has more limited dynamic capabilities than even Objective C, which can be used to generate executables with a tiny footprint. Language implementors don't need tree shaking or anything like that to get decent performance and memory footprint, they just need to pay attention to memory and performance issues.
Note that there is a whole crop of vaporware hand-size PC's now: Antelope, OQO, Tiquit, Nimble, etc.
However, it is less and less clear why anybody should care about them. A PDA with a 400MHz ARM has sufficient computing power and you can plug in a CF or USB disk drive if you need more storage.
Of course, there is the fact that Windows XP applications aren't sold for ARM, but for Linux, you get a full desktop computing environment out of one of those machines (well, if you blow away the pre-installed PPC or Zaurus PDA software).
As I was saying, read the PolyJ papers and read the design info on C# generics, then come back. They tell you why VM changes are necessary. You yourself pointed out a glaring type loophole: compatibility with the existing collection classes.
Java's generics are a lousy compromise, driven by Sun's fear of breaking backwards compatibility. C# got it right: you have to change the VM and the libraries in order for generics to work right.
Mono supports both JIT compilation, as well as precompilation (mono --aot program will precompile your code), improving startup code significantly.
At issue isn't my code (which is short), at issue is the load times for the libraries. Presumably, whoever built the binary distribution (I'm using AToker's Debian packages) did whatever is best for it. And startup times for Mono GUI apps, while not as slow as Swing, are slower than native apps. Also, the memory footprint (RSS) for gtk-hello-world.exe is 7.3Mbytes, which is a lot for something that only puts up an empty window. JITs have their costs, and native batch compilers really do have their place.
If anything Mono feels *faster* every day, as we improve the JIT engine.
Yes, but at the same time, Mono gets more libraries and people link to more libraries. That's what makes applications start up slower and consume more memory even if the JIT is improving.
You don't know what you are talking about. The JSR 14 generics proposal offers compile-time type-safety while retaining compatibility with old (i.e. not generified) libraries.
No, you don't know what you are talking about. But people can just dig through the specs and papers themselves to find out.
Instead of multidimensional arrays, we got some classes with a horrendous syntax that, on some theoretical JIT, might actually run faster than a snail.
I was referring specifically to Java's multidimensional arrays.
As for Java's speed in general, Sun's Java implementation is currently faster than Microsoft's C# implementation or Mono (Sun has had seven years to hack it, fater all). But Java-the-language has intrinsic limitations that make it dreadfully slow for many applications, among them the lack of multidimensional arrays and the lack of value classes. Try implementing an efficient complex number class in Java, for example.
The government doesn't have the rigth to license cars or drivers, let alone put environmental restrictiosn on them.
Sure "it" does. That's because the government is all of us: government by the people and for the people. Our government is a way by which we agree how to behave towards one another. And you can bet that most people want cars licensed and polluters off the road.
Travel is a FUNDAMENTAL HUMAN RIGHT.
Freedom of movement is not the same as being allowed to drive whatever polluting gas guzzler you like. Travel on foot or by bicycle. Once you start spewing noxious chemicals, other people have a right to stop you.
Much of the good, expensive content is produced by academics. They are usually doing that work as part of their job, so they are already getting paid. And the book deals aren't all that great for them anyway so the financial incentive isn't all that great.
So, no, basically I think your analysis is wrong. In fact, removing the profit motive from book writing might well greatly improve the overall quality of the books we get. How many VisualBasic Brain Surgery for Dummies in a Nutshell do we need?
Java announced Generics months ago. In all, it seems like the java stuff is more exciting, although the lambda-like stuff in C# seems interesting.
Java generics are broken because they don't guarantee type safety across compilation units. That requires VM changes, changes that Microsoft was willing to make but Sun wasn't.
Java is more and more turning into an accumulation of evil kludges. Instead of type-safe generics, we got a hack. Instead of lexical closures, we got nested classes. Instead of structs, we got some half-hearted promise of optimization under some nebulous set of circumstances that can't work in general. Instead of multidimensional arrays, we got some classes with a horrendous syntax that, on some theoretical JIT, might actually run faster than a snail.
I don't know whether C# will grow up into a well-designed general purpose programming language, but it is crystal clear that Java has missed the boat.
Re:moving towards bloatware or are these important
on
C# 2.0 Spec Released
·
· Score: 1
These features are important: generics are needed for type safety, but they are also complicated. Lexical closures are really, really nice.
In short, yes, any modern general purpose programming language needs these features, and Microsoft seems to have done a fairly good job in integrating them.
The language and virtual machine are fully documented,
Yes, too bad that you can't make independent implementations of the language without violating Sun's patents and Sun's licenses on the specification (yes, the Java specification requires a license). (Of course, there are lots of third party Java implementations--Sun has been enforcing their intellectual property only selectively. But that doesn't change the fact that the specification is not open.)
you can download the sources to jdk and libraries,
If you are foolish enough to download and look at the sources to the JDK and the libraries, Sun has you in their pocket: any Java implementation you work on from then on may well be considered a "derivative work".
and is much more open than C$, though less than others open source projects.
That statement is implying that Java is somehow an "open source project". It is not. Java is a highly proprietary platform without even a free specification. And you are able to get the source code to Sun's Java implementation only under a restrictive, non-open source license.
For ECMA C#, the specifications are open and (as far as anybody knows) without any legal restrictions on them. Furthermore, Mono is a fully open source implementation of ECMA C#.
Microsoft.NET may be a proprietary platform, but so is Java. ECMA C# is an open and free language.
Mono is JIT-based. It is starting to suffer from the same problems that Java suffers from: huge memory footprints and slow startup times.
C# is a nice enough language to compile into regular, linkable executables. The resulting executables would not necessarily run faster in terms of raw CPU performance than JIT-based implementations, but they would be much, much better behaved as applications: faster startup times, easier distribution, lower memory footprint.
Re:Why C# doesn't Totally Suck
on
C# 2.0 Spec Released
·
· Score: 2, Interesting
If only it was cross platform from the word go. Mono's nice, but the MSVS IDE is what keeps Microsoft/Windows up and above Linux as far as ease of development goes.
For some people, perhaps. I find the MS development tools so nauseatingly bad that they are one of the main reasons that I don't do anything with Windows.
Fortunately, on Linux you get a choice: excellent command line tools and IDEs. On Windows, unfortunately, you don't: Windows command line tools simply are completely useless.
This is a specification coming out of Microsoft that hasn't gone through a standards body. Do we know whether there are any intellectual property restrictions on implementing the C# 2.0 specifiation?
It is a good sign that this document only has a copyright on it and doesn't require a license agreement to download. In contrast, the Java specifications you can only access under a restrictive license agreement that impose contractual obligations on you that go far beyond patents or copyrights (note to open source developers: don't access Sun's Java specifications--you'll be tainted).
But that still leaves patents for C# 2.0. Do we know whether there are any? ECMA C# (the previous version) appears to be free and clear, but what about this version?
That suggestion seems like typical free marketeer stupidity. Just the administrative costs of keeping track of who has them, how much they record, and what their rates should be is huge.
If blackboxes are a good idea, everybody should have them and they should be standardized and regulated by law. If the public is not willing to accept them generally, then people shouldn't get screwed randomly because their car happens to have them.
This "we will give you a discount if you use them" is an underhanded way to sneak something in that the majority may not want by arranging things so that sooner or later, only the very rich can afford not to have them anymore.
If you aim to develop a GUI app, and it's not already written in Qt, then yes, you'll likely have a big rewrite in front of you. If it's in Qt, it'll likely be an easier change.
That's only a small part of the problem. A bigger part is that I can't even use the development tools I use for everything else.
Note that the Z also comes with Jeode, a Java VM, so it can run mobile Java apps. A definite plus.
Java is also proprietary and also is compatible with nothing else, so that puts you in the same boat as Qt. Furthermore, the mobile Java platform is very limited.
Slashdot Mirror
it could be smart enough to notice that only one block of the file changed, and share the remaining blocks with the old version.
That would then mean that the kernel needs to incorporate much or all of CVS (note that ID3 retagging may shift all the blocks).
And that's something you can only do efficiently with kernel help; if you want userspace libraries doing that kind of thing, you end up reimplementing most of the filesystem innards yourself.
Quite to the contrary: functionality for copy-on-write and for sharing ranges of bytes among files is generally useful. It is bad design to spend so much effort implementing that for versioning and then only make it available for that one complex and questionable function.
Instead, there should be a minimal API for composing files from shared blocks or even shared byte ranges in the kernel, together with support for copy-on-write functionality, but the versioning itself should be provided in user code.
That's one feature from VMS that I wish unix had.
That feature doesn't need to be in the kernel, since it can easily and transparently be provided in user space.
If you like, you can enable this right now using a simple hack on top of PlasticFS or your own, custom LD_PRELOAD hack.
Providing file versioning in the kernel or enabling it globally in some other form has not caught on because it is a huge hassle and causes lots of problems, even in systems that know about it.
For example, when you retag one MP3, do you want to keep an old version? What about if you retag your entire 50G collection of MP3s?
The default of not versioning files in UNIX works better. Versioning and its implementation is highly application and implementation dependent. Emacs, OpenOffice, cvs, and other tools do the right thing, and they do it much better than anything the kernel could ever hope to do.
And what, pray tell, is your definition of an "open source company"? One that owns no intellectual property? Could you give an example?
Defining what is an open source company is hard. But a company whose officials refer to open source software like Linux and Gnome as "open source crap" and that tells programmers "not to worry about licenses" does not qualify as far as I'm concerned. Furthermore, Sun's business interests clearly are not aligned with the overall success of open source: Sun's value proposition is their proprietary software, Solaris and Java.
Sun is using open source software to harm competitors (e.g., with OpenOffice), and sometimes the open source community benefits. But Sun's business model is solidly rooted in proprietary software.
Yeah, so Java ain't GPL'd. Big effin' deal. The specs are freely available to anybody who wants to implement 'em.
No, the Java specs are NOT "freely available to anybody who wants to implement 'em". First of all, many aspects of Java are covered by Sun patents and even if the specs were free and unencumbered, you could still not implement them without infringing on Sun's patents. But I suggest that you actually read the license to which you have to agree when you download many of the Java specs: it explicitly prohibits you from just going off and implementing them; there are very specific conditions and obligations attached to implementing Sun's specs, which are incompatible with open source licenses. That is one of the things that makes Sun such a bad citizen. And it is even worse that they (apparently succesfully, judging by your comments) try to confuse people about it.
If Sun weren't trying to play legal games with the Java specs and patents, then I think they would be acceptable from an open source point of view.
Yeah, they're a publicly-traded company, just like IBM or RedHat. They do what's in the best interest of their stockholders.
Yes, and don't you forget it: that is exactly what makes their interests and the interests of open source developers and open source users different. After all, that is just what Microsoft is doing as well.
Among other things, the FTC recommends that the burden of proof on parties challenging patents in court be lowered from the current 'clear and convincing' standard, to the easier 'preponderance of the evidence' standard.
Given the exceptional nature of patents--extending a government enforced monopoly on ideas and entire markets for decades--one should perhaps even demand that the person defending a patent should provide "clear and convincing evidence" that the patent is valid.
However, just changing the standard to "preponderance of the evidence" sounds like a good change and something that is long overdue.
Sorry, but taking pictures of your company's loading dock and posting them to the web is just stupid. That has nothing to do with Macintosh or anything like that, it has to do with rules against taking pictures at work. Companies are justified in being worried about leaks of proprietary information. People pictures at the company picnic may be tolerated, as may be outside shots of the building, but taking pictures of what gets shipped to or from a company definitely crosses the line.
Sun is using open source to fill in big gaps in their software offerings, but what they sell also has a significant proprietary component. In particular, a lot of the Java-related products are proprietary.
On balance, this is probably still good for open source and open systems. But we have to be wary of Sun: they are not an open source company, and many of their efforts are not in the best interest of the open source community.
Devices such as this are a far cry from a plain vanille desktop PC -- notebooks present similar challenges. Getting power management working is bound to be hassel.
People run Linux on laptops all the time.
The biggest challenge I've faced is handwriting recognition.
Well, if that's the "biggest challenge", then the challenges are indeed not very great. xscribble and Qtopia are both as good (or as bad) as any of the other PDA input solutions.
Nothing in the PDA/Slate form factor beats the Newton there.
By definition, plenty of things "beat" Newton because Newton is a dead product (in addition to a dead physicist). And, frankly, I never cared for the Newton's handwriting input anyway.
The Tiqit actually has a little thumb keyboard and explicitly supports Linux, so it seems like a good choice on all counts.
"It's going to get us away from C-drive computing,"
Gee, people got away from that many years ago, but MSFT just didn't notice.
UNIX and Linux already have a single, unified, global namespace. With mountable WebDAV directories, you can even extend the UNIX/Linux namespace to the web (= simpler, user-mode servers, instead of NFS).
There are lost of ahead-of-time compilers for modern languages which produce programs with large memory footprints. Among them: GCJ. So if the GNU compiler can't work miracles with Java, there's no reason to assume it'll work miracles with C# (+ the runtime and huge class library) either.
A huge memory footprint is an issue with the runtime, not the compiler. Using a batch compiler is necessary to simplify the runtime to the point that executables have a small runtime footprint and start up quickly (having an entire JIT operate at runtime will consume lots of memory), but it is not sufficient by itself. The gcj implementation obviously does not do a good enough job, but that's not the fault of the gcc compiler, it's a problem with the runtime.
There are effective approaches to reducing footprint that have nothing to do with when the bytecode is turned into native code. Tree-shaking is one that worked for Lisp and similar systems. (That does require static ahead-of-time program *analysis*, but that's different.) Sharing VMs for different programs is another.
Tree shaking didn't really work well in practice, and large memory footprints and slow startup times were one of the things that killed Lisp (the other were its bizarre type system and lack of value classes, some of which Java inherits and C# fixes).
The downside is that you may lose some of the dynamic capabilities of the language.
C# still has more limited dynamic capabilities than even Objective C, which can be used to generate executables with a tiny footprint. Language implementors don't need tree shaking or anything like that to get decent performance and memory footprint, they just need to pay attention to memory and performance issues.
Those machines should run Linux just fine.
Note that there is a whole crop of vaporware hand-size PC's now: Antelope, OQO, Tiquit, Nimble, etc.
However, it is less and less clear why anybody should care about them. A PDA with a 400MHz ARM has sufficient computing power and you can plug in a CF or USB disk drive if you need more storage.
Of course, there is the fact that Windows XP applications aren't sold for ARM, but for Linux, you get a full desktop computing environment out of one of those machines (well, if you blow away the pre-installed PPC or Zaurus PDA software).
As I was saying, read the PolyJ papers and read the design info on C# generics, then come back. They tell you why VM changes are necessary. You yourself pointed out a glaring type loophole: compatibility with the existing collection classes.
Java's generics are a lousy compromise, driven by Sun's fear of breaking backwards compatibility. C# got it right: you have to change the VM and the libraries in order for generics to work right.
Mono supports both JIT compilation, as well as precompilation (mono --aot program will precompile your code), improving startup code significantly.
At issue isn't my code (which is short), at issue is the load times for the libraries. Presumably, whoever built the binary distribution (I'm using AToker's Debian packages) did whatever is best for it. And startup times for Mono GUI apps, while not as slow as Swing, are slower than native apps. Also, the memory footprint (RSS) for gtk-hello-world.exe is 7.3Mbytes, which is a lot for something that only puts up an empty window. JITs have their costs, and native batch compilers really do have their place.
If anything Mono feels *faster* every day, as we improve the JIT engine.
Yes, but at the same time, Mono gets more libraries and people link to more libraries. That's what makes applications start up slower and consume more memory even if the JIT is improving.
It seems you have not bothered to even use Mono,
It seems you presume a little too much.
You don't know what you are talking about. The JSR 14 generics proposal offers compile-time type-safety while retaining compatibility with old (i.e. not generified) libraries.
No, you don't know what you are talking about. But people can just dig through the specs and papers themselves to find out.
I was referring specifically to Java's multidimensional arrays.
As for Java's speed in general, Sun's Java implementation is currently faster than Microsoft's C# implementation or Mono (Sun has had seven years to hack it, fater all). But Java-the-language has intrinsic limitations that make it dreadfully slow for many applications, among them the lack of multidimensional arrays and the lack of value classes. Try implementing an efficient complex number class in Java, for example.
The government doesn't have the rigth to license cars or drivers, let alone put environmental restrictiosn on them.
Sure "it" does. That's because the government is all of us: government by the people and for the people. Our government is a way by which we agree how to behave towards one another. And you can bet that most people want cars licensed and polluters off the road.
Travel is a FUNDAMENTAL HUMAN RIGHT.
Freedom of movement is not the same as being allowed to drive whatever polluting gas guzzler you like. Travel on foot or by bicycle. Once you start spewing noxious chemicals, other people have a right to stop you.
Much of the good, expensive content is produced by academics. They are usually doing that work as part of their job, so they are already getting paid. And the book deals aren't all that great for them anyway so the financial incentive isn't all that great.
So, no, basically I think your analysis is wrong. In fact, removing the profit motive from book writing might well greatly improve the overall quality of the books we get. How many VisualBasic Brain Surgery for Dummies in a Nutshell do we need?
Java announced Generics months ago. In all, it seems like the java stuff is more exciting, although the lambda-like stuff in C# seems interesting.
Java generics are broken because they don't guarantee type safety across compilation units. That requires VM changes, changes that Microsoft was willing to make but Sun wasn't.
Java is more and more turning into an accumulation of evil kludges. Instead of type-safe generics, we got a hack. Instead of lexical closures, we got nested classes. Instead of structs, we got some half-hearted promise of optimization under some nebulous set of circumstances that can't work in general. Instead of multidimensional arrays, we got some classes with a horrendous syntax that, on some theoretical JIT, might actually run faster than a snail.
I don't know whether C# will grow up into a well-designed general purpose programming language, but it is crystal clear that Java has missed the boat.
These features are important: generics are needed for type safety, but they are also complicated. Lexical closures are really, really nice.
In short, yes, any modern general purpose programming language needs these features, and Microsoft seems to have done a fairly good job in integrating them.
The language and virtual machine are fully documented,
.NET may be a proprietary platform, but so is Java. ECMA C# is an open and free language.
Yes, too bad that you can't make independent implementations of the language without violating Sun's patents and Sun's licenses on the specification (yes, the Java specification requires a license). (Of course, there are lots of third party Java implementations--Sun has been enforcing their intellectual property only selectively. But that doesn't change the fact that the specification is not open.)
you can download the sources to jdk and libraries,
If you are foolish enough to download and look at the sources to the JDK and the libraries, Sun has you in their pocket: any Java implementation you work on from then on may well be considered a "derivative work".
and is much more open than C$, though less than others open source projects.
That statement is implying that Java is somehow an "open source project". It is not. Java is a highly proprietary platform without even a free specification. And you are able to get the source code to Sun's Java implementation only under a restrictive, non-open source license.
For ECMA C#, the specifications are open and (as far as anybody knows) without any legal restrictions on them. Furthermore, Mono is a fully open source implementation of ECMA C#.
Microsoft
Mono is JIT-based. It is starting to suffer from the same problems that Java suffers from: huge memory footprints and slow startup times.
C# is a nice enough language to compile into regular, linkable executables. The resulting executables would not necessarily run faster in terms of raw CPU performance than JIT-based implementations, but they would be much, much better behaved as applications: faster startup times, easier distribution, lower memory footprint.
If only it was cross platform from the word go. Mono's nice, but the MSVS IDE is what keeps Microsoft/Windows up and above Linux as far as ease of development goes.
For some people, perhaps. I find the MS development tools so nauseatingly bad that they are one of the main reasons that I don't do anything with Windows.
Fortunately, on Linux you get a choice: excellent command line tools and IDEs. On Windows, unfortunately, you don't: Windows command line tools simply are completely useless.
This is a specification coming out of Microsoft that hasn't gone through a standards body. Do we know whether there are any intellectual property restrictions on implementing the C# 2.0 specifiation?
It is a good sign that this document only has a copyright on it and doesn't require a license agreement to download. In contrast, the Java specifications you can only access under a restrictive license agreement that impose contractual obligations on you that go far beyond patents or copyrights (note to open source developers: don't access Sun's Java specifications--you'll be tainted).
But that still leaves patents for C# 2.0. Do we know whether there are any? ECMA C# (the previous version) appears to be free and clear, but what about this version?
enough said
That suggestion seems like typical free marketeer stupidity. Just the administrative costs of keeping track of who has them, how much they record, and what their rates should be is huge.
If blackboxes are a good idea, everybody should have them and they should be standardized and regulated by law. If the public is not willing to accept them generally, then people shouldn't get screwed randomly because their car happens to have them.
This "we will give you a discount if you use them" is an underhanded way to sneak something in that the majority may not want by arranging things so that sooner or later, only the very rich can afford not to have them anymore.
If you aim to develop a GUI app, and it's not already written in Qt, then yes, you'll likely have a big rewrite in front of you. If it's in Qt, it'll likely be an easier change.
That's only a small part of the problem. A bigger part is that I can't even use the development tools I use for everything else.
Note that the Z also comes with Jeode, a Java VM, so it can run mobile Java apps. A definite plus.
Java is also proprietary and also is compatible with nothing else, so that puts you in the same boat as Qt. Furthermore, the mobile Java platform is very limited.