Heh... I do believe that you could re-purpose it for that. Not terribly hard since they're using a stripped down Linux (Think Angstrom...) with just the browser as largely it's sole functionality.
For most web apps, you only need Java or Flash, unless you're talking about a ActiveX type component.
Seriously.
And if you're talking ActiveX, either you're doing WINE or Windows (Linux has to use WINE and CE need not apply here- won't have support there...;-) )- since most of the relevant websites that one would use a WebTablet on don't use ActiveX and one of the two aforementioned other "binary only" applications- then you're covered even with ARM.
It burns through batteries at a rate at least 4-5 times that of a similarly decked out ARM OMAP3 machine.
The only thing going for a Nano is that it's a decent performing low-power x86- pretty much the first credible one in a long, long time. If you're caring less about x86 support (and for this, you probably wouldn't...) and more about credible with real battery life, neither Atom or Nano make the cut.
You're talking the difference between an atomic bomb and a conventional dispersal weapon that spreads nuclear materials that've been weaponized and present a serious health hazard if you breathe in the dust.
In the parent poster's case, if they render unto aerosol the same 13.6 pounds of plutonium, it will be weeks and months before the main mess is cleaned up properly- and if any of the dust is missed, it'll be 100,000 years before it becomes "safe"- and there'll be stuff they miss, rest assured of it. If you bring in a smallish amount of that dust in you're lungs, you're toast.
You'll probably not want to stay there, if the truth's known, because of that little detail.
This depends on whether it's finely powdered or not. Get it dispersed into the air as an aerosol, and you've got a bigger danger.
You can clean the "immediate" area for most of it, but the dust will linger for long times and be an inhalation risk- breathe in any bit of that dust and you're screwed. Done right, it would be much closer to how the parent poster describes than how you frame it.
Considering that they're going to do it ANYWAY if they think you're sharing, no matter how they come upon that twisted notion...
The hypothetical arguments everyone keeps flipping around keep missing the point- RIAA is suing people on tenuous information, no matter what the source of that tenuous information.
Reducing the sources for having them bark up the wrong tree helps but does NOTHING to keep you from getting sued at one point over false allegations.
Removing the problem altogether is a better answer- they shouldn't be off doing this crap in the first place. (To be sure, neither should the sharers, but that's a different discussion...)
As someone facing a similar situation at his day job, 2.4 is painful in some regards. In my case, 2.6 allows me to do a non-standard initramfs (the stock is minimal and then you can load other initrd or initramfs images from the kernel options...) so that I can tapdance around the three differing hackish bootloaders they did in 2.4. This allows me to do major cleanups in what they did for doing NFS rootfs on the IXP2800 blades and on the X86 ones with minimal pain.
Most of the people commenting on 2.6 being too big are thinking of the whole size with everything loaded up. Minimal kernels with just your drivers loaded and only your drivers in the module build, you end up with only about 5-10% increase in footprint in memory and store space, with the ability to provide modern device support for things. In the case of what you mention, you're moving to an Atom based machine board. Given that you're moving to a modern board, the odds of things being "nicely" supported is lower with the 2.4 kernel.
Since you're manipulating large volumes of data over GigE, you're going to want to switch, probably even with the old ARM stuff if you can manage it. 2.6 provides much more responsive networking performance (so long as you do your network code right and don't dink with the scheduler (heh...let's just say I corrected a not so good idea there recently...)).
You may have to port a few custom drivers over to 2.6, but in the end, it'll work better since the driver architecture is better in 2.6.
Embedded systems encompass a LARGE range of systems. Some of those systems need a filesystem (such as an MP3 player or a NAS server...), some need them less, but it makes some tasks within the space easier.
Not all embedded systems are PICs or similar. Your mobile phone is an embedded device, but I'd shudder to try to code that all with "traditional" embedded techniques and practices. Same goes for a whole host of things that are considered to be embedded.
It's more because the fixtures have been fielding much lower lumen-per-watt devices than the CFL's, coupled with people trying to huckster people into believing that their LED's are 35 watt and 45 watt equivalents when the devices they're selling actually do good to perform like 15-25 watt devices.
Rayovac just recently fielded the first 300 lumens output LED lantern on the market. It is comparable to a 35 watt incandescent bulb for only 4 watts of capacity. It's only a small-ish step to higher capacities that DO fill the room. It's just that it's still quite a bit pricier than one would normally like to spend on them.
It depends on your situation. In Texas, someone was obligated to hand something over that wasn't the company's, wasn't developed with their resources, and had nothing to do with his work or their lines of business- just because he signed one of those things. Non-competes are largely unenforceable here, but IP assignments, etc. are a differing story. You can NEVER presume there's no legal basis for anything without a lawyer vetting that position for you.
That would be correct. The thing is, that you CAN compromise some of the other needed stuff as well (which would be the MItM part...) and this CA that isn't following official stated procedures would be all you'd need to cover up the fact that it'd been done.
I'd have to concur there. Each and every one of the CA certs associated with Comodo in Firefox 3 is being purged from my trusted lists on all my machines as I type this.
What they just did is bogus- this stuff only works when you follow the steps to the letter and everyone else does the same. I hope there's a CA cert revocation coming down the pike for Comodo and all it's affiliated CA's (There's about 5 of them in my list on my machine here...). Once you screw up like this, you honestly can't trust the current certs from them and it's difficult to trust them in the future.
Heh... The biggest question I would have is that how are they going to get legit PI licenses to investigate all of that; they can't have this plan without breaking the law in the same manner they've been doing with the lawsuits themselves. And with this plan, now they're involving the ISPs with those civil liabilities. Nice...
If I were an ISP, I'd tell them to go stuff themselves unless they had proof obtained in a manner that a court of law would consider legit.
Because "illegal" isn't just criminality. It's also conceivably tortious, meaning you can have civil law violations.
Infringement can either be tortious, criminal, or both. There's truthfully no way for them to pin criminal charges on anyone they've "caught" in that "dragnet" of theirs, so they're trying for civil violations which have less stringent requirements for proving a tort was committed by the parties. Unfortunately for them, they don't have much of a valid case in any of the instances so they're folding when push comes to shove, relying on the costs to crush anyone that doesn't settle up with them.
Heh... You'd just have other exploitable issues, either within the Java JVM or in poorly written code- just not the same class of them. I don't place blind faith in a language to clean up after myself.
This isn't backing out. If you understood what Net Neutrality actually meant, you'd understand that this is quite a bit different.
In the Google story, all they're doing is putting dumb bit shovels closer to you.
In the thing that people for 'net neutrality' are talking about, the ISP gives higher priority to the content THEY provide and unless you pay tribute to each ISP, they do nothing or actually degrade your priority, meaning you stuff gets to you slower or not at all- depending on whether it's the ISP's crap or your content provider paid their danegeld.
Slashdot Mirror
I wish we COULD mod that one up well past +5. It's spot-on with what's wrong.
Heh... I do believe that you could re-purpose it for that. Not terribly hard since they're using a stripped down Linux (Think Angstrom...) with just the browser as largely it's sole functionality.
No... Nokia contracted with Adobe to produce a proper ARM Linux binary just for the Nxxx web tablets.
Aaand you're missing the point.
For most web apps, you only need Java or Flash, unless you're talking about a ActiveX type component.
Seriously.
And if you're talking ActiveX, either you're doing WINE or Windows (Linux has to use WINE and CE need not apply here- won't have support there... ;-) )- since most of the relevant websites that one would use a WebTablet on don't use ActiveX and one of the two aforementioned other "binary only" applications- then you're covered even with ARM.
It's faster, yes.
It burns through batteries at a rate at least 4-5 times that of a similarly decked out ARM OMAP3 machine.
The only thing going for a Nano is that it's a decent performing low-power x86- pretty much the first credible one in a long, long time. If you're caring less about x86 support (and for this, you probably wouldn't...) and more about credible with real battery life, neither Atom or Nano make the cut.
You're talking the difference between an atomic bomb and a conventional dispersal weapon that spreads nuclear materials that've been weaponized and present a serious health hazard if you breathe in the dust.
In the parent poster's case, if they render unto aerosol the same 13.6 pounds of plutonium, it will be weeks and months before the main mess is cleaned up properly- and if any of the dust is missed, it'll be 100,000 years before it becomes "safe"- and there'll be stuff they miss, rest assured of it. If you bring in a smallish amount of that dust in you're lungs, you're toast.
You'll probably not want to stay there, if the truth's known, because of that little detail.
This depends on whether it's finely powdered or not. Get it dispersed into the air as an aerosol, and you've got a bigger danger.
You can clean the "immediate" area for most of it, but the dust will linger for long times and be an inhalation risk- breathe in any bit of that dust and you're screwed. Done right, it would be much closer to how the parent poster describes than how you frame it.
Considering that they're going to do it ANYWAY if they think you're sharing, no matter how they come upon that twisted notion...
The hypothetical arguments everyone keeps flipping around keep missing the point- RIAA is suing people on tenuous information, no matter what the source of that tenuous information.
Reducing the sources for having them bark up the wrong tree helps but does NOTHING to keep you from getting sued at one point over false allegations.
Removing the problem altogether is a better answer- they shouldn't be off doing this crap in the first place. (To be sure, neither should the sharers, but that's a different discussion...)
As someone facing a similar situation at his day job, 2.4 is painful in some regards. In my case, 2.6 allows me to do a non-standard initramfs (the stock is minimal and then you can load other initrd or initramfs images from the kernel options...) so that I can tapdance around the three differing hackish bootloaders they did in 2.4. This allows me to do major cleanups in what they did for doing NFS rootfs on the IXP2800 blades and on the X86 ones with minimal pain.
Most of the people commenting on 2.6 being too big are thinking of the whole size with everything loaded up. Minimal kernels with just your drivers loaded and only your drivers in the module build, you end up with only about 5-10% increase in footprint in memory and store space, with the ability to provide modern device support for things. In the case of what you mention, you're moving to an Atom based machine board. Given that you're moving to a modern board, the odds of things being "nicely" supported is lower with the 2.4 kernel.
Since you're manipulating large volumes of data over GigE, you're going to want to switch, probably even with the old ARM stuff if you can manage it. 2.6 provides much more responsive networking performance (so long as you do your network code right and don't dink with the scheduler (heh...let's just say I corrected a not so good idea there recently...)).
You may have to port a few custom drivers over to 2.6, but in the end, it'll work better since the driver architecture is better in 2.6.
They're already breaking it by going to a new cpu arch on the platform.
Embedded systems encompass a LARGE range of systems. Some of those systems need a filesystem (such as an MP3 player or a NAS server...), some need them less, but it makes some tasks within the space easier.
Not all embedded systems are PICs or similar. Your mobile phone is an embedded device, but I'd shudder to try to code that all with "traditional" embedded techniques and practices. Same goes for a whole host of things that are considered to be embedded.
It's more because the fixtures have been fielding much lower lumen-per-watt devices than the CFL's, coupled with people trying to huckster people into believing that their LED's are 35 watt and 45 watt equivalents when the devices they're selling actually do good to perform like 15-25 watt devices.
Rayovac just recently fielded the first 300 lumens output LED lantern on the market. It is comparable to a 35 watt incandescent bulb for only 4 watts of capacity. It's only a small-ish step to higher capacities that DO fill the room. It's just that it's still quite a bit pricier than one would normally like to spend on them.
When are they NOT barking up the wrong tree?
It depends on your situation. In Texas, someone was obligated to hand something over that wasn't the company's, wasn't developed with their resources, and had nothing to do with his work or their lines of business- just because he signed one of those things. Non-competes are largely unenforceable here, but IP assignments, etc. are a differing story. You can NEVER presume there's no legal basis for anything without a lawyer vetting that position for you.
That would be correct. The thing is, that you CAN compromise some of the other needed stuff as well (which would be the MItM part...) and this CA that isn't following official stated procedures would be all you'd need to cover up the fact that it'd been done.
All of the Comodo related entries (there's about 5 or so of them in Firefox 3...).
I'd have to concur there. Each and every one of the CA certs associated with Comodo in Firefox 3 is being purged from my trusted lists on all my machines as I type this.
What they just did is bogus- this stuff only works when you follow the steps to the letter and everyone else does the same. I hope there's a CA cert revocation coming down the pike for Comodo and all it's affiliated CA's (There's about 5 of them in my list on my machine here...). Once you screw up like this, you honestly can't trust the current certs from them and it's difficult to trust them in the future.
Heh... The biggest question I would have is that how are they going to get legit PI licenses to investigate all of that; they can't have this plan without breaking the law in the same manner they've been doing with the lawsuits themselves. And with this plan, now they're involving the ISPs with those civil liabilities. Nice...
If I were an ISP, I'd tell them to go stuff themselves unless they had proof obtained in a manner that a court of law would consider legit.
Because "illegal" isn't just criminality. It's also conceivably tortious, meaning you can have civil law violations.
Infringement can either be tortious, criminal, or both. There's truthfully no way for them to pin criminal charges on anyone they've "caught" in that "dragnet" of theirs, so they're trying for civil violations which have less stringent requirements for proving a tort was committed by the parties. Unfortunately for them, they don't have much of a valid case in any of the instances so they're folding when push comes to shove, relying on the costs to crush anyone that doesn't settle up with them.
No, like a spoon, it's DULL...it'd hurt more.
Few browsers enable privilege escalation like IE does on a regular basis.
Heh... You'd just have other exploitable issues, either within the Java JVM or in poorly written code- just not the same class of them. I don't place blind faith in a language to clean up after myself.
It does not negate either remark I made.
It's a Darwin Awards territory thing- SERIOUSLY.
This ISN'T insightful.
This isn't backing out. If you understood what Net Neutrality actually meant, you'd understand that this is quite a bit different.
In the Google story, all they're doing is putting dumb bit shovels closer to you.
In the thing that people for 'net neutrality' are talking about, the ISP gives higher priority to the content THEY provide and unless you pay tribute to each ISP, they do nothing or actually degrade your priority, meaning you stuff gets to you slower or not at all- depending on whether it's the ISP's crap or your content provider paid their danegeld.