From listening to the presentation, the only real changes for Linux are adding support for the LongRun power management software. It looks like Linux will still be running on it in x86 compatibility mode because immediately after bootup it shuts down access to the code morphing section. Basically it leaves the doors open long enough to download software bugpatches to the chip itself, then shuts down to avoid virus writers having a field day.
So Linux should run just fine. The binary compatibility issues are only because the underlying VLIW architecture could change out to anything, so the only thing that has to be recompiled is their code morphing software.
For that matter given the structure of the thing they could completely redesign the entire architecture of the system, risc to cisc, add dozens of registers, change every single internal opcode, shorten the bus, and as long as they could recompile their code morphing software to run on the new target they'll get binary compatibility with x86.
Linux doesn't run in microcode. It would be a cool effort to port to it, but from the comments made they will not be documenting that layer of the chipset at all.
At this point, its not even an OPTION for me to buy a movie on VHS any more. I own 3 dvd players (2 in computers, 1 standalone) but I do not own a (working) VCR any more.
This is a shame though, TPM is one of the few movies I was looking forward to picking up. Yeah I know it sucked, but lightsabres are cool.
You don't even need that really. What you need is the ability to lie about the AS that you belong to and start flooding peers of that AS with bogus routes until the peer runs out of memory.
Routers don't like it when they run out of memory, especially Ciscos. I ran into similar issues when I was implementing OSPF and accidentally killed a dozen Ciscos, a few Ascends and Portmasters with some miscrafted packets. Its harder to do with MD5 authentication in place though.
Each of the games mentioned use a PVS or a derivative thereof for visibility determination.
A PVS is not a perfect set, so there will still be some splash into the non-visible area. The client remains vulnerable to the same proliferation of aimbots, driver hacks and the ability to see around corners that has plagued Quake 1 since its inception.
Actually its not all that unreasonable of a solution, if you gave the server a tighter PVS than the client and sent things that were technically within the client's PVS but not likely to become visible you could cause a reasonable amount of confusion to the bot, on the other hand, if the bot has a reasonably simple bit of logic not allowing it to attempt to shoot through walls that won't help much, except to keep bots from leading people around corners.
Also, if you miss a packet or two and that 'phantom' winds up visible, it would be really disorienting to the player using the current protocols.
The only really nice thing about this proposed partial fix is it could be done on a server with no client side changes.
Your desktop weighs 20lbs because its a hell of a lot more computer than the 'paper computer' proposed by Willard.
You don't need a lot of smarts in a computer that really is just 3 sheets of paper with some circuitry in the middle that has a button for 'pay my phone bill' and an rf transmitter to bleep off the answer.
Battery life doesn't matter because its a one-shot item, hence its throwaway nature and materials.
I wouldn't expect one to have much of a life expectancy OTOH, and there are just too many issues with most potential applications of the system. If the RF broadcast missed or the post office creases the 'computer', the fact that its hard to get output to report a malfunction and you'd need a receiver in order to check to make sure your broadcast got through to be really safe for most applications and the fact that quickie contact keys like the ones described are prone to stick.
The question is, given that you aren't going to be able to put much processing power at all in the 'computer', is there enough that you CAN put in to make it worth the manufacturing cost for any real world application?
It is refreshing to see a legitimate patent application (or two) for a change though.
If you leave the standardization process in place and don't trample their Java trademark, they really could care less what you implement that sort of follows their standard. I have agreed(throughout each of the posts I've made on this subject so far) that I believe they opensourcing the Java code would be a good thing for Java's stability and development process. I simply do believe that they will ever open the Java name to anything that does not pass their centralized testing because it just wouldn't make business sense for Sun to let their name be dragged through the mud by Tom, Dick and Harry's JVM.
There still remains the issue that in the face of open source they may not be able to garner the funding to continue their standards testing in the current manner and after all Sun is a corporation and has investors to consider, they still have to try to turn a profit. They have to appease their shareholders, not the FSF. I'm not saying that this precludes Sun opensourcing Java, but it is a potential issue that remains to be addressed.
I do not believe that I missed his point. I agree about open sourcing java. I agree that Sun was way out of line on the Blackdown issue and the SCPL is a slavedriver license.
I disagree that the situation should be a free-for-all-write-whatever-you-want-and-call-it-J ava clusterf*ck.
You CAN already write a cleanroom JVM and implement the Java standard library. (As RMS himself pointed out there are already several such versions floating around).
Java(tm) is a Trademark. The trademark belongs to Sun, the name is their intellectual property like it or not to do with as they please.
The standards testing process is only necessary to use the Java name.
Stallman's call to allow users to implement compatibility or not is irrelevant as long as you don't call your product 'Java'. The name Java is already watered down enough by Microsoft's misimplementation of it.
Going GPL and saying do whatever the hell you want with it and you can still call it Java would be a death knell for the 'brand' Java.
At this point having the 100% Pure Java seal of approval or right to call a product Java is a right that Sun controls. Its their trade mark, they can do that.
Sun has a lot of their credibility tied up in their association with the Java name, and if they let Joe on the corner write his Java(tm) virtual machine and call it Java with no screening or compatibility testing the brand would lose all distinction and they could lose the trademark and people would run roughshod over the Sun name with Java* this-that-and-the-other all of which being in varying states of compatibility and everything done with Java in the title ruining Sun's credibility.
In other words, Sun isn't going to give up control of the Java name to the FSF or the ECMA standards commitee. The have too much of their company's credibility on the line.
Open sourcing it is not a bad idea, but would have to be done carefully given Sun's investment in the trademark.
Re:Please moderators, tell me what is Insightful h
on
RMS on Java and GPL
·
· Score: 1
Just because he's the founder of the free source foundation and author of gcc, doesn't mean that the guy can't occasionally be wrong.
I am glad that someone like RMS exists. He says a lot of things that need to be said. I even agree that open sourcing the java standard library might be a good thing and the JVM for that matter. However by not charging for them they might not be able to adequately fund their testing process or survive in the face of the rest of their business model crumbling.
My objection was to the blanket statement made at the conclusion of his point of view article that java should permit unlimited technical changes.
Java's future is rocky enough as it is without worrying about 2 dozen incompatible environments (having both the Sun and MS schools of thought is bad enough)
RMS seems to be mouthing off about God and everything lately.
Now I love open source and free software as much as the next guy, and while Sun's decision to pull Java out of the standardization process kind of pissed on my cornflakes, I can take it in stride.
But whats with RMS's insistance that open source will fix every ill known to man? Open sourcing java and removing the standardization process would aggravate the embrace and extend problem that they are already facing from microsoft.
Every little embedded java implementor would go off and add little extensions to improve their implementation and it would fragment into a ton of insular groups each convinced that their way is the right way, like early c compilers.
Java's licensing is all about maintaining a portable compatible development environment. I agree their methodology is a little flawed, but throwing standardization to the wind is not IMNSHO a good policy.
If you want to implement your non-Sun 'java' implementation, go ahead, just don't call it 'Java' and you can change until your heart's content.
I suppose open sourcing java itself wouldn't be all that bad from a bug-fix standpoint, but RMS's call for 'permitting unlimited technical changes' is opening a can of worms that Sun (understandably) would rather keep well sealed.
AT&T's (and OmniSky's coverage) is pretty much limited to major metropolitan areas, which is fine for my purposes. (I travel on business occasionally) The Ricochet system another poster mentioned is unfortunately pretty much a geographically limited novelty.
I've been considering building my own Wearable for a while now. (off and on)
I'm leaning towards something around the power level of the Palm Vx or Handspring Visor Deluxe (the Springboard port has definite possibilities) with text to speech hardware. I haven't been able to try out any of those one-handed keyboards, but I would think that a braille keyboard (6 keys plus space, used 3 per hand could be broken apart and set 3 keys to a hip (or palm) for data entry in a pinch.
Then again maybe that onhandpc thing had the right idea in only really gearing up for data retrieval rather than data entry.
I considered using the Qualcomm pdQ as a base for one at one point, except the pdQ has its own proprietary undocumented connector and appears that Qualcomm is going to drop support to move to a CE platform. (Also, it doesn't help that the pdQ only transfers data CDMA (14.4kbps and the only carrier in my area that supports it is Sprint, and they charge by the minute)
Using a PDA for the heart of it would allow me to remove the 'getup' and still carry the information I want.
My journada has too much bulk for me to consider carrying something like that as a starting point.
I have a bunch of serial controllable LED displays that I could use for information sources
That parachute PCMCIA adaptor for the palm might be a place to start, when they ship it atleast, but that would rule out a handspring module and it probably would require some jerrymandering to fit together with a CDPD modem in place.
The question is then if I can fit a dual serial uart and a speech synth chip into a springboard module.
If you're looking for affordable internet access for your wearable, you might consider investigating CDPD (Cellular Digital Packet Data)
CDPD is used in the Palm III's Minstrel, and the new Palm V Omnisky Minstrel [www.omnisky.com]). If I recall there are a couple of PCMCIA type II and III cards that support it as well (the Spider comes to mind)
AT&T has 'unlimited' service for it at around $25/month for the palm $55/month for other devices in many areas (called AT&T Wireless IP Service) and it gives you a 19.2k TCP/IP stack.
The service is damn near ideal for wearable/pda use, so, I wouldn't go so far as to say there are no options for internet connectivity.
Slashdot Mirror
So Linux should run just fine. The binary compatibility issues are only because the underlying VLIW architecture could change out to anything, so the only thing that has to be recompiled is their code morphing software.
For that matter given the structure of the thing they could completely redesign the entire architecture of the system, risc to cisc, add dozens of registers, change every single internal opcode, shorten the bus, and as long as they could recompile their code morphing software to run on the new target they'll get binary compatibility with x86.
Linux doesn't run in microcode. It would be a cool effort to port to it, but from the comments made they will not be documenting that layer of the chipset at all.
This is a shame though, TPM is one of the few movies I was looking forward to picking up. Yeah I know it sucked, but lightsabres are cool.
Assuming they encode the resulting coeffiencients properly, yes.
Routers don't like it when they run out of memory, especially Ciscos. I ran into similar issues when I was implementing OSPF and accidentally killed a dozen Ciscos, a few Ascends and Portmasters with some miscrafted packets. Its harder to do with MD5 authentication in place though.
A PVS is not a perfect set, so there will still be some splash into the non-visible area. The client remains vulnerable to the same proliferation of aimbots, driver hacks and the ability to see around corners that has plagued Quake 1 since its inception.
Also, if you miss a packet or two and that 'phantom' winds up visible, it would be really disorienting to the player using the current protocols.
The only really nice thing about this proposed partial fix is it could be done on a server with no client side changes.
You don't need a lot of smarts in a computer that really is just 3 sheets of paper with some circuitry in the middle that has a button for 'pay my phone bill' and an rf transmitter to bleep off the answer.
Battery life doesn't matter because its a one-shot item, hence its throwaway nature and materials.
I wouldn't expect one to have much of a life expectancy OTOH, and there are just too many issues with most potential applications of the system. If the RF broadcast missed or the post office creases the 'computer', the fact that its hard to get output to report a malfunction and you'd need a receiver in order to check to make sure your broadcast got through to be really safe for most applications and the fact that quickie contact keys like the ones described are prone to stick.
The question is, given that you aren't going to be able to put much processing power at all in the 'computer', is there enough that you CAN put in to make it worth the manufacturing cost for any real world application?
It is refreshing to see a legitimate patent application (or two) for a change though.
There still remains the issue that in the face of open source they may not be able to garner the funding to continue their standards testing in the current manner and after all Sun is a corporation and has investors to consider, they still have to try to turn a profit. They have to appease their shareholders, not the FSF. I'm not saying that this precludes Sun opensourcing Java, but it is a potential issue that remains to be addressed.
I disagree that the situation should be a free-for-all-write-whatever-you-want-and-call-it-J ava clusterf*ck.
You CAN already write a cleanroom JVM and implement the Java standard library. (As RMS himself pointed out there are already several such versions floating around).
Java(tm) is a Trademark. The trademark belongs to Sun, the name is their intellectual property like it or not to do with as they please.
The standards testing process is only necessary to use the Java name.
Stallman's call to allow users to implement compatibility or not is irrelevant as long as you don't call your product 'Java'. The name Java is already watered down enough by Microsoft's misimplementation of it.
Going GPL and saying do whatever the hell you want with it and you can still call it Java would be a death knell for the 'brand' Java.
At this point having the 100% Pure Java seal of approval or right to call a product Java is a right that Sun controls. Its their trade mark, they can do that.
Sun has a lot of their credibility tied up in their association with the Java name, and if they let Joe on the corner write his Java(tm) virtual machine and call it Java with no screening or compatibility testing the brand would lose all distinction and they could lose the trademark and people would run roughshod over the Sun name with Java* this-that-and-the-other all of which being in varying states of compatibility and everything done with Java in the title ruining Sun's credibility.
In other words, Sun isn't going to give up control of the Java name to the FSF or the ECMA standards commitee. The have too much of their company's credibility on the line.
Open sourcing it is not a bad idea, but would have to be done carefully given Sun's investment in the trademark.
I am glad that someone like RMS exists. He says a lot of things that need to be said. I even agree that open sourcing the java standard library might be a good thing and the JVM for that matter. However by not charging for them they might not be able to adequately fund their testing process or survive in the face of the rest of their business model crumbling.
My objection was to the blanket statement made at the conclusion of his point of view article that java should permit unlimited technical changes.
Java's future is rocky enough as it is without worrying about 2 dozen incompatible environments (having both the Sun and MS schools of thought is bad enough)
Now I love open source and free software as much as the next guy, and while Sun's decision to pull Java out of the standardization process kind of pissed on my cornflakes, I can take it in stride.
But whats with RMS's insistance that open source will fix every ill known to man? Open sourcing java and removing the standardization process would aggravate the embrace and extend problem that they are already facing from microsoft.
Every little embedded java implementor would go off and add little extensions to improve their implementation and it would fragment into a ton of insular groups each convinced that their way is the right way, like early c compilers.
Java's licensing is all about maintaining a portable compatible development environment. I agree their methodology is a little flawed, but throwing standardization to the wind is not IMNSHO a good policy.
If you want to implement your non-Sun 'java' implementation, go ahead, just don't call it 'Java' and you can change until your heart's content.
I suppose open sourcing java itself wouldn't be all that bad from a bug-fix standpoint, but RMS's call for 'permitting unlimited technical changes' is opening a can of worms that Sun (understandably) would rather keep well sealed.
I could see that if it was a big time e-retailer or Ford or something, but not at the scale of the outfit they were describing.
I've been considering building my own Wearable for a while now. (off and on)
I'm leaning towards something around the power level of the Palm Vx or Handspring Visor Deluxe (the Springboard port has definite possibilities) with text to speech hardware. I haven't been able to try out any of those one-handed keyboards, but I would think that a braille keyboard (6 keys plus space, used 3 per hand could be broken apart and set 3 keys to a hip (or palm) for data entry in a pinch.
Then again maybe that onhandpc thing had the right idea in only really gearing up for data retrieval rather than data entry.
I considered using the Qualcomm pdQ as a base for one at one point, except the pdQ has its own proprietary undocumented connector and appears that Qualcomm is going to drop support to move to a CE platform. (Also, it doesn't help that the pdQ only transfers data CDMA (14.4kbps and the only carrier in my area that supports it is Sprint, and they charge by the minute)
Using a PDA for the heart of it would allow me to remove the 'getup' and still carry the information I want.
My journada has too much bulk for me to consider carrying something like that as a starting point.
I have a bunch of serial controllable LED displays that I could use for information sources
That parachute PCMCIA adaptor for the palm might be a place to start, when they ship it atleast, but that would rule out a handspring module and it probably would require some jerrymandering to fit together with a CDPD modem in place.
The question is then if I can fit a dual serial uart and a speech synth chip into a springboard module.
And dangit, this still won't let me play mp3s =)
CDPD is used in the Palm III's Minstrel, and the new Palm V Omnisky Minstrel [www.omnisky.com]). If I recall there are a couple of PCMCIA type II and III cards that support it as well (the Spider comes to mind)
AT&T has 'unlimited' service for it at around $25/month for the palm $55/month for other devices in many areas (called AT&T Wireless IP Service) and it gives you a 19.2k TCP/IP stack.
The service is damn near ideal for wearable/pda use, so, I wouldn't go so far as to say there are no options for internet connectivity.