Slashdot Mirror
What to Expect from Linux 2.6.12
apt-get writes "Saw this Linuxworld report from the annual Australian Linux conference, Linux.conf.au, in Canberra last week. The article outlines some of the new features we can expect for the 2.6.12 kernel release, including: support for trusted computing, and security enhanced Linux. The kernel developers are also working on improving the 'feel' of the Linux desktop with inotify for file managers and events notification so hardware 'just works'. Unfortunately no release date other than 'sometime soon' is given."
does this mean I can tust my computer now?
:-(
we've had a growing apart since it started cheating on me and got a virus
Never ask for directions from a two-headed tourist! -Big Bird
Is the inclusion of trusted computing a good thing here? Many people in the /. crowd didn't seem to like the idea of it's inclusion in Windows...
Was its inclusion in the kernel by choice?
I know I'm going to rub a few feathers the wrong way, but I think this kind of feature creep is actually good for the Linux kernel.
The more features we can get into kernel mode, the less we need to rely on "chaining" and other Unix-way solutions and we can think more about applications and OS services as "whole units".
And since the majority of installations of this latest version will be on desktops, the more hardware support, the better the hardware support, the more seamless the hardware support, the better.
It would be nice to see some componentization of the kernel to allow for easy stripping of unnecessary features, but as the kernel will stand, the features are all necessary.
Just for those not in the know..
/home recursively. I don't remember why or which. :)
Inotify is a replacement for dnotify. With both you can watch for a file for changes. You can even watch a directory for changes. However with dnotify you couldn't recursively watch a directory for changes. To do so required basically 'opening' each folder and quickly you use up the maximum number of files you can open.
With inotify it still doesn't directly support recursively watching a directory but example code for doing so is given and doesn't have the same problems. One distro uses this for watching
As for the notification thing - that's part of HAL, and means usb pens, cameras, etc should be 'auto detected' and the user can be notified and asked what to do automatically.
I think these changes are nice. But what Linux needs is a rethinking of the way device drivers are integrated. Bundling them all with the kernel will just no longer work (did you ever try to configure a kernel these days?). What I am looking for is a way to be able to use the same driver (aka 'module') in different kernels without having to recompile all over again, and the ability to compile a driver without having the complete kernel source installed.
---- join dshield.org Distributed Intrusion Detec
Also, how about growing files with mmap? Currently one can not mmap() beyond the end of the file on Linux...
In Soviet Washington the swamp drains you.
This seems like a good thing to me. One of the advantages of Linux not been driven by a need to produce revenue.
1. There is no 2.7 tree, so no backporting.
2. Why do you assume, that the interest is sudden? Maybe the technology is simply deemed ready (as in tested and reliable enough) now to go into the main kernel?
The current linux kernel is pretty amazing if you think about it. It's running on everything from OS 390's right down to cell phones with features for everything inbetween. This flexability generally means that the kernel has a lot of untested combinations. Thats a potential problem.
The kernel needs a team of people that specifically tries to break the kernel. Right now kernel testing is haphazard at best. By devoting a team of people (just like the developers) whose sole purpose in life is to break the kernel we (the community) will improve the security, and quality of future linux kernels. It will also improve the quality of code going into the kernel.
The new code sounds very good - but the linux development community needs some hackers to break stuff.
Cluge
"Science is about ego as much as it is about discovery and truth " - I said it, so sue me.
GUN Linux
Eric, is that you?
Secure messaging: http://quickmsg.vreeken.net/
Ross Anderson's Critique
IBM's Rebuttal
Trusted Gentoo
IBM's rebuttal does a decent job of allaying some of the fears - for example, it states that it will not prevent you from running any OS & programs you wish to on your own computer (which, for the record, I believe - witness the Trusted Gentoo project and e.g. this this link). They state that their approach to Trusted Computing is not particularly well-suited to DRM, and on the face of it, I agree - there seems to be little attempt at restricting the user of a computer with the TPM from doing what they want. However, in my opinion, as a base for an utterly crippling DRM regime, distributors simply could not ask for a better setup, as I'll argue a little later.
So to re-cap, it seems that if you are running Trusted hardware, there are no restrictions on what you can do on your computer in isolation; you can install Linux, run any number of Open Source apps, etc. But the keyword here is in isolation, and it is here that the dangers of Trusted Computing are revealed. For you see, Trusted Computing enables the usage of remote attestation wherein a server may request a hash of all software currently running on your computer. This hash is, for all intents and purposes, unforgeable, and if you disable your TPM (as IBM stress that you can, and again for the record, I see no reason to disbelieve them), no hash will be sent. The server may then assess this hash of software (or note that no hash has been provided, in which case it may well treat your computer as Untrusted) and decide, based on what software you are running, to simply not serve you with whatever material you requested - for example, it may decide that it will not deliver MP3's to your computer unless it knows for a fact that the receiving application is one that is known to encrypt the content as soon as it is received (so that e.g. it simply cannot be viewed while not running in Trusted mode) and which will take every step to ensure that once received, the unencrypted content never leaves your machine (e.g. by being written to CD, e-mailed , etc.). As you can imagine, the above scenario is not at all far-fetched as the **AA/ other media distributors are positively *creaming* themselves at the thought of stamping out casual file-sharing or even making backups for your own use in some of your other devices.
So we are left with the situation where someone who does not use Trusted hardware (and is thus unable to respond to attestation requests) or those who do run Trusted hardware but whose software fingerprint is not deemed acceptable by the server will simply not be granted access to certain material, rendering such people at a big disadvantage. And it's no good buying hardware free from Trust chips from China or such places on the "black market"; this offers no advantage at all as Trusted hardware, as mentioned, does not stop you using your computer the way you want in isolation; the problem only occurs when you try to interact with other computers.
So far, this sounds unpleasant but not too bad (although I would urge you to read Anderson's linked essay for some more imaginative and serious abuses), but if we allow ourselves to follow the slippery-slope, we end up at the state where ISPs will not allow your computer to access the internet at all (for surfing, e-mailing, anything) unless you are running Trusted hardware and software. Obviously, the social, political and legal barriers to this occurence are non-trivial, but we've all seen ridiculous Acts qu
Apparently, accourding to some posts on the Linux Audio User list the latency in native 2.6.12 is as good as the patched 2.4 for audio use.
This is great news for all of us using Linux for audio. It's also a pretty mean feat, as the 2.4 low latency patches were a little bit brute force compared to the 'correct' method in 2.6 of fixing all the problem spin lock areas in the kernel, a much harder task.
Now all we need is to get the RT LSM module into the main kernel. (It allows non root uses real time scheduling without messing about, it's not vital for perfomance but nice for usability.)
I have not tried 2.6.12 myself yet, but have got great results with unpatched 2.6.11 kernels.
I realize that it is probably paid for by IBM as part of their campaign to try to dupe people into thinking that the DRM vehicle they call "trusted computing" (remember: that is "trusted" as in "other people can trust your computer to control you") is something benign. However, implementing "TC" in Linux feels like a gigantic waste of time: does anybody here REALLY think that the proprietary DRM applications that are the ONLY REASON WHY WE WOULD NEED "TC" are ever going to be ported to Linux?
Do you see the DRMed "music stores" (it is more like a barter: "give us your money and control over your computer, and we'll let some Britney and Fiddy come from your speakers!") falling over themselves to run on Linux? Do you think that is because Linux doesn't support "TC" or because those companies couldn't possibly care less about Linux as a platform? I'll give you three guesses. And the ENTIRE POINT with "TC" is to make it impossible for us to reverse engineer and write our own replacements for those applications - so be definition we can forget about that alternative.
All I can say is, I hope they had fun implementing it, and that they feel happy about the all the people who believe the astroturfing that "TC" isn't the Torjan Horse of DRM.
"TC" is DRM is the tool of closed networks, closed source, a closed society, and a closed future. People who believe it will coexist with Linux are so naive that it would be quaint if it wasn't so fucking scary...
Every day I see a new bug on the ieee1394 mailing list. There are some serious issues with firewire on linux. It is nowhere as mature as it is on winxp or macosx. DMESG spits out lots of errors, sometimes my drives unmount themselves when I transfer 50gb+ (ext3/reiser were massacres, xfs was slightly better). Even with the latest kernel these problems persist.
Should you be curious, I've posted the slides to my talk on LWN.net.
Jonathan Corbet, LWN.net
One feature that isn't talked about much, but is very popular amongst gamers is the configurable USB mouse polling rate. For years it has been available as a kernel patch, but now it has finally been included in the kernel. This means no more recompiling your kernel just to increase your mouse polling rate from 125hz to 500hz. It can now be set from your boot loader or from the command prompt.
Why is this so great? Well, the typical polling rate of 125hz for USB mice is noticably less smooth than a polling rate of 500hz, whether you are using your mouse in games or a desktop app. For this reason many people preferred to use PS2 mice, as they could be polled at up to 200hz. Now with this new feature, PS2 can be retired. Get yourself a high resolution USB optical mouse and set the polling rate to 500hz.
You can feel the difference.
In most FPS games you typically respond with very small, quick mouse movements. The faster you poll the mouse the more accurate the mouse motion can be tracked which means less undershooting/overshooting your target intended target.
Is it a night and day difference? No.
First off, a CRT's refresh rate can be above 100hz, but even so, the CRT's refresh rate is not synchronized with the mouse polling rate. So the cursor drawn to the screen is done so using the last mouse polling data. With 125hz, this means the data could be 8 miliseconds old, while with 500hz, the data is a maximum of 2 miliseconds old. Hence there is less lag in physical mouse movement and its logical and visual effect.
It is actually more complicated than that, but those lag values are for lag due to mouse rate alone. Of course the CRT refresh rate introduces its own lag. But in short, keeping monitor refresh rate constant, because the monitor is not synchronized with the mouse, increasing the polling rate of the mouse makes for an improvement. Conversly the same can be said for increasing the refresh rate of the monitor.
You don't have to take my word for it. If you are already using a good USB mouse at 125hz, try it at 500hz. You will notice the difference. Once you use 500hz for several days, try switching back to 125hz. You will hate it. The difference is even more noticable with higher resolution mice, such as 800 dpi and 1600 dpi optical mice because the movement delta can be quite large and a delay of 8 miliseconds of a large delta "feels" awkward.
Of course, if you use a very crappy low resolution USB mouse, the difference is harder to notice.