People are different from each other. Write that down 10.000 times, and god willing, maybe it will stick. (Though I actually don't expect you to understand)
Apparently the plugin protection was waiting for a response from the plugin, while the plugin protection's request hadn't even been sent because farmville was overloading the plugin's event loop.
Are you drunk? The app that was deleted was a test case for a malicious application. That's all it was.
Anyway, if you don't want applications downloaded from the app store policed and possible deleted I have a simple solution for you. Don't use the app store.
And if you really want to run the application anyway, go ahead, install the APK manually. You can actually do that.
Google probably wanted to capture as many SSID's in as little time as possible as accurately as possible.
It's possible they had this setup with the intent of reconstituting partial SSID broadcast frames. Or maybe non-SSID frames are of some interest to determining a more exact location of the AP.
Maybe they had multiple directional antennas on the van. Hooked up to a gps and a compass there should be some interesting analysis to be done from that.
Maybe they wanted to compare frame X from antenna A to frame Y from antenna B where van C was driving 50 kmph at a curve of D and where X was received 5 seconds later than Y and where van C was traveling from location E to F. Now tell me the most likely location of the access point that sent both frames.
1. Linux doesn't need an ABI. 2. Drivers need to go in mainline. 3. That code of the driver in mainline needs to be maintained, or it is ejected from the kernel. 4. Instead of continuous maintenance, manufacturers would rather just write a driver once, and be done with it. 5. But, Linux doesn't need an ABI.
Anyway, the viewpoints of the kernel-devs seem pretty clear. On the one hand having manufacturers write drivers for Linux would be a nice thing to have. But Linux will never have an ABI towards drivers. It's not that the kernel devs don't care, they just don't care enough. Or rather, the reasoning is "source or nothing". I'm not saying they are wrong to want source drivers. I'm not saying they are wrong to put roadblocks up for manufacturers that want to deliver binary drivers. I can understand.
Equally true for the manufacturers. On the one hand they would gladly deliver Linux drivers. But they don't want to deliver source drivers, they want to deliver binary blobs. And they want a stable ABI for those binary blobs. Again, I can understand their reasoning. They don't want others to see the source, and they want to deliver just a few binary blobs at most, and have the total Linux x86 spectrum covered.
Anyway, I doubt the Linux driver situation will ever fundamentally improve. Because, in the end, the problem isn't technical, it's philosophical.
It's unprofessional on the part of Mozilla. Most people at Mozilla who knew about Jetpack and who knew about the MetaLab estimate would have known MetaLab was being ripped off.
It points to multiple people not taking responsibility for recognizing and dealing with such an issue. The problem is probably institutional. Mozilla needs to get their people to a ethics training course.
In the attack, the privilege escalation is _on the network_, not locally. An attacker of this type doesn't need local root privileges on a desktop pc, they want privileges on the servers.
The attack might then upload your private SSH key. Either they brute-force the password of the key on a cluster, or they analyze every document you have access to for words that could be the password. Maybe they replace the link you have on your desktop to SSH with a link to a SSH binary of their own.
Having local user privileges and lots of patience is sufficient to eventually crack a network wide open. And it will work with Linux too.
I do take issue with the "derivative" work position used by GPL license holders sometimes. (I've got no argument with GPL license holders, it's just that the GPL has this thing with derivative works that is very often talked about)
Particularly, in the case of a blog management tool, the tool would not be derived from Mysql, even if it incorporated it, distributed it, and had no provision for using another database. Rather, parts of the blog would be derived from SQL, a common, pre-existing syntax that Mysql chose to implement.
Even if it is statically linked, the SQL interface layer, that both applications chose, decouple them from each other in the software's architecture.
At the very least, the Google Nexus has a command for 'rooting' the phone. I feel I must qualify this further. It's a command, or rather a procedure that shows a disclaimer telling you, you'll be voiding your warranty, but rooting your phone. It is not a hack.
AFAIK, with other Android phones, rooting the phone has always been a hack.
A manufacturer's opportunity is a customer's danger. These opportunities you speak of frustrate customers as they attempt to find out if a brand is trustworthy or not. Worse, they confuse would-be customers, and scare them away from the platform to begin with.
There should be no need for a extra branding or quality guarantee. If it's on the app store than it works. (Caveat, except for stuff that's squirreled away under something like 'experimental', but at that point the user's anticipations are being managed by the labeling.)
Ditto. I too haven't bought an Android phone yet because I've got no guarantees, promises or even allusions from the manufacturer that they will upgrade the firmware of the phone when a new Android version comes out.
The only reason I'm considering buying the Google Nexus is because Google sells the phone and supports the phone. Also, as Google has given the Google Nexus to its employees, there's a good chance it will keep getting updates for it's lifetime.
Note; if HTC were to come out and say "we'll make Android updates for the next X years for device Y" that would be cool for me too. I would just hate being stuck without updates.
Slashdot Mirror
Cows give sour milk! Trains responsible!
AC electricity dangerous! Edison proves by electrocuting elephant.
Cars dangerous! New law passed mandating that every car be preceded by a man with a bell and lantern.
People are different from each other. Write that down 10.000 times, and god willing, maybe it will stick. (Though I actually don't expect you to understand)
accidental mod, posting to remove it.
Apparently the plugin protection was waiting for a response from the plugin, while the plugin protection's request hadn't even been sent because farmville was overloading the plugin's event loop.
Are you drunk? The app that was deleted was a test case for a malicious application. That's all it was.
Anyway, if you don't want applications downloaded from the app store policed and possible deleted I have a simple solution for you. Don't use the app store.
And if you really want to run the application anyway, go ahead, install the APK manually. You can actually do that.
Well, that does it, I'm scheduling a conference call so that we can all learn how to do productive conference calls.
(j/k)
You don't need an enclosure for every drive. Just one hot-swap enclosure.
There you go, the floppy disk is dead, long live your stack of 2TB hard disks.
Google probably wanted to capture as many SSID's in as little time as possible as accurately as possible.
It's possible they had this setup with the intent of reconstituting partial SSID broadcast frames. Or maybe non-SSID frames are of some interest to determining a more exact location of the AP.
Maybe they had multiple directional antennas on the van. Hooked up to a gps and a compass there should be some interesting analysis to be done from that.
Maybe they wanted to compare frame X from antenna A to frame Y from antenna B where van C was driving 50 kmph at a curve of D and where X was received 5 seconds later than Y and where van C was traveling from location E to F. Now tell me the most likely location of the access point that sent both frames.
(Location G, obviously. ... HEY, I found it!)
Just have the phone encrypt everything with a key that is stored in volatile memory. Then, if somebody pulls out the battery... instantwipe.
Bonus points if that volatile memory is actually located in a tamper-resistant TPM chip.
Those who do know just roll their eyes and quietly check you off in their head as a know it all turd.
And mention it in the next review cycle.
It enables people to bypass the corporate firewall. Lots of places only allow access to the internet via a proxy server.
Neither, you hang on to the phone for a while till you get a chance to turn it into the police. In the meantime you leave a note with the bartender.
Better still, if you know it's a BigCorp prototype, and BigCorp HQ is only 20 miles away, you drive to BigCorp HQ and drop it off.
True, but daily I still see lots of cows grazing while they're looking at the funny colored cars whizzing by.
If your explanation is correct, the easiest solution would be playing a recording of engine sound from the speakers when the hybrid engine is on.
Adobe itself could put a "render as html 5" function in Flash CS 5.
Go to http://www.20q.net/ and give the wrong answer to one of those questions.
There are also privacy controls for what apps can see of your profile if they are used by a friend of yours.
No. Mutilation is the correct word. Just because lots of people in a country/culture think it is ok, that doesn't make it right.
And my personal viewpoint on circumcision after birth; it's child abuse, plain and simple.
1. Linux doesn't need an ABI.
2. Drivers need to go in mainline.
3. That code of the driver in mainline needs to be maintained, or it is ejected from the kernel.
4. Instead of continuous maintenance, manufacturers would rather just write a driver once, and be done with it.
5. But, Linux doesn't need an ABI.
Anyway, the viewpoints of the kernel-devs seem pretty clear. On the one hand having manufacturers write drivers for Linux would be a nice thing to have. But Linux will never have an ABI towards drivers. It's not that the kernel devs don't care, they just don't care enough. Or rather, the reasoning is "source or nothing". I'm not saying they are wrong to want source drivers. I'm not saying they are wrong to put roadblocks up for manufacturers that want to deliver binary drivers. I can understand.
Equally true for the manufacturers. On the one hand they would gladly deliver Linux drivers. But they don't want to deliver source drivers, they want to deliver binary blobs. And they want a stable ABI for those binary blobs. Again, I can understand their reasoning. They don't want others to see the source, and they want to deliver just a few binary blobs at most, and have the total Linux x86 spectrum covered.
Anyway, I doubt the Linux driver situation will ever fundamentally improve. Because, in the end, the problem isn't technical, it's philosophical.
It's unprofessional on the part of Mozilla. Most people at Mozilla who knew about Jetpack and who knew about the MetaLab estimate would have known MetaLab was being ripped off.
It points to multiple people not taking responsibility for recognizing and dealing with such an issue. The problem is probably institutional. Mozilla needs to get their people to a ethics training course.
In the attack, the privilege escalation is _on the network_, not locally. An attacker of this type doesn't need local root privileges on a desktop pc, they want privileges on the servers.
The attack might then upload your private SSH key. Either they brute-force the password of the key on a cluster, or they analyze every document you have access to for words that could be the password. Maybe they replace the link you have on your desktop to SSH with a link to a SSH binary of their own.
Having local user privileges and lots of patience is sufficient to eventually crack a network wide open. And it will work with Linux too.
I do take issue with the "derivative" work position used by GPL license holders sometimes. (I've got no argument with GPL license holders, it's just that the GPL has this thing with derivative works that is very often talked about)
Particularly, in the case of a blog management tool, the tool would not be derived from Mysql, even if it incorporated it, distributed it, and had no provision for using another database. Rather, parts of the blog would be derived from SQL, a common, pre-existing syntax that Mysql chose to implement.
Even if it is statically linked, the SQL interface layer, that both applications chose, decouple them from each other in the software's architecture.
And indeed, damn the technical details to hell.
Anyway, IMHO, as always.
At the very least, the Google Nexus has a command for 'rooting' the phone. I feel I must qualify this further. It's a command, or rather a procedure that shows a disclaimer telling you, you'll be voiding your warranty, but rooting your phone. It is not a hack.
AFAIK, with other Android phones, rooting the phone has always been a hack.
A manufacturer's opportunity is a customer's danger. These opportunities you speak of frustrate customers as they attempt to find out if a brand is trustworthy or not. Worse, they confuse would-be customers, and scare them away from the platform to begin with.
There should be no need for a extra branding or quality guarantee. If it's on the app store than it works. (Caveat, except for stuff that's squirreled away under something like 'experimental', but at that point the user's anticipations are being managed by the labeling.)
Ditto. I too haven't bought an Android phone yet because I've got no guarantees, promises or even allusions from the manufacturer that they will upgrade the firmware of the phone when a new Android version comes out.
The only reason I'm considering buying the Google Nexus is because Google sells the phone and supports the phone. Also, as Google has given the Google Nexus to its employees, there's a good chance it will keep getting updates for it's lifetime.
Note; if HTC were to come out and say "we'll make Android updates for the next X years for device Y" that would be cool for me too. I would just hate being stuck without updates.