I completely agree about the dynamic content bit -- and I don't think the right answer is for us to have to mail around tarballs of C source and makefiles.
And while you're correct in spirit, in that converting from Java byte codes to native code is fundamentally the same problem as converting from native Platform A code to native Platform B code, the latter is orders of magnitude more difficult. Java was designed for just such a conversion, and so is about as simple as you can get.
Real Programs, on the other hand, are unbelievably complex to the point that simply deciding "Is this byte code or data (or both)?" is literally unsolvable in the general case. For comparison, the distinction between code and data is obvious in Java. Plus, for "real" emulation you have to emulate all the weird I/O ports and other basic hardware, none of which is trivial.
Comparing a Java VM to serious hardware emulation because they are both emulators is is like comparing "Hello World" to MacBeth because they are both English text -- technically correct, but not a really meaningful comparison.
And, you'll note that I *did* address your complaint in my post by noting that source distribution hasn't exactly been a wildly successful means of moving code around, issues with commercial entities not wanting to release source notwithstanding.
Source distribution is a pain in the butt. Making programs is frequently not as simple as it should be, and the ease installing programs under Unix is a very far cry from the ease installing programs under Windows. (And, admittedly, there are a ton of things which are much easier under Unix. But, let's face it, getting programs working is not one of those)
If Unix had a great, working system in place for distributing source which was completely automated, handled missing dependencies gracefully and intelligently, and didn't frequently require you to be a Unix wizard just to get a basic application working, I'd be a lot more inclined to agree.
The fact is, however, that often getting things to work is a hell of a lot tougher and more time-consuming than it should be. Binary distribution is nice and convenient, and until the Unix camp has something in the same convenience ballpark I will continue to maintain that the open-source community has most certainly *not* solved this problem.
Yes, and look how well that's worked for the Unix camp.
I'm not dissing open source -- I'm just pointing out the realistic view that it doesn't instantly solve all your problems. I realize that just about everybody on Slashdot will freak out about this, but I actually don't like Linux. I don't use it. I think it's just another Unix, and much as I dislike Windows I don't have to spend nearly as much time struggling with it just to (for example) upgrade my video card. (Cue collective gasps from audience). Unix has its place, and I think that place is firmly in the server room at this point in time.
(Disclaimer: This is not intended to be a troll. Please don't interpret "I don't like Linux" as "I think Windows is better than Linux", because I don't like Windows either. I think they're both half-assed solutions to a really difficult problem, and I think we can do better. What I mean is more along the lines of "If you think the open source community has already created the Holy Grail of operating systems, you've got to get your heads out of your asses and join the real world")
So, if your thinking is that Linux should be the only platform because it represents the One True Way -- I answer that by saying that you sound an awful lot like a particular group in Redmond, WA that also thinks their platform is the One True Way.
This industry cannot exist without competition, open *or* closed. Saying that these problems exist because your platform is not the only one in existence is incredibly childish.
I realize that Slashdotters love to trumpet the Open Source horn, but this comment is absurd. "Open Source" != "runs on all platforms".
The amount of work necessary to get a complicated X app running on many different flavors or Unix is certainly non-trivial, and that's just *one* family of operating systems. And it either requires distributing umpteen different binaries or requiring endusers to actually compile the whole damned program. All well and good for people whose lives are Unix, but do you *seriously* expect Joe Computer User to have to compile all his applications just to use a computer? ("how hard is it to type 'gmake all'?" I hear from the audience... as if you'd expect your grandma to do it, and you've *never once* had that result in forty-six different errors that you had to fix by modifying the makefile. make is not the answer)
The problem of having a program run on multiple platforms is not "caused by closed standards in the first place" as you state. It is caused simply by having multiple standards -- closed or open makes no difference. SomeRandomOpenSourceOS (TM) running on SomeRandomOpenSourceProcessor (TM) would have just as much trouble running Unix programs as Windows does. This is a great solution to a real problem; don't knock it just because you have a hardon for Linux.
I've only rarely heard of new dead pixels appearing. LCDs tend to lose brightness gradually over the years, rather than suddenly lose individual pixels.
I've heard 10,000 hours operational life quoted until the LCD dims to half its original brightness.
"Java is write once, run anywhere. This is a major advantage if you are running lots of client Java code on varying platforms. But since most Java development is server based then the fact that a program is WORA loses its charm"
Ummm... you don't develop server code, do you? You have this backwards. And I say this as a professional server-side Java developer.
Client code is precisely where WORA is irrelevant, because Windows might as well be the only game in town. This is one of the big reasons why Java hasn't exactly taken the desktop by storm -- any sensible person, even a Java fan like myself, will tell you that Java has a number of disadvantages (primarily WRT to the GUI), and the ability to move to non-Windows platforms doesn't generally hold enough attraction to outweigh the disadvantages.
The situation is completely different on the server, where there are tons of different architectures (Solaris, Linux, BSD, Win NT & 2000, AIX, etc.), and clients don't like having to buy and support new servers just to run your software.
So if you want to deal with an AIX shop, you either write highly portable Unix code (a chore in itself) and rule out the Windows/etc. market, or you write Java code. A lot of people have been taking the latter option (and of course on a server there is no concern about Java's poor GUI performance). Java absolutely kicks ass on the server precisely because of its portability.
"...best of both worlds by giving you all the
functionality you have come to expect from the Java platform with the added benefit of using languages other than Java (C++, C#, VB, Javascript, VBScript, Perl and a few others)..."
Or rather, it gives me all of the functionality I have come to expect, other than the ability to run on non-Windows platforms, a fantastic component library, a far more capable graphics library, incredible ease of loading and linking new code, and a million other things..Net has all the disadvantages of Java but none of its advantages.
But, the advantage of.Net is that instead of restricting myself to one good language, I can have my team of programmers writing the project in a half-dozen bad languages, none of which is comprehensible to more than one of them. Woohoo!
Seriously, though, I truly don't consider that an advantage. Try working on a two million line program, chunks of which are written in dead languages nobody around understands, and which only compile in specific old versions of their respective compilers, and *then* tell me that giving a team of fifty people the ability to each use absolutely any language they please is a Good Thing.
Not quite. The physical size of the lasing device is irrelevant; all that matters (WRT putting data on a surface) is the light coming out of it.
Any decent laser can be used to produce an incredibly thin beam, such that the limiting factor becomes the wavelength of the light. This is the reason for all the brouhaha over blue lasers - nothing to do with the physical size of the laser, but the fact that using a smaller wavelength allows you to pack more data on the surface.
Now, physical dimensions aside, these *are* UV, so clearly they're short-wavelength lasers, but IIRC the blue lasers are around 460nm (is that right?) so a 386nm UV would allow for roughly 42% more data to be packed on a given surface.
Of course, use of UV lasers in home electronics devices could be *really* dangerous, because if you somehow looked into the laser you wouldn't even realize it until you noticed the irreparable damage to your retina.
why do stories like this get posted?
on
DSLBlaster?
·
· Score: 2
Go ahead, moderate this a troll. I can take it.
But seriously, why post this story? It's an utterly useless hardware hack which is tremendously behind the state of the art and (IMHO) doesn't even qualify as particularly creative.
Using audio signals to transmit digital data!! Woohoo!! That's never been done before!! Now, the flourescent light network story was pretty interesting, and at least relatively novel, but this is pure drivel.
If you read the tech specs, they're only getting 96Kb out of this thing, and it requires a leased line. Going through this amount of work to get twice the performance of an ordinary modem seems a bit ludicrous. What I'm amazed about is that they're only getting 96Kb -- I'm no signal expert, but that seems positively anemic given a 48KHz sampling rate. They're only getting two bits per sample?? WTF?? Truly pathetic next to my 1.5Mb DSL at home.
Japanese *has* folded into Chinese, as has Korean. It's the CJK block (Chinese, Japanese, Korean). There are two blocks, Traditional and Simplified. Additional characters could be encoded in Plane 1 (as I've pointed out elsewhere in this thread).
The CJK block, IIRC, already has ~27,000 characters in it. About 42,000 of the Unicode codepoints are already assigned.
And your comment about "Unicode has resisted this effort" is worse than clueless - this is already implemented as surrogate pairs, which enable about a million more characters.
This is worse than an IANAL thread... we need IKANAU (I Know Absolutely Nothing About Unicode) disclaimers.
Not sure where you got Planes 1, 2, and 14 from. It's just Plane 0 (normal characters) and Plane 1 (surrogates). No characters whatsoever are assigned outside of Plane 0, although some are pending approval.
UTF-8, UTF-16 (UCS-2), and UCS-4 (not just UTF-16, as you say) all allow Plane 1 to be addressed, as would any other encoding which covered the surrogate codepoints (although none such exists, to my knowledge). UTF-8 allows this either through discrete encoding of two separate surrogate characters, which takes six bytes, or a special 4-byte encoding which encodes the Plane 1 character directly (rather than as two surrogates).
No, the private use area is inappropriate for this sort of thing. Private use characters are (as the name implies) not intended to be visible to other applications; they are for encoding weird data within a single application.
There is a much larger block of public code points, which allows for over a million characters (none of which have been assigned yet, but the code points are there).
UTF-8 is an encoding format, which specifies a means of encoding Unicode characters using variable-length byte sequences. The number of bytes it uses to encode characters does not dictate how many characters Unicode supports.
Unicode, as I've stated elsewhere, supports a little over a million characters. There are ~50,000 characters in Plane 0, and 2^20 (~1 million) in Plane 1. Plane 1 is made up of surrogate pairs, which are two special characters next to one another (a high surrogate and a low surrogate). There are 1024 of each, leading to 2^20 Plane 1 characters.
It encodes over one million codepoints, actually (the erroneous statements of other posters notwithstanding). All currently assigned Unicode characters exist within the basic Unicode Plane 0, as it's called, which handles ~50,000 characters. Twenty-some-odd-thousand of those characters are in the CJK block (Chinese, Japanese, and Korean characters).
Now, a range of Unicode characters is set aside for so-called "surrogates", and a high surrogate and a low surrogate character placed next to one another form a "surrogate pair" which specifies an extended character in UCS Plane 1. None of UCS Plane 1 codepoints are actually assigned to anything yet, but since there are about 2^20 (~one million) Plane 1 codepoints, they will easily handle all remaining glyphs with a ton left over. Tengwar, Klingon and others have all been considered for Plane 1 encoding (although I just checked and Klingon has been rejected. Sorry folks).
So, the simple fact is that anyone who says Unicode can't support enough characters has been smoking a bit too much crack lately. Do yourself a favor and go read the spec before getting your panties in a twist.
The Game Gear was also huge, heavy, and sucked six AA batteries dry in about an hour and a half. It was roughly equivalent to an NES in power and had maybe two games worth playing - Sonic and Columns.
The Game Boy Advance, on the other hand, is far smaller and lighter, runs for about 20 hours on two AAs, and is substantially more powerful than an SNES. It also has an incredible launch lineup, and more quality games scheduled to come out for it than any other system in the world.
As far as your pissy "Nintendo sucks" comments, you are aware that the Nintendo GameCube (due in Nov.) will actually be the cheapest next-gen system, and uses optical disks, contrary to what you seem to be suggesting? It's also launching with a bunch of games which look like they'll be amazing. It seems you're tired of the "high price point" but would rather buy a more expensive system with crappier games (at least in the case of the Xbox). Whatever.
Seriously, how does this differ from the myriad glove input devices which have existed for decades?
Gloves are old news, and although I admit that a cheap, accurate one would be interesting, I don't see how this warrants front-page news. Their site reeks of late-eighties Virtual Reality hype...
If I may paraphrase your comment, you are basically saying: "I don't understand the patent system".
Let's say that I'm a researcher working on high-efficiency solar panels. I develop a new, laminated-diamond solar cell which is far more efficient than existing techniques. I apply for a patent on it.
Your response is: "It's just not valid to say your solar panel is novel just because you use laminated diamond". That is, you are saying that because solar cells are old hat, my super-high-efficiency solar cell isn't any different. The patent office (and researchers working in the field) would tell you differenty.
Regardless of your personal opinion on the matter, the patent system is pretty clear on this (IANAL, but I have gone through the patent application process before). The only way that you could claim this application was invalid based on your argument is to say that it's "obvious" to use MPEG and hard disks to store video, given the prior invention of a VCR or other relevant technology.
More specifically, that it would be obvious to an engineer of average skill working in the relevant field to move toward this technology. Given how long after MPEG became available it took for someone to develop a TiVo-like device, and the fact that most people seem to think the TiVo was a neat, innovative technology, "obvious" is a bit of a long shot. I should also point out that the claim is less broad than that - it applies to TiVo's specific technology for doing this, not the very broad "MPEG and hard disks" claim.
Yes, VCRs have been done. They are properly referenced in the prior art section of this patent. But unless there was a prior invention either exactly the same or close enough to this one that the progression is "obvious", this patent is perfectly valid.
You'll note that I mentioned hardware failure was still a problem. Hardware failure is the only thing RAID protects against, so obviously a journalled RAID filesystem is ideal.
Of course it only protects the filesystem from being corrupted; what did you think I was talking about? That is, after all, the entire point of running an fsck in the first place.
Replace "faster fscks" with "instant fscks" and "less risk of data loss" with "no risk of data loss".
I admittedly haven't used Linux's implementation of JFS, but a decent journalled filesystem can consistency-check the disk so fast it's ridiculous.
Further, short of hardware failure, there is literally *no* way for a bug-free journalled FS to lose successfully written data. Period. Obviously you'll lose whatever didn't get fully journalled yet when the power failed (or whatever), but everything that actually got written to disk will be 100% reliable once the fsck completes. No lost clusters, no files hanging out in limbo. It's literally impossible.
Stole the show?? Every single article I have read about E3 gave the graphics nod to Rogue Leader for GameCube. Where did you hear that DOA3 was the show-stealer?
I did not say we should all stick to one language -- you are putting words in my mouth. But the fact is, if you're the only programmer in the world who knows language X, and you insist on programming in it, you'll be doing it by yourself.
"Fringe" programming languages are useful as research projects, certainly. But the real world doesn't seem to need more than a handful of them.
Slashdot Mirror
I completely agree about the dynamic content bit -- and I don't think the right answer is for us to have to mail around tarballs of C source and makefiles.
And while you're correct in spirit, in that converting from Java byte codes to native code is fundamentally the same problem as converting from native Platform A code to native Platform B code, the latter is orders of magnitude more difficult. Java was designed for just such a conversion, and so is about as simple as you can get.
Real Programs, on the other hand, are unbelievably complex to the point that simply deciding "Is this byte code or data (or both)?" is literally unsolvable in the general case. For comparison, the distinction between code and data is obvious in Java. Plus, for "real" emulation you have to emulate all the weird I/O ports and other basic hardware, none of which is trivial.
Comparing a Java VM to serious hardware emulation because they are both emulators is is like comparing "Hello World" to MacBeth because they are both English text -- technically correct, but not a really meaningful comparison.
And, you'll note that I *did* address your complaint in my post by noting that source distribution hasn't exactly been a wildly successful means of moving code around, issues with commercial entities not wanting to release source notwithstanding.
Source distribution is a pain in the butt. Making programs is frequently not as simple as it should be, and the ease installing programs under Unix is a very far cry from the ease installing programs under Windows. (And, admittedly, there are a ton of things which are much easier under Unix. But, let's face it, getting programs working is not one of those)
If Unix had a great, working system in place for distributing source which was completely automated, handled missing dependencies gracefully and intelligently, and didn't frequently require you to be a Unix wizard just to get a basic application working, I'd be a lot more inclined to agree.
The fact is, however, that often getting things to work is a hell of a lot tougher and more time-consuming than it should be. Binary distribution is nice and convenient, and until the Unix camp has something in the same convenience ballpark I will continue to maintain that the open-source community has most certainly *not* solved this problem.
...Of course, virtually all cell phones are moving towards Java currently. I can't imagine the rest of the embedded industry being very far behind.
Yes, and look how well that's worked for the Unix camp.
I'm not dissing open source -- I'm just pointing out the realistic view that it doesn't instantly solve all your problems. I realize that just about everybody on Slashdot will freak out about this, but I actually don't like Linux. I don't use it. I think it's just another Unix, and much as I dislike Windows I don't have to spend nearly as much time struggling with it just to (for example) upgrade my video card. (Cue collective gasps from audience). Unix has its place, and I think that place is firmly in the server room at this point in time.
(Disclaimer: This is not intended to be a troll. Please don't interpret "I don't like Linux" as "I think Windows is better than Linux", because I don't like Windows either. I think they're both half-assed solutions to a really difficult problem, and I think we can do better. What I mean is more along the lines of "If you think the open source community has already created the Holy Grail of operating systems, you've got to get your heads out of your asses and join the real world")
So, if your thinking is that Linux should be the only platform because it represents the One True Way -- I answer that by saying that you sound an awful lot like a particular group in Redmond, WA that also thinks their platform is the One True Way.
This industry cannot exist without competition, open *or* closed. Saying that these problems exist because your platform is not the only one in existence is incredibly childish.
I realize that Slashdotters love to trumpet the Open Source horn, but this comment is absurd. "Open Source" != "runs on all platforms".
The amount of work necessary to get a complicated X app running on many different flavors or Unix is certainly non-trivial, and that's just *one* family of operating systems. And it either requires distributing umpteen different binaries or requiring endusers to actually compile the whole damned program. All well and good for people whose lives are Unix, but do you *seriously* expect Joe Computer User to have to compile all his applications just to use a computer? ("how hard is it to type 'gmake all'?" I hear from the audience... as if you'd expect your grandma to do it, and you've *never once* had that result in forty-six different errors that you had to fix by modifying the makefile. make is not the answer)
The problem of having a program run on multiple platforms is not "caused by closed standards in the first place" as you state. It is caused simply by having multiple standards -- closed or open makes no difference. SomeRandomOpenSourceOS (TM) running on SomeRandomOpenSourceProcessor (TM) would have just as much trouble running Unix programs as Windows does. This is a great solution to a real problem; don't knock it just because you have a hardon for Linux.
I've only rarely heard of new dead pixels appearing. LCDs tend to lose brightness gradually over the years, rather than suddenly lose individual pixels.
I've heard 10,000 hours operational life quoted until the LCD dims to half its original brightness.
You say this as someone who has never used Java2D.
"Java is write once, run anywhere. This is a major advantage if you are running lots of client Java code on varying platforms. But since most Java development is server based then the fact that a program is WORA loses its charm"
... you don't develop server code, do you? You have this backwards. And I say this as a professional server-side Java developer.
Ummm
Client code is precisely where WORA is irrelevant, because Windows might as well be the only game in town. This is one of the big reasons why Java hasn't exactly taken the desktop by storm -- any sensible person, even a Java fan like myself, will tell you that Java has a number of disadvantages (primarily WRT to the GUI), and the ability to move to non-Windows platforms doesn't generally hold enough attraction to outweigh the disadvantages.
The situation is completely different on the server, where there are tons of different architectures (Solaris, Linux, BSD, Win NT & 2000, AIX, etc.), and clients don't like having to buy and support new servers just to run your software.
So if you want to deal with an AIX shop, you either write highly portable Unix code (a chore in itself) and rule out the Windows/etc. market, or you write Java code. A lot of people have been taking the latter option (and of course on a server there is no concern about Java's poor GUI performance). Java absolutely kicks ass on the server precisely because of its portability.
"...best of both worlds by giving you all the
.Net has all the disadvantages of Java but none of its advantages.
.Net is that instead of restricting myself to one good language, I can have my team of programmers writing the project in a half-dozen bad languages, none of which is comprehensible to more than one of them. Woohoo!
functionality you have come to expect from the Java platform with the added benefit of using languages other than Java (C++, C#, VB, Javascript, VBScript, Perl and a few others)..."
Or rather, it gives me all of the functionality I have come to expect, other than the ability to run on non-Windows platforms, a fantastic component library, a far more capable graphics library, incredible ease of loading and linking new code, and a million other things.
But, the advantage of
Seriously, though, I truly don't consider that an advantage. Try working on a two million line program, chunks of which are written in dead languages nobody around understands, and which only compile in specific old versions of their respective compilers, and *then* tell me that giving a team of fifty people the ability to each use absolutely any language they please is a Good Thing.
Not quite. The physical size of the lasing device is irrelevant; all that matters (WRT putting data on a surface) is the light coming out of it.
Any decent laser can be used to produce an incredibly thin beam, such that the limiting factor becomes the wavelength of the light. This is the reason for all the brouhaha over blue lasers - nothing to do with the physical size of the laser, but the fact that using a smaller wavelength allows you to pack more data on the surface.
Now, physical dimensions aside, these *are* UV, so clearly they're short-wavelength lasers, but IIRC the blue lasers are around 460nm (is that right?) so a 386nm UV would allow for roughly 42% more data to be packed on a given surface.
Of course, use of UV lasers in home electronics devices could be *really* dangerous, because if you somehow looked into the laser you wouldn't even realize it until you noticed the irreparable damage to your retina.
Go ahead, moderate this a troll. I can take it.
But seriously, why post this story? It's an utterly useless hardware hack which is tremendously behind the state of the art and (IMHO) doesn't even qualify as particularly creative.
Using audio signals to transmit digital data!! Woohoo!! That's never been done before!! Now, the flourescent light network story was pretty interesting, and at least relatively novel, but this is pure drivel.
If you read the tech specs, they're only getting 96Kb out of this thing, and it requires a leased line. Going through this amount of work to get twice the performance of an ordinary modem seems a bit ludicrous. What I'm amazed about is that they're only getting 96Kb -- I'm no signal expert, but that seems positively anemic given a 48KHz sampling rate. They're only getting two bits per sample?? WTF?? Truly pathetic next to my 1.5Mb DSL at home.
This is news because... why, exactly?
Japanese *has* folded into Chinese, as has Korean. It's the CJK block (Chinese, Japanese, Korean). There are two blocks, Traditional and Simplified. Additional characters could be encoded in Plane 1 (as I've pointed out elsewhere in this thread).
... we need IKANAU (I Know Absolutely Nothing About Unicode) disclaimers.
The CJK block, IIRC, already has ~27,000 characters in it. About 42,000 of the Unicode codepoints are already assigned.
And your comment about "Unicode has resisted this effort" is worse than clueless - this is already implemented as surrogate pairs, which enable about a million more characters.
This is worse than an IANAL thread
Not sure where you got Planes 1, 2, and 14 from. It's just Plane 0 (normal characters) and Plane 1 (surrogates). No characters whatsoever are assigned outside of Plane 0, although some are pending approval.
UTF-8, UTF-16 (UCS-2), and UCS-4 (not just UTF-16, as you say) all allow Plane 1 to be addressed, as would any other encoding which covered the surrogate codepoints (although none such exists, to my knowledge). UTF-8 allows this either through discrete encoding of two separate surrogate characters, which takes six bytes, or a special 4-byte encoding which encodes the Plane 1 character directly (rather than as two surrogates).
No, the private use area is inappropriate for this sort of thing. Private use characters are (as the name implies) not intended to be visible to other applications; they are for encoding weird data within a single application.
There is a much larger block of public code points, which allows for over a million characters (none of which have been assigned yet, but the code points are there).
*sigh*. No.
UTF-8 is an encoding format, which specifies a means of encoding Unicode characters using variable-length byte sequences. The number of bytes it uses to encode characters does not dictate how many characters Unicode supports.
Unicode, as I've stated elsewhere, supports a little over a million characters. There are ~50,000 characters in Plane 0, and 2^20 (~1 million) in Plane 1. Plane 1 is made up of surrogate pairs, which are two special characters next to one another (a high surrogate and a low surrogate). There are 1024 of each, leading to 2^20 Plane 1 characters.
It encodes over one million codepoints, actually (the erroneous statements of other posters notwithstanding). All currently assigned Unicode characters exist within the basic Unicode Plane 0, as it's called, which handles ~50,000 characters. Twenty-some-odd-thousand of those characters are in the CJK block (Chinese, Japanese, and Korean characters).
Now, a range of Unicode characters is set aside for so-called "surrogates", and a high surrogate and a low surrogate character placed next to one another form a "surrogate pair" which specifies an extended character in UCS Plane 1. None of UCS Plane 1 codepoints are actually assigned to anything yet, but since there are about 2^20 (~one million) Plane 1 codepoints, they will easily handle all remaining glyphs with a ton left over. Tengwar, Klingon and others have all been considered for Plane 1 encoding (although I just checked and Klingon has been rejected. Sorry folks).
So, the simple fact is that anyone who says Unicode can't support enough characters has been smoking a bit too much crack lately. Do yourself a favor and go read the spec before getting your panties in a twist.
The Game Gear was also huge, heavy, and sucked six AA batteries dry in about an hour and a half. It was roughly equivalent to an NES in power and had maybe two games worth playing - Sonic and Columns.
The Game Boy Advance, on the other hand, is far smaller and lighter, runs for about 20 hours on two AAs, and is substantially more powerful than an SNES. It also has an incredible launch lineup, and more quality games scheduled to come out for it than any other system in the world.
As far as your pissy "Nintendo sucks" comments, you are aware that the Nintendo GameCube (due in Nov.) will actually be the cheapest next-gen system, and uses optical disks, contrary to what you seem to be suggesting? It's also launching with a bunch of games which look like they'll be amazing. It seems you're tired of the "high price point" but would rather buy a more expensive system with crappier games (at least in the case of the Xbox). Whatever.
Seriously, how does this differ from the myriad glove input devices which have existed for decades?
Gloves are old news, and although I admit that a cheap, accurate one would be interesting, I don't see how this warrants front-page news. Their site reeks of late-eighties Virtual Reality hype...
If I may paraphrase your comment, you are basically saying: "I don't understand the patent system".
Let's say that I'm a researcher working on high-efficiency solar panels. I develop a new, laminated-diamond solar cell which is far more efficient than existing techniques. I apply for a patent on it.
Your response is: "It's just not valid to say your solar panel is novel just because you use laminated diamond". That is, you are saying that because solar cells are old hat, my super-high-efficiency solar cell isn't any different. The patent office (and researchers working in the field) would tell you differenty.
Regardless of your personal opinion on the matter, the patent system is pretty clear on this (IANAL, but I have gone through the patent application process before). The only way that you could claim this application was invalid based on your argument is to say that it's "obvious" to use MPEG and hard disks to store video, given the prior invention of a VCR or other relevant technology.
More specifically, that it would be obvious to an engineer of average skill working in the relevant field to move toward this technology. Given how long after MPEG became available it took for someone to develop a TiVo-like device, and the fact that most people seem to think the TiVo was a neat, innovative technology, "obvious" is a bit of a long shot. I should also point out that the claim is less broad than that - it applies to TiVo's specific technology for doing this, not the very broad "MPEG and hard disks" claim.
Yes, VCRs have been done. They are properly referenced in the prior art section of this patent. But unless there was a prior invention either exactly the same or close enough to this one that the progression is "obvious", this patent is perfectly valid.
You'll note that I mentioned hardware failure was still a problem. Hardware failure is the only thing RAID protects against, so obviously a journalled RAID filesystem is ideal.
Of course it only protects the filesystem from being corrupted; what did you think I was talking about? That is, after all, the entire point of running an fsck in the first place.
Replace "faster fscks" with "instant fscks" and "less risk of data loss" with "no risk of data loss".
I admittedly haven't used Linux's implementation of JFS, but a decent journalled filesystem can consistency-check the disk so fast it's ridiculous.
Further, short of hardware failure, there is literally *no* way for a bug-free journalled FS to lose successfully written data. Period. Obviously you'll lose whatever didn't get fully journalled yet when the power failed (or whatever), but everything that actually got written to disk will be 100% reliable once the fsck completes. No lost clusters, no files hanging out in limbo. It's literally impossible.
Generally true, but keep in mind that Baal, the Lord of Hatred, is *the* prime evil. Diablo is younger and less powerful.
The cinematic between Acts II & III has Baal calling Diablo his younger brother, if you want proof.
Stole the show?? Every single article I have read about E3 gave the graphics nod to Rogue Leader for GameCube. Where did you hear that DOA3 was the show-stealer?
...since you're the one who's reading it wrong.
I quote:
"Yahoo has server-side software written in all the languages Eric Raymond recommends to hackers, except Java."
You'll note that the word 'store' does not appear anywhere in that sentence.
I did not say we should all stick to one language -- you are putting words in my mouth. But the fact is, if you're the only programmer in the world who knows language X, and you insist on programming in it, you'll be doing it by yourself.
"Fringe" programming languages are useful as research projects, certainly. But the real world doesn't seem to need more than a handful of them.