"In order to prevent active attacks, device drivers are required to poll the underlying hardware every 30ms for digital outputs and every 150 ms for analog ones to ensure that everything appears kosher. This means that even with nothing else happening in the system, a mass of assorted drivers has to wake up thirty times a second just to ensure that⦠nothing continues to happen"
So there you go, your video and audio drivers have to poll the hardware repeatedly, which takes all of the CPU, video, and audio hardware out of low-power state when they could otherwise be idle.
As far as I know, this remains the spec for drivers, and does partially explain why Windows would use more power at idle than other operating systems.
I vaguely recall someone from AMD (??) writing a paper back when Vista was introduced that went over the implementation of driver signing in Windows, and how that was going to impact battery life. Basically, as I recall, in order to implement DRM the OS will repeatedly check the drivers and the hardware to make sure that all signatures remain valid, so it doesn't really idle well at all.
On the one hand, Ubuntu has seriously improved desktop Linux, particularly in hardware auto-detection and driver support.
No, it didn't. All of the software used for auto-detection and auto-setup of hardware originated and has been largely developed in Fedora. Ubuntu's first releases took place after Red Hat had worked out a lot of the bugs, and the Fedora releases at that time were just as good. Some of the releases before the release of Ubuntu did not have those tools fleshed out.
The only place where you are marginally correct is proprietary drivers. Ubuntu had options to enable repositories for third-party proprietary drivers, where Fedora adheres to Free Software principals.
OK, so there were two things I wanted Red Hat to have that Debian did, back then: more community involvement and apt.
Apt came along eventually, and then was replaced by yum.
At the same time, there were a lot of things that I liked better about RPM. RPM packages were PGP signed long before debs. As far as I could tell from the documentation, debs were either all or mostly built by hand where RPM packages were built using a script included in the src.rpm. Last, Debian used to have mirrors for everything except for updates that fixed security problems. I never could make any sense of that; it seemed completely backward.
Your recollection is off. PAM was in the distribution at least as early as version 4, and has never checked complexity at login. The old cracklib module that was used to check complexity doesn't even offer that service.
My first Linux distro was Slackware, and it was damn educational. I had to do a lot of stuff on my own. A little less than a year later, I tried Red Hat Linux (4.2) and never turned back.
I tried Debian a few times early on, and the system would always break when I applied updates. Break, as in, it would either no longer boot or I could no longer log in.
Debian was what I wanted in a distribution: committed to Free Software. Red Hat angered a lot of users when it split off Fedora, but I never understood that. Fedora was the distribution that I wanted Red Hat to be. Free Software and community driven. Since apt and yum came into the picture, Red Hat's distribution has been the best of the bunch. The company maintains their commitment to Free Software, releasing the code to acquisition after acquisition, and leads all others in developing GNU/Linux.
Thank you Red Hat. There are too many negative comments here. I love Fedora.
1% greater chance of dying from cancer for 77 people
Even that's exaggerated. There are an estimated ~2000 people who face an elevated risk of thyroid cancer. Even with that elevated risk, there is never expected to be a statistically measurable increase in the actual development of thyroid cancer.
And thyroid cancer is treatable. It has a 97% survival rate. Those people are going to be screened annually. They're probably going to be just fine.
People keep asking this question without any idea how it possibly could be a back door.
SELinux is a security layer in addition to the existing security controls. It can deny applications the permission to perform various actions, and that's about it.
Besides, I bet the user interface elements of Android could also be "replaced fairly easy". Anything can.
That's not a fair comparison. Linux's interfaces mostly conform to a documented standard that is already implemented by other kernels. Therefore, it should be a relatively small task to replace one kernel with another kernel that already exists and implements most or all of what is required. (I'd imagine that there would be additional drivers requried)
There is no existent alternative implementation of the Android userland. Replacing it would require a lot of engineering. It would not be easy.
I've experienced the same from time to time, and typically what I find is that someone in the cafe (or more than one person) is/are streaming hi def video and ruining the entire network for everyone.
So... we're probably going to see new connection flood DOS attacks like the ones that prompted SYN cookies a couple of decades ago. Application stacks will need to handle their own congestion control, and applications that do so poorly will negatively impact carrier networks. And, yay, a new variant of TLS when there are already several versions that aren't widely implemented, let alone deployed.
Oh, and in the application so that each of those problems can be addressed over and over. Yay!
Not on his part. The world at large did not believe that Iraq had WMDs, which is why the UN did not authorize the use of force.
Even we didn't believe it. Recall that Cheney advocated a "1% doctorine." If there was even 1% chance that Iraq had WMDs, he thought we should invade. In other words, we were 99% certain that there were no weapons, but, "What the hell? Let's invade."
Fuck you and fuck anyone who defends those murderous scumbags. People died for their aggression.
That seems like an overreaction. You can't purchase anything from the Google Play Store without a Google account (which automatically means Plus). Why would they allow someone who can't use the Play Store to review an app there? That's nothing more than an open invitation for abuse.
Finally, cubieboard is 2x the cost. Newsflash: spend more, get more.
It's not 2x, it's less than 50% more expensive. +$14 on top of $35. For reliability, it's worth the extra cost. But it's not just reliability, it's also has useful interfaces that aren't present on the Pi, like SATA. SATA is worth the extra cost. But it's not jut reliability and SATA, it's also a whole lot faster and generally more capable. It's also a more open SoC.
Your perception that one socket for power is better than another is ridiculous, BTW
As another user suggested, it's not the form factor, is the available current. A USB wall wart is still going to be designed to conform to USB draw limitations. That means that a USB device attached to a Pi is capable of drawing as much power as the wart is designed to provide. That USB device + Pi are capable of drawing more.
It would make the system more reliable, yet. Not reliable, though. If you connect a USB device to the Pi that draws the maximum amount of power provided by the USB power input on the Pi, the two devices are still going to need more than is being input. Capacitors can take care of short bursts, but it's still possible to need more energy than is available, at which point the system will fail. Usually that'll mean a USB attached device will go offline, and some don't recover well. As we've seen, that's usually the Ethernet port, and you have to reset the Pi to fix the problem. It's gross.
Funny thing, I ordered a cubieboard this morning before this story was posted: http://cubieboard.org/
Two of my roommates have RPis. One of them has two of them. I watched them both struggle with the RPi units when they were first setting them up. Those things are god awful. Graphics requires a binary blob, and the USB power source causes a lot of stability problems. Since the Ethernet is attached by USB, this normally manifests by the Ethernet dropping off, the kernel spewing messages about it, and the whole system reduced to a grinding mess as syslogd tries to write all that noise to the SD card. Running off of USB power is just ridiculous.
The cubieboard is 2x as fast, has 2-4x the memory, a SATA port, and Ethernet on the SoC rather than via USB. And, since it doesn't power off of a USB port I expect it to be a lot more stable. Most importantly to me: it doesn't require a binary blob for standard graphics.
Slashdot Mirror
What is it doing? Ask the engineers that built it
For one, it's polling the hardware looking for attacks against its DRM systems:
http://www.cs.auckland.ac.nz/~pgut001/pubs/vista_cost.html
So.. your CPU, video hardware, and audio hardware don't idle well.
Found it: http://www.cs.auckland.ac.nz/~pgut001/pubs/vista_cost.html
"In order to prevent active attacks, device drivers are required to poll the underlying hardware every 30ms for digital outputs and every 150 ms for analog ones to ensure that everything appears kosher. This means that even with nothing else happening in the system, a mass of assorted drivers has to wake up thirty times a second just to ensure that⦠nothing continues to happen"
So there you go, your video and audio drivers have to poll the hardware repeatedly, which takes all of the CPU, video, and audio hardware out of low-power state when they could otherwise be idle.
As far as I know, this remains the spec for drivers, and does partially explain why Windows would use more power at idle than other operating systems.
I vaguely recall someone from AMD (??) writing a paper back when Vista was introduced that went over the implementation of driver signing in Windows, and how that was going to impact battery life. Basically, as I recall, in order to implement DRM the OS will repeatedly check the drivers and the hardware to make sure that all signatures remain valid, so it doesn't really idle well at all.
If being wrong about electric vehicle pollution makes you an eco-tard, congratulations. You're an eco-tard.
Sierra Club
Popular Science
Or maybe we can all just conduct ourselves with a little more respect. That would be really nice.
On the one hand, Ubuntu has seriously improved desktop Linux, particularly in hardware auto-detection and driver support.
No, it didn't. All of the software used for auto-detection and auto-setup of hardware originated and has been largely developed in Fedora. Ubuntu's first releases took place after Red Hat had worked out a lot of the bugs, and the Fedora releases at that time were just as good. Some of the releases before the release of Ubuntu did not have those tools fleshed out.
The only place where you are marginally correct is proprietary drivers. Ubuntu had options to enable repositories for third-party proprietary drivers, where Fedora adheres to Free Software principals.
OK, so there were two things I wanted Red Hat to have that Debian did, back then: more community involvement and apt.
Apt came along eventually, and then was replaced by yum.
At the same time, there were a lot of things that I liked better about RPM. RPM packages were PGP signed long before debs. As far as I could tell from the documentation, debs were either all or mostly built by hand where RPM packages were built using a script included in the src.rpm. Last, Debian used to have mirrors for everything except for updates that fixed security problems. I never could make any sense of that; it seemed completely backward.
Your recollection is off. PAM was in the distribution at least as early as version 4, and has never checked complexity at login. The old cracklib module that was used to check complexity doesn't even offer that service.
My first Linux distro was Slackware, and it was damn educational. I had to do a lot of stuff on my own. A little less than a year later, I tried Red Hat Linux (4.2) and never turned back.
I tried Debian a few times early on, and the system would always break when I applied updates. Break, as in, it would either no longer boot or I could no longer log in.
Debian was what I wanted in a distribution: committed to Free Software. Red Hat angered a lot of users when it split off Fedora, but I never understood that. Fedora was the distribution that I wanted Red Hat to be. Free Software and community driven. Since apt and yum came into the picture, Red Hat's distribution has been the best of the bunch. The company maintains their commitment to Free Software, releasing the code to acquisition after acquisition, and leads all others in developing GNU/Linux.
Thank you Red Hat. There are too many negative comments here. I love Fedora.
Can you provide a reference for the Seagate failure you mentioned? Offhand, it almost sounds like you're thinking of the Samsung laptop UEFI bug:
http://mjg59.dreamwidth.org/22855.html
1% greater chance of dying from cancer for 77 people
Even that's exaggerated. There are an estimated ~2000 people who face an elevated risk of thyroid cancer. Even with that elevated risk, there is never expected to be a statistically measurable increase in the actual development of thyroid cancer.
And thyroid cancer is treatable. It has a 97% survival rate. Those people are going to be screened annually. They're probably going to be just fine.
People keep asking this question without any idea how it possibly could be a back door.
SELinux is a security layer in addition to the existing security controls. It can deny applications the permission to perform various actions, and that's about it.
How do you imagine that it would be a back door?
Besides, I bet the user interface elements of Android could also be "replaced fairly easy". Anything can.
That's not a fair comparison. Linux's interfaces mostly conform to a documented standard that is already implemented by other kernels. Therefore, it should be a relatively small task to replace one kernel with another kernel that already exists and implements most or all of what is required. (I'd imagine that there would be additional drivers requried)
There is no existent alternative implementation of the Android userland. Replacing it would require a lot of engineering. It would not be easy.
You don't even have to read the article. The summary says that Google will replace AT&T at all US locations.
I've experienced the same from time to time, and typically what I find is that someone in the cafe (or more than one person) is/are streaming hi def video and ruining the entire network for everyone.
Seems like everyone has an agenda.
Well, yes, but I tend to side first with the people whose agenda is "Don't kill us."
So... we're probably going to see new connection flood DOS attacks like the ones that prompted SYN cookies a couple of decades ago. Application stacks will need to handle their own congestion control, and applications that do so poorly will negatively impact carrier networks. And, yay, a new variant of TLS when there are already several versions that aren't widely implemented, let alone deployed.
Oh, and in the application so that each of those problems can be addressed over and over. Yay!
The goal: to extend human lives by hundreds or thousands of years, if not indefinitely
Yes, if you don't know how long lives will be extended, it will be indefinite. That's what indefinite means.
revisionist history much?
Not on his part. The world at large did not believe that Iraq had WMDs, which is why the UN did not authorize the use of force.
Even we didn't believe it. Recall that Cheney advocated a "1% doctorine." If there was even 1% chance that Iraq had WMDs, he thought we should invade. In other words, we were 99% certain that there were no weapons, but, "What the hell? Let's invade."
Fuck you and fuck anyone who defends those murderous scumbags. People died for their aggression.
http://en.wikipedia.org/wiki/Iraq_and_weapons_of_mass_destruction
I realize that privacy isn't a right under the Constitution, explicitly
Rights exist, absent government. The U.S. Constitution doesn't create rights, it protects several of them from government infringement.
A couple of days ago, Bruce Schneier posted a blog entry that seems relevant. There's something in the military mindset about secrecy that I don't understand, and perhaps none of us do.
How people talked about the secrecy surrounding the Manhattan project.
That seems like an overreaction. You can't purchase anything from the Google Play Store without a Google account (which automatically means Plus). Why would they allow someone who can't use the Play Store to review an app there? That's nothing more than an open invitation for abuse.
Finally, cubieboard is 2x the cost. Newsflash: spend more, get more.
It's not 2x, it's less than 50% more expensive. +$14 on top of $35. For reliability, it's worth the extra cost. But it's not just reliability, it's also has useful interfaces that aren't present on the Pi, like SATA. SATA is worth the extra cost. But it's not jut reliability and SATA, it's also a whole lot faster and generally more capable. It's also a more open SoC.
Your perception that one socket for power is better than another is ridiculous, BTW
As another user suggested, it's not the form factor, is the available current. A USB wall wart is still going to be designed to conform to USB draw limitations. That means that a USB device attached to a Pi is capable of drawing as much power as the wart is designed to provide. That USB device + Pi are capable of drawing more.
It would make the system more reliable, yet. Not reliable, though. If you connect a USB device to the Pi that draws the maximum amount of power provided by the USB power input on the Pi, the two devices are still going to need more than is being input. Capacitors can take care of short bursts, but it's still possible to need more energy than is available, at which point the system will fail. Usually that'll mean a USB attached device will go offline, and some don't recover well. As we've seen, that's usually the Ethernet port, and you have to reset the Pi to fix the problem. It's gross.
Funny thing, I ordered a cubieboard this morning before this story was posted:
http://cubieboard.org/
Two of my roommates have RPis. One of them has two of them. I watched them both struggle with the RPi units when they were first setting them up. Those things are god awful. Graphics requires a binary blob, and the USB power source causes a lot of stability problems. Since the Ethernet is attached by USB, this normally manifests by the Ethernet dropping off, the kernel spewing messages about it, and the whole system reduced to a grinding mess as syslogd tries to write all that noise to the SD card. Running off of USB power is just ridiculous.
The cubieboard is 2x as fast, has 2-4x the memory, a SATA port, and Ethernet on the SoC rather than via USB. And, since it doesn't power off of a USB port I expect it to be a lot more stable. Most importantly to me: it doesn't require a binary blob for standard graphics.
They aren't being replaced. Each of these codenames is an additional optimization layer. The performance enhancements are cumulative.