I'm curious what is viewed as a backing device. Lets say I have a SAN exporting three volumes via iSCSI to a single server. Does this patch think those volumes share a single BDI, or does it treat them separately?
I think the three volumes will be seen as independent BDIs, because that's the simplest implementation (look at the block device the pages are for, don't attempt to count things at multiple levels). Being too granular isn't a problem, because a process will be slowed down if it writes to any of the three iSCSI volumes that are throttled by the network.
Making the RC6 engine for Intel graphics the default was reverted at the last minute due to instability, http://www.phoronix.com/scan.php?page=news_item&px=MTAzN.... It can still be enabled manually by adding i915.i916_enable_rc6=1 to the kernel boot parameters, just like 3.1.
Another interesting change concerning Logitech Unifying devices is that multiple devices are now given separate /dev entries, instead of being multiplexed into one device.
The EVM part interests me. It provides a way of guaranteeing that a file has not been changed by using a combination of a passphrase and a key stored in the TPM, along with hashes of files stored as xattrs on disk.
TCCBOOT? You could verify the source code of the kernel on a thumb drive, then boot the computer with TCCBOOT and compile the kernel from source every time you boot the computer. http://bellard.org/tcc/tccboot.html
Ah yes, the old Reflections on Trusting Trust. http://cm.bell-labs.com/who/ken/trust.html Fortunately that wasn't nodata's question. Recompiling the kernel from known source should ensure that it hasn't been modified to misread xattrs.
I found his moral section on security interesting:
"...The acts performed by these kids are vandalism at best and probably trespass and theft at worst. It is only the inadequacy of the criminal code that saves the hackers from very serious prosecution."
and
"I have watched kids testifying before Congress. It is clear that they are completely unaware of the seriousness of their acts. There is obviously a cultural gap. The act of breaking into a computer system has to have the same social stigma as breaking into a neighbor's house."
So while interested in trusted code and security, he was also interested in criminal penalties for unauthorized access to computer systems. Of course, it's an unstoppable force and the metaphor with the real world is tenuous --it's just an interesting take.
There is absolutely nothing stopping most people from just breaking a window and climbing into their neighbor's houses. But people don't generally do that, because there's a social stigma against it. There's no security around men's and women's bathrooms to make sure only the "right" people go in, but people know they shouldn't do that. There's no physical barrier on (most) roads to prevent a driver from going on the other side of the road, or ignoring lights, but drivers take courses that explain how to drive properly. That's the kind of cultural gap he's talking about. Stealing is easy, but we teach kids from an early age to respect each other's property. We could easily instill the same respect for digital territory, but culture hasn't caught up yet. I think it will soon though.
The digital realm does introduce remoteness[1] too though -and there isn't the possibility of immediate repercussions (as one can find in the physical world).
Additionally, the number of people who trespass digital properties are very few, relatively speaking and could be compared to scofflaws, drunk drivers, etc. but, and this is the big but, their impact is asymmetrical. They can have an effect on large numbers of people.
Despite that, I do agree that culture can be changed in a generation.
So does that mean there will soon be distro support for the newer netbooks? (full sizish keyboards under an 11 inch monitor with slightly faster AMD CPU is the payoff, but the graphics and wifi have been problematic from what I understand)
It's an important tangent to me: I like the very small laptop form, but the newer models have not been well supported yet.
On and off kernel hacker here. Compile and test the release candidates Linus puts out every fortnight. When the inevitable breakage happens, use `git bisect` to track down the offending commit.
It's tedious and time consuming but you will make people very happy. The only way to test something as big and critical as the kernel is by having users actually run it.
https://lwn.net/Articles/456904/
(Linked from http://kernelnewbies.org/Linux_3.2, which has more detail than the HN posted article)