I can concede to all your points about whether Java defines bounds checking or not, just for the sake of the argument. The fact of the matter is that it is possible to implement bounds checking in C, just that most (all?) current C implementations don't, for the sake of performance and being close to the hardware, and not least to preserve compatibility with current ABIs.
The C standard defines that out-of-bounds accesses of arrays/objects invoke "undefined behavior". As I said earlier, it is neither theoretically nor practically impossible to define that generally undefined behavior as process-terminating in a certain C implementation. Most C implementors would rather leave that to the hardware, however. (Just as most Java implementors leave it to the virtual hardware)
I see this as A Good Thing (TM), since once again, C offers choice where Java offers restriction -- if you want bounds checking, choose a C compiler that does that.
No; "IOException in blah:..." isn't an error message, it's a crash dump. It tells the end-user nothing about what's wrong. The end-user doesn't want internal crap when a file is missing.
To be honest, I don't really see any large difference between a crash dump and a fatal error message. They both serve the purpose of stating the reason for abnormal program termination before it happens. I'm not saying that all exceptions should be handled that way -- only the unexpected ones (which could, for example, be a FileNotFoundException and would most probably include IOExceptions). The only difference I can see is that a crash dump prints debugging data, while a fatal error message only prints the actual error.
In other words, the difference is that a fatal error message, which you seem to want, is more concise, and in that case, like I said earlier, the fault is with Java for having a top-level exception handler that prints the entire stack trace instead of a more concise message, such as stating the name of the exception and its associated error message. If one wants the stack trace, one could run the JVM with a --debug option.
In fact, it could even be said that this is the job of the actual application programmer. However, in that case, one should still be allowed not to catch exceptions directly where a method is called, but rather let them propagate back up the stack to the main method and let it handle exception printing.
Another point that I've made previously is that, even regardlessly of my above statements, this is the task of compiler warnings, rather than terminating compilation. If one really wants to compile a program like javac does now, one should run the compiler with -Wall -Werror or similarly (which company coding standards could require). In other cases, one could not do that.
If you want a quick and dirty language to write your small utility programs in, use perl.
I agree that one should use a language more suited to the purpose at hand. However, who says that some Q&D programs aren't most suited to be written in Java? Even regardlessly of their architecture, it might be that one wants/needs to use a utility library only available in Java.
Not every programming language in the world needs to support Q&D programs at the cost of the people who have to use programs without knowing all the internal details.
First of all, one does not need to support Q&D programs when creating a language. Surely, you can see that it takes more work to implement the forcing of exception handler directly after the method call, both for the JVM developers and the javac developers (and for the application programmers using Java)?
Second, why would not forcing immediate exception handling somehow "cost" the people who have to use program without knowing all the internal details anything? One does not need a language that forces immediate exception handlers in order to handle exceptions immediately. Did I mention compiler warnings?
You kids and your 486DX/33. Surely, you've got more than a megabyte of RAM in there as well. Back in my day, we welded wires and relays ourselves, only to get a 2 Hz processor with, if you were lucky, 32 words of primary memory. And yes, we had mine ore ourselves to cast the wires and relays.
These are valid ways to make a living, but they'll never be as lucrative as Microsoft's business model. Namely, to write the software once, sell it over and over, and sell the extras separately.
Likewise, the leader of a free country will never be as rich or powerful as a dictator.
another point to consider: if people want to get proprietary software (or music for that matter) without paying for it (if it's against the license). They should consider using something else.
Of course it's not right to get proprietary software/music/movies without paying for it. However, that doesn't mean that it's the same thing as taking GPL'd software and closing it.
Taking proprietary IP and opening it up is harmful for few (the copyright holder(s)) and useful for many (the general public), while taking free IP and closing it is harmful for many (the general public and the copyright holder(s)) and useful for few (only the ones who close it). The GPL is designed to prevent that from happening.
Like I said, that doesn't mean that it's right to open up proprietary software. Nevertheless, one shan't say that there's no difference.
Bounds checking in Java is defined in the standards document independent of the JVM, just like in Ada and other portable languages that do bounds checking.
Whether the Java standards docs or the JVM standards docs define this (of course, they both do) is fairly irrelevant, since they are both designed for each other.
The fact of the matter is that when you compile Java code for its canonical platform -- the JVM -- array bounds checking is not implemented in the compiled code, but rather in the JVM (the "physical platform").
That's the difference I make. Neither C nor Java does bounds checking in the compiled code (except when using ahead-of-time Java compilers like gcj, but I would argue that that is primarily because they have to emulate the JVM properly -- compiling ahead-of-time is the exception rather than the rule when it comes to Java). ADA or BASIC or whatever you will does bounds checking in the compiled code, because they know that the platform they are compiled for doesn't support it and decide to patch of for its deficiencies.
Compiled Java code depends on the platform to do bounds checking, and so does compiled C code. The difference is that the Java platform (or its emulator) actually does bounds checking, while most popular physical CPUs, that compiled C code runs on, do not.
I know that the difference in semantics is small. However, my point is that there is nothing in C that prevents the platform to do bounds checking -- it's just that most platforms don't. In other words, it's a lack of security at the platform level, not at the language level.
If I do "cat foo", I expect a message like "foo: file not found", not "IOException in blah: blah.java line 59, called from..."
So your real complaint is that you get too verbose error messages? In that case, that's a fault in the default Java bottom-level exception handler. It could well print a short-hand error printout instead of a full stack trace whenever a "--debug" option or similar is not given to the JVM. What LISP programmer would catch exceptions in every single defun only to generate less verbose errors?
The advantage of having exception handling in a language is largely (although admittedly not only) for the programmer's convenience -- he/she does not have to explicitly check for errors at every function return, but can just expect his/her program to terminate on unexpected conditions (a.k.a. exceptions) rather than continuing with undefined behavior. With Java's forced exception checks, that advantage is negated.
You could argue that it is for security rather than convenience, but in that case, as I said before -- that's would warnings are for. Company standards could more than well force you to compiled all your code with -Wall -Werror or similar, while I could ignore that for my own programs.
Also, regardlessly of what kind of errors you happen to expect, what about when I write a small utility program that only I will ever use? Why should I then be forced to catch exceptions just to generate more concise errors for myself to see?
foo can't tell the difference between an array getting passed in and a pointer to anything.
So? foo doesn't have to care, since the bounds checking should be done in hardware (as it is in the JVM). In fact, foo cares just as much as any given Java implementation of foo would care. The hardware should know the limits of the array that the pointer points to.
A pointer in C does not have to be a single integer to a large linear address space. It can just as well be implemented as an "object/array identifier" paired with an offset into that object/array. On IA32, that would be equivalent to storing a pointer as both the selector and the address into that select (although that would, of course, not be perfect either, since one can still load arbitrary selectors on IA32)
No, when Java is compiled natively, it does bounds checking.
Of course -- because the JVM does it. When you recompile code for one hardware platform to another, then naturally you have to account for the idiosyncrasies of the original platform. Java is able to define arrays in the way it does because of their representation on Java's native platform (the JVM).
It's a silly idea that a program should crash because the file isn't there. In a non-trivial program, you would never want the program to end without an appropriate error message just because a file wasn't there.
It's far from a silly idea. What if I write a Java replacement for UNIX cat or some other similar small utility program? Whyever would I want it to survive an IOException or a FileNotFoundException?
To take another, similar example, why would I want to check for an InterruptedException in a thread that I know will never be interrupted?
Nonsense. Arrays and pointers are defined as being equivalent in many ways in the ISO C standard. But
is valid C code anywhere. It is practically impossible for a compiler to do proper bounds checking for C, because of this, and this is true on every system.
What would be so strange about that code? The "= 0" is valid only because 0 and NULL is defined as equivalent, and null values are permitted in Java as well. The array could be allocated as a native object of 42 chars by a hardware platform capable of doing so. For example, it could even be done on an i386 by allocating a descriptor with an upper limit of 42 bytes -- the reason why it is impractical on i386 is primarily because it's impossible to allocate more than 8192 descriptors to one process, and of course because arbitrary descript loading isn't prohibited by the processor. I do, however, not understand what about that code makes it so "impossible" to do bounds checking.
But you have the option of native compilers and JVM compilers.
So?
x86 ELF files aren't portable between OSes, and no matter the theoretical portability, and the practical existance of emulators for certain OSes running x86 ELF files, most people don't have them installed. As a practical thing, you can take a bytecode compiled Java file and run it on many people's systems. Whether or not it's being emulated isn't an interesting question; whether or not it will run is.
Precisely my point. It's not a qualitative property of Java itself that makes it "portable", but rather the availability of emulators for the JVM.
The reason for these is that Java is designed to be able to be run on minimal systems, and potentially insecure networks. Java code can be streamed across networks (e.g. as applets) and the integrity of that code can be verified. This is extremely useful for things like networked devices and embedded systems.
You can stream LISP forms as well, and the reader won't read them unless they are correct. That seems to achieve about the same goal. My point, however, is this: One should not have to verify the integrity of the code to ensure stability. The underlying system should be stable regardlessly of the integrity of the code running on it.
Yes, but none were mainstream, and widely used in almost all areas of IT.
How does a language's popularity count as a merit for the language itself? By that argument, before there was Java, C was used almost everywhere in IT, and although it was this popular (which obviously is supposed to be a merit in itself), people like you still argue against it.
It allows higher performance. You can have byte code that has already been put through various optimisation, so it can be started immediately and then background optimisation and translation to native code can occur. As for ASCII format - that would require compilation at the point of deployment. This takes time and takes a lot of memory - very bad for getting programs started quickly, and would rule out any serious use in embedded systems, such as mobile phones.
So how about languages like LISP, Ruby or Perl? All of these have interpreters that take up less memory than the JRE, and compile their sources in no time, yet are (arguably) as fast as Java. In the recent Slashdot article about Ruby 2.0 being released soon, there seemed to be a lot of argument about which was faster -- Ruby or Java -- so that issue seems less than settled. Let's just say that all those three start running virtually immediately on my computer for sure, while the JVM takes more than a second to start running a program. They also take a fraction of the memory that the JVM requires. Admittedly, I haven't been able to measure the performance statistics of a J2ME JVM, but considering how long it takes to start a MIDlet on my Symbian, it doesn't seem to be that much better than the J2SE JVM running on my desktop computer. Also, none of these languages actively prevent the use of a JIT compiler, and at least LISP can be compiled to an intermediate binary form if you'd really want to.
Because they don't serve the same purpose syntactically. It is far more than just 'synchronised' - there is a lot of detail specified about how threads should behave and which actions are atomic etc. that all Java implementations must conform to.
Admittedly, C does not specify this. However, as long as you limit yourself to programming for the same architectures that Java runs on, I'd say the operations that are atomic in C are as well defined as in Java, etc.
I know this probably sounds cynical, but I do. After decades of development experience, I find that being forced to do things like exception handling had a major benefit in the quality of code; after all, we are all fallible.
So how about the times when I really don't care about whether there comes an IOException while opening a file? I may well want that exception to propagate to the end of the stack and terminate the program. But no -- according to javac I must catch it, and then arrange for some other way to terminate the program.
Either way, these things are what compiler warnings are for. It's precisely the purpose of the -Wall -Werror options to gcc -- company standards could require you to compile with these options, and yet I can ignore it when just writing some small utility program for myself.
While (1) torture is certainly a bad thing and (2) China may well be considered a thread to the US, I don't really see how torture in China is a threat to the US.
(1) It is probably the first really mainstream general-purpose widely-used language with garbage collection.
It is my impression that LISP was fairly mainstream and widely used back in the day. Admittedly, that was probably before programming itself was mainstream.
(2) It was specifically designed for safety at the start, with things like exception handling, bytecode validation and security managers.
Strange. I was certain that LISP has exception handling too. As for bytecode validation, that seriously shouldn't even be necessary, and LISP makes up more than well for it with its actual structured. As for security managers, since when was security the job of the programming language rather than the operating system?
(3) It is the first mainstream language to run mostly on a VM, so you get portability not just at the source code level, but at the level of compiled programs.
(1) So how is that better than emulating an x86?
(2) There were tons of interpreted languages before Java. As for portability of compiled programs rather than source code portability -- how is that better than JIT compiling or an ordinary LISP REPL? How is it better to use a binary format rather than an ASCII readable format (such as source code)?
(4) It was designed from the start to handle multiple threads safely.
What, you mean the `synchronized' keyword? How is it better to use a new keyword instead of just a function?
Java is not a language of clever tricks and obscure code, like C++ can be.
My point exactly. C(++) can be a language of clever tricks and obscure code. It doesn't necessarily have to be, however, and usually it isn't. It's both possible and common to write clean C code. However, C (and arguably C++) allow you to use clever tricks and obscure code if you want to and know what you're doing. In Java, you cannot do that even if you wanted to. I don't really see less choice being better.
However, it is a very practical language that has learned from many of the mistakes of earlier designs.
Those words would carry a lot more weight if you had included an example of such a mistake. If you were thinking about C++, then I fully agree with you, whatever example you may have been thinking of. C++ is the most abysmal excuse for a language I have ever seen.
If you have been developing for decades like me, switching to Java and finding the ability to write a program, compile it and then decide where it should be deployed (and have this work almost perfectly most of the time) is pretty amazing.
Except for the "compile it" part, I do that every day with open source C programs, and I don't see what makes it so very much greater to just copy a jarball rather than copy and compile a tarball.
While I'm in this mood, let me crush another myth about Java vs. C, namely the "Java is more secure than C since you can't access arbitrary addresses and Java makes array bounds checks" myth. In this case, it is important to seperate the language and the architecture on which the programs run. It is not the Java language that does these things, but rather the JVM. C is quite capable of those things as well -- unfortunately, most (all?) major physical CPU architectures don't support them. Therefore, don't blame C for that -- blame IA32, Sparc, PPC, etc.
Yet another one? Well, since you asked: The "Java is more portable and runs on all architectures" myth. In fact, Java is the least portable language I have ever seen. It only runs on one single architecture: The JVM. It just so happens that there is a JVM emulator for most major physical CPU architectures. Would you say the same about C if there were an IA32 emulator for mostly any platform? Most likely not -- It's just that Sun has marketed Java this way.
However, in the page linked from the previous post here on Slashdot about Firefox nearing 50,000,000, it said that the counter does not count direct downloads. It only counts those which come from the web bouncer, so Gentoo downloads still don't count.
You mean like Ghostscript, gv, ggv, gpdf, xpdf (is there a kpdf?), et al.?
On a more serious note, you don't need a new format to introduce a competitor. Even though I certainly agree that Adobe's Acroreader is more than well bloated, the PDF format itself isn't flawed.
And printing to an XML page description format that I can quickly parse?
Could you tell me how you were planning to parse XML faster than you can parse a linear token-based format like PDF? I'd certainly be interested in what parser that would be.
Say what you will of BitKeeper. I'm sure it was very convenient and powerful and who knows what. I'm sure Linus had good reasons for using it.
However, a thing like this wouldn't have happened with Free Software. By that, I don't just mean something like the free software attitude would have prevented it or anything -- this would actually have been impossible if BitKeeper had been free software.
This is, of course, because even if McVoy had been the only developer and he decided to move to a non-free license for a new version for whatever reason, someone would just have had to fork it. Therefore, things like this cannot happen with free software.
The same, of course, goes with all proprietary software. Now, I don't believe that Microsoft will go out of business anytime soon (no matter how much I'd want it to), but imagine if it did! Suddenly, Windows would be completely unsupported and would never be developed further. Smaller companies can probably go bankrupt for lesser things than that. With GNU/Linux, that literally cannot happen. Someone will always go on working on it, and even if noone does voluntarily, you can always hire someone to do so.
It sounds very different to me. DRM is not implemented on the disks themselves. Rather, it is enforced that DVD player/decoder manufacturers are required to implement the DRM schemes.
CD copy protection, OTOH, is implemented on the disk itself, by using non-standard on-disk formats that common computer CD drives aren't capable of reading, while common audio CD players are.
Thus, IANAL but I would believe that the difference is that the CD disk manufacturers can do whatever they want with their disks (as long as the customers are kept informed), while the DVD SIGs aren't allowed to force the player manufacturers to do what they want.
What I don't understand is why Microsoft was supporting that bill to begin with. Not that I'm against homosexual marriage (rather, I'm against any limitation of freedom, and not allowing homosexual marriage is certainly such a limitation), but what does that have with software to do?
Microsoft is a software company. Software and homosexual marriage are completely unrelated. End of story. Right?
In that, I think it was completely right by Microsoft to take a neutral stance in this issue. It doesn't matter if every single employee actually supported this bill -- in that case, they can support it personally, not by representation from a company dealing with completely unrelated things.
This isn't subject to DMCA. DMCA allows reverse engineering for interoperability. No developers, commercial or not, need Nikon's permission to reverse this legally in the US.
While reverse-engineering is allowed by DMCA, decryption is not. The DMCA specifically disallows any kind of non-allowed (by the original inventor) decryption. That is one of the primary issues about the DVD CSS encryption.
TFA:
I use 3 hard drives in every one of my 20 servers, 2 running as a RAID-1 and the third as a spare in case the raid goes down.
Correct me if I'm wrong now, but isn't a spare drive completely unnecessary with RAID 1? With RAID 1, you can just have all your drives in the array, always, and the controller won't have to copy the data to the spare if an active drive goes down.
AFAIK, one uses spares with RAID 5 or similar solutions. When using RAID 5, one would have a spare to take over if an active drive goes down -- if it was active before it would expand the size of the array and would have data on its own on it, and thus couldn't take over for another drive.
I realize that RAID 1 with a spare may yield slightly better nominal write performance if in a software RAID array. OTOH, three drives would also yield better nominal read performance than just 2 drives and a spare. And, it wouldn't matter at all with hardware accelerated RAID.
So my point is: Is it just me, or is this guy going all wrong about his RAID? I just want to verify my thoughts, if someone would spar with me.
Slashdot Mirror
The C standard defines that out-of-bounds accesses of arrays/objects invoke "undefined behavior". As I said earlier, it is neither theoretically nor practically impossible to define that generally undefined behavior as process-terminating in a certain C implementation. Most C implementors would rather leave that to the hardware, however. (Just as most Java implementors leave it to the virtual hardware)
I see this as A Good Thing (TM), since once again, C offers choice where Java offers restriction -- if you want bounds checking, choose a C compiler that does that.
To be honest, I don't really see any large difference between a crash dump and a fatal error message. They both serve the purpose of stating the reason for abnormal program termination before it happens. I'm not saying that all exceptions should be handled that way -- only the unexpected ones (which could, for example, be a FileNotFoundException and would most probably include IOExceptions). The only difference I can see is that a crash dump prints debugging data, while a fatal error message only prints the actual error.In other words, the difference is that a fatal error message, which you seem to want, is more concise, and in that case, like I said earlier, the fault is with Java for having a top-level exception handler that prints the entire stack trace instead of a more concise message, such as stating the name of the exception and its associated error message. If one wants the stack trace, one could run the JVM with a --debug option.
In fact, it could even be said that this is the job of the actual application programmer. However, in that case, one should still be allowed not to catch exceptions directly where a method is called, but rather let them propagate back up the stack to the main method and let it handle exception printing.
Another point that I've made previously is that, even regardlessly of my above statements, this is the task of compiler warnings, rather than terminating compilation. If one really wants to compile a program like javac does now, one should run the compiler with -Wall -Werror or similarly (which company coding standards could require). In other cases, one could not do that.
I agree that one should use a language more suited to the purpose at hand. However, who says that some Q&D programs aren't most suited to be written in Java? Even regardlessly of their architecture, it might be that one wants/needs to use a utility library only available in Java. First of all, one does not need to support Q&D programs when creating a language. Surely, you can see that it takes more work to implement the forcing of exception handler directly after the method call, both for the JVM developers and the javac developers (and for the application programmers using Java)?Second, why would not forcing immediate exception handling somehow "cost" the people who have to use program without knowing all the internal details anything? One does not need a language that forces immediate exception handlers in order to handle exceptions immediately. Did I mention compiler warnings?
Sheesh.
And still you post at Slashdot? ;-)
In other news, Duke Nukem Forever just went gold.
So you never noticed "anology"? ;-)
Taking proprietary IP and opening it up is harmful for few (the copyright holder(s)) and useful for many (the general public), while taking free IP and closing it is harmful for many (the general public and the copyright holder(s)) and useful for few (only the ones who close it). The GPL is designed to prevent that from happening.
Like I said, that doesn't mean that it's right to open up proprietary software. Nevertheless, one shan't say that there's no difference.
Whether the Java standards docs or the JVM standards docs define this (of course, they both do) is fairly irrelevant, since they are both designed for each other.
The fact of the matter is that when you compile Java code for its canonical platform -- the JVM -- array bounds checking is not implemented in the compiled code, but rather in the JVM (the "physical platform").
That's the difference I make. Neither C nor Java does bounds checking in the compiled code (except when using ahead-of-time Java compilers like gcj, but I would argue that that is primarily because they have to emulate the JVM properly -- compiling ahead-of-time is the exception rather than the rule when it comes to Java). ADA or BASIC or whatever you will does bounds checking in the compiled code, because they know that the platform they are compiled for doesn't support it and decide to patch of for its deficiencies.
Compiled Java code depends on the platform to do bounds checking, and so does compiled C code. The difference is that the Java platform (or its emulator) actually does bounds checking, while most popular physical CPUs, that compiled C code runs on, do not.
I know that the difference in semantics is small. However, my point is that there is nothing in C that prevents the platform to do bounds checking -- it's just that most platforms don't. In other words, it's a lack of security at the platform level, not at the language level.
So your real complaint is that you get too verbose error messages? In that case, that's a fault in the default Java bottom-level exception handler. It could well print a short-hand error printout instead of a full stack trace whenever a "--debug" option or similar is not given to the JVM. What LISP programmer would catch exceptions in every single defun only to generate less verbose errors?
The advantage of having exception handling in a language is largely (although admittedly not only) for the programmer's convenience -- he/she does not have to explicitly check for errors at every function return, but can just expect his/her program to terminate on unexpected conditions (a.k.a. exceptions) rather than continuing with undefined behavior. With Java's forced exception checks, that advantage is negated.
You could argue that it is for security rather than convenience, but in that case, as I said before -- that's would warnings are for. Company standards could more than well force you to compiled all your code with -Wall -Werror or similar, while I could ignore that for my own programs.
Also, regardlessly of what kind of errors you happen to expect, what about when I write a small utility program that only I will ever use? Why should I then be forced to catch exceptions just to generate more concise errors for myself to see?
So? foo doesn't have to care, since the bounds checking should be done in hardware (as it is in the JVM). In fact, foo cares just as much as any given Java implementation of foo would care. The hardware should know the limits of the array that the pointer points to.
A pointer in C does not have to be a single integer to a large linear address space. It can just as well be implemented as an "object/array identifier" paired with an offset into that object/array. On IA32, that would be equivalent to storing a pointer as both the selector and the address into that select (although that would, of course, not be perfect either, since one can still load arbitrary selectors on IA32)
To take another, similar example, why would I want to check for an InterruptedException in a thread that I know will never be interrupted?
What would be so strange about that code? The "= 0" is valid only because 0 and NULL is defined as equivalent, and null values are permitted in Java as well. The array could be allocated as a native object of 42 chars by a hardware platform capable of doing so. For example, it could even be done on an i386 by allocating a descriptor with an upper limit of 42 bytes -- the reason why it is impractical on i386 is primarily because it's impossible to allocate more than 8192 descriptors to one process, and of course because arbitrary descript loading isn't prohibited by the processor. I do, however, not understand what about that code makes it so "impossible" to do bounds checking. So? Precisely my point. It's not a qualitative property of Java itself that makes it "portable", but rather the availability of emulators for the JVM.You can stream LISP forms as well, and the reader won't read them unless they are correct. That seems to achieve about the same goal. My point, however, is this: One should not have to verify the integrity of the code to ensure stability. The underlying system should be stable regardlessly of the integrity of the code running on it.
How does a language's popularity count as a merit for the language itself? By that argument, before there was Java, C was used almost everywhere in IT, and although it was this popular (which obviously is supposed to be a merit in itself), people like you still argue against it.
So how about languages like LISP, Ruby or Perl? All of these have interpreters that take up less memory than the JRE, and compile their sources in no time, yet are (arguably) as fast as Java. In the recent Slashdot article about Ruby 2.0 being released soon, there seemed to be a lot of argument about which was faster -- Ruby or Java -- so that issue seems less than settled. Let's just say that all those three start running virtually immediately on my computer for sure, while the JVM takes more than a second to start running a program. They also take a fraction of the memory that the JVM requires. Admittedly, I haven't been able to measure the performance statistics of a J2ME JVM, but considering how long it takes to start a MIDlet on my Symbian, it doesn't seem to be that much better than the J2SE JVM running on my desktop computer. Also, none of these languages actively prevent the use of a JIT compiler, and at least LISP can be compiled to an intermediate binary form if you'd really want to.
Admittedly, C does not specify this. However, as long as you limit yourself to programming for the same architectures that Java runs on, I'd say the operations that are atomic in C are as well defined as in Java, etc.
So how about the times when I really don't care about whether there comes an IOException while opening a file? I may well want that exception to propagate to the end of the stack and terminate the program. But no -- according to javac I must catch it, and then arrange for some other way to terminate the program.
Either way, these things are what compiler warnings are for. It's precisely the purpose of the -Wall -Werror options to gcc -- company standards could require you to compile with these options, and yet I can ignore it when just writing some small utility program for myself.
Maybe that's just me...
(2) There were tons of interpreted languages before Java. As for portability of compiled programs rather than source code portability -- how is that better than JIT compiling or an ordinary LISP REPL? How is it better to use a binary format rather than an ASCII readable format (such as source code)? What, you mean the `synchronized' keyword? How is it better to use a new keyword instead of just a function? My point exactly. C(++) can be a language of clever tricks and obscure code. It doesn't necessarily have to be, however, and usually it isn't. It's both possible and common to write clean C code. However, C (and arguably C++) allow you to use clever tricks and obscure code if you want to and know what you're doing. In Java, you cannot do that even if you wanted to. I don't really see less choice being better. Those words would carry a lot more weight if you had included an example of such a mistake. If you were thinking about C++, then I fully agree with you, whatever example you may have been thinking of. C++ is the most abysmal excuse for a language I have ever seen. Except for the "compile it" part, I do that every day with open source C programs, and I don't see what makes it so very much greater to just copy a jarball rather than copy and compile a tarball.
While I'm in this mood, let me crush another myth about Java vs. C, namely the "Java is more secure than C since you can't access arbitrary addresses and Java makes array bounds checks" myth. In this case, it is important to seperate the language and the architecture on which the programs run. It is not the Java language that does these things, but rather the JVM. C is quite capable of those things as well -- unfortunately, most (all?) major physical CPU architectures don't support them. Therefore, don't blame C for that -- blame IA32, Sparc, PPC, etc.
Yet another one? Well, since you asked: The "Java is more portable and runs on all architectures" myth. In fact, Java is the least portable language I have ever seen. It only runs on one single architecture: The JVM. It just so happens that there is a JVM emulator for most major physical CPU architectures. Would you say the same about C if there were an IA32 emulator for mostly any platform? Most likely not -- It's just that Sun has marketed Java this way.
However, in the page linked from the previous post here on Slashdot about Firefox nearing 50,000,000, it said that the counter does not count direct downloads. It only counts those which come from the web bouncer, so Gentoo downloads still don't count.
"Microsoft Tigger - No more crashes" -- It does sound precisely like the Windows Installer, doesn't it?
On a more serious note, you don't need a new format to introduce a competitor. Even though I certainly agree that Adobe's Acroreader is more than well bloated, the PDF format itself isn't flawed.
Could you tell me how you were planning to parse XML faster than you can parse a linear token-based format like PDF? I'd certainly be interested in what parser that would be.Warning: A HumorNotFound exception has occurred. Please correct problem between monitor and chair.
However, a thing like this wouldn't have happened with Free Software. By that, I don't just mean something like the free software attitude would have prevented it or anything -- this would actually have been impossible if BitKeeper had been free software.
This is, of course, because even if McVoy had been the only developer and he decided to move to a non-free license for a new version for whatever reason, someone would just have had to fork it. Therefore, things like this cannot happen with free software.
The same, of course, goes with all proprietary software. Now, I don't believe that Microsoft will go out of business anytime soon (no matter how much I'd want it to), but imagine if it did! Suddenly, Windows would be completely unsupported and would never be developed further. Smaller companies can probably go bankrupt for lesser things than that. With GNU/Linux, that literally cannot happen. Someone will always go on working on it, and even if noone does voluntarily, you can always hire someone to do so.
CD copy protection, OTOH, is implemented on the disk itself, by using non-standard on-disk formats that common computer CD drives aren't capable of reading, while common audio CD players are.
Thus, IANAL but I would believe that the difference is that the CD disk manufacturers can do whatever they want with their disks (as long as the customers are kept informed), while the DVD SIGs aren't allowed to force the player manufacturers to do what they want.
Microsoft is a software company. Software and homosexual marriage are completely unrelated. End of story. Right?
In that, I think it was completely right by Microsoft to take a neutral stance in this issue. It doesn't matter if every single employee actually supported this bill -- in that case, they can support it personally, not by representation from a company dealing with completely unrelated things.
Either way, GnomeMeeting works very well and ships by default as part of GNOME.
</sarcasm>
AFAIK, one uses spares with RAID 5 or similar solutions. When using RAID 5, one would have a spare to take over if an active drive goes down -- if it was active before it would expand the size of the array and would have data on its own on it, and thus couldn't take over for another drive.
I realize that RAID 1 with a spare may yield slightly better nominal write performance if in a software RAID array. OTOH, three drives would also yield better nominal read performance than just 2 drives and a spare. And, it wouldn't matter at all with hardware accelerated RAID.
So my point is: Is it just me, or is this guy going all wrong about his RAID? I just want to verify my thoughts, if someone would spar with me.