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."
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.
This seems like a good thing to me. One of the advantages of Linux not been driven by a need to produce revenue.
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.
'did you ever try to configure a kernel these days?' - no, my distro does it for me.
I don't see what the problem is. My distro has all the drivers compiled for me. What use case do you have other than compiling your own kernel for the sake of it?
On a practical level, Linus has said many times that he won't do this because it would require freezing the internal kernel api. While this might sound good for an outsider, you only have to consider how much say the USB structure has been reorganised to realise how bad an idea it would have been if this was all frozen.
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...
I think the complaints about locking machines down are more in who gets the keys...
Tedious Bloggy Stuff - hooray?
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...
Microsoft hasn't provided a stable API. Many Drivers from NT4.0, 2000, XP and 2003 don't work accress all NT based platforms. There answer has been to support all NT based platforms with diff. drivers for Each OS. What happens when longhorn comes out. Either the manf. has keep up with the changes of Longhorn and released updated driver for that version or doesn't support it and you can't use that device on Longhorn. I have been bitten with hardware no longer supported in new Microsoft OS more times than I care to admit. Under Linux I have a Raid Controller by a manf. that went out of bussines 10 Years ago that still works under linux today. In linux it seems once supported allwas supported.
Did you read what you just said ?
... next time microsoft needs all the internal documents from your company, they will just open their explorer, that just happens to be implicitly trusted by your company's software, and it can do 2 things : they can both read the documents, and they can make the documents AND any backup copies you may have inaccessible.
...
Next time you find out by email your boss is about to fire you because you're e.g. colored, you will not be able to forward that mail to the authorities, and your boss will be able to destroy ALL traces of that email from his home.
Next time the police really needs data on a person's computer it will not be possible to extract it, because "TPM" will prevent it.
And
Adobe will be able to do this for pdfs, your bank for your bank statements,
THAT is what TPM is about.
AC: It isn't usefull by itself, but if you combine it with ExecShield and SELinux it could be a useful security layer.
Or, you could just combine ExecShield and SELinux by themselves and have a useful security layer, without needing Trusted Computing at all.
Brushing aside the minor side-features, Trusted Computing is really about tamper-resistant hardware enforcing the signatures of software on the PC. The main use of that is preventing the legal and physical owner of that PC from hacking programs on his own computer, so that RIAA music publishers can continue to trust it.
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.