That defendant should also include copies of both letters in a complaint to the New York Bar Association. Not that it'd be enough to get the lawyer disbarred, but it might make him have second thoughts about the fight he's trying to pick. Bar Associations (possibly excepting Arkansas') tend to take a rather dim view of lawyers committing perjury (or at least of getting caught out at it).
At the press conference somebody mentioned in passing that the web pad had a USB port that you could use to add (among, presumably, other things) a keyboard.
The pop-up virtual keyboard on the touch screen is probably sufficient for truly mobile use -- e.g. when you're holding the pad in one hand (kinda like a clipboard) and just want to one-finger type in a URL or a few simple commands. For serious typing I'd rather have a real keyboard and something to rest my hands/arms on anyway, which means putting the thing down on a table, etc anyway.
(These things are almost at the tech level of the pads in "2001: A Space Odyssey" -- recall the scene where Bowman and Poole are eating while watching the TV (?) broadcast about their mission, each watching on his own web-pad-like device. At least something from that movie came about in the right timeframe. Too bad it wasn't the orbiting hotel and the bases on the Moon.)
Some highlights from the technology whitepaper on the Transmeta website. It should answer some of the FAQ's raised here so far. (My comments/observations in italics).
Code Morphing software will "typically reside in standard Flash ROMs on the motherboard". This implies it could be in RAM, and potentially dynamically reconfigurable or switchable, on a suitable designed motherboard. (Elsewhere the paper implies that this ROM software is or can be copied to RAM at boot up for faster execution.)
The VLIW engine has "two integer units, an [FPU], a memory (load/store) unit, and a branch unit". These can operate in parallel.
All VLIW code, both translated x86 (or whatever) code and Code Morphing code, live in a separate memory space invisible to x86 code. The size of this memory space can be set at boot time or the OS can make the size adjustable. This last implies that the OS can somehow see this memory, so it's either not totally invisible to x86 code or the OS has some VLIW code hooks.
"The Code Morphing software includes in its arsenal a wide choice of execution modes for x86 code, ranging from interpretation [...] through translation using simple-minded code generation, all the way to highly optimized code [...] A sophisticated set of heuristics helps choose among these execution modes based on dynamic feedback information gathered during actual execution of the code." This sounds a lot like Sun's "HotSpot" technology for Java VMs. Either way it sounds cool..
"the translator adds code whose sole purpose is to collect information such as block execution frequencies, or branch history."
There's hardware support to help the code morphing, ie support for exceptions, speculation, optimization of memory and for self-modifying code. All x86 registers are shadowed, there's a working and a shadow copy. As blocks of x86 code get translated, that page's entry in the Crusoe MMU (for the translation cache) is marked as "translated" so that it doesn't get translated again. A write (by x86 code, indicating self-modifying code) into that block causes that bit to be cleared.
The Crusoe processor voltage and clock (at least on the 5400) are accessible to the Code Morphing software, which can adjust them on the fly to optimize power/performance for the running app.
The TM 5400 is optimized for Windows but it'll run any x86 OS.
The neat thing, that I haven't seen anyone here pick up on yet, is that the Mobile Linux based web pads, etc, will have about a six-month lead over any Windows-based Crusoe machine -- that is, if you want a web pad (and they are cool looking machines), you get Linux. The 3120 is in production now, the 5400 won't be for another few months. (Oh, I suppose some manufacturer might decide to do a Windows-based machine on the the 3120, but it'd be more expensive: Windows license cost, hard drive for the OS (the Linux is ROMable), added development cost).
They also said that the VLIW instruction sets are different for the TM3120 and TM5400 chips, the Code Morphing Software has different back-ends for each chip (and is compiled to different targets).
But yeah, unless/until Transmeta releases the specs or someone reverse-engineers the instruction set, we won't see any do-it-yourself CPU emulators.
They did mention that one of the demos was a Crusoe running Java bytecode 'natively' (ie CMS translating bytecode directly to VLIW), so perhaps we will see some other CPU emulations in future.
However, the current architectures (and it wasn't clear whether this was of the chip or of the system the chip is in) don't seem to allow for dynamically switching instruction sets - once the thing has booted up the CMS code the pathways to that low level stuff are closed.
This makes sense for Transmeta at this point to keep the market from getting confused, but I hope that once this settles out that they start looking at making the thing more flexible.
The fact is, if you analyze a bumblebee according to the aerodynamics of fixed-wing vehicles, they can't fly worth a darn. This is correct -- when was the last time you saw a bumblebee glide?
The error of course is in the assumption that fixed-wing aerodynamics applies, and it doesn't. Analyze them by the aerodynamics of moving wing vehicles (which amounts to using helicopter aerodynamics, there being damn few ornithopters), and things work much better. (Still not strictly accurate, of course, insect wing flapping is pretty complex.)
Helicopters glide about as well as bumblebees when you stop the wings (blades).
I'll give you your (1) (maybe), but automatic footnoting is hardly a Microsoft innovation. I had it in my FORMAL portable text formatter back in 1979-1980ish, which I believe pre-dates Word 1.0. And I probably cribbed it from Waterloo Script or one of the other text processors around.
The list of forbidden weaponry is a bit ridiculous. There's a group around these parts (the Mad Scientists Club) that has run a "Critter Crunch" for over ten years at the annual MileHiCon and other venues. Their critters (bots) are limited to 20 pounds and a one-foot-cube (before combat start -they're free to expand after that), as much as anything to make it easy to find space for the combats.
Weaponry on various critters has included harpoons (tethered), flamethrowers, "elephant snot" (a superlubricant gel, used to deny the opponent any traction), strobes, silly-string (not very effective, but entertaining), as well as stuff like saws and forklifts. Highly entertaining. The size and weight constraints demand a lot of ingenuity.
Consider: Microsoft pays no dividends, so real earnings per share (until you sell) is zero. Even if you look at Microsoft's reported earnings (which they don't share with stockholders as dividends anyway), earnings per share at todays share prices is pathetic. (Sure, there are others that do worse -- e.g. Amazon.com -- but that's hardly a guideline for investing.)
The only thing that makes Microsoft shares worth anything at all (since they have no inherent earning potential) is what other people might be willing to pay for them. Just like Beanie Babies. If the fad blows over -- the market becomes disillusioned with MSFT -- the shares will be worth only slightly more than the paper they're printed on. (About $3/share cash, plus whatever an investment that earns about $1/share per year is worth. Call it about $20, tops -- and that's assuming that MSFT could maintain its business.)
No customer saw that dialog in any shipping copy of windows
Perhaps, perhaps not. Irrelevant in either case.
Members of the trade press did see that dialog in advance copies of Windows they may have received for review. If you're Joe ComputerCustomer and you read in Jerry X. Dvorak's ByteWeek column that he couldn't get Windows to work under DR-DOS (because of some wierd error) but could under MS-DOS, what are you going to think? "Better stay away from DR-DOS" is what.
MS didn't need to put that in the final shipping version because by then most of the damage had already been done.
(why is it that the US can have nuclear missiles in northern Canada, but the Russians can't have them in Cuba?)
Unless you have access to info that hasn't been made public, the only nuclear missiles in northern (or any other part of) Canada were Bomarcs and Genies, SAMs and AAMs respectively for shooting down bombers.
The missiles that (in part) prompted the basing of nukes in Cuba were Jupiter IRBMs based in Turkey, which in fact the US quietly withdrew as part of the deal that settled the Cuban missile crisis. (Of course they were largely obsolete by then anyway, with the development of e.g. Titan and Polaris ICBMs).
The man would be Tucker, the car would be the Tucker Torpedo.
Way ahead of its time in many ways, at least in initial design. Reports vary about how well the final product matched the initial design (mostly due to lack of start-up funds). The movie paints the established auto industry as the bad guys in this, they didn't want the competition. How accurate that is I don't know.
(That movie and story always reminds me of Gary Hudson and his repeated attempts (Phoenix, Roton, etc) at bringing a small reusable spaceship to market.)
For example, the Chernobyl reactor didn't "melt down", it caught fire. (It was a graphite-moderated design, it got hot enough for the graphite to catch fire. Nasty.)
And the Hindenberg "disaster" wasn't that bad -- most aboard actually survived, and zeppelins had been flying for years without incident before that. It just happened that there was a reporter present (and we know how often the news media get it right). There were numerous other air disasters they could have mentioned (like the DC-10 incident where an engine fell off, destroying hydraulic lines in the process. Turned out they'd been using a fork-lift to remove/replace the engine for servicing, messing up the mounting bolts).
And, Windows aside, perhaps the biggest computer-related screw up was the messed up deal between IBM and Motorola that ended up with IBM using the Intel 8088 instead of the Moto 68008 chip in IBM's first PC. (Accounts differ, one version has it that Moto refused to license the design to a second source, which IBM wanted.)
...The DeCSS program... is a substantial derivation of confidential proprietary information which DVD CCA licenses pursuant to the CSS Agreement....
This is why DVD CCA cares about DeCSS. They don't really care about copies of DVDs, or whether a few Linux geeks meddle with DVD content. They care that DeCSS hits them where they live: their licensing fees.
Admittedly I'm speculating here, since I have no particular knowledge of how the DVDCCA licenses that weak cryptosystem to the DVD player manufacturers and DVD content providers. But let's assume that they get some (per copy?) royalty - or certainly at least some annual licensing fee - from the manufacturers and media companies. Now appears on the scene compatible encrypting/decrypting software that is free of DVDCCA's encumbrances. Kiss those licensing fees goodbye.
The company is going after the hackers, web site owners, et alia now because (a) they're seen as a softer target and (b) to preempt any abandonment of licensing by their existing customers. You can bet that if they waited until clients started switching to DeCSS code to sue (possibly for violation of contract terms?) they'd have a much tougher time of it (or think they would -- I don't think this is going to be as easy as they thought).
I don't know if this angle has been considered by anyone yet, and the hearing is going on right now, but it helps to have a good idea of your opponents real goals when getting involved in something like this.
Geez, that certainly takes the prize for absurdity.
I know folks who've been 'infringing' on this patent since years before it was issued (and before handheld lasers were readily available - this couple was into home holography). Mind, they had a dog, not a cat.
You've got to wonder why anyone would even bother paying the patent application fees for something (a) so obvious and (b) that they don't stand a hope in hell of ever collecting a royalty for.
An open source reverse engineered client for MSA might be acceptable to some, but what happens when MS changes the protocol with their next release?
The community responded well, with PNG, when Unisys started enforcing the patent on GIF. Surely we can come up with an open source, open protocol server and client for audio (and perhaps later, video)?
I mean, come on, people. Sending audio over the net is nothing new (I've been doing it since Sparcstation 1 days, using "cat annoying-audio-file.au | rsh othermachine cat >/dev/audio" to bug coworkers:-), surely there are some good unpatented compression techniques we can use to get acceptable performance over 28K modems? (Perhaps it's because so many free software developers typically have much higher bandwidth connections, that we haven't seen free versions of this stuff yet?)
All those workerbees who listen to the radio over the net while at work aren't going to be accepting Linux on the desktop without it.
Not even that many. 10^14, tops. The first digit identifies the type of card (Visa, Amex, MC, etc) and the last digit is a checkdigit. (I used to know the formula for the checkdigit, since I coded software to check it, but that was years ago).
And I believe the next few digits after the first identify the issuing bank, so one could probably make educated guesses about that.
Not that there aren't a zillion other ways to just go ahead and steal real CC numbers, if one is so inclined.
Of course, in a couple of years, we might not be on the x86 anymore, toto. And if any of these proposed future chips execute Java bytecodes at hardware-lookin' speeds, watch out, Microsoft!:)
Interesting juxtaposition, there. If the Transmeta "Crusoe" chip does turn out to be a dynamically re-microprogrammable CPU, it could as easily remicroprogram itself to run Java bytecode natively as it could x86 code. More generally, whatever magic it does to run x86 code faster than an actual x86, it could also do to run Java bytecode faster than anything else out there.
I've found that the portability of Java is greatly exagerated. Taking a working Java app from an NT server to a different enviroment took several weeks. None of this was due to Microsoft, the app was written in 'pure' Java.
I've found just the opposite. Java apps that run painlessly across NT, W9x, Unix, Linux and MacOS without recompiling (and I'm not talking trivial demo applets, either). Yes, there are occasional problems, generally these turn out to be either JVM bugs (more a problem a few years ago than today) or, more often, sloppy coding (e.g. being careless about coding file names in a non-portable manner). That latter isn't a Java problem, it'd happen with any language. At least Java provides some fixes.
In addition, you have to considere the rapid pace at which Java seems to evolve. [...] Java 1.0 isn't compatable with Java 1.1, which isn't compatable with Java 2.
Not true. While some methods may be deprecated in later versions of Java, they still compile. More importantly, a Java 1.0 classfile still runs under a 1.1 or 1.2 JVM. The bytecode hasn't changed much.
All of this in a language which was released about 4 years ago?
Haven't been around new languages much, have you? The first few years of C++ were as bad, the original widely distributed version of the language didn't have either multiple inheritance or templates, and several then-legal C++isms are now deprecated (e.g. assignment to this, handy for walking a list). The same goes for just about every other new language, as wider usage turns up design flaws or omissions that the original language designer(s) hadn't thought of (or thought necessary).
It's not just the GUI -- Java brings with it a slew of standard - really standard - libraries.
But beyond that, even though all us ubergeeks here code perfect C/C++, never leak memory or botch a pointer reference or run off the end of an array (yeah,right), there are plenty of programmers out there who do occasionally slip up, and writing in Java catches (or prevents) these omissions and thus the debug cycle is reduced. Fewer bugs is a good thing.
Further and more, C and/or C++ code won't run in a browser, unless you download a plug-in with all the security risks that entails. Browser apps are (in some contexts) a good thing.
There are other reasons. Personally I like Java's OO model better than C++'s. C++ has gotten a little crufty with age (I first learned it back when there were no C++ compilers, only cfront. IMHO it was better then.)
Besides, do you think Microsoft's implementation of <stdgui.h> would have been any more standard than what they did to Java?
Although, like "the Apollo 11 landing", the "recovery of Apollo 13" is a bit too broad and general to, IMO, qualify as a hack. It comprised several hacks, to be sure (as did the whole Apollo project), but we should look at them separately perhaps.
The single greatest hack of Apollo 13 was, I think, the kludging together of assorted baggies, spacesuit hoses, checklist covers and duct tape together with the (square) LiOH canisters from the CM to fit the (round) hole for the LM canisters.
The single greatest hack of the Apollo project -- which made it possible at all -- was probably the Lunar Orbit Rendezvous mission profile itself. That was championed by a lone engineer in the face of a lot of opposition that wanted Earth Orbit Rendezvous (requiring two Saturn V launches) or Direct Ascent (requiring a Nova-class booster).
Speech-recognition technology can't do this job even now (1993), and almost certainly won't in this millennium, either.
Back in the early 1980s - I don't recall the exact year, call it 1983ish - I played briefly with a speech recognition system one of the profs at Concordia U (where I worked at the time) was developing. It ran on a VAX 11/780 (under VMS), input was via an A/D converter (I used the D/A side of it for sound effects for the game I programmed). It could recognize and parse continuous speech from a random speaker. The catch was that it couldn't do it in realtime, it took about fifteen minutes of processing for about five seconds of speech. Taking out the overhead of printing out all the steps it was taking in the analysis might have shaved a couple of minutes off of that.
But that was fifteen years ago, on a one MIPS machine. Modern machines with some preprocessing of the signal via DSP could do better than realtime. Add in the neural net system that can recognize certain keywords from the background noise even better than humans (mentioned on/. a couple of months ago) to flag specific conversations for analysis and the problem becomes downright simple.
Screening text messages by comparison is a piece of cake. A bit more of a challenge is the high volume of binary packets on the net -- most of them probably jpeg fragments from pr0n sites -- but those will have characteristic formats/patterns that distinguish them from, say, encrypted text. (Of course, steganography is becoming popular...)
I don't know what the KDE folks are targetting, but I can tell you that I've got a 16 MB, 66MHz 486 here on which KDE (1.1) certainly runs. It's really s-l-o-w to fire up new apps, of course, but it does run. (I'd say 16MB is a minimum, looking at my/proc/meminfo and/proc/swaps. Otherwise you'll really be thrashing.) (Note I don't usually use KDE on it, since it's primarily a server.)
Since KDE 2.0 is supposedly a little leaner, running on that hardware shouldn't be a problem.
Slashdot Mirror
That defendant should also include copies of both letters in a complaint to the New York Bar Association. Not that it'd be enough to get the lawyer disbarred, but it might make him have second thoughts about the fight he's trying to pick. Bar Associations (possibly excepting Arkansas') tend to take a rather dim view of lawyers committing perjury (or at least of getting caught out at it).
At the press conference somebody mentioned in passing that the web pad had a USB port that you could use to add (among, presumably, other things) a keyboard.
The pop-up virtual keyboard on the touch screen is probably sufficient for truly mobile use -- e.g. when you're holding the pad in one hand (kinda like a clipboard) and just want to one-finger type in a URL or a few simple commands. For serious typing I'd rather have a real keyboard and something to rest my hands/arms on anyway, which means putting the thing down on a table, etc anyway.
(These things are almost at the tech level of the pads in "2001: A Space Odyssey" -- recall the scene where Bowman and Poole are eating while watching the TV (?) broadcast about their mission, each watching on his own web-pad-like device. At least something from that movie came about in the right timeframe. Too bad it wasn't the orbiting hotel and the bases on the Moon.)
Some highlights from the technology whitepaper on the Transmeta website. It should answer some of the FAQ's raised here so far. (My comments/observations in italics).
Code Morphing software will "typically reside in standard Flash ROMs on the motherboard". This implies it could be in RAM, and potentially dynamically reconfigurable or switchable, on a suitable designed motherboard. (Elsewhere the paper implies that this ROM software is or can be copied to RAM at boot up for faster execution.)
The VLIW engine has "two integer units, an [FPU], a memory (load/store) unit, and a branch unit". These can operate in parallel.
All VLIW code, both translated x86 (or whatever) code and Code Morphing code, live in a separate memory space invisible to x86 code. The size of this memory space can be set at boot time or the OS can make the size adjustable. This last implies that the OS can somehow see this memory, so it's either not totally invisible to x86 code or the OS has some VLIW code hooks.
"The Code Morphing software includes in its arsenal a wide choice of execution modes for x86 code, ranging from interpretation [...] through translation using simple-minded code generation, all the way to highly optimized code [...] A sophisticated set of heuristics helps choose among these execution modes based on dynamic feedback information gathered during actual execution of the code." This sounds a lot like Sun's "HotSpot" technology for Java VMs. Either way it sounds cool..
"the translator adds code whose sole purpose is to collect information such as block execution frequencies, or branch history."
There's hardware support to help the code morphing, ie support for exceptions, speculation, optimization of memory and for self-modifying code. All x86 registers are shadowed, there's a working and a shadow copy. As blocks of x86 code get translated, that page's entry in the Crusoe MMU (for the translation cache) is marked as "translated" so that it doesn't get translated again. A write (by x86 code, indicating self-modifying code) into that block causes that bit to be cleared.
The Crusoe processor voltage and clock (at least on the 5400) are accessible to the Code Morphing software, which can adjust them on the fly to optimize power/performance for the running app.
The TM 5400 is optimized for Windows but it'll run any x86 OS.
The neat thing, that I haven't seen anyone here pick up on yet, is that the Mobile Linux based web pads, etc, will have about a six-month lead over any Windows-based Crusoe machine -- that is, if you want a web pad (and they are cool looking machines), you get Linux. The 3120 is in production now, the 5400 won't be for another few months. (Oh, I suppose some manufacturer might decide to do a Windows-based machine on the the 3120, but it'd be more expensive: Windows license cost, hard drive for the OS (the Linux is ROMable), added development cost).
They also said that the VLIW instruction sets are different for the TM3120 and TM5400 chips, the Code Morphing Software has different back-ends for each chip (and is compiled to different targets).
But yeah, unless/until Transmeta releases the specs or someone reverse-engineers the instruction set, we won't see any do-it-yourself CPU emulators.
They did mention that one of the demos was a Crusoe running Java bytecode 'natively' (ie CMS translating bytecode directly to VLIW), so perhaps we will see some other CPU emulations in future.
However, the current architectures (and it wasn't clear whether this was of the chip or of the system the chip is in) don't seem to allow for dynamically switching instruction sets - once the thing has booted up the CMS code the pathways to that low level stuff are closed.
This makes sense for Transmeta at this point to keep the market from getting confused, but I hope that once this settles out that they start looking at making the thing more flexible.
Have they actually built any?
Yes. Started sampling last year. The 3120 is in production now and the 5400 will be in a few months. Mobile computer manufacturers have samples now.
The fact is, if you analyze a bumblebee according to the aerodynamics of fixed-wing vehicles, they can't fly worth a darn. This is correct -- when was the last time you saw a bumblebee glide?
The error of course is in the assumption that fixed-wing aerodynamics applies, and it doesn't. Analyze them by the aerodynamics of moving wing vehicles (which amounts to using helicopter aerodynamics, there being damn few ornithopters), and things work much better. (Still not strictly accurate, of course, insect wing flapping is pretty complex.)
Helicopters glide about as well as bumblebees when you stop the wings (blades).
I'll give you your (1) (maybe), but automatic footnoting is hardly a Microsoft innovation. I had it in my FORMAL portable text formatter back in 1979-1980ish, which I believe pre-dates Word 1.0. And I probably cribbed it from Waterloo Script or one of the other text processors around.
:)
As for "Bob", the less said the better
The list of forbidden weaponry is a bit ridiculous. There's a group around these parts (the Mad Scientists Club) that has run a "Critter Crunch" for over ten years at the annual MileHiCon and other venues. Their critters (bots) are limited to 20 pounds and a one-foot-cube (before combat start -they're free to expand after that), as much as anything to make it easy to find space for the combats.
Weaponry on various critters has included harpoons (tethered), flamethrowers, "elephant snot" (a superlubricant gel, used to deny the opponent any traction), strobes, silly-string (not very effective, but entertaining), as well as stuff like saws and forklifts. Highly entertaining. The size and weight constraints demand a lot of ingenuity.
Microsoft is a rock solid investment.
Yep, about as rock solid as Beanie Babies.
Consider: Microsoft pays no dividends, so real earnings per share (until you sell) is zero. Even if you look at Microsoft's reported earnings (which they don't share with stockholders as dividends anyway), earnings per share at todays share prices is pathetic. (Sure, there are others that do worse -- e.g. Amazon.com -- but that's hardly a guideline for investing.)
The only thing that makes Microsoft shares worth anything at all (since they have no inherent earning potential) is what other people might be willing to pay for them. Just like Beanie Babies.
If the fad blows over -- the market becomes disillusioned with MSFT -- the shares will be worth only slightly more than the paper they're printed on. (About $3/share cash, plus whatever an investment that earns about $1/share per year is worth. Call it about $20, tops -- and that's assuming that MSFT could maintain its business.)
No customer saw that dialog in any shipping copy of windows
Perhaps, perhaps not. Irrelevant in either case.
Members of the trade press did see that dialog in advance copies of Windows they may have received for review. If you're Joe ComputerCustomer and you read in Jerry X. Dvorak's ByteWeek column that he couldn't get Windows to work under DR-DOS (because of some wierd error) but could under MS-DOS, what are you going to think? "Better stay away from DR-DOS" is what.
MS didn't need to put that in the final shipping version because by then most of the damage had already been done.
(why is it that the US can have nuclear missiles in northern Canada, but the Russians can't have them in Cuba?)
Unless you have access to info that hasn't been made public, the only nuclear missiles in northern (or any other part of) Canada were Bomarcs and Genies, SAMs and AAMs respectively for shooting down bombers.
The missiles that (in part) prompted the basing of nukes in Cuba were Jupiter IRBMs based in Turkey, which in fact the US quietly withdrew as part of the deal that settled the Cuban missile crisis. (Of course they were largely obsolete by then anyway, with the development of e.g. Titan and Polaris ICBMs).
Heh. Time to implement my new .sig.
The man would be Tucker, the car would be the Tucker Torpedo.
Way ahead of its time in many ways, at least in initial design. Reports vary about how well the final product matched the initial design (mostly due to lack of start-up funds). The movie paints the established auto industry as the bad guys in this, they didn't want the competition. How accurate that is I don't know.
(That movie and story always reminds me of Gary Hudson and his repeated attempts (Phoenix, Roton, etc) at bringing a small reusable spaceship to market.)
For example, the Chernobyl reactor didn't "melt down", it caught fire. (It was a graphite-moderated design, it got hot enough for the graphite to catch fire. Nasty.)
And the Hindenberg "disaster" wasn't that bad -- most aboard actually survived, and zeppelins had been flying for years without incident before that. It just happened that there was a reporter present (and we know how often the news media get it right). There were numerous other air disasters they could have mentioned (like the DC-10 incident where an engine fell off, destroying hydraulic lines in the process. Turned out they'd been using a fork-lift to remove/replace the engine for servicing, messing up the mounting bolts).
And, Windows aside, perhaps the biggest computer-related screw up was the messed up deal between IBM and Motorola that ended up with IBM using the Intel 8088 instead of the Moto 68008 chip in IBM's first PC. (Accounts differ, one version has it that Moto refused to license the design to a second source, which IBM wanted.)
...The DeCSS program ... is a substantial derivation of confidential proprietary information which DVD CCA licenses pursuant to the CSS Agreement....
This is why DVD CCA cares about DeCSS. They don't really care about copies of DVDs, or whether a few Linux geeks meddle with DVD content. They care that DeCSS hits them where they live: their licensing fees.
Admittedly I'm speculating here, since I have no particular knowledge of how the DVDCCA licenses that weak cryptosystem to the DVD player manufacturers and DVD content providers. But let's assume that they get some (per copy?) royalty - or certainly at least some annual licensing fee - from the manufacturers and media companies. Now appears on the scene compatible encrypting/decrypting software that is free of DVDCCA's encumbrances. Kiss those licensing fees goodbye.
The company is going after the hackers, web site owners, et alia now because (a) they're seen as a softer target and (b) to preempt any abandonment of licensing by their existing customers. You can bet that if they waited until clients started switching to DeCSS code to sue (possibly for violation of contract terms?) they'd have a much tougher time of it (or think they would -- I don't think this is going to be as easy as they thought).
I don't know if this angle has been considered by anyone yet, and the hearing is going on right now, but it helps to have a good idea of your opponents real goals when getting involved in something like this.
Geez, that certainly takes the prize for absurdity.
I know folks who've been 'infringing' on this patent since years before it was issued (and before handheld lasers were readily available - this couple was into home holography). Mind, they had a dog, not a cat.
You've got to wonder why anyone would even bother paying the patent application fees for something (a) so obvious and (b) that they don't stand a hope in hell of ever collecting a royalty for.
An open source reverse engineered client for MSA might be acceptable to some, but what happens when MS changes the protocol with their next release?
:-), surely there are some good unpatented compression techniques we can use to get acceptable performance over 28K modems? (Perhaps it's because so many free software developers typically have much higher bandwidth connections, that we haven't seen free versions of this stuff yet?)
The community responded well, with PNG, when Unisys started enforcing the patent on GIF. Surely we can come up with an open source, open protocol server and client for audio (and perhaps later, video)?
I mean, come on, people. Sending audio over the net is nothing new (I've been doing it since Sparcstation 1 days, using "cat annoying-audio-file.au | rsh othermachine cat >/dev/audio" to bug coworkers
All those workerbees who listen to the radio over the net while at work aren't going to be accepting Linux on the desktop without it.
Thus, pass 10^16 numbers to one of the sites,
Not even that many. 10^14, tops. The first digit identifies the type of card (Visa, Amex, MC, etc) and the last digit is a checkdigit. (I used to know the formula for the checkdigit, since I coded software to check it, but that was years ago).
And I believe the next few digits after the first identify the issuing bank, so one could probably make educated guesses about that.
Not that there aren't a zillion other ways to just go ahead and steal real CC numbers, if one is so inclined.
Of course, in a couple of years, we might not be on the x86 anymore, toto. And if any of these proposed future chips execute Java bytecodes at hardware-lookin' speeds, watch out, Microsoft! :)
:)
(Insert Beowulf, Transmeta, Java/XML/C-- comment here
Interesting juxtaposition, there. If the Transmeta "Crusoe" chip does turn out to be a dynamically re-microprogrammable CPU, it could as easily remicroprogram itself to run Java bytecode natively as it could x86 code. More generally, whatever magic it does to run x86 code faster than an actual x86, it could also do to run Java bytecode faster than anything else out there.
Hmm...
I've found that the portability of Java is greatly exagerated. Taking a working Java app from an NT server to a different enviroment took several weeks. None of this was due to Microsoft, the app was written in 'pure' Java.
I've found just the opposite. Java apps that run painlessly across NT, W9x, Unix, Linux and MacOS without recompiling (and I'm not talking trivial demo applets, either). Yes, there are occasional problems, generally these turn out to be either JVM bugs (more a problem a few years ago than today) or, more often, sloppy coding (e.g. being careless about coding file names in a non-portable manner). That latter isn't a Java problem, it'd happen with any language. At least Java provides some fixes.
In addition, you have to considere the rapid pace at which Java seems to evolve. [...] Java 1.0 isn't compatable with Java 1.1, which isn't compatable with Java 2.
Not true. While some methods may be deprecated in later versions of Java, they still compile. More importantly, a Java 1.0 classfile still runs under a 1.1 or 1.2 JVM. The bytecode hasn't changed much.
All of this in a language which was released about 4 years ago?
Haven't been around new languages much, have you? The first few years of C++ were as bad, the original widely distributed version of the language didn't have either multiple inheritance or templates, and several then-legal C++isms are now deprecated (e.g. assignment to this, handy for walking a list). The same goes for just about every other new language, as wider usage turns up design flaws or omissions that the original language designer(s) hadn't thought of (or thought necessary).
Why did we need Java?
It's not just the GUI -- Java brings with it a slew of standard - really standard - libraries.
But beyond that, even though all us ubergeeks here code perfect C/C++, never leak memory or botch a pointer reference or run off the end of an array (yeah,right), there are plenty of programmers out there who do occasionally slip up, and writing in Java catches (or prevents) these omissions and thus the debug cycle is reduced. Fewer bugs is a good thing.
Further and more, C and/or C++ code won't run in a browser, unless you download a plug-in with all the security risks that entails. Browser apps are (in some contexts) a good thing.
There are other reasons. Personally I like Java's OO model better than C++'s. C++ has gotten a little crufty with age (I first learned it back when there were no C++ compilers, only cfront. IMHO it was better then.)
Besides, do you think Microsoft's implementation of <stdgui.h> would have been any more standard than what they did to Java?
You beat me to it.
Although, like "the Apollo 11 landing", the "recovery of Apollo 13" is a bit too broad and general to, IMO, qualify as a hack. It comprised several hacks, to be sure (as did the whole Apollo project), but we should look at them separately perhaps.
The single greatest hack of Apollo 13 was, I think, the kludging together of assorted baggies, spacesuit hoses, checklist covers and duct tape together with the (square) LiOH canisters from the CM to fit the (round) hole for the LM canisters.
The single greatest hack of the Apollo project -- which made it possible at all -- was probably the Lunar Orbit Rendezvous mission profile itself. That was championed by a lone engineer in the face of a lot of opposition that wanted Earth Orbit Rendezvous (requiring two Saturn V launches) or Direct Ascent (requiring a Nova-class booster).
Speech-recognition technology can't do this job even now (1993), and almost certainly won't in this millennium, either.
/. a couple of months ago) to flag specific conversations for analysis and the problem becomes downright simple.
Back in the early 1980s - I don't recall the exact year, call it 1983ish - I played briefly with a speech recognition system one of the profs at Concordia U (where I worked at the time) was developing. It ran on a VAX 11/780 (under VMS), input was via an A/D converter (I used the D/A side of it for sound effects for the game I programmed). It could recognize and parse continuous speech from a random speaker. The catch was that it couldn't do it in realtime, it took about fifteen minutes of processing for about five seconds of speech. Taking out the overhead of printing out all the steps it was taking in the analysis might have shaved a couple of minutes off of that.
But that was fifteen years ago, on a one MIPS machine. Modern machines with some preprocessing of the signal via DSP could do better than realtime. Add in the neural net system that can recognize certain keywords from the background noise even better than humans (mentioned on
Screening text messages by comparison is a piece of cake. A bit more of a challenge is the high volume of binary packets on the net -- most of them probably jpeg fragments from pr0n sites -- but those will have characteristic formats/patterns that distinguish them from, say, encrypted text. (Of course, steganography is becoming popular...)
I don't know what the KDE folks are targetting, but I can tell you that I've got a 16 MB, 66MHz 486 here on which KDE (1.1) certainly runs. It's really s-l-o-w to fire up new apps, of course, but it does run. (I'd say 16MB is a minimum, looking at my /proc/meminfo and /proc/swaps. Otherwise you'll really be thrashing.) (Note I don't usually use KDE on it, since it's primarily a server.)
Since KDE 2.0 is supposedly a little leaner, running on that hardware shouldn't be a problem.