Unfortunately, it's probably apocryphal. I honestly and SERIOUSLY doubt that IBM, let alone Cravath, would be party to extortion of any kind- and the story describes that very practice in question, which is a felony in most jurisdictions for good reasons.
You can call it "leverage", but in the end, it's still just extortion.
Now. Especially if you're using one of the Honeycomb tablets. You can run it with X86 Android now on any desktop with the proviso that you just simply can't run NDK derived stuff without having someone provide you with the X86 native code variants for that Android image/distribution.
Heh... Think of Hildon as GNOME Mobile, more or less. That was what Nokia was aiming for when they did it originally.
As it stands, Android is a Linux distribution with a specific and unique App framework that runs under the Dalvik VM.
That's why Canonical was able to make an execution environment that the dev threw his hands up in disgust over- he'd arrived at the conclusion that it was "open" in one sense and not another. For example, you can't get the market app and a few other things except by jiggery-pokery or permission from Google themselves. There's a few other gotchas to doing what Canonical tried for- NDK work won't work directly (This doesn't preclude trickery to call into Qemu or similar, though...) on an X86 system, for example.
In the end...the only thing that makes Android "special" is that the mobile device players went with it instead of Maemo/Meego because it was more "ready" first, combined with more of a closed (which I allude to...) world than the other provided- and it was a bit more restricted than the other answers at the time it came out. The main reason that tablets are using it instead of some other bespoke Linux variant right at the moment is more inertia and app availability than anything else.
Yes and no. Post it note on a monitor means that they have physical access to the premises which does not equate to physical access to the machine, per se. I can assure you...interview in a cube or office where they've done that and it's seen doesn't equate to physical access to the machine. You presume that there's no other ability to access the network, etc. which would be incorrect.
It's not quite that simple... If you make a hash/crypto scheme that will be less vulnerable to this, you make it much more difficult to use it as a means for passwords in the first place as it's much more difficult to compute for authentication.
Heh... Hashes ARE effectively one-way encryption with comparison of the cyphertexts. This isn't a problem of the hash itself compromising the problem- this is a brute force attack where you have the hash and you're iteratively going through each and every possibility, hashing it up and comparing it. If you did what you proposed, it'd be little different for this attack. It's just simply that the cheap GPUs make it simple and cheap. They've had this capability to attack things like WPA-PSK this way for a while, using a Virtex5 FPGA to empower a low-end Celeron laptop to smash through the keyspace on an access point in minutes.
That's because the Second gives arms to the people...if you put this in the perspective of the quote I put in my comment to the parent, it makes a bit more sense.
My "chief aversion" is the system of greed, private profit, privilege, and violence which makes up the control of the world today, and which has brought it the tragic crisis of unprecedented hunger and unemployment. I am opposed to the new deal [sic] because it strives to strengthen and prolong production for private profit. At bottom I am for conserving the full powers of every person on earth by expanding them to their individual limits. Therefore, I am for socialism, disarmament, and ultimately for abolishing the State itself as an instrument of property, the abolition of the propertied class and sole control by those who produce wealth. Communism is the goal. It sums up into one single purpose -- the abolition of the system dog-eat-dog under which we live, and the substitution by the most effective non-violence possible of a system of cooperative ownership and use of all wealth.
- Roger Nash Baldwin, founder of the ACLU.
Do you HONESTLY believe that they're really on about the things you think they are?
The first one's a given- part of the problem is the compositor, part of it is the GPU... The second one's less the compositor and more the GPU driver (don't have this problem on all AMD devices and so far none of my NVidia ones...) The last is more a problem with the driver and you'd have it on select 2D-only setups as well.
That's because you're thinking that full-screen magically turns off the context that they're using in the desktop compositing process or that the desktop has quit running- which isn't what's going on. Each separate rendering context will use GPU resources, from memory to cycles if there's any activity going on in the background (Which is surely going on...it's part of why gaming performance on Fi...er...Vista was 20-40% lower at release when compared to XP.). How badly it does this is a noxious mix of the driver and the app using the same, whether it's the game or the compositing engine. It's the price you pay for 3D driven eye-candy.
If it's not as usable as it ought to be, it won't get used as much- and more to the point, if it's in this sort of state, it probably ought not to have been fielded in the first place...Unity or Gnome Shell. Seriously.
How about this... IMPACT Government Services. Because of all the BAD decisions they've made over the last decade or two, they're broke. Mugging people for more money isn't going to fix things, it's either going to prolong it or worse (Think in terms of someone that gets a consolidation loan just to go back doing the things they were doing that PUT them in the mess they were in...). I'm of the opinion that they need to realize that their cherished "progressive" ways and means aren't going to make things better and they need to start deciding just exactly WHAT needs to go.
In the case of Harmony, it was an attempt to make a cleanroom implementation of the Java Classlib. In this case, it's Oracle looking like they're just handing it all over to them, lock, stock, and barrel. If so, there's no trap to be had.
I think that has less to do with TI and more to do with ARM not divulging all the info to drive the TrustZone feature- it requires kernel support (obviously) and therefore unless ARM lets the info loose, you're not getting it- otherwise you could just recompile the kernel to use it- in spite of TI's "not releasing it".
When you realize that this will be FASTER than the Atom board and consume roughly 1/10th the power and allow you to target tablets and handhelds...something that the Atom won't do...it becomes a bit more interesting. At least to some people. Never mistake your values for everyone else's.
Yes, you can. In fact, there's several Mac/Win/Linux clients available. However, Ekiga.net's configuration's problematic with at least a few SIP clients- it relies on STUN to obtain the public IP for register with the service (Which is the OLD way of doing things and is a deprecated mode of operation per RFCs...). Jitsi, a likely cross-platform candidate (as it's in mostly java with the Video/Audo streaming handled by JNI driven native code...), only supports the new tech, "ICE", to traverse NAT firewall configurations and the SIP support's not yet fully implemented. As a result, you can't register Jitsi and a few other SIP clients on Linux and MacOS with Ekiga.net. If they'd reconfigure things, they could handle anyone. Jitsi suggests iptel.org as the SIP registar and router service instead of Ekiga.net. In truth, as long as you can find a SIP service that will work with your client, you SHOULD be able to set up calls with most other clients on other services as long as you know what service they're on. Beauty of SIP- and XMPP is a similar story.
It's very obvious he's not had this dubious joy experienced yet- else he'd not be making this comments. There IS a reason I'm looking for alternatives.
There's two sets of answers right at the moment:
Pick a SIP based service that's "free" that will work with Ekiga or Jitsi (or a host of others on Linux...). Pick Google Talk and use something on the Linux/MacOS side like Pidgin or Jitsi (or perhaps the web plugin...) and use the web plugin or the desktop GTalk app.
Everything else is mainly Windows only right at the moment.
Heh... They're "thinking" about using crypto on things like the radio links. They're "concerned" about things like "latency" (Here's a hint, if you're worried about injecting a 1-2 character's worth of transmission time delay at 9600 baud, you're doing it wrong.) so the industry's been reticient at trying to at least lock down some aspects of the remote links. Biggest problem is the downtime of some systems in addition to the overall expense of things while they retrofit to higher data rates, end-to-end crypto (and not the security mode of DNP3 and other SCADA device protocols...), and security monitoring. Most of the "smart grid" security model's been predicated on security through obscurity and authenticated command and control with data being plaintext in most cases because that's the "least expensive" solution to the "problem".
Slashdot Mirror
Unfortunately, it's probably apocryphal. I honestly and SERIOUSLY doubt that IBM, let alone Cravath, would be party to extortion of any kind- and the story describes that very practice in question, which is a felony in most jurisdictions for good reasons.
You can call it "leverage", but in the end, it's still just extortion.
Now. Especially if you're using one of the Honeycomb tablets. You can run it with X86 Android now on any desktop with the proviso that you just simply can't run NDK derived stuff without having someone provide you with the X86 native code variants for that Android image/distribution.
Heh... Think of Hildon as GNOME Mobile, more or less. That was what Nokia was aiming for when they did it originally.
As it stands, Android is a Linux distribution with a specific and unique App framework that runs under the Dalvik VM.
That's why Canonical was able to make an execution environment that the dev threw his hands up in disgust over- he'd arrived at the conclusion that it was "open" in one sense and not another. For example, you can't get the market app and a few other things except by jiggery-pokery or permission from Google themselves. There's a few other gotchas to doing what Canonical tried for- NDK work won't work directly (This doesn't preclude trickery to call into Qemu or similar, though...) on an X86 system, for example.
In the end...the only thing that makes Android "special" is that the mobile device players went with it instead of Maemo/Meego because it was more "ready" first, combined with more of a closed (which I allude to...) world than the other provided- and it was a bit more restricted than the other answers at the time it came out. The main reason that tablets are using it instead of some other bespoke Linux variant right at the moment is more inertia and app availability than anything else.
Considering that VC++ compiles to native or CLR how would you know?
And I'm needing chest-waders for all this BS and bad "science".
Yes and no. Post it note on a monitor means that they have physical access to the premises which does not equate to physical access to the machine, per se. I can assure you...interview in a cube or office where they've done that and it's seen doesn't equate to physical access to the machine. You presume that there's no other ability to access the network, etc. which would be incorrect.
It's not quite that simple... If you make a hash/crypto scheme that will be less vulnerable to this, you make it much more difficult to use it as a means for passwords in the first place as it's much more difficult to compute for authentication.
Heh... Hashes ARE effectively one-way encryption with comparison of the cyphertexts. This isn't a problem of the hash itself compromising the problem- this is a brute force attack where you have the hash and you're iteratively going through each and every possibility, hashing it up and comparing it. If you did what you proposed, it'd be little different for this attack. It's just simply that the cheap GPUs make it simple and cheap. They've had this capability to attack things like WPA-PSK this way for a while, using a Virtex5 FPGA to empower a low-end Celeron laptop to smash through the keyspace on an access point in minutes.
I'd be aiming for that and trying to get the FBI to pursue an investigation of violations of 18 USC 242 (Deprevation of Rights Under Color of Law).
Did you happen to have that sort of torrent with the Xoom or the Iconia Tab A500?
That's because the Second gives arms to the people...if you put this in the perspective of the quote I put in my comment to the parent, it makes a bit more sense.
Do you HONESTLY believe that they're really on about the things you think they are?
How about getting RID of MotoBlur...it was one of the problems causing the performance issues to BEGIN WITH.
I'm thinking E17, myself... :-D
The first one's a given- part of the problem is the compositor, part of it is the GPU...
The second one's less the compositor and more the GPU driver (don't have this problem on all AMD devices and so far none of my NVidia ones...)
The last is more a problem with the driver and you'd have it on select 2D-only setups as well.
That's because you're thinking that full-screen magically turns off the context that they're using in the desktop compositing process or that the desktop has quit running- which isn't what's going on. Each separate rendering context will use GPU resources, from memory to cycles if there's any activity going on in the background (Which is surely going on...it's part of why gaming performance on Fi...er...Vista was 20-40% lower at release when compared to XP.). How badly it does this is a noxious mix of the driver and the app using the same, whether it's the game or the compositing engine. It's the price you pay for 3D driven eye-candy.
Uh...here's a hint...
If it's not as usable as it ought to be, it won't get used as much- and more to the point, if it's in this sort of state, it probably ought not to have been fielded in the first place...Unity or Gnome Shell. Seriously.
How about this... IMPACT Government Services. Because of all the BAD decisions they've made over the last decade or two, they're broke. Mugging people for more money isn't going to fix things, it's either going to prolong it or worse (Think in terms of someone that gets a consolidation loan just to go back doing the things they were doing that PUT them in the mess they were in...). I'm of the opinion that they need to realize that their cherished "progressive" ways and means aren't going to make things better and they need to start deciding just exactly WHAT needs to go.
In the case of Harmony, it was an attempt to make a cleanroom implementation of the Java Classlib. In this case, it's Oracle looking like they're just handing it all over to them, lock, stock, and barrel. If so, there's no trap to be had.
I think that has less to do with TI and more to do with ARM not divulging all the info to drive the TrustZone feature- it requires kernel support (obviously) and therefore unless ARM lets the info loose, you're not getting it- otherwise you could just recompile the kernel to use it- in spite of TI's "not releasing it".
When you realize that this will be FASTER than the Atom board and consume roughly 1/10th the power and allow you to target tablets and handhelds...something that the Atom won't do...it becomes a bit more interesting. At least to some people. Never mistake your values for everyone else's.
Yes, you can. In fact, there's several Mac/Win/Linux clients available. However, Ekiga.net's configuration's problematic with at least a few SIP clients- it relies on STUN to obtain the public IP for register with the service (Which is the OLD way of doing things and is a deprecated mode of operation per RFCs...). Jitsi, a likely cross-platform candidate (as it's in mostly java with the Video/Audo streaming handled by JNI driven native code...), only supports the new tech, "ICE", to traverse NAT firewall configurations and the SIP support's not yet fully implemented. As a result, you can't register Jitsi and a few other SIP clients on Linux and MacOS with Ekiga.net. If they'd reconfigure things, they could handle anyone. Jitsi suggests iptel.org as the SIP registar and router service instead of Ekiga.net. In truth, as long as you can find a SIP service that will work with your client, you SHOULD be able to set up calls with most other clients on other services as long as you know what service they're on. Beauty of SIP- and XMPP is a similar story.
Be that as it might be...the odds of a Linux client seeing those improvements are slim to none...and I think slim took a sabbatical...
Ah, for want of mod points... :-D
It's very obvious he's not had this dubious joy experienced yet- else he'd not be making this comments. There IS a reason I'm looking for alternatives.
There's two sets of answers right at the moment:
Pick a SIP based service that's "free" that will work with Ekiga or Jitsi (or a host of others on Linux...).
Pick Google Talk and use something on the Linux/MacOS side like Pidgin or Jitsi (or perhaps the web plugin...) and use the web plugin or the desktop GTalk app.
Everything else is mainly Windows only right at the moment.
Heh... They're "thinking" about using crypto on things like the radio links. They're "concerned" about things like "latency" (Here's a hint, if you're worried about injecting a 1-2 character's worth of transmission time delay at 9600 baud, you're doing it wrong.) so the industry's been reticient at trying to at least lock down some aspects of the remote links. Biggest problem is the downtime of some systems in addition to the overall expense of things while they retrofit to higher data rates, end-to-end crypto (and not the security mode of DNP3 and other SCADA device protocols...), and security monitoring. Most of the "smart grid" security model's been predicated on security through obscurity and authenticated command and control with data being plaintext in most cases because that's the "least expensive" solution to the "problem".