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."

Comments

Yay!

[qwertphobia]

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 :-(

Re:Yay!

[Ph33r th3 g(O)at]

You can trust her if you want, but I recommend you use a DRM wrapper on your trusted root for the time being.

Re:Yay!

[thePjunisher]

Er... no, it means you can never trust your computer again. The basic premise here is that you, the user, is a threat, and your computer must limit you in order to be trusted. A 'Trusted' computer in this context is one that can be trusted not to copy music or movies or programs or whatever...

Re:Yay!

[Brento]

does this mean I can tust my computer now?

Not if you're using the spell checker at the moment, no.

Re:Yay!

[Gaima]

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 :-(

I thought we were talking about the Linux kernel?

Re:Yay!

[mpcooke3]

lol

Sadly not. More likely this means someone else can trust your computer but you can't.

Re:Yay!

[dtfinch]

Better use protection.
http://www.dict.cc/?s=tust

Re:Yay!

[ShieldW0lf]

A 'Trusted' computer in this context is one that can be trusted not to copy music or movies or programs or whatever...

For those who do not know, 'Trusted' in this context means:

"We cannot ensure it is secure and are vulnerable to it if it is not, therefore, despite any misgivings we may have about the fact, we are currently trusting it."

The trustworthiness is irrelevant.

Re:Yay!

[namekuseijin]

What was so funny about the above comment? It just described what all about "trusted computing" actually is without the confusing legalese speech.

Re:And then...

[Ziviyr]

Wow, looks like you've found some sort of "pattern" there.

Quick, patent it!

Trusted Computing

[khujifig]

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?

Re:Trusted Computing

[Anonymous Coward]

Trusted Computing is just a technology and like probably all technology it can be used to do something good with it (make computers safer), or something bad (take control away from the user to enforce DRM, for example).

As the former seems to be what the inclusion in the Linux kernel is about, I think it's a good thing. And remeber, it's a free system, so you'll always have the choice not to use it or only use what you want to use it for.

Re:Trusted Computing

[fistfullast33l]

And remeber, it's a free system, so you'll always have the choice not to use it or only use what you want to use it for.

Sure you'll have a choice if you decide to compile your own kernel. But I don't see grandma or uncle bob downloading theirs from kernel.org and compiling it from source. I don't oppose it's inclusion in the tree but I think if money is involved (RIAA and MPAA have deep pockets), it won't be too difficult to persuade some of the more user-friendly distros to compile a stock kernel with trusted computing compiled in.

I guess I just believe that computer scientists have a responsibility to protect users from malicious and sneaky actions that violate their rights as computer users. Or maybe I just have a pessimistic view of society.

Re:Trusted Computing

[Anonymous Coward]

It's a different thing. The 'trusted computing' in Windows is all about DRM, preventing you from getting access to data on your machine.

The 'trusted computing' in Linux 2.6.12 is about being able to run a process that is restricted in what it can do (read and write to a pipe, essentially), so that you can run an arbitary downloaded binary without worrying that it will do bad things. (think: distributed.net, SETI, etc).

Re:Trusted Computing

[madaxe42]

do something good with it (make computers safer)

Call me silly, but how is 'making computers safer' a good thing? I don't *need* protecting from the big bad wide world, there are enough intrusions into my life to make it 'safer' as it is - each and almost every one of them pisses me off.

Re:Trusted Computing

[paulpach]

Yes. Trusted computing is a very good thing. This is some of the things you can expect:

When you compile or install a software, you can sign it. The computer will not execute anything that is not signed. This stops many viruses and trojan horses, so you can trust that you authorized everything the computer executes. It is just a security layer just like the no execution bit.

The important thing here is that the user is in full control of the system. The user gets to sign the packages or he can choose to use a distro that signs them for him. He chooses what the computer runs and what not. There is no third party that limits what the user can/cannot execute.

Besides signing software, TCPA (the chip that is going to be supported by the kernel) does encryption on hardware. So you can have hardware accelerated encryption/decryption, and your CPU will be free to do other things. This is not much different from hardware accelerated 2d & 3d graphics. Again, this is a very good thing.

Many people opose trusted computer because they confuse this with DRM (Digital rights management). DRM is technology that limits the right to open media. Trusted computer does not limit your rights at all. The confusion arises from the fact that microsoft plans to use TCPA (Trusted computer) to implement DRM.

TCPA support will totally be optional. You can enable/disable it when compiling the kernel. You normally want it enabled to take advantage of hw accelerated encryption, but if you are still paranoid (read misinformed) and think there is some evil corporation that is going to use TCPA to limit your rights, you can just turn it off.

There is a nice article from ibm that clarifies the issue

Re:Trusted Computing

[R.D.Olivaw]

As much as I would like it to be so, I don't know any grandmas or uncle bobs that install their own Linux machine. All the grandmas and uncle bobs that I know don't even know how to install windows (not that's it's necessarily easier but it is the general perception). They either get it shipped with the OS or get their grandson/cousin to install it.
those who get it with the PC most probably will end up with windows anyway. The others will have the support of the half geek to either install a distribution that fits their TC needs or download/patch/recompile the kernel of those that don't.

Re:Trusted Computing

[Ford Prefect]

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...

Re:Trusted Computing

[zootm]

If you don't need protection, don't turn it on. I assume that the kernel segments that deal with trusted computing will be able to be compiled out, and you'll be fine. As for the fact that it'll probably be included by default on many systems, I have to say that I don't consider "safe by default" a fallacy in any way.

Re:Trusted Computing

[finkployd]

Trusted computing as a whole is a good thing, with one componant that is a very bad thing: Remote attestation. This will allow remote systems to know exactly what software you are using to connect to them (cryptographically, so no spoofing it unless you are really good at factoring large primes :)

The nightmare scenerio is far beyond the typical DRM use case that most slashdotters fret about. Imagine if Microsoft wanted to ensure that only "trusted" client can connect to windows file sharing services, ie lock out Samba. Or make it so that only IE can connect to IIS webservers.

Sure they may not, but they are building the technology to allow this to happen and if ever they fall upon hard times, they will be legally obligated to their shareholders to take any advantages they can to ensure profits.

Re:Trusted Computing

[CastrTroy]

Many activeX controls have to be signed for them to run, and they have no trouble getting signed by very high profile companies such as VeriSign. Signing files doesn't prove anything. To get real security, you should run it in a sandbox. When a sandbox is properly implemented, you don't have to worry about whether the code is signed or not.

Re:Trusted Computing

[Anonymous Coward]

What about shell scripts or compiled applications that we write ourselves? Do they have to be signed, and how can that be done in a secure fashion? That could be a real nuisance.

The impression I got was that only the image of critical parts of the OS needed to be signed, and its signature would be verified by the boot process. But I'm probably wrong.

Re:Trusted Computing

[WNight]

Trusted Computing won't actually help security much at all. Look at the majority of the exploits - they're buffer overflows, ways of tricking a valid program into doing something you don't want.

Trusted computing is a red herring, intended solely to bring crippling DRM to the desktop. Enjoy.

Re:Trusted Computing

[drsmithy]

so that you can run an arbitary downloaded binary without worrying that it will do bad things.

You mean, like preventing it from getting access to data on my machine ?

Re:Trusted Computing

[Anonymous Coward]

Yes, exactly that. It can compute, take input, and return output, but nothing else.

It's like running an application in a very locked-down sandbox.

Re:Trusted Computing

[smittyoneeach]

Yeah, you might have good judgment, but is your box an island?
In the case of cars, traffic lights, while an admitted PITA, do make commuting possible.
Or are you one of those just-put-in-a-roundabout Brits? :)

Re:Trusted Computing

[Blapto]

If you're a *nix user, think really cool chroot jail.

Re:Trusted Computing

[guet]

This is a really nice idea. I wish OS X had this - new apps could be trusted only with the prefs folder and your documents folder initially, and then the user prompted if it asked to save something elsewhere (or perhaps the system could be smart and allow override from within the system save dialog).

Network access for apps should only be enabled if explicitly allowed (you'd only have to do it once per app after all).

At the moment if you download a binary you just have to pray that you are correct to trust it. It'd be nice to have this kind of fine-grained control.

Re:Trusted Computing

[madaxe42]

Hear hear! And, with my trusty landy by my side, I can cruise straight over them, thereby bypassing the need to steer. Ah, trusty roundabouts. Trusty landy. Trusty blind/deaf/dumb british police.

Re:Trusted Computing

[Anonymous Coward]

You're right about TCPA, but the 'trusted computing' stuff going into 2.6.12 has *nothing* to do with TCPA support - it's more like a fancy chroot jail for a specific class of untrusted processes.

Re:Trusted Computing

[erlenic]

I would imagine shell scripts would be fine, as it's the interpreter (bash, perl, etc.) that's actually executing code. There might be an option in the configuration to require signatures on individual scripts though, which could be handy on a server.

As for your second paragraph, I've heard similar things as well. I think it was an early attempt at TCPA, or maybe just misinformation. I heard it as the BIOS would require the boot loader, and maybe kernel, be signed, then the OS would manage other signatures itself. This could be used to prevent an intruder from using a boot disk to bypass your security.

Re:Trusted Computing

[Anonymous Coward]

When TC is pervasive on M$, all media will be DRM'ed and you will have no choice but to use M$ if you want to participate. Linux will be able to use TC for security, but because of it's open nature, no trusted content will be released for it.

Re:Trusted Computing

[Anonymous Coward]

Trusted computing is necessary to make DRM work. Any other use can be implemented in software. Basically you *have* to surrender control of your computer in order to play protected content. TC will allow protected content to be available for M$, but not on open systems. Not only will it lock out permissible uses under current copyright loaw, but it will serve to further bolster the monopoly of windows.

Re:Trusted Computing

[gowen]

there are enough intrusions into my life to make it 'safer' as it is - each and almost every one of them pisses me off.

So the building standards that require that your office won't collapse in a minor earthquake piss you off, eh?
The drink-drive laws that help reduce the number of drunken fuckheads driving three ton killing machines piss you off, eh?
The waste laws that stop your local pharmaceutical firm dumping chlorine and ammonia in your local lake piss you off, eh?
The non-proliferation treaties that make it difficult for insane dictators to build nuclear weapons piss you off, eh?

My, you're a brave lad.

Re:Trusted Computing

[NutscrapeSucks]

Actually, I'd bet the "majority of exploits" are social-engineering attacks where users are tricked into running email attachments, installing software from a webpage, or installing spyware bundles like Kazaa.

The solution for this is an easily configurable sandbox, which the vapor factory in Redmond says they are working on. Maybe "Sandboxed computing" is a better term, but the DoD called it "trusted computing", so that's what we're stuck with.

"Sandbox computing" also has little relationship to the trusted key storage, bootloader verification and other planned DRM features (as far as I can tell). But its fun to conflate the two ideas for FUD and profit.

Re:Trusted Computing

[finkployd]

I won't argue with that, but it seems that remote attestation will allow them to comply with the letter of the law (even publishing all protocol specs) and still lock out competition.

Finkployd

Re:Trusted Computing

[Minna Kirai]

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.

Re:Trusted Computing

[Minna Kirai]

This is some of the things you can expect:

Already, we see software design flaws. Just because you mention there are multiple things tells us that it's not a clean system, and that it ignores the traditional Unix dictate: "Do one thing, and do it well".

You list the user blocking unsigned programs from running, and you also list hardware-accelerated encryption. Those are two entirely different features, and there is no good reason why they should be part of the same system. If I desire either of those, I should be able to install it individually.

More importantly, you ignored the most important feature of Trusted Computing: remote attestation. Indeed, it is to support RA that "Trusted" hardware will be built at all- if it was just about the OS not running unsigned programs, that could be implemented in pure software. And the encryption-accelerator is just a bonus feature they tossed in, "As long as we're stamping new chips anyhow". RA says you can prove to remote individuals that you are only running software signed by them, so content publishers can prohibit the use of 3rd party programs to view their data.

Vendor lock-in and beyond.

Re:Trusted Computing

[Minna Kirai]

Trusted computing as a whole is a good thing, with one componant that is a very bad thing: Remote attestation.

Nuclear bombs are on a whole good things, with one componant that is a very bad thing: widespread death.

You can't admit that the single motivating factor of a system is bad, but then say that the afterthoughts and bonus utilities somehow make up for it. And if you don't believe remote attestation was the driving factor to create Trusted Computing, just look at its history of sponsors.

Re:Trusted Computing

[Minna Kirai]

If you don't need protection, don't turn it on.

And then don't bother connecting to the internet either, because no web-site operators will let you view their pages without Trusted Computing enabled.

Otherwise, you might republish their copyrighted works without compensation... that's just too much of a risk. Or you could execute many other forms of abusive programs to disrupt the experiences of their other users.

Really, untrusted PCs are just too dangerously unpredictable to allow out in public.

Re:Trusted Computing

[Minna Kirai]

roundabouts are the greatest traffic controlling device ever.

No. Except in very limited scenarios of traffic flow variations, they are worse than square intersections. The fundamental problem is that they're not scalable.

A stop-sign can be upgraded to a traffic light if usage has grown too high. Then, that traffic light can have its stop/go periods adjusted to compensate for varying rates of incoming cars throughout the day.

A roundabout is completely nonadjustable. There is a little circle, and that's all. If traffic rate is very low, then a stop sign could've worked, and its a waste. If traffic is very high, then a roundabout would be overwhelmed, and you need electric lights (or a police officer).

The roundabout structure creates the same algorithmic flaw computer scientists call "starvation" in a multitasking operating system. Suppose I have streets A and B crossing each other. And suppose that as new towns are built on either side, the traffic flow of A grows to be 300 times greater than on B. (That exact thing has happened at several places in the USA, which is why roundabouts are being removed in that country).

If there is a stop sign, then cars strictly alternate: one from A, one from B, one from A, etc. Both streets can move. If there is a stop light or traffic officer, then it may alternate like that, or it may be a more complex pattern, such as 50 cars from A, 4 from B. Even in a traffic jam situation, where vehicles might be backed up for 5 kilometers, traffic keeps flowing through both streets at a steady rate.

But if there's a roundabout, and it's very crowded, then cars driving on B simply cannot cross A at all. Because of the traffic jam, there is an effectively infinite supply of cars moving down A. According to the rule, "Vehicles in the roundabout have the right of way". Therefore, as long as cars from A keep coming, people waiting on B can't move at all. It is illegal for them to attempt to cross. They can wait 500 cars or 5000 cars, it doesn't matter.

Conclusion: roundabouts are bad. If traffic is low, a stop sign can do the job with less construction costs. If traffic is high, then a roundabout can't work fairly to all drivers, and electric lights are needed.

Re:Trusted Computing

[DJCacophony]

no spoofing it unless you are really good at factoring large primes

wouldnt large primes just factor down to 1 and the number?

Re:Trusted Computing

[finkployd]

I worded that wrong, finding the two primes that are the factors of a large number.

Finkployd

Re:Trusted Computing

[Anonymous Coward]

What do you mean? Do you mean that Trusted Computing is not intended for DRM? Thatis what its sponsors would have you believe, but the reality is this - as a security measure, TC is more or less redundant. As a measure for perfect enforcement of DRM, TC is damn near the absolute best thing imaginable. And you can bet that Microsoft will do everything in its power to ensure that those not running Trusted Windows (with the emphasis on Windows - Trusted Linux is among Microsoft's targets) are disadvantaged in every possible way, with being denied internet access being their ideal.

Re:Trusted Computing

[kyojin the clown]

Have you ever seen a roundabout in action? i drive around the UK all the time, it used to be my job to deliver motors to addresses nationwide.

you NEVER wait 5000 cars at a roundabout - any busy road is likely to be busy in both directions - therefore anyone turning right, or into the road you are trying to exit, creates a space for you to enter the roundabout. the more cars are trying to exit a road onto the roundabout, the more cars are likely to be entering that road from the roundabout. its absolutely scalable for this reason - the more traffic there is, the more likely smoeone will create an opening for you on the roundabout.

plus, there is nothing to stop you putting traffic lights all over a roundabout, which allows you to control traffic artificially at busy periods.

oops, i appear to have a boner for roundabouts. sad.

Re:Trusted Computing

[madaxe42]

No, the laws which piss me off are those which make me unable to do things with my time as I choose them, things which could only possibly affect me, such as (not that I'm into this kind of thing), but in the UK sado-masochism is illegal. It counts as assault. It's illegal for me to drive on my own land, if I have no driving license. It's illegal for me to wire my own house, even if i live in the middle of nowhere. It's illegal for me to lay my own network cables. It's illegal for me to posess or purchase non-addictive drugs - seriously, what's up with that?

Re:Trusted Computing

[runderwo]

Hardware crypto acceleration (a feature that is already available in add-on cards) and mandatory signature checking by the processor are two separate features. Either could exist without the other.

The problem with signature checking is that first of all, it does not prevent signed malware, and second, that the private key is not your private key but some corporation's. I'm certain that there will be features to manage a user keyring (so you can insert your own key, or keys of developers you trust), but it would be hard to believe that there would not be a private keyring of the entertainment industry and Microsoft that is not accessible to the user. A hardware keyring would also be quite limited in size compared to the keyring in a software based signature checking scheme. Mandatory signature checking could be performed by either the processor or OS, and verification of a signature is not a computationally expensive process for something as small as a typical executable. Using hardware accelerated crypto (which is available in other forms already) as an excuse for making your computer subservient to others is simply poor reasoning on their part - but people are buying it in droves.

Re:Trusted Computing

[Anonymous Coward]

(posting anonymously, cuz I work at verisign, though not in any of the cert-related depts...)

Free clue -- VeriSign's raison d'etre is not to convince end users that Business X is "trustworthy", only to verify whether or not someone representing themselves as Business X is in fact Business X. We verify the connection(s) between a real-world/meatspace identity and an electronic identity.

If We Install Spyware, Inc. applies for a SSL cert for www.weinstallspyware.com, our job is to verify that the guy requesting the cert is actually works for We Install Spyware, and that the domain name is also legitimately connected with the company. Ditto for code signing certs.

If, after we have verified that yes, indeed, the spyware you are about to install is really from We Install Spyware, Inc, you still want to install it, then hey, that's on you. We verify the company's identity, that's all.

Re:Trusted Computing

[rifftide]

Users signing third party code as part of installation doesn't sound right. Signing something implies that you accept a certain level of responsibility for it. It's never a good idea to sign something you neither wrote nor completely understand.

Re:Trusted Computing

[ocelotbob]

Maybe MS-style trusted computing is going to do nothing for security, but again, this is linux-style trusted computing. This lets you do things like put in a rule in a configuration file that states something along the lines of "apache has no purpose running ssh, so if it tries, deny it, and also send an email to the security alert address". This way, if apache does try to run ssh, you get a nice email letting you know that all's not well and that there's a vulnerability somewhere along the line.

Re:Trusted Computing

[Anonymous Coward]

You could implement this with standard Unix permissions. Create a user for the application, give it access only to its pref and docs directories, and set uid of the binary to this user. Kludgy (docs you create with it will be assigned to the app's user, not you) but kinda works.

Re:Trusted Computing

[phek]

they all definitly piss me off

So the building standards that require that your office won't collapse in a minor earthquake piss you off, eh?
Why should there be a law requiring this standard? We live in a capitalist society, so business's should use this as a marketing advantage (If I live in california and am getting a house built, I'm definitly going to go with the company that offers the earthquake resilient houses, but if I live somewhere like chicago where earthquakes are pretty uncommon, I'd like the choice of not having this option.

The drink-drive laws that help reduce the number of drunken fuckheads driving three ton killing machines piss you off, eh?
There's no statistics that prove that the harsher laws that were put in place in the late 80's for DUI's has helped at all. Even according to MADD stats, between 1982 and 1988, drunk driving fatilities dropped 9%, and since the harsher laws were put into place (I believe it was 988), the stats have only dropped 12% for this 15year period. Plus a car doesn't weight 3 tons.

The waste laws that stop your local pharmaceutical firm dumping chlorine and ammonia in your local lake piss you off, eh?
Yes this law pisses me off too. I would much rather have this law and the law that restricts me from vandalizing/destroying the property which is polluting me environment removed. As I recall, most companies find loopholes in these laws to allow them to keep their pollution levels high

The non-proliferation treaties that make it difficult for insane dictators to build nuclear weapons piss you off, eh?
We've already proven that these treaties don't work (iraq, north korea... [ok, so there were no WMD's found in iraq, that just shows that saddam swallowed them before he got caught]). On the other hand its great that we've reduced the amount of nucleur power these countries have been able to produce causing increased pollution and a lower standard of living for their citizens due to increased cost of power.

Re:Trusted Computing

[IamTheRealMike]

Mod this guy up, he is totally right. ActiveX has given code signing a bad name because people (apparently including Microsoft) misunderstood what it did. As the AC says, it just proves a connection between the online world and meatspace, not the trustworthyness of a program.

This should be obvious, really. How do you define what makes software trustworthy? How do you define "bad things"? What about software that falls into a gray area? Who gets to impose their moral and ethical values onto others? The best code signing can do is let you take the owners of the cert to court.

This stuff is discussed more in the autopackage FAQ because for some reason people tend to associate "easy to install software" with "will get spyware" even though there's no evidence of that.

Code signing can be useful, but it proves very specific things: for instance, that a mirror hasn't been cracked, or that a particular file was produced by somebody with a trackable real world identity (so they can be taken to court if they're really doing something wrong). It certainly isn't a magic cure-all to the problem of malware.

Somebody above said that you could use SELinux to sandbox programs so you can be sure they won't do bad things. This isn't really correct. While programs can certainly be sandboxed to some extent - after all, that's what root vs user does - you can't expect users to set individual permissions on a per app basis. After all, the GIMP may not look like it requires the ability to initiate network connections, but what if you use GNOME-VFS and type a URL into the open dialog box? What if you, the admin who sandboxes the app, never use that feature and don't consider it but one of your users does?

Sandboxing, like code signing, is a useful technique but it isn't a real "solution" to malware either. I'm not really sure what the solution actually is. Perhaps there isn't one, just as there's no single solution for real world disease either. I'm sure of one thing though - if there is a solution, TCPA certainly isn't it.

Re:Trusted Computing

[TERdON]

You're asuming the "stop rule". That doesn't apply in Europe, so here it, for sure, is the other way around. We have the "right hand rule" instead (of course, the britons are doing it backwards - left hand rule. Also, the french/italians/blah don't really follow it... [/FLAME]). You shall ALWAYS let the car from the right drive first, even if you were at the stop sign first (assuming it's a four road crossing with stop signs in all directions - they're really unusual. If not, you still have to wait - the stop signs mean "let all crossing vehicles pass first", not just "stop", at least here.).

With these trafic rules, a roundabout actually IS better. There's going to be quite a lot of holes in the traffic flow. With stop signs, you have to wait for the time when there's a hole in BOTH directions (except if turning right). In a roundabout, one direction is enough.

Re:Trusted Computing

[cloudmaster]

The busy 4-way stops that I've seen generally include at least 2 people who think that all they have to do is stop, "waiting their turn" is a rather unnecesary component.

Re:Trusted Computing

[entrigant]

Heh I think you may have missed the point. YOU sign the apps running on YOUR system. You DO NOT have to rely on a 3rd party to sign them. Unless the site wanting to run the ActiveX control has your keys, they cannot sign it. VeriSign cannot do this for them. Just because signing a certificate to verify an identity and signing an app with a private key to allow it to run on your system both use the word signing, doesn't mean they are the same thing.

Re:Trusted Computing

[cpeterso]

Do you login as root to do your day-to-day work? Thought so.

Re:Trusted Computing

[Sloppy]

Trusted computing is a very good thing.

Trusted computing is a good thing, if and only if the owner of the computer can override every aspect of it. And by override, I don't mean disable. I mean, it needs to be possible for the owner to plug in any arbitrary desired value into the PCR, manually access stored keys instead of the computer assuming that the user is malware, etc.

Basically, a user needs to be able to do, if he deems it necessary, everything that a malicious virus might wish it could do. The difference being, of course, that it is logically impossible for anything an owner decides to do to his computer, to be considered malicious.

If it is possible to implement remote attestation, with the certainty that the owner of the computer has not told his computer to "lie", then Trusted Computing is not a good thing. Ultimately, a computer must serve only one master.

Besides signing software, TCPA (the chip that is going to be supported by the kernel) does encryption on hardware.

Here is where I get suspicious. You're talking about a performance issue. Nobody has gripes with hardware acceleration. But it should be optional, just as is the case with 3D graphics.

If extra hardware is truly necessary rather than merely a good idea, then I smell a rat.

Re:Trusted Computing

[Sinical]

so no spoofing it unless you are really good at factoring large primes :)

Well, I dunno about you, but I can factor a "large prime" pretty damn quick. "Uh, what is 1 and the number itself, Alex."

Re:Trusted Computing

[finkployd]

Sigh.
I screwed up the wording, I already explained it much earlier in this thread. You are a day late and a dollar short on that joke.

Finkployd

Re:Trusted Computing

[WNight]

And it's no-doubt fun to be a Microsoft Astroturfer running around lying about how Trusted Computing isn't the first step to the brave new Microsoft Computer that you buy, but aren't able (or allowed to try) to run your own non-verified apps outside the "safety" of a sandbox, for your own protection.

Trusted Computing on its own isn't a problem, but it's an absolutely useless security measure. It does nothing that other, better, (ACLs, Capabilities, SELinux) technologies do, and it doesn't provide any real protection. It'll initially stop some "run this file" spam from working, but people send those inside password protected zip files - if they have to explain in the email how to right-click and 'sign' the applet, they will, and people will go along with it in order to view FunnyAd.wmv.

Trusted Computing is somewhere down by tripwire and other signature scanning utilities for how effective it'll be. It'll be good to know if someone trojaned outlook, but had you just used an OS with real file permissions, nobody could have done so anyway.

The fundamental problem with Trusted Computing is that it doesn't realize that there are bad actions that can be taken in the context of the sandbox a "valid" yet buggy app runs in. Sure, you've got Outlook locked into its area, but someone can tell outlook to delete all your email, not through a signed and safe program, but by exploiting yet another bug.

But, isn't it better than nothing? No. It doesn't offer any protections that better methods do not, and it does it in a way that is very amenable to remote oversight and having your privelleges on your computer overridden. If TrustedComputing were something that you setup in the bios, generated your own key for, and could view the key and use it on your own, then Trusted Computing would be for the user, as opposed to for the RIAA and Microsoft. But, we see the truth in this. For our own good the key will be determined when it leaves the factory and will be nothing but a RIAA/etc backdoor into your system. And yeah, yeah, we've all heard the joke about how it'll be optional. Optional as long as you don't want to do anything with a network cable plugged in, or view any media that you own.

Re:Trusted Computing

[Minna Kirai]

Have you ever seen a roundabout in action?

Go visit the "Sagamore Rotary" in the USA. (Google Maps satellite view)

you NEVER wait 5000 cars at a roundabout

Well, if that were always true, then roundabouts can work. But in the real world, often one street is far more popular that the other. That is more likely to occur in a large, semi-rural nation than in a small dense one. Also, traffic patterns in a old and fully-inhabited country like Britain won't change as much as in the USA, where whole new towns are constructed far more frequently.

As I explained, roundabout only does well if the traffic levels remain the same as when it was designed. It cannot be adapted to changes as easily as a stoplight can.

- any busy road is likely to be busy in both directions

If it's only busy in both directions, then the starvation problem I described still happens. Only if all directions are busy can drivers from each direction be sure they'll be allowed to move.

plus, there is nothing to stop you putting traffic lights all over a roundabout, which allows you to control traffic artificially at busy periods.

Except that it if you were going to build lights anyhow, you don't need a roundabout whatsoever, and can use some of the saved space for buildings or sidewalks, or simply improved visibility, making the road safer.

A stoplight is more convenient for drivers, because sometimes they can pass through the intersection without slowing down and all. And, stoplights are safer and more convenient for pedestrians, because they can see cars coming in both directions, and those cars will be forced to stop some of the time. Crossing the street at a roundabout means a car may come at you from around the circle at any time- you never have a guarrantee it's been told to halt.

Re:Trusted Computing

[WNight]

That's what various security programs for Linux already do. But they do it without a secret RIAA/Microsoft key/backdoor in the BIOS.

Besides, Trusted Computing is about (supposedly) being able to trust the signed apps. Most bugs come from convincing the trusted application to do something it shouldn't, even just something that it'd be allowed to do. It's like convincing Outlook in windows to delete the user's email (or email it off to everyone in your address book), something Outlook will have the permissions to do.

Microsoft deliberately claims that Trusted Computing will make users safer. Something *no* security professional agrees with. Strangely, despite Microsoft's ethics, their past record of trying to control the user, and the RIAA/MPAA's desire to remotely authenticate you before you do ANYTHING with "their" movie/music, they want you to believe that this will make it safer for you. Give the keys to your computer to someone else, so that they can verify everything you are, and are not, doing, and they just might let you use media that the law says you own.

Wow, where do I sign up for the kool-aid?

Re:Trusted Computing

[Minna Kirai]

With these trafic rules, a roundabout actually IS better.

True, if you apply a stupid rule, then anything can work badly. I can defeat Tiger Woods in golf if he's using the "One Hand Rule", but that doesn't make me a better player.

If you were drawing up your own traffic rules, you'd have two choices for both stop sign intersections and roundabouts. One of the choices requires a heavy traffic stream to pause and allow a vehicle wanting to cross it to move, and the other does not.

"Vehicles in roundabout have the right of way" means some cars may need to wait indefinately until there is nobody in the roundabout in front of them. But, if you try to "fix" this by saying that cars in the roundabout must yield to allow others to come in, you have turned it into a hazardous demolition derby.

The rule for simple intersections can be changed either way, and its actually safer with the alternating rule (because nobody is encouraged to zip across in a small opening). But a rule to protect roundabouts from persistent blockage will be more dangerous.

Re:Trusted Computing

[Antique Geekmeister]

There's no confusion. You can sign *NOTHING* without one of the expensive and tightly controlled signature keys from Microsoft or one of their tightly controlled clients, used to authorize the new keys you might want to load into the DRM. No initial signature, no new keys. It's fundamental to the key management, to prevent software from loading unauthorized keys.

The DRM basis of the "Trusted Computing" initiative is quite clear from its orign as Microsoft's "Palladium" project: it is designed to permit software and file signing, which is fine, but it's also been designed to control hardware access and the use of feature sets.

This particularly includes DVD players, graphics cards or video players, and even boot loaders so that the actual hardware functions cannot be used without appropriately authorized software keys. The actual purpose is to support DRM, and that's the business case for including it in Windows software.

I'm sorry that Linux has to deal with it in its current incarnation: almost every feature of "trusted computing" has been available for years in the software world, but has been limited by patent arguments and federal policies on the export of encryption technologies in the US, and other restrictions on encryption in other countries. Be clear on this: any robust "signature" technology can be used for encryption, and vice versa. It's only by limiting its at the hardware level and the most basic OS level that you can prevent its use for good general encryption, and that's a big feature of the planned usage of it.

Moreover, the planned key management of it is ridiculous. A small set of signed root keys, maintained by Microsoft, is fundamental to the usage model. Who trusts Microsoft to use its secret ninja powers only for the forces of good?

Re:Trusted Computing

[Alsee]

You are mistaking Trusted Computing as being a good thing for your benefit. You do not need Trusted Computing to do what you suggest.

The ONLY time you need Trusted Compting is when you want to restrict what the owner can do on his own machine and when you want the computer to send certified spy reports to other people (known as remote attestation) which the owner cannot control or modify.

For example Trusted Computing can set up a directory that can only be read by a specific unmodified program (such as a DRM music player). Once that directory is created then THE OWNER can never read anything in that directory, except through the specified software and with that software's permission and under the conditions set by that software. Trusted Computing can then send a spy report to the RIAA that you cannot read this directory and that the DRM software is running, the RIAA can then send an encrypted song to the DRM software to be stored in this folder. The Trust system secures the computer against you, the owner.

Any other use, any genuine security for your benefit, it can always be accomplised with a non-Trusted setup. It can be accomplished with an almost identical system where you know your master key.

That is the crucial aspect of Trusted Computing - knowing your master key. In Trusted Computing your master key is locked inside a chip, the specification says the chip is forbidden to allow you to know your master key, and the specification requires that the chip self destruct and destroy your data if you attept to read the chip to learn your master key.

-

Re:Trusted Computing

[Anonymous Coward]

I agree that what you say is the 'main reason' is a single reason for trusted computing.
But for systems that are switches or teller machines or heart monitors or guidance control systems for a missle or some other device, they use trusted computing for very good reason.
There are many uses for computers. Some of this is on the desktop. On the desktop 'trusted' can be a hinderance. Engineers need their many devices to work and not be tampered with. Many of these are nodes on a network with no keyboards and no monitors. They can be embedded in devices. Trusted computing assures that all of this is not tampered with. It really makes sense.

Try to think beyond your desktop, dude. Most processors are somewhere else.

Re:Trusted Computing

[Alsee]

Who modded this up? It is wrong on almost every point.

When you compile or install a software, you can sign it. The computer will not execute anything that is not signed.

Which has absolutely nothing to do with Trusted Computing.

If you want to do that you can do it right now with a trivial change to the EXE loader code. Hell, you can do it on a Win98 machine without a patch - all you need to do is redirect EXE and similar filetype association to point you your own little stub code to do that check. You can obviously do it with a trivial patch to Linux or DOS or any system.

Trusted Computing has nothing to do with signing files. In Trusted Computing any code's hash *is* it's "signature" and controlls what data it may decrypt. It is that hash which is reported over the internet. No need for any signature from anyone. You can certainly add signatures for various purposes on top of the Trust system, but it really has nothing to do with Trusted Computing itself.

The important thing here is that the user is in full control of the system.

Sure - in the sense that if he does not "voluntarily" turn over total control to the Trust system and to other people then it is impossible to install and run the new Trusted software and impossible to read or use any Trusted files and it will be impossible to view any Trusted website, and potentially in about 5-8 years he may be denied any internet access. The Trusted Computing Group has announced a project for routers that would deny an internet connection to any computer that is not locked down in Trusted Compliant mode. In fact at the Washington DC Global Tech Summit the president's Cyber Cecurity Advisor called on ISPs to plan on making exactly this sort of system a mandatory part of their Terms of Service to get internet access. I can dig up a link to this speech if you don't beleive me.

So short term refusal to submit to Trusted Computing and give up control of your computer just means you can't use a few new peices of software and you won't be able to buy the RIAA and MPAA's new DRM download sales. However the problem gets worse over a couple of years. Refusal to submit means you get locked out of more and more software and more and more files and more and more websites. Eventually you may be be effectively banned from the internet unless you 'voluntarily' activate the Trust chip.

But yes, you are always 'free' to leave the Trust system off. You are 'free' to crawl into a hole in the ground and use nothing new and connect to no one. You are 'free' to to choose to get locked in a prison cell instead of giving up control of your computer.

So you can have hardware accelerated encryption/decryption

Lie.

To be fair I assume *you* are not lying, merely that you are honestly echoing a lie that has been told to you.

Trust chips cheap low horsepower silicon. Running crypo on them is SLOWER than on even the lowest of ordinary low end CPUs. In fact a single basic crypto operations may take a full second or more to run on these very low capability Trust chips.

If you want crypto accelleration, great, get a standard hardware crypto accellerator. They've been around forever and they have absolutely nothing to do with Trusted Comptuing.

Many people opose trusted computer because they confuse this with DRM

You could get EVERY claimed benefit to the owner of Trusted Computing with identical hardware where the owner is given a printed copy of his master key. The fundamental design requirement of Trusted Computing is that they owner is forbidden to know his master key and the specification requires that the chip must self-destruct and destroy your data if you attempt to get at your master key.

The *ONLY* purpose of forbidding the owner to know his own key is to enable DRM enforcment and DRM-type functionality, to restrict the owner. Being forbidden to know your own key has the sole effect of restricting what you c

Re:Trusted Computing

[Alsee]

I think the complaints about locking machines down are more in who gets the keys

It doesn't matter if it's Windows or Linux, the Trusted Computing specification forbids the owner to get his keys. It requires that the chip self-destruct and irretrievably destroy your data if you attempt to get your key out of the chip.

Trusted Linux is just about as bad as Trusted Windows.

-

Re:Trusted Computing

[NutscrapeSucks]

You seem like that you might be under the impression that "TrustedComputing" is a Microsoft brandname. It isn't, it's a class of security systems which include things like Linux Capabilities and SELinux. So it simply does not parse to say that SELinux is better than trusted computing, because SELinux is trusted computing.

(Or technically, an implementation of SELinux would be, if it existed.)

I agree that sandboxes aren't a cure-all, but but neither is the Unixy/OS X "Type your admin password". I still think would be a nice feature to have on a personal system, for myself anyway.

Re:Trusted Computing

[Alsee]

Trusted Computing is just a technology and like probably all technology it can be used to do something good with it

Trusted Computing really comes down to the single point of preventing an owner from knowing his own crypto key. There is absolutely no "good" purpose for that. An owner can get ALL of the same benefits and non of the problems from identical hardware where he does know his master key.

So no, the design of Trusted Computing cannot be defended as being technology that can be used for good or evil. A technology with a poison pill inside is pure evil when they refuse to let you have the identical technology without the poison pill.

-

Re:Trusted Computing

[Minna Kirai]

AC: But for systems that are switches or teller machines or heart monitors or guidance control systems for a missle or some other device, they use trusted computing for very good reason.

Nope. On those systems, there is no reason for Trusted Computing at all. Only one person will be allowed to install program on them, and she will do it only very rarely- probably just once, in the factory when the missile is built. Mission critical embedded systems like those server exactly one owner; but Trusted Computing is about making PCs also serve corporations aside from the owner of the hardware.

Devices like that don't connect to the public internet, and they don't view media files written by other people. They are a black box, and almost nothing gets in or out.

Trusted Computing is irrelevant to a situation like that, unless the system admin is so dangerously incompetent that he needs an extra failsafe to keep him from installing malware on a warhead.

Re:Trusted Computing

[WNight]

Trusted Computing is a trademark, of a working group that Microsoft, AMD, Intel, and others are part of.

The trusted computing site disagrees about the possiblility of SELinux being involved with Trusted Computing (tm). They are quite sure that TC is tamper-proof hardware keys and strong encryption, providing an assurance that the key a message was signed with was itself signed by the TC group, in one form or another.

As such, it isn't for security, as I have described. It will provide next to no actual security benefits and most of the members of the TCG have stated that they see it providing a robust platform for DRM.

Thankfully a scheme like this can't work, too many secrets to keep. It'll be another DVD-CSS fiasco as it gets broken and stripped of watermarks. Unfortunately, it'll cost us a fortune to have implemented and it'll get in the way of many legitimate transactions. Like all other rights-denial software it'll end up harming the honest and unsophisticated users, but thanks to the nature of information, being broken by everyone who has heard of Google.

Re:Trusted Computing

[chadruva]

If TCPA is supported on kernel and we can use access it like any other device, then it is a really good inclusion to the kernel, now we can brute force keys faster by having on hardware encryption/decryption plus the CPU working on parallel, this will surely come handy.... muhahahahaha

Re:Trusted Computing

[BillyBlaze]

The argument against TCPA is a little better-informed than you admit, but it's goals are more long-term and big-picture. (Perhaps too much so, but nevertheless...)

The idea is that while TCPA can be used to help security or accelerate encryption, it of course can also be used for DRM, which includes not only things like delivering entertainment in such a way as to screw the user as hard as physically possible, but also the scary stuff about keeping you from blowing the whistle on evil schemes, etc. The idea is that the current fact that files can be copied by the recipient, and that client computers can act in a way not sanctioned by the servers, is an important safeguard, both in maintaining the balance of fair use and in more serious matters.

I don't think most TCPA opponents are so misinformed as to think that enabling a TCPA chip somehow immediately limits you, or that it's not optional. Instead, they just don't want to see TCPA become popular, because of the bad things which will inevitably follow.

Re:Trusted Computing

[NutscrapeSucks]

> Trusted Computing is a trademark,

Thanks for the correction -- I was only aware of the general sense of the term, and that's what my post referred to. I agree that the signed-key system probably will have very few realistic security applications.

Re:Trusted Computing

[Minna Kirai]

Too bad you're still down on 3 and not 5. Came in late I guess. I wish there was a way to flag a post as a reply to 5-10 different erroneous messages at once.

That is really the sole point of genuine contention - whether an owner can know his own master key.

Looking at the other messages on this topic, there is a ton of delusion circulating on that point. The corporate PR departments are earning their paychecks.

It would probably be wise for the various anti-TCPA websites to emphasize this one fact more strongly. The Trusted Computing boosters have been quite effective at diverting the conversation to assorted side bonuses like preventing worms and keyloggers, and often well-meaning people who just want to see better designed desktop OSes (more granular permissions, sandboxing, etc) defend TCPA of of ignorance of the fundamental fact that users don't get the key.

Re:Trusted Computing

[Minna Kirai]

Thankfully a scheme like this can't work, too many secrets to keep.

I think it can definitely work, needing only a 20% expansion in the jackbooted-thug workforce to prevent dissemation of hardware-circumvention techniques. Hardware-hacker nerds aren't brave- all it takes is two or three stomped necks, and they slink away.

Simply point out that breaking Trusted Computing helps terrorists, and the police will FIND a way to protect the Security of TCPA, for the Freedom of the Homeland.

Those are pretty big changes

[Trigun]

Are they backporting from the 2.7 tree? I know that SE linux has been around for a while, but why the sudden interest by the kernel maintainers?

Re:Those are pretty big changes

[Anonymous Coward]

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?

Re:Those are pretty big changes

[Stephen Williams]

AFAIK, there is no 2.7 tree. New development is still being done in 2.6.

-Stephen

Re:Those are pretty big changes

[aug24]

Uh, *what* 2.7 tree? The patch which turns Linux into SELinux, which has been developed by some spooks somewhere, is moving up into the main kernel. That's all that's represented.

When you have a multi-developer environment with a single tree, you push your changes up and pull your and other people's changes down. Hopefully everything remains stable at every level except the individual developer's trees. Back in reality, of course, this is not entirely true ;-)

That's how Linux is developed... prolly on a bigger scale than pretty much any other parallel development setup.

J.

Re:Those are pretty big changes

[Trigun]

I had thought that any major changes were held off until the devel branch had started. I guess that trusted computing isn't as big of a deal as I thought it would be. Maybe that's a good sign.

As for the non-existance of the 2.7 tree, that's what I thought, hence the question. After reading it again, I guess it was a little ambiguous.

Re:Those are pretty big changes

[aug24]

ISTR that there is still a debate about whether or not to have a devel tree, just lots of branches. Hence the description I made, which I now realise without context was a bit ambiguous too!

Anyway, Linus was saying a while ago that it might as well be up to the distributors to stabilise for 'proper' use, giving the kernel maintainers the freedom to accept patches that take them in the right direction, without having to be obsessed with stability. So you ftp from your mirror of choice, depending how hardcore you are!

J.

Re:Those are pretty big changes

[Zemplar]

"Are they backporting from the 2.7 tree? I know that SE linux has been around for a while, but why the sudden interest by the kernel maintainers?"

Perhaps to further strengthen Linux as a viable alternative to Solaris 10, which now includes most of what used to be "Trused Solaris", their uber-secure version. Linux is great, but I still think anyone here would agree that Solars, for the moment, is still more secure than Linux at present.

Re:Those are pretty big changes

[odaiwai]

The 2.7 tree? You know, normally time-travellers are not supposed to give too much away.

Re:Those are pretty big changes

[0racle]

Big changes used to be put into a devel branch, but they decided to screw with a good thing. Its up to distros to stablize the kernel now so I guess LFS people are out of luck.

Feature creep

[Dancin_Santa]

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.

Re:Feature creep

[Tim C]

You got one thing right - you *are* going to rub a lot of feathers the wrong way saying that. I'm not saying I agree or disagree with the idea, but understand that having lots (and lots) of little tools that do one thing only, that can be chained together is the "Unix way".

For a lot of people, that's a lot of the appeal of Unix and Unix-like systems.

Re:Feature creep

[Builder]

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.

What on earth makes you say that ? Linux Desktop installations aren't suddenly going to ramp up just because we have a new kernel, and changes to the kernel alone will not make Linux suitable for the desktop.

Linux's major market is still on the server. It's only now really starting to make the move from the edge of the network into the data centre. The main Linux market is going to be the server for a long time to come!

As for 'compentization', we already have this. Just compile the kernel with the minimum features you need, and the rest as modules. Most distros ship this way by default.

Re:Feature creep

[Anonymous Coward]

"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"."

You worth dung heap. You complete waste of skin. The whole mindset that drives the *nix community is the idea of chaining and small modules doing one thing and doing it very well.

I don't want events in my fucking kernel. I don't want notification service sin my kernel. I want the fastest, simplest kernel imaginable.

Shit like this is just fodder for the "Linux is always playing catch-up" crowd and when shit like this is pulled, it makes them abso-fucking-lutly right.

You know, it is fucking idiotic moves like this, that are nothing more then a poor attempt to overthrow Microsoft, that drove me to switch to BSD.

If I wanted a piss poor OS that made the kernel into some bloated piece of crap I would use BeOS

Re:Feature creep

[gowen]

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".

What? That makes little sense. If you want to write monolithic apps for Unix, it's completely possible. Ever heard of Oracle, Firefox, Emacs, Evolution? Similarly, one could write a console app that combines the features of grep, find, locate and xargs in one "handy" command.

The fact that no-one has written these things just means that traditional Unix programmers don't like/want them. That may well be changing, but the kernel is an irrelevancy. Absolutely none of these things need any of the kernel services touted in this article.

Re:Feature creep

[JohnFluxx]

I'm not sure what your post is saying.

Hardware support has nothing to do with feature creep (directly anyway - indirectly they effect underlying device systems like usb,scsi,ide etc).

Seemless hardware support (HAL etc) is a new feature, so point there.

The inotify thing is a replacement for dnotify (I know you didn't mention it, but it was in the article) so doesn't add any features really, just fixes bugs.

The whole thing about relying less on chaining... I just didn't get.
Can you give any example where something that used to be considered to be a user space problem is now kernel space? It's always been known that we need kernel notifications for hardware etc.

The 'chaining' thing will never go away - you'll always need kernel space talking to user space middle ware talking to user space apps.
Nobody has ever thought otherwise, and unlikely anyone will ever think otherwise.

The 'whole units' bit only makes sense if you're a manager.

Re:Feature creep

[Anonymous Coward]

"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."

Erm...you can do that now and have been able to for most (all?) of the last decade.

At runtime, there are modules. At compile time, whole sections of code can be removed.

The Linux kernel is only monolythic at the lowest levels; it's not a microkernel message passing system and that's not going to change. That's one of the reasons why it has been ported to so many processor architectures -- even the arch-specific parts only get added if you are compiling for that processor!

What function(s) do you see specifically?

Re:Feature creep

[Vo0k]

Linux is supposed to be fun. That's the most important part about it. Not "good for mission-critical applications", not "suitable for enterprise solutions", not "desktop-ready", not "lower in TCO than competition", not "faster", not "more free", not "less bloated", not "more robust", not "scalable", "stable", "secure", "efficient", "competitive", "easy". Just fun. This is the ultimate priority and all the rest results directly from it. Make it a corporate monster and you take all the fun away from it, so let's avoid it. Make it free, and you make it more fun, so let's make it free.

Security is interesting, but gets boring on the long run.
Stabilizing, bugfixes etc are a drudgery, but later using buggy code sucks.
Cleaning up badly written code is difficult.
Writing drivers really sucks.
Features are fun.

Re:Feature creep

[Bert64]

Well, "solutions" are often built of lots of modules (functions) chained together... with a wrapper app that makes them appear to be one cohesive lump..
It does make far more sense to have the functions available outside of the larger solution, so they can be adapted to service other solutions aswell. But that's not to say you can't have large monolithic-looking apps that internally use the same smaller components to get their work done.

Re:Feature creep

[MBGMorden]

Linux's major market is still on the server. It's only now really starting to make the move from the edge of the network into the data centre. The main Linux market is going to be the server for a long time to come!

I'm pretty sure that what he was inferring was that this new kernel would be used moreso on the existing desktop installations versus the server installations. That's not too far fetched. Server systems tend to not update what isn't broken unless there's a major security advisory. My mail server is still running FreeBSD 4.11 and will do so for the foreseeable future. I still keep up with the updates for the daemons that are loaded and do stuff (Postfix, Amavisd, Dovecot, etc), but overall I don't care about support for USB2.0 or the latest graphics card. So long as it sits in the rack and keeps delivering mail then I'm not going to do anything too drastic.

Re:Feature creep

[Taladar]

While I am disgusted by the idea of abandoning piping and similar powerful unix-features I can imagine why he mentioned it in a kernel-article-comment. He probably meant Linux should implement some high-level (read: more complicated and less powerful) IPC-Model (Interprocess Communication) like Windows' DDE or something like that.

Re:Feature creep

[gowen]

"Linux" already has several high-level IPC models. Not only are their the CORBA brokerage architectures supplied by Gnome, KDE (and other possibly other X apps), but on a kernel level you've also got support for good, old-fashioned shared memory, and named pipes/FIFOs.

DDE/COM-style sharing of data between apps can [and therefore should, IMHO] be done entirely in userspace.

Re:Feature creep

[Metzli]

Try :%s/Linux/Windows/g and see how that reads. It sounds like those who use Linux are starting to get into the same mindset as those who use Windows. To paraphrase your statements:
Security is boring.
Stability and fixing bugs are boring.
Writing drivers is no fun.
Features are good.

Aren't mindsets like this part of what got MS into the patch, reboot, patch, reboot, etc. cycle it's in now?

I don't mean to start a flame war, but this is one of the reasons I _really_ don't like Fedora Core. I don't have specific examples off the top of my head, but I've never really liked it. I have stopped using it since FC3 and will likelly never go back. It has nice bells and whistles, but the bugginess and instability that I and my friends (all of whom are professional Unix admins) have experienced have turned almost all of us to OS X and Ubuntu/Debian. Yes it's a "test" OS, but it just doesn't have the rock-hard stability that I expect from Linux.

Re:Feature creep

[Jason Hood]

little tools that do one thing only, that can be chained together is the "Unix way".

There is a term for what you are describing:

"Separation of Layers"

Re:Feature creep

[leecn]

There is an OS that doesnt do things the "unix way", perhaps you could just use it?

Re:Feature creep

[McDutchie]

It would be nice to see some componentization of the kernel to allow for easy stripping of unnecessary features,

Umm.. ever heard of kernel modules and the plethora of kernel configuration options and methods? I honestly cannot see how you could get even more 'componentized'

Re:Feature creep

[Minna Kirai]

There is a term for what you are describing:
"Separation of Layers"

False. The term she was describing is the Rule of Modularity. "Separation of Layers" is a special case, which requires that the modules are ordered in a hierarchial pattern. Designs which cannot be described in an acyclical graph may still be modular.

Furthermore, a google search on "separation of layers" produces nothing similar to what she was describing.

Re:Feature creep

[ultranova]

I don't want events in my fucking kernel. I don't want notification service sin my kernel.

But Linux already has these in the kernel. They are called signals, and are used to deliver notifications of events - for example, "SIGTERM", which means "please die" or "SIGKILL" which means "DIE!!!" or "SIGCHLD" which means "your child has died".

How is this any different from the message delivery system of any other OS ?

I want the fastest, simplest kernel imaginable.

Wouldn't this imply a microkernel ? And wouldn't a microkernel absolutely require a good event-passing system (since the majority of work is done in user-mode servers and the kernel mostly just controls message-passing) ?

Re:Feature creep

[Vo0k]

No, the mindset of microsoft is...
- management - Max Profit
- marketing - making it seem to be cool/fun.
- designers - whoring to the upper management
- programmers, QA - Get paid without overworking yourself

Manager: "My stock option value is another $100 now. Let's find the guilty..."
Marketing: "So how do we wrap this rotten fish to make it look fresh?"
Designer: "Whoa, this SOUNDS so modern, that boss MUST be impressed! (Will anyone use it though? No.)"
Programmer: "I'm to implement this pile of crap? Okay, let's get done with this and forget as fast as possible."
QA: "Smoketest passed, boss approved, deadline in 2 days, stamping 'ready for release' and not digging any deeper or I might find something somebody might not like."

That's the mindset of many software corporations. Possibly including RedHat as well.

What this means

[JohnFluxx]

Just for those not in the know..

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 /home recursively. I don't remember why or which. :)

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.

Re:What this means

[Lussarn]

One distro uses this for watching /home recursively. I don't remember why or which. :)

It probably is for Beagle for indexing and searching.

Re:What this means

[JohnFluxx]

Oh just to reply to myself.. dnotify had this problem where if you watched a file say on a CD, it meant that file was 'opened' and hence the CD couldn't be ejected because it was being used..

inotify fixes this.

(waiting 2 mins between posts... sigh)

Re:What this means

[MichaelSmith]

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.

This should be taken care of by hotplug, but I have an interesting problem with Ubuntu 4.05.

The first time a USB storage device is connected to the system Gnome detects and automounts the disk. Unplugging the disk removes the icon from the gnome desktop.

The next time the device is connected gnome does not mount the device. The only way to get Gnome to recognise the device is to logout (restarting Nautilus)

I am surprised this doesn't work properly. Any suggestions? I can't find any reference to this problem on the Ubuntu or Gnome web sites.

Re:What this means

[Speare]

I don't know what fixed the problem, but Fedora Core 2 had the same issue for me, but it works quite differently (and correctly) in FC3.

Re:What this means

[Ford Prefect]

Inotify is a replacement for dnotify. With both you can watch for a file for changes. You can even watch a directory for changes.

I've seen the older dnotify thing at work in KDE, and even that seemed to work much better than the equivalent in MacOS X on my iBook. I've frequently saved a file from Safari, gone to attach it in Mail only to find it's not present in the file selection dialogue box (that I've opened after saving the file). A quick click on the desktop makes things update, but it's bloody annoying.

I've noticed that open source solutions to problems like this often iterate through various designs, starting from a quick hack, moving on to something with more features grafted on and then an occasional redesign or two before something much longer-lasting and full-featured comes into being. I suppose the lesser need for backwards-compatibility helps a lot - you can kill a crap design and rewrite any (open source) software which used it, instead of having to keep it until the end of time in the style of Windows...

Re:What this means

[MichaelSmith]

Thanks. I have a FC3 system to test on. Most likely it will be the version of Nautilus.

Re:What this means

[JohnFluxx]

I doubt this is much different from Windows internally. No doubt they have quick hacks with incremental changes which is then released when ready. (or not, insert MS bash here if you want).
It's just with linux it's all out in the open.

Re:What this means

[maxwell demon]

that's part of HAL

HAL? Then I understand the addition of Trusted Computing. It's needed to implement "Sorry Dave, I cannot let you do that!" :-)

Re:What this means

[dtfinch]

I tried plugging a laptop hard drive to a USB adapter and then into a Windows desktop so I could recover the drive (the laptop was dead). It recognized it as a USB mass storage device, but did not give it a drive letter. Took a look in the Disk Management control panel. It saw the drive, and its partitions, and acknowledged that there was no drive letter. I right clicked the partition and the option to assign it a drive letter was greyed out. So I tried the diskpart command line tool. It said that the drive was active, and it saw the NTFS windows partition, but that the drive was hidden and had no volumes. There was no command to mount the partition.

I tried the drive on 3 computers, with XP home, XP professional, and 2000 professional. Same results on each, except that the 2000 computer spontaneously rebooted and afterwards could no longer mount any usb drives.

So I plugged it into an ancient computer running Ubuntu Hoary. The drive was immediately detected and mounted. An icon was placed on the desktop. A nautilus window was popped up to browse the drive's contents. I was able to backup the entire drive to a server without error and without the use of a command line. I just dragged & dropped.

I haven't encountered your problem yet. You could try Ubuntu Hoary to see if that fixes it. To upgrade from the command line:
sudo gedit (or whatever text editor you prefer) /etc/apt/sources.list
replace each "warty" with "hoary" and save
sudo apt-get update
sudo apt-get dist-upgrade

Re:What this means

[tialaramex]

hotplug isn't enough

The hotplug system is part of the OS, running as root, and is intended to do things like insert driver modules, pump firmware around, and set permissions. This is useful even on a server, although its more important for a laptop or desktop machine. It doesn't do anything to your desktop directly though...

HAL uses DBUS to notify the user's desktop software about these exciting events so that it can do something appropriate. The desktop doesn't have dangerous privileges (so it's unlikely to accidentally format your main SCSI drive instead of the freshly inserted USB flash) and is able to interfact with the user through pop-ups and making icons appear in file managers etc.

This system (Hotplug + HAL + DBUS) replaces earlier systems where desktop software polled for any interesting changes every few seconds. The new system is event driven, using resources only when they're needed, and should hopefully be more powerful too.

Re:What this means

[Macka]

Will be interesting to see if they've improved it in Tiger.

Re:What this means

[intangible]

Windows will only assign a USB drive the next drive letter after the last physical device. For example: if your cd-rom is D: then the USB drive will try to mount at E:, however, if you have E: mapped to a network drive, the USB drive will not be mounted.

Re:What this means

[spitzak]

The fact that you *have* to "unmount" is the bug, you know.

I know, they may have trashed their data because they did not unmount. However it is silly to "punish" them by making it impossible to stick the disk back in to see if it is trashed.

Here is what I consider the ideal solution, far better than Windows or OS/X. Lets see if somebody can actually do this right:

When the drive is pulled, the system checks to see if all I/O had been flushed to it. If so it unmouts. The desktop environment responds instantly by removing any display of that drive or it's contents in file browsers.

If I/O has not been flushed the disk indicator remains in the desktop display, with a big red mark indicating that it had been pulled. Usually sticking it back in and pulling it after a second will flush the rest of the data and unmount it correctly. The user can also ignore it and stick new USB drives in (getting new icons) or do something on the menu to make it forget about the drive.

Attempting to shut down or log off with any red marked disks will ask the user to stick them back in so the data can be flushed. The user can hit cancel if they don't want to.

This flushing of a reinserted device must check carefully that it is the same device and it has not been written to by another machine while it was pulled.

Re:What this means

[Jerf]

Yes, but once that quick hack is deployed, even to beta testers who then build on it (if the testers are large enough), Microsoft supports them in perpetuity.

Example: COM, DCOM, ActiveX, now the various .NET protocols, and remember "COM" covers several iterations itself and has several variants. Windows supports them all.

I am increasingly convinced of two things: One, this is why Windows is so bloated; once a feature gets in, it never gets out. I suspect this is the sole reason; if anything, Microsoft programmers are above average so most other explanations don't fly. Two, this is why open source-style development, realizing you can't have backwards compatibility forever and ever and depending on source code and its recompilation, will eventually win; reverse compatibility becomes too expensive. (This is not to say OSS will win, though OSS gets a big foot in the door when source is distributed, but that the style is inevitable. Shipping binary code to run directly on the processor is just too low-level to be shipping programs around in 2005. The JVM has this right, as do a number of open source projects, shipping the code to a virtual machine around.)

This also explains my assertion that Microsoft programmers are above average with the observed code quality coming out of Redmond; they get increasing amounts of the "above-averaged-ness" frittered away in backwards compatibility support. If Microsoft could truly just start 100% fresh, which they can't (destroy-the-business kind of can't), they'd probably produce a fearsome OS. We'll never know.

(The eye candy of Longhorn may take all the processor they've spec'ed out, but, most likely, the reason it needs so much memory is all the garbage hanging around, being backwards compatible. The OSS equivalent of Longhorn eyecandy will fit in much less memory, even if it needs the same or more processor, as a result, and the memory advantage is only going to grow on the OSS side, because by and large, it doesn't implement every half-assed idea from 1988 on in itself. It tries to constrain the half-assed ideas to the last year or so, and goodness knows there are plenty to go around.)

Re:What this means

[dtfinch]

If that was the case it would have worked on all 3 Windows PC's. They do each have a network drive on Z:. I'm sure we've used USB drives in the past without trouble. I'm curious if the disk having been C: when it was in the laptop matters, like if it tries to remount hard disks as the drive letter they were previously and failed because C: is taken. I found several forum postings by people having the same exact problem, trying to access a hard disk removed from another system, without any mentioning having found a solution. After a few hours of frustration, I figured that my best remaining bet was using Linux to copy a Windows NTFS formatted drive to a Windows (actually Samba) server because Windows itself wasn't up to the task of supporting its own media.

Re:What this means

[ceswiedler]

Can't the kernel also do a "soft" unmount, which flushes everything to disk to get it in a clean state, but leaves the filesystem mounted in the kernel?

If the user unplugs the drive, the kernel does a complete unmount, and if they access it again, the drive is transparently remounted.

Considering how many operating systems have this problem, I doubt the solution is this simple...

Re:What this means

[Q2Serpent]

I had the same problem. The solution is to open the partition on the USB drive and change the partition type to the proper type for NTFS. When I had the problem, it was a FAT32 formatted partition, but the partition type flag was Linux. Windows didn't like that, but linux had no problems with it.

Change the partition type to what Windows expects, and you should be ok.

Re:What this means

[diamondsw]

Kernel event notification is present in Mac OS X as well, but the Finder and NavServices don't use it yet. Tiger may fix this, but I doubt it (people would have been dancing in the streets).

Oddly, it *was* enabled in early betas of Panther, and then mysteriously vanished. Sad. :(

Re:What this means

[dtfinch]

It was an NTFS partition created by XP Home. The drive was not a flash drive, but a laptop hard drive which I removed from a dead laptop and connected to a USB adapter to connect to a desktop to recover the data.

Re:What this means

[Dwonis]

Normally, you can use the "sync" mount option to enable synchronous writes. Unfortunately, this is currently broken in the Linux vfat driver.

Re:What this means

[Psyrg]

The grandparent is almost correct in my experience. I have found that NTFS partitions can be marked as hidden by Windows if it finds error with it.

Linux can mount these volumes in the normal way, whilst Windows will refuse.

Re:What this means

[Q2Serpent]

Well, if Windows created the partition, it may be a separate problem. But I was indeed talking about a USB hard drive - I have an external enclosure with a 120GB seagate in it that I had this problem with.

Sorry I couldn't help.

inotify

[Anonymous Coward]

'iNotify' Apple about this release and let's see what they have to say about 'iT'.

Re:inotify

[FauxPasIII]

> 'iNotify' Apple about this release and let's see what they have to say about 'iT'.

If I'm not mistaken, inotify is actually a play on the word "inode", since that's what it's watching.

What about a better solution for device drivers

[UnderAttack]

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.

Re:What about a better solution for device drivers

[Anonymous Coward]

> did you ever try to configure a kernel these days?
it's a whole load easier than the pre-menu days when you had to go through every single option line by line...

Re:What about a better solution for device drivers

[JohnFluxx]

'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.

Re:What about a better solution for device drivers

[Anonymous Coward]

I've been a avid user of Linux for a long time.

The days of compiling a custom kernel is over, except for people who like playing with the latest features or gentoo users.

Not because it's impractical, just because there is no point.

If you have a high-quality distro (Suse, Mandrake, Debian, Ubuntu, Fedora etc) then the distro people are quicker to apply kernel patches to fix security issues, test them for bugs, and release updated kernels then what you can normally get thru kernel.org.

The performance advantage of running a custom kernel to cut down on excess drivers is pretty much null and void if you have more then 16 megs of RAM.

Stability with distro versions of kernels are generally very good because they are tested in your operating enviroment before they are given to you.

So unless you run into oddball issues (such as the very latest hardware) or requirements recompiling a kernel is a non-issue, even with very experianced and demanding linux users.

Re:What about a better solution for device drivers

[Professor_UNIX]

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.

So you're saying it's better to have major kernel APIs changing constantly and breaking third-party drivers (even open source ones that need to be tweaked) rather than coming up with a stable interface to expose to module developers? There's no reason they can't write an abstraction layer between the internal kernel code that changes from release to release and the modules... they just don't want to. It's a political and philisophical argument for Linus.

Re:What about a better solution for device drivers

[pkphilip]

I think it will be useful to have a system whereby drivers can be loaded without requiring the entire kernel to be compiled.

Granted most distributions do ship with as many of the drivers as possible, but I have found myself in a spot a few times when the Linux kernel did not have the drivers for something fairly critical which was needed during installation - for instance, I am trying to install linux onto my AMD64 machine but none of the linux kernels (including 2.6.11) support the southbridge chipset on my motherboard.. and so Linux cannot detect the harddisk on my computer...which means I cannot install Linux on the machine now.

I installed XP on the same machine without a problem - just popped in the device driver CD and the harddisk was immediately recognized.

It will be great to have that facility on Linux as well - changed your graphics card? just pop in the driver CD and install the driver and you are ready to go..

Re:What about a better solution for device drivers

[fearofcarpet]

I'm not sure what the beef here is... I happen to run Gentoo and love having the ability to easily add/remove/modularize (is that even a word?) drivers from the kernel... And it is rock stable even on an amd64... I can streamline the kernel (becuse it makes me feel better) and ditch things I don't want (like hiding certain hardware or compiling 3rd party drivers in their place). Just giving the kernel what I know it needs does cut down on boot times because of hardware auto-detection, but of course you can just edit init scripts to get the same effect... I'm pretty sure you don't need the entire ~100 MB source to compile drivers either. Fedora stopped including the kernel-source RPMs a while ago and I have had no trouble compiling custom drivers.

Isn't this the great thing about Linux though? I can re-compile the kernel to my heart's content under Gentoo and pretend it makes my computer faster. If I want to slap Linux on a computer and just have everything work, I can go Fedora, SuSE, whatever, and have everything built in and well tested. My choices with Mac OS or Windows basically boil down to "should I go with the latest version, or stick with what I have?". But hey, whatever changes are coming down the pipe for device drivers is fine by me as long as it doesn't rob me of any choices or flexibility.

Re:What about a better solution for device drivers

[JohnFluxx]

"So you're saying it's better to have major kernel APIs changing constantly and breaking third-party drivers (even open source ones that need to be tweaked) rather than coming up with a stable interface to expose to module developers? "

Yes. Nuff said. A frozen api hinders development, and hopefully disuades closed source drivers. (but that's another argument).

And there are technical reasons you can't just write an abstraction layer. At what layer would you put it? Have you seen the reworking in the last 5 years that has gone on for ide-scsi and usb for example?
I don't think there's a way you could have come up with a good abstraction layer that would have allowed for the changes that the ide and scsi layers have gone through.

Btw, the philisophical argument is good enough just by itself, I think. :)

Re:What about a better solution for device drivers

[cortana]

Linus has explained why a HAL is a stupid idea several times.

The way Linux driver development works is: release your driver under the GPL. Show that you are capable of maintaining it. Once it works well enough, get it merged into the Kernel. Continue to maintain it.

If you don't like it, fork it, and leave the developers with a development model that actually works.

If Linux had a HAL, we would have the Windows situation: hundreds of drivers that were written, worked for a while, and then were dumped as soon as the company that produced them decided they could make more money by forcing us to upgrade to their next product.

I would like to leave such cargo-culting of drivers for Windows chumps. This way we get fewer drivers, but the ones that are written are of much higher quality--and are actually maintained, too.

Re:What about a better solution for device drivers

[stevey]

A lot of modules are able to be built outside the kernel tree nowadays, they will require the 'kernel-headers' installed which match the running kernel, but not the full source.

For example, mounting remote filesystems with ssh-fs shows how you can build this module easily on a Debian system.

Whilst the packages are different on other Linux distributions, the steps should be similar.

Re:What about a better solution for device drivers

[JohnFluxx]

When I was younger I loved downloading the next kernel, going through every single option, reading the help, and deciding if I want it.

Great fun :) Led to me contributing a tiny bit to the kernel (I have a 3 line patch in there still! :) )

I don't these days.. perhaps I should. Great for learning even if I don't produce a working kernel heh.
It would be fun to play with SElinux and everything. I'm such a geek.. ;)

Re:What about a better solution for device drivers

[cortana]

I was reading the comments posted to the GCC 4.0 announcement story yesterday, and I have just been struck with how similar Linus' and RMS' attitudes are on the subject of stabilising the subsystems of Linux and GCC.

RMS gets so much flack, enough to significantly reduce the signal:noise ratio of the story. But no one takes a similar view when Linus doesn't want to stabilise kernel APIs for the same reason.

I guess the moral of the story is that ACs are hypocrittical twats, and that Slashdot should disable AC posting. It would probably eliminate 99% of the bullshit posted here. :)

Re:What about a better solution for device drivers

[dash2]

That's great if you're on the server end. As a laptop user, I'd rather have a low-quality driver for my wifi card than none at all - and no, I do not want to be pointed to a list of cards that work with Linux, I just want the card I have already bought to work, thank you!

Re:What about a better solution for device drivers

[JohnFluxx]

Speaking of the flack RMS gets - I went to speech by him a few months ago. I hadn't heard him speak before for many years. He actually had some very good ideas and presented himself beautifully. Not the RMS I knew from 5 years ago.

Re:What about a better solution for device drivers

[cortana]

Frankly, it's your responsibility to do some research before you buy hardware. :)

I was bitten by Wifi too, I saw that prism54 was in the kernel so I bought an SMC 2802W. Unfortunatly, it turns out that the 2802W was silently replaced everywhere with the 2802Wv2 (same model number, FCC ID, no way to tell the cards apart).

Of course, the 2802Wv2 is of course totally different on the inside, and was produced after Conexant; they seem to have used the same shitty design as they did for their Winmodems; apparantly the 2802Wv2 offloads all the work to the host CPU, which means the driver has to be a lot more complicated. And asking Conexant for hardware specs is about as likely to work as is building a space elevator out of cheese.

To get back on topic: if you want a low quality driver you can probably use ndiswrapper + whatever hunk of shit your card's manufacturer supplied you with for use in Windows.

Re:What about a better solution for device drivers

[Anonymous Coward]

You don't need to recompile the entire kernel to load a driver. Drivers can be compiled against a running kernel and installed right there and then, assuming they're written properly.

I've changed my graphics card many times. Unlike Windows I didn't need to "pop in the driver CD", I just turned the computer back on and it worked.

I suppose we could tell people to put a music CD in their computer and then reboot it a few times so that they feel they've "done something", but honestly, why not just let them use it?

Re:What about a better solution for device drivers

[JohnFluxx]

by outsider I meant someone who doesn't follow kernel development. So a user would count yes. And by my defintion of an outsider they are not discerning enough to know what they need.

And no, their concerns are not paramount. I don't give a damn what they say they want as its rarely what's best since by definition they don't understand the whole situation.

The end goals I do care about. I want good drivers as much as anyone, but I don't see the best way for that is a stable driver API.

Re:What about a better solution for device drivers

[Angostura]

Nifty. If the model works so well for device drivers, let's extend it to apps and desktop managers.

Afterall, who wants 100s of potentially dodgy and unstable apps, when we can have a few robust Linus-certified apps.

Re:What about a better solution for device drivers

[cortana]

Linus doesn't give a crap what goes on in user space. The Linux system calls have been kept stable since 2.0, I think (can't speak from personal experience since I only came in around 2.4.18).

Re:What about a better solution for device drivers

[Robert The Coward]

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.

Re:What about a better solution for device drivers

[MartinG]

Allowing modules compiled for one kernel to run with another would require fixing the ABI. This is bad because it means the developers can't make changes they need as quickly as they would like. In the end that adversely effects users because they have to wait too long for new features.

The way things are now does not adversely effect users, but does slightly annoy developers who compile their own kernels.

They have it the right way around already. Keep things as they are. "better kernel in general" is more important than "easier to compile kernel and modules"

Re:What about a better solution for device drivers

[ArsonSmith]

I don't use the Linus-certified apps but I do use the Debian-certified apps. And just like hte kernel sometimes I compile third party apps that may or may not work depending on if they are following Debian.

Re:What about a better solution for device drivers

[MartinG]

Sorry, I was ambiguous.

By fix, I mean:

"To put into a stable or unalterable form"

and NOT:

"To restore to proper condition or working order; repair"

Hope that clears it up.

Re:What about a better solution for device drivers

[runderwo]

Actually, here's an idea. Since compiling a Linux driver requires no C library, you could ship the compiler GCC and binutils on the driver CD itself. You would only need the headers for the kernel you are running installed, which are provided by the distribution already, separate from the full kernel source.

A script copies the compiler, driver sources, and kernel headers to a chroot; compiles the driver; exits the chroot; copies the driver to the appropriate location; and loads it. Another script removes the driver if the user changes his mind.

No stable binary interface is necessary in this way, and no development tools on the user's system so no worries about GCC standards tightening breaking the compile - only worry is source compatibility, so the tested kernels can be stamped on the CD. (e.g., Compatible with Linux up to version 2.6.10)

Re:What about a better solution for device drivers

[runderwo]

Every new release of glibc would be binary incompatible with the last version.

In what way? All I can think of is the C++ ABI transition (which can hardly be referred to as a mistake) and the problems that happen when people use internal library symbols that are mistakenly exported and then later not exported anymore.

Re:What about a better solution for device drivers

[bogado]

Couldn't be a compromise? I mean, and I am definitly an outsider here, couldn't we have a subset of the kernel interface that would remain stable (for say a major release code 2.4 -> 2.6). This subset would not guarantee that it would be the best and faster way to achieve things, so when a low level stuff had to be changed the kernel hackers would simply emulate the new api. Opensource drivers could jump to the new, faster api, while old closed source drivers would stay behind.

But as I said, I don't even know if I am not being compleatly dumb or something (I don't have much kernel hacking experience)... :-D

Re:What about a better solution for device drivers

[diamondsw]

Of course, this has nothing to do with the kernel API. Since the source is available (and someone is clearly maintaining it) it could be recompiled if the kernel API changed.

A bunch of stuff broke in the 2.6 kernel - how was this different than if they'd tweaked the kernel API and cleaned this mess up?

Re:What about a better solution for device drivers

[sploxx]

I think that there really isn't any problem.

As long as you have the kernel headers available (and the GPLed source of the driver, of course :), you can compile a loadable driver module without touching any other part of the kernel.

Debian with it's separate kernel-image/kernel-headers packages shows nicely how the problem can be solved. I run several systems with additional hardware and drivers but a stock debian kernel.

Re:What about a better solution for device drivers

[hankaholic]

did you ever try to configure a kernel these days?

What is this "these days"? To build a new kernel, you untar the source, copy linux-old/.config to the new linux-2.6.xx directory, run "make oldconfig" (which will ask you only about new configuration items) if you like, make bzImage && make modules && su make modules_install.

It's about eight commands to untar, copy old config, cd into new source directory, configure, build, and update your bootloader (with an extra if you still use LILO). It's the same set of commands it's always been, and you only have to worry about configuration options which are new to the kernel you're building. Good vendors will even provide you their default configuration (Debian does, for instance) so you can start with a known configuration and tailor to your needs.

Some kernels even export the configuration from which they were built as /proc/config or /proc/config.gz, making it easier than ever to start with a given system and tailor it to your needs.

"make oldconfig" and /proc/config* are your friends.

Re:What about a better solution for device drivers

[Nevyn]

I think it will be useful to have a system whereby drivers can be loaded without requiring the entire kernel to be compiled.

You can do this. RHEL, for instance, has had driver update CDs ... where you couldn't install normally, so you insert the driver update CD before your install CD and now you can. Just like XP/Solaris/OSX/whatever-comercial-OS.com.

Re:What about a better solution for device drivers

[Minna Kirai]

Sorry, I was ambiguous.

For that intended meaning, use "freeze" instead of "fix". The only way "freeze" can be ambiguously interpreted is by leading to jokes about overclocked CPUs.

Re:What about a better solution for device drivers

[pkphilip]

Thanks for the info. I didn't know that. Any idea how this works - if you do, please do email me on prem at songbirdtech.com.

I know it is possible to insmod a new module.. but the module must be first compiled along with that kernel.

These RHEL driver updates - are these just driver modules precompiled for the version of RHEL kernel installed? I mean, if the version of the RHEL kernel installed on my computer is 2.6.9, would I need to get the driver update CD for 2.6.9 kernel or can I just pickup any of the driver CDs and insmod any of the modules in?

Re:What about a better solution for device drivers

[JohnFluxx]

There may be practical problems with that, however dealing with the wider picture....

One of the arguments is that we want it to be inconvient for companies to make closed source drivers. People argue that a short term gain (closed source) is better than the long term gamble in trying to force them to write an open source driver, but I would disagree.

Consider this - linux comes with more drivers than what windows XP comes with.

Re:What about a better solution for device drivers

[dash2]

I accept that responsibility and as it happens, my card works fine - after I downloaded the source which has been around for about 2 years and still not made it into the kernel tree. But that attitude will not get Linux far on the desktop.

Microsoft: "We'll sell you our software and hardware manufacturers will bundle drivers that work with it"

Linux: "We bundle some drivers for free, but not until the hardware is maybe a year old, and we won't provide a stable API for manufacturers to write drivers, and if your hardware doesn't work, tough."

At this point, open source becomes a cost not a benefit.

I suggest that the Borg-like approach of absorbing all drivers into the One True Kernel Tree is not scalable or sensible when hardware is a moving target.

Re:What about a better solution for device drivers

[bogado]

I agree with you. I want all my drivers to be open source, but I also want my machine to work as it was designed too. When you talk about desktops, you can avoid buying some hardware that simply don't work. but in laptops they come with hardware mounted in, and a least here in brazil is kind of hard of finding many options (you can find only HP, toshiba , sony and if you go knock on their doors IBM).

My toshiba laptop wireless card only have closed source, they say that if they would open all of the driver people would be able to abuse the hardware. Security from obscurity :-P, I could bet that sooner or latter people will start abusing the hardware anyway, not the point anyway.

The point is I love opensource but I have to taint my kernels daily, I use nvidia to work with accelerated graphics. I use my wireless card (madwify or something). All of those would be useless or much less functional of weren't for closed source drivers.

The way we have now dosen't work, they simply pass the hard work to the comunity and go away with it. They even get a little less evil sense, because they suport linux (not all linux people are so serious about the freedom anyawy). The way I look at things we get the worst of both worlds, nvidia, madwify make their closed source drivers that can or cannot work, we have to recompile or get a fresh binary driver for every kernel update. And companies don't feel any uncovinient from that position, and worst they may stop supporting those binary drivers at any moment witch will make then soon incompatible with newer kernels.

Don't get me wrong, but I think we should simply prohibit this binary modules or accomodate them in a nicer way. This middle position of closing our eyes is not getting us anywhere (once more, in my opinion). It is not forcing anyone to be more open about their pieces of hardware.

what I want? I want to know how the hardware I bought works, is that ask too much???

Re:What about a better solution for device drivers

[JohnFluxx]

I know its hard in the short term. I too use nvidia (what else is there?).
But look at the server market for example - most (all?) companies that produce server hardware also have open source drivers. Look at the raid support etc.
Would we have had such open source drivers if we made it so easy for the companies to produce closed source drivers?

Also using your own examples - would you hunt around so much for compatible hardware with open source drivers (hence rewarding that company) if all hardware had either closed or open source drivers?

Re:What about a better solution for device drivers

[BillyBlaze]

Actually, it's:

Microsoft: "We'll sell you our software and hardware manufacturers will bundle drivers that work with it."

Linux: "We'll give you not only our software but also a bunch of drivers, however, many hardware vendors will hang you out to dry."

The point is, the Linux community does more for you than Microsoft, and for free. This is what open source gets you. However, manufacturers won't write a driver if it won't move much more hardware. That part has nothing to do with open source; it has to do with the relative sizes of the markets involved. Open source even fixes this shortcoming where possible, by doing the manufacturer's jobs for them, provided they can get the necessary hardware specs. IOW, if Linux had 90% of the desktop market, by your logic, closed source would hinder driver development. In fact, driver development has everything to do with market share.

Also, borg-like or not, the One True Kernel Tree can scale much better, and produce a higher-quality result, than the Windows approach does. The problem is that while hardware is a moving target, software is an even faster moving target. For a given piece of hardware, the design is eventually fixed, and though there will be newer models and designs, the installed base provides constancy. For a given piece of software, however, requirements are constantly changing and designs are constantly improving. Windows and linux have different approaches to solving this problem, and the Linux one is better.

In Windows, there are tons of third party drivers, and being drivers, they depend on the APIs and design of "the" Windows kernel. So what must Microsoft do when they want to change something? For a small change, first they add the new system, then they add a compatibility layer for the old APIs, then they release it. Although no driver needed to be changed, every driver has become slower and less reliable, and the kernel has become more bloated. Larger changes that require breaking compatibility completely pretty much require a new release of Windows. Which means that drivers have to be changed anyway, and worse, two versions have to be maintained. And if the hardware company has gone under, users may be unable to use the hardware with the new version of Windows.

Under the open source model and with most drivers in the tree, making changes of any size is much easier. Just make the change and modify the drivers that rely on it to use the new or updated API. There's no crufty compatibility layer adding bloat to the kernel. This works for any size change. The hardware companies don't have to lift a finger, because an API change wouldn't be accepted without a corresponding update of any affected maintained in-kernel drivers. And if the company dies, if enough users still have the hardware, it remains supported.

For a concrete example of this, look at the transition to 64-bit. Linux was there first (if you count non-x86 architectures, by several years), and for in-kernel drivers, there was no problem. All the source was there to be modified by the same people who actually ported the kernel, the hardware vendors didn't have to lift a finger. For Windows, updating the kernel to run in 64-bit mode has required (or is requiring) a massive coordinated effort between Microsoft and all the major hardware vendors. And of course, the vendors that have died have left their users with no way to run their hardware in 64-bit Windows. And the surviving vendors now have to release two versions of all their drivers, as opposed to just having one version, which gets compiled by distributors in 32- or 64-bit mode as needed, in the tree.

Boring missing features...

[mi]

Can Linux, please, implement the kqueue (PDF) interface, please?

Also, how about growing files with mmap? Currently one can not mmap() beyond the end of the file on Linux...

Re:Boring missing features...

[myspys]

IANACC (i'm not a c coder), BUT according to ftruncate it would seem that you can do just that

"However, sometimes it is necessary to reduce the size of a file. This can be done with the truncate and ftruncate functions. They were introduced in BSD Unix. ftruncate was later added to POSIX.1.

Some systems allow you to extend a file (creating holes) with these functions. This is useful when using memory-mapped I/O (see Memory-mapped I/O), where files are not automatically extended. However, it is not portable but must be implemented if mmap allows mapping of files (i.e., _POSIX_MAPPED_FILES is defined)."

Re:Boring missing features...

[mi]

You will not be able to mmap() the space "created" by ftruncate(). That's my grudge. I don't want the trouble of maintaining my own buffer(s) and write-ing it/them out.

I want to mmap() way beyond the possible size of the result (very possible especially on 64-bit platforms) and just write to that memory. Once I'm done, I'll ftruncate the file to whatever length it ends up being.

On BSD the method works fine. On Linux it does not :-(

On Solaris (8 and 9 -- not sure about 10) mmap() is even worse, though -- you can only mmap() certain sizes...

Re:Boring missing features...

[Argon]

Just mmap() way beyond the possible size of the result and ftruncate just before writing to that memory. You can optimize by doing fewer ftruncates than the actual writes by some good guesses. I can't see how writing to the memory and then ftruncating the file works on BSD. There needs to be some backing store for the memory that you write.

Re:Boring missing features...

[mi]

I can't see how writing to the memory and then ftruncating the file works on BSD. There needs to be some backing store for the memory that you write.

Not necessarily. The backing store can be created by the kernel on the fly, once the process tries to write to the mmap-ed, but not backed space.

This is what I do: open, ftruncate up to 2Gb, write, unmap, ftruncate down to the actual size, close. This is very convenient. For example, one can pass two mmap-ed buffers to something like BZ2_bzBuffToBuffCompress and have an entire file compressed without reads, writes, and useless local buffers.

Re:Boring missing features...

[mi]

open, ftruncate up to 2Gb, write, unmap, ftruncate down to the actual size, close

Oops. I missed the mmap before the writing step above...

Re:Boring missing features...

[mi]

Here, try this little program. Compile and link with -lbz2...

Re:Boring missing features...

[davi_slashdot]

This is too simple. Just call ftruncate() and mremap(). Grow doubling the size, and it gets fast.

Re:Boring missing features...

[Jamie Lokier]

For file descriptor events, Linux has a better implementation than kqueue, called epoll. It's better because it works with all types of file descriptor (thanks to using the same kernel functions as poll/select internally), not just the subset documented in the kqueue man page. Which means you can use epoll in a generic replacement for select/poll, which you can't quite do with kqueue.

kqueue can do other things, including aio which is useful, and it is marginally more efficient due to fewer system calls for registration, but the documented file descriptor limitations are a weak point so it should not be copied exactly the same into Linux. It is possible to add the other things that are useful from kqueue to epoll, but nobody has done so. Perhaps there isn't much demand for it.

mmap: you can grow files while using mmap on them. That's what ftruncate and mremap are for. Oh, did you want to grow files automatically to the nearest rounded-up page when you write to a page beyond the current size? That's not as useful as it sounds, because typically you must still check against a bound, otherwise you'll write beyond the end of the mapping's virtual address. Given that you must have that check, you can easily check against a smaller bound instead and call ftruncate when you're about to exceed it, plus mremap to arbitrarily extend the mapping, which is better than limiting yourself to a fixed maximum size with mmap in advance.

And if you don't want to allocate disk blocks: ftruncate creates a sparse file, the disk blocks are allocated on demand when you write to individual mapped memory pages.

Enjoy,
-- Jamie

Re:Boring missing features...

[mi]

epoll's man-page is dated 2002, whereas kqueue exists in FreeBSD since (at least) 2000. I think, it was wrong for Linux to introduce a totally different API to address the same concerns. Our RedHat is running 2.4.20-31.9bigmem and does not have epoll anyway...

But if it did, would one be able to use epoll to make tail -f more efficient? Or is that, whan [id]notify are for?

As for mmap() -- please download my simple program and try to get it to work on Linux.

Re:Boring missing features...

[Jamie Lokier]

epoll's man-page is dated 2002, whereas kqueue exists in FreeBSD since (at least) 2000. I think, it was wrong for Linux to introduce a totally different API to address the same concerns.

When we designed epoll for Linux 2.5, kqueue was considered as well as the experimental /dev/epoll. Both were rejected, in fact they had similar faults, but /dev/epoll was greatly simplified and became the epoll interface you see today.

Our RedHat is running 2.4.20-31.9bigmem and does not have epoll anyway...

That's because it's a 2.5/2.6 feature. It could be retro-fitted to those old 2.4 kernels but RedHat haven't done so.

But if it did, would one be able to use epoll to make tail -f more efficient? Or is that, whan [id]notify are for?

Yes, you'd use inotify to watch for changes to the file. If you want a scalable event loop too, use epoll to wait for inotify events along with other things.

epoll is missing some things. The most awkward is waiting for AIO completions. Then again, Linux AIO is still being designed, and the kqueue man page says that although it's mentioned, AIO completion in kqueue isn't yet implemented either...

As for mmap() -- please download my simple program and try to get it to work on Linux.

Sure, just fix the bugs and it works. :)

- outd = open(argv[1], O_WRONLY|O_CREAT, stat.st_mode);
+ outd = open(argv[1], O_RDWR|O_CREAT, stat.st_mode);

Your mistake is trying to map a write-only file. It's not permitted because the CPU is not capable of write-only pages, so all write-only mappings are really read-write mappings. If BSD is letting you map a write-only file on the same kind of CPU, that's a security hole in BSD.

- in = mmap(NULL, stat.st_size, PROT_READ, 0, ind, 0);
+ in = mmap(NULL, stat.st_size, PROT_READ, MAP_SHARED, ind, 0);

Technically one of MAP_SHARED or MAP_PRIVATE is required, and Linux enforces this.

Enjoy :)
-- Jamie

Re:Boring missing features...

[Argon]

"This is what I do: open, ftruncate up to 2Gb, write, unmap, ftruncate down to the actual size, close. This is very convenient."

You can do this on Linux too, I do it all the time. Am I missing something?

Re:Boring missing features...

[mi]

When we designed epoll for Linux 2.5, kqueue was considered as well as the experimental /dev/epoll.

kqueue is in FreeBSD since 4.1 or, at least, April 2000. epoll was first introduced into Linux-2.5.x (when exactly?) and is still not present in production kernels -- you blame Red Hat. Linux' failure to implement a known, well documented and exemplified, freely available API, which predates Linux' own solution by several years, is the gist of my complaint.

Your mistake is trying to map a write-only file. It's not permitted because the CPU is not capable of write-only pages, so all write-only mappings are really read-write mappings. If BSD is letting you map a write-only file on the same kind of CPU, that's a security hole in BSD.

Nice theory, but wrong. Try exploiting it. Unless you open with O_RDWR (or O_RDONLY), you can not mmap with PROT_READ (EPERM). And if you don't mmap with PROT_READ, you can not, well, read (SIGBUS).

However you slice it, FreeBSD is just superior. In this very thread we found:

mmap: no requirements for files being readable as well as writable; no size (nor offset) alignment requirement; ability to mmap sparse files for writing is found in both OSes -- my wrong. kqueue: found in stable FreeBSD releases since 2000, while no equivalent seems available in stable Linux distros in 2005; whatever equivalent there is in new kernels, it is gratuitously incompatible with other OSes, that "got there first". zealots/advocates -- last, but not least: Linux people tried to "prove", the missing features are not possible or represent security holes; one pro-Linux AC even used a profanity against kqueue...

But that much we knew all along :-) -- my initial post was a call for Linux to fix the shortcomings, I did not mean to rub them into Linux fans like this...

Re:Boring missing features...

[mi]

You can do this on Linux too, I do it all the time. Am I missing something?

Yes, you can. I was confused by other mmap-limitations on Linux and wrongly presumed, the problem lies with the file having "holes".

See my other recent posts in this thread for details.

Re:Boring missing features...

[Jamie Lokier]

kqueue is in FreeBSD since 4.1 or, at least, April 2000. epoll was first introduced into Linux-2.5.x (when exactly?)

The initial version started in December 2001. epoll in its present form was added to the base kernel in 2.5.45, October 2002.

and is still not present in production kernels

Wrong. It's in every 2.6-based distro, which is most of them right now, and for the "commercial enterprise class" users that includes Red Hat Enterprise Linux 4 and SuSE Linux Enterprise Server 9.

Linux' failure to implement a known, well documented and exemplified, freely available API, which predates Linux' own solution by several years, is the gist of my complaint.

I know the gist of your complaint, but kqueue really was considered during the design of the current epoll, and was rejected. Looking at the kqueue documentation now, I think Linus was right to reject it.

The ideas underlying kqueue are good, but the implemented API has flaws. Take a look at the documentation, and ask: Can you wait for reading/writing on a terminal file descriptor? What about an audio device? A serial port? The answer is not according to the documentation, yet it ought to be possible to wait on an any file descriptor with the same meaning as select/poll.

The initial versions of /dev/epoll had the same flaws and others. But that was rejected too, and it had to be changed to the epoll you see today before it was accepted.

epoll isn't perfect. In fact I argued for a more general event-waiting API at the time, but Linus likes simplicity, and that's what we have now. It is nice and simple to use. It's major ommision is that it doesn't play well with AIO, and that will have to be solved eventually.

Your mistake is trying to map a write-only file. It's not permitted because the CPU is not capable of write-only pages, so all write-only mappings are really read-write mappings. If BSD is letting you map a write-only file on the same kind of CPU, that's a security hole in BSD.

Nice theory, but wrong. Try exploiting it. Unless you open with O_RDWR (or O_RDONLY), you can not mmap with PROT_READ (EPERM). And if you don't mmap with PROT_READ, you can not, well, read (SIGBUS).

It's you who are wrong on this. Ok, let's try exploiting it.

I've mapped a write-only file with PROT_WRITE only (not PROT_READ), opened with O_WRONLY. The file is write-only: it has permission 0200 (--w-------), and it can't be opened for reading or read-write: verified by "cat test_mmap_file" correctly saying "Permission Denied" and other ways it cannot be read.

Then I read from the mapping and printed what was read, to prove it was really reading the file's contents. I tried both a local file in /tmp, and also a file over NFS. Results:

FreeBSD 5.3/i386: I can read from the write-only file using mmap.
NetBSD 2.0/i386: I can read from the write-only file using mmap.
FreeBSD 5.3/Alpha: I can read from the write-only file using mmap.

Well, well, the exploit works. You should really test a feature before arguing about it. :)

Tsk, a security hole in the current production versions of FreeBSD and NetBSD no less. :) [It's unlikely to have major consequences, though, as write-only files are rarely used and never for anything critical.]

The results for i386 are no surprise, as the CPU itself is incapable of write-only mappings. (It's a bug that BSD let's you map a write-only file at all, but given that it does then it's not surprising you can r

Re:Boring missing features...

[bani]

Rofl. You totally owned him.

Wish I had mod points...

Re:Boring missing features...

[mi]

The initial version started in December 2001. epoll in its present form was added to the base kernel in 2.5.45, October 2002.

December 2001 is 18 months after April 2000 -- which is when kqueue stuff was merged from -current into -stable branches of FreeBSD. "Initial version" was available even earlier, of course.

The ideas underlying kqueue are good, but the implemented API has flaws. Take a look at the documentation, and ask: Can you wait for reading/writing on a terminal file descriptor? What about an audio device? A serial port? The answer is not according to the documentation, yet it ought to be possible to wait on an any file descriptor with the same meaning as select/poll.

This may be a flaw in the implementation (or even just the documentation), which would've been different on Linux anyway. Why could not Linux provide a compatible API along with the improvements in the implementation? NIH seems like the reason...

Well, well, the exploit works. You should really test a feature before arguing about it. :)

Would you care to show your code before overexciting the fans? In my tests attempts to read from such mmapings result in SIGBUS -- on FreeBSD-5.4 and on 4.10.

Amount of changes

[spineboy]

I'm surprised at such a fine granular change in the kernel (2.6.11 -> 2.6.12) with all of these changes - some sound pretty big. This really sounds more like a larger version bump, e.g. 2.8. I guess it's debateable since it's such a grey area in terms of what constitutes a version change.

But all in all, these new improvements sound great.
-address space randomization for defence against buffer overflow attacks and remote script kiddies.
Reiser 4, Xen suport, software suspend, trusted computing support,latency improvements and improved kernel space notification. - WOW - lot's o' stuff.

Re:Amount of changes

[PastaLover]

They are currently working with a scheme that adds an extra version number. So small changes go into that last number (eg. 2.6.11.7 -> 2.6.11.8) and the large changes then become something to put in what used to be smaller changes. The extra version number allows them to put bugfixes out faster than in the old model I guess, so you don't have all those patchsets around to keep track off for sysadmins, while the other one now adds features. I seem to recall that was the second goal, to reduce feature latency in the kernel. (eg. they no longer have to backport stuff from the development trees because the feature has been in there and stable for years, but the rest of the kernel isn't ready to be switched over yet)

Re:Amount of changes

[astralbat]

I think the article is misleading. I don't think we will be seeing reiser4 in 2.6.12.

I was considering reiser4 recently and as the article states, its still quite unstable.

Re:Amount of changes

[ajs]

I think that the metric so far has been that things likely to make the installation of x.y*2.z difficult on an x.y.z-1 system, or were likely to require a few iterations of integration and testing were deferred until z.y*2+1.0 was forked.

Re:Amount of changes

[Cobra_666]

I'm using Reiser4 and it seems it's quite stable. I've never had any problems with it. Actually I had more problems with Reiserfs3 than with Reiser4... Of course YMMV

Re:Amount of changes

[agrippa_cash]

I've been using Reiser4 on a spare partition for a while now, and my only suspected issue (inexplicible HDD activity) may not have been related. When I compiled it in, Hans Reiser stated that there were 0 open bugs. My understanding is that Reiser4 is so bizarrely un-posix that Linus isn't comfortable with it. The HR/LT discussion regarding R4s inclusion was posted here a while back.

Re:Amount of changes

[Antique Geekmeister]

It's too much. It should be called something like 2.8 or 2.6.20 to make clear the level of change.

This ain't M$'s "trusted computing"

[Anonymous Coward]

M$'s trusted computing is aimed at MPAA/RIAA: "You can trust M$ to not allow users access to your data even though its on their computer"

Linux trused computing is aimed at users/admins: "You can trust that User A can't muck with User B, expecially if User B is root!"

Re:This ain't M$'s "trusted computing"

[archeopterix]

Linux trused computing is aimed at users/admins: "You can trust that User A can't muck with User B, expecially if User B is root!"

That doesn't convince me. Why aren't the existing mechanisms (cpu running user code in protected mode) sufficient for that?

"Unfortunately no release date"

[Salk]

This seems like a good thing to me. One of the advantages of Linux not been driven by a need to produce revenue.

We need a "break the kernel" team

[cluge]

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

Re:We need a "break the kernel" team

[youknowmewell]

Just let my mom use a linux box for a while, she'll break it.

Sorry mom! *ducks* No I mean it, I'm sor*smack*

Re:We need a "break the kernel" team

[tilleyrw]

OK. First, a Le$$on in Reality. Imagine this said with a drawl...

"How will this kernel-breaking, bug-busting team be compensated for their time?"

Re:We need a "break the kernel" team

[cortana]

If you want to use a tested kernel, buy RHCE. There's no way to do decent regression testing, etc, without paying someone for their time and effort.

Re:We need a "break the kernel" team

[WNight]

Presumably the same way all the other open-source developers are. Huge wads of cold hard cash.

Re:We need a "break the kernel" team

[cortana]

I don't see your point. If you're not happy with RHCE, don't buy it... it's pretty simple. The fact that your laptop dies when you use RHCE doesn't change the fact that no one is going to spend time and money coming up with a decent regression test suite, etc etc, without being compensated!

PCHDTV drivers finally! w00 h00!!

[pyite69]

This is the most exciting kernel release ever. Some of these drivers have been out there for years when they really need to get into Linus' kernel ASAP.

Now let's get the intel wireless drivers, pvr250, CLE266, etc.

Some time soon...

[Progman3K]

Let's keep it that way!
As long as the developers release it when it's done, and not according to some abstract schedule, we'll have the best operating system there is.

Re:Some time soon...

[lewiz]

As long as the developers release it when it's done, and not according to some abstract schedule, we'll have the best operating system there is.

But with "when it's done" there is very much the temptation to keep squeezing in those last few features. Problem is, this can keep adding up. FreeBSD have now switched to a more date-driven release schedule after spending too long between major releases.

I think a good combination of the two is best for everybody.

Re:Some time soon...

[diamondsw]

While I agree in this case, Debian should be a good example of why this is NOT always a good idea...

Re:Linux x

[NineNine]

The masses are slowly realising that proprietary, closed source solutions are not the way forward and that computers will mainly advance from the imput of the community.

Uuuh, I don't think that anybody has told the masses yet. You wanna tell 'em or should I?

Re:Linux x

[pe1rxq]

GUN Linux

Eric, is that you?

Kernel advances

[digitaldc]

"Kernel advances such as position independent executables, non-executable memory regions, stack smashing protection and execution capabilities are introduced. Implementations such as PAX and exec-shield are compared." Now if they can just get those last few kernels to execute properly, we will have created flawless popcorn!

What I'd like to see...

[drsmithy]

Are some drivers for my Promise TX4000 IDE controller so I can upgrade to a 2.6 kernel and benefit from the better software RAID...

Re:What I'd like to see...

[kasperd]

upgrade to a 2.6 kernel and benefit from the better software RAID...

Is software RAID in 2.6 better than in 2.4? I mean it really works great on my 2.4 based system, in which ways could it become significantly better? First of all performance is really good, a friend of mine spend more money on his RAID controller than I did on my entire computer, still my Linux software RAID runs circles around his hardware RAID. And management of Linux software RAID is actually quite easy.

I heard that in Linux 2.6 you can partition a software RAID, ok that is a nice thing, but building a RAID from harddisk partitions is at least as flexible. The only improvement I really miss is that in case of bad sectors it would sync a spare before kicking out the faulty disk.

Re:What I'd like to see...

[drsmithy]

Is software RAID in 2.6 better than in 2.4?

Apparently (from several benchmarks I stumbled across trying to find out if any 2.6 kernels support my controller) it's significantly faster (on the order of 40%) faster.

SELinux

[Sunspire]

SELinux has AFAIK been included in 2.6 for a long time already. What's new in 2.6.12? The article is pretty light on details.

Re:SELinux

[flithm]

It's been available for 2.6 yes, but that does not mean it's been included in the main distribution package... which it hasn't been.

Re:SELinux

[hey]

Its in Fedora Core -- but it doesn't work for me.
Even targeted disallows things that should be allowed.

Maybe I'm missing something..

[dcbarker]

.. but the article says Xen will run Windows, however the Xen website says that only an early version would run a ported version of Windows, and that it'll be when some new architecture of processors (announced by AMD and Intel) are available before it's actually supported..

*phew* That was one long sentance!

Dave

Re:Maybe I'm missing something..

[Anonymous Coward]

Xen would be able to run Windows perfectly well in it's current state, and it did at one point, but the problem is legal and licensing restrictions.

Either some of the software that is used, or some of the drivers that are used, are under a restrictive license (probably from MS) so that while it's technically possible, it is legally impossible.

Isn't closed source a bitch?

With the newer CPUS they have built in abstractions into the hardware that would possibly allow things like Xen to 'operate closer to bare metal' and thus avoid whatever software has the legal restrictions.

Re:Maybe I'm missing something..

[Lemming Mark]

Xen 1.x could run a ported Windows XP on standard PC hardware. This is the port that was never released to the public.

Xen-unstable (the development tree, to become 3.0 this summer) includes support for Intel Vanderpool virtual machine extensions - these will allow it to run unmodified guest OSs on supporting hardware.

Unmodified Linux guests will boot on Xen right now on Vanderpool hardware. Windows guests are a little further off (possibly post 3.0) because they require support for various 16-bit x86 cruft ;-)

Re:Linux x

[mchawi]

GUN Linux?

Is that the new Linux that doesn't try and beat Windows/Apple/Unix with better features but just goes out and shoots them dead? ;)

Drivers, drivers, drivers.

[Anonymous Coward]

I was just reading the latest Kernel Traffic and it hit me how much of a flux the driver model seems to be in. Constantly.

Microsoft Windows seems to have had a stable driver interface since at least Win2K (probably NT4 too). The weird thing is that eschewing binary compatibility, like Linus likes to do, really ought to make it easier to stabilize a model? I mean, they have all the upsides with none of the downsides.

I really don't care personally -- I don't write drivers -- but isn't it a bit odd that the system is constantly rewritten (or at least majorly tweaked)? New month -- New driver model. New locking mechanism. New everything. What's not new is broken hardware sleep/resume!

Drivers aren't sexy, and it seems a lot of time is spent just spinning in place (no phun intended)

Re:Drivers, drivers, drivers.

[Cyno]

Win2k eh? Of course it has a stable API. That's like saying RedHat 9 has a stable API. It hasn't changed since I first used it. Sure its still running the 2.4 kernel. But that's okay, because you want stability, right?

Even Microsoft says anything before WinXP SP2 wasn't a "modern OS". So if you suddenly upgrade to WinXP SP2 will your Win2k drivers work? Or will you have to get new XP drivers? If you have to get XP drivers for any of your hardware you're arguement is toast!

Re:Drivers, drivers, drivers.

[Cyno]

Oh, okay, well I misspelled you're anyway.

From the driver development POV its irrelevant since any changes to the driver API will be patched into all drivers it affects by the developer who changes the API. If they break the API I won't have to go and fix my driver, because all that would have been part of the API checkin. Any new drivers will have to conform to this new API, but if you're a developer you're going to be in the loop and know what you're doing.

The only problems you get are from a user POV. If you try to use an old driver with a new kernel it won't work. This makes people frustrated because they're ignorant about the kernel. But any distro will use new drivers that come with the new kernel, so it won't be a problem if you upgrade through recommended channels by your distro.

Essential links....

[ssj_195]

... for people wishing to know more about the possible ramifications of Trusted ("Treacherous"...?) Computing:

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

Re:Essential links....

[Minna Kirai]

I'm buggered if I can find an answer to this, but if anyone is using Konqueror 3.4 with famd,

No, I doubt anybody is using famd. At least, someone who uses removable media (like cdroms) can't very well run it, because it will keep directories open and prevent umounting.

Maybe once linux 2.6.12 brings out the new inotify things, famd will become tolerable to run continually, and it'll start getting bugfixes in.

PS. I am only 30% joking.

Re:Essential links....

[ssj_195]

Thanks for the response :) I've actually tried it with gamin (the new famd replacement which uses inotify) under Kubuntu, and it still didn't work :/ Once I added my patch, though, all was dandy - changes to files were echoed automatically in all relevant konqueror windows. And - *shock! horror!* I could insert my pen drive, open it up in Konqeror and either yank the pen out or do the "Safely Remove Hardware" thing and the folder view went to empty with none of this crappy "Device is busy!" stuff anymore. Same with CDs. I was very impressed - it's about time this kind of thing got fixed, as it's been a real headache. Bravo, all those who helped to make this work!

I guess I'll post a brand new bug report as my appendment to an existing one has gone completely unnoticed - the bug has surfaced on two distros now, so I'm fairly sure it is a proper bug, and now that the famd & removeable-storage mount-point fuckery is hopefully behind us for ever, it would be a shame if Konqueror didn't capitalise on it.

Re:Essential links....

[swillden]

The offered advantages are, in my opinion, fairly weak - you can eliminate online cheating in multi-player games, and media companies are more likely to allow downloads of materials (DRM'd up the wazoo, of course).

The real advantages appear primarily in corporate environments. Using hashes plus remote attestation to report precisely what version of what OS you're running, in an unforgeable way, is theoretically possible, but, IMO, impractical. It also requires a "secure" BIOS that cannot be flashed with arbitrary code, but only with code that is signed by the board manufacturer. That's a bigger concern, IMO, because it is a technology that has no benefits to the owner of the machine.

For a corporate environment, however, the usage would be to ensure that the software hasn't *changed*. After IT images a machine, the hash would be stored and then the machine could be queried for a remote attestation that the current hash matches the original value. If not, the machine may not be allowed on the network, etc.

An even more important usage is strong file/disk encryption, e-mail signing and VPN access. The TPM can store keys that are "bound" to a particular system configuration. If you boot the machine with different software or (if you configure it this way) with a different BIOS configuration, then the keys will no longer be accessible. So, for example, you could configure a laptop that carries sensitive information to encrypt the disk with a key that is bound to a well-secured system config. If the laptop is lost or stolen, the attacker won't be able to get the data through the normal OS (because it's well-secured and he doesn't have authentication credentials to get in) and if he boots the machine off of a live CD or some such, the decryption keys will not be available.

Similarly, a key used to authenticate to a VPN can be bound in the TPM. That way, IT doesn't have to worry about infected/hacked machines coming in through the firewall.

There are other examples.

This is useful technology, and it may even be useful to home users. It's certainly useful to people who have a need to care about real security.

Unfortunately, it may also enable strong DRM. That's just one application of the technology. It's an application we need to fight, of course, but the oft-heard refrain here on slashdot "Attack the use, not the tool" is applicable, IMO.

Re:Essential links....

[OeLeWaPpErKe]

Did you read what you just said ?

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 ... 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.

Adobe will be able to do this for pdfs, your bank for your bank statements, ...

THAT is what TPM is about.

Re:Essential links....

[BlueFall]

NB: Note that this long and tedious post deals with IBM's Trusted technology only; I'm afraid I know very little about Microsoft's Palladium, which by all accounts was even worse :)

Just as a nitpick, this is not IBM's technology, but that of TCPA/TCG. IBM is one of the first to include this technology in their systems and thus probably wants to make sure that the actual capabilities are well-known.

BTW at some point, Palladium (aka NGSCB), was proposed to include a secure path to the monitor and keyboard (and possibly other io devices). This feature could be actually very useful in preventing local snooping.

Re:Essential links....

[swillden]

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.

How would a TPM prevent you from forwarding it? If you can read it, you have access to it. If you have access to it, you can forward it, unless your e-mail client doesn't allow forwarding... which has nothing to do with the TPM.

As far as secure deletion... sure. If you encrypt a bunch of data with a given key, then destroy the key, you've effectively destroyed all of the encrypted copies. This is true whether the encryption key is bound to a TPM or not.

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.

Perhaps. The TPM technology being deployed is not designed to be secure against physical attacks. I'm sure that if the police really wanted to they could get someone to extract the TPM master key (probably destroying the TPM in the process, but that doesn't matter).

Of course, from a data security perspective, that's a bad thing. Ultimately, any protection you implement that keeps the data from bad guys will also be able to keep data from good guys. There's no magic bullet.

I'm sure that if TCPA technology becomes widely supported, some hardware manufacturers will produce "high-security" PCs with TPMs that *are* secure against physical attacks. That's important for people who require high security. It's unfortunate for police, but what can you do?

Look, security is a double-edged sword. Good security can be used for good purposes and also for evil purposes. Weak security is just weak, and therefore does little good or evil. Attack the use, not the tool.

And ... 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.

Wow... that's a pretty big leap. My only response to that is: If MS wants to do this, they can do it just as easily without a TPM as with. Somewhat easier, actually. I suppose that with a TPM you might be tempted to put data on your PC that you would otherwise not put on a computer at all... in any case, the OS has full access to whatever is on the machine, so if you don't trust the author of your OS, you'd better assume you can't place anything of importance on the machine.

THAT is what TPM is about.

No, that's what you imagine TCPA is about. If you're going to make claims like this, you should at least try to offer an explanation of the mechanism.

Re:Essential links....

[Truekaiser]

hmm very good post. but you might want to check the tcpa specs on the tcpa website. it does have the ability to prevent you from booting a os.
to sign a os kernel so it can be booted from you need your key(the only one you will freely have)
the master key of the system(you have no idea what it is, only the company that makes the motherboard has this as well as a major software company)
and optionally(depending on the manufacturer) a certificate.
though i will bet you cash right now that;

1. the optional certificate will be required to boot a operating system on 9 out of 10 motherboards with this.

and

2. that the certificate will cost 3 to 4 figures to get per motherboard model(though certain discounts will apply if you are a certain large software company).

Re:Essential links....

[Minna Kirai]

If you have access to it, you can forward it, unless your e-mail client doesn't allow forwarding... which has nothing to do with the TPM.

No, you need to think it through.

If a person's email client doesn't allow forwarding, she will get a replacement, more functional client. But as you've already stated, remote attestation will mean that the sender can check which email client she is using, and refuse to transmit the message except to applications that it trusts.

It's a way of forcing users to run programs that are crippled in one or more ways, which they otherwise wouldn't be willing to do.

Re:Essential links....

[swillden]

If a person's email client doesn't allow forwarding, she will get a replacement, more functional client. But as you've already stated, remote attestation will mean that the sender can check which email client she is using, and refuse to transmit the message except to applications that it trusts.

No. Remote attestation will only show that the system configuration, as fed to the TPM, matches the expected config. If the mail client is hashed into the TPM, and if the system is configured not to allow the user to install any other mail client, and if the mail client refuses to forward except to "applications it trusts" (what does that mean? An e-mail client that won't send to arbitrary e-mail addresses? How... 1990), and if the mail client doesn't allow cut and paste, then the user cannot forward the message.

You'll notice that all of the above could also be done just as well without a TPM. Provide a corporate system with an e-mail client that authenticates with a public key (like, say, Lotus Notes), configure it -- somehow -- to know where to forward or not forward messages, and so that it doesn't allow cut-and-paste, then lock the system down so that the user can't obtain the e-mail authentication key, doesn't have any other way of sending e-mail and can't install any other software, then you've achieved the same thing.

There's no reason to all this without a TPM, and there's no reason to do it with a TPM. A TPM really doesn't even make any difference, except that with a TPM you don't have to worry about disabling the user's ability to boot off of a floppy or a CD-ROM (which is easy enough without a TPM -- just configure the BIOS appropriately and password protect it).

I find it really interesting that most of the "Evil TPM Abuse" schemes that people bandy around have so little to do with the TPM.

Re:Essential links....

[Minna Kirai]

doesn't have any other way of sending e-mail and can't install any other software, then you've achieved the same thing.

Without TPM, that's impossible. You can't yet stop people from installing other software... at least without crippling the functionality of your system.

For example, TPM means that a corporation could send emails to an employee's home PC, and still have guarantees that he won't view it with any unapproved software. Today, if a corp wants that degree of control over software employees use, they must sacrifice flexibility and become less economically competitive.

Re:Essential links....

[Alsee]

I'd like to point out that there is no advantage or justification for prohibiting an owner from knowing his key. Not in the home, and not in the corporate environment.

In an office enviornment the owner is the company. The company would have these keys, or could even destroy these keys if they wished. The machines would still be just secure against the employee using it. The company would still be just as able to authenticate the state of their machines.

An even more important usage is strong file/disk encryption, e-mail signing and VPN access. The TPM can store keys that are "bound" to a particular system configuration. If you boot the machine with different software or (if you configure it this way) with a different BIOS configuration, then the keys will no longer be accessible.

That is still true if you know your key. The only difference is that the owner is free to use his key to decrypt that data anyway if he chooses to do so.

If the laptop is lost or stolen, the attacker won't be able to get the data

Just as true if you know your key. Sure someone could steal your laptop AND your key and get access, just as they could steal your laptop and your password and get access. And if you're really paranoid over the issue, well you can get you key with the machine and immediately burn it. Then you are exactly back where you would have been without the key.

-

Re:Essential links....

[swillden]

I'd like to point out that there is no advantage or justification for prohibiting an owner from knowing his key. Not in the home, and not in the corporate environment.

Ahh, Alsee... we've been the rounds on this one. I was going to be disappointed if you didn't show up.

I'm not going to rehash the old arguments, except to ask a single question.

First, the background.

Among all of the high-security crypto devices on the market, the devices used by banks, by government agencies, by corporate PKI systems, every single one of them has a master key which is generated inside the device and never, ever divulged. Many of them have many other never-revealed keys. It was also considered a major advance in smart card security when the first cards appeared that had the ability to generate key pairs on-card so that the private key need never exist off-card. Every major PKI smart card deployment I've been involved with has *demanded* this feature, including the Common Access Card used by all Dept. of Defense personnel.

Now the question:

Why is it that none of those entities, the device makers and the device buyers, want to be able to get those keys out of the devices, to have a copy for "safekeeping"?

Re:Essential links....

[swillden]

Without TPM, that's impossible. You can't yet stop people from installing other software... at least without crippling the functionality of your system.

The same is true with a TPM. If you hash all application software into the TPM state, no new software can be added without changing the hash. If you hash only selected software, the user can simply use something else, unless you lock down the system to prevent all software installation.

For example, TPM means that a corporation could send emails to an employee's home PC, and still have guarantees that he won't view it with any unapproved software.

How? I may simply be stupid, but I don't see any way that this could be accomplished with a TCPA TPM. Please describe the mechanism, based on the features provided by a TCPA TPM.

Re:Essential links....

[swillden]

well, isn't drm a tool?

Yes. And, actually, it's a tool that even has legitimate uses. Companies would love to be able to distribute auto-expiring documents that can't be printed or copied, only read, when they're giving out sensitive information under NDA.

but drm is a bad tool, as in it doesn't work as expected because the expectations behind it are flawed.

DRM for control of copyrighted materials is indeed built upon many bad assumptions. That doesn't affect the nature of the tool, only of the use.

So, imho, is tpm.

What are the "flawed expectations" which lead you to this conclusion?

Re:Essential links....

[Alsee]

Why is it that none of those entities, the device makers and the device buyers, want to be able to get those keys out of the devices, to have a copy for "safekeeping"?

I have no problem with a bank or anyone else choosing to buy a version and not have any need or desire to get their key.

The TPM's primary market is going to be home PCs and ordinary consumer devices of all sorts. The specification forbids me to buy one and get my key if I want it. I have a general objection to my computer being designed to be secure against me and to treat me as an enemy, but I have an even bigger objection with the ensuing results.

The TPM specifications for PC systems, along with some related software documentation, is for a system where it will be impossible for me to install and activate essentially any new commercial software unless I run a Trusted and Compliant system. For a system where websites will be able to query for Trust capabilities and what software I'm running, if I'm not running Trusted Compliant hardware and approved OS and and approved browser (one that prohibits ad blocking for example) then I will be locked out of an increasing number of websites. I also have a huge problem with the Trusted Computing Group's documented project for a Trusted Router that would deny me any internet access at all without a Trusted and Compliant system. And I have a huge problem with the President's Cyber Security advisor calling on ISP to eventually make exactly this software of system a mandatory part of Terms of Servive to get internet access at all.

Allow people the CHOICE to buy fully compatible systems and have their keys if they wish and not penalize them for it then I'll be happy as a clam.

So long as the system is designed to be secure against me and deny me access to my keys and prohibit me from reading or modifying my own data on my harddrive and prohibit me from being able to run or modify my own software (and have it *work*, which sealed keys and attestation both prevent), and so long as such a system is going to be effectively FORCED on me and everyone else, I will do anything and everything in my power (just short of outright violence) against it.

If you want a chip and not your key, fine with me! I have no objection so long as I do not get denied the option to have my key and do not get penalized for knowing my key.

Do you have any objection to me opening up a business with a lab ripping people's chips open for them and extracting their keys for them? Sure the chips are designed to be tamper resistant and self destruct if their owner attempts to do that, but as a business and with a lab it couldn't take to long to work out a consistant proceedure for doing it. Hell, I'm not greedy, I'll do it practically at cost. I want everyone to have their key if they want it. Millions of people with PCs who have a printout of their key.

And if there is no problem with that, if people *CAN* have their key if they want it, then why the hell not just sell chips with that option in the first place? Just avoid the stupid extra step of having to spend a couple of bucks at a lab to extract your key.

And assuming you agree there is nothing wrong with going into that business, you're actually better off selling those alternate chips with their keys to avoid the existance of that cheap bulk business. That way you can buy your chip without a key, and if someone steals your laptop there won't be a handy-dandy company all set up to extract that key for dirt cheap. Your no-key chip is more secure if there is a ready supply of key+chips to avoid the existance of convient ripper services.

-

Re:Essential links....

[swillden]

I have no problem with a bank or anyone else choosing to buy a version and not have any need or desire to get their key.

Okay, let me rephrase the question. Why is it that the users of these devices demand that they *not* be able to get the key? I want to make sure that you understand this principle, because there's no point in discussing further if you don't know why guarantees of key non-accessibility are valuable in general.

Re:Essential links....

[Alsee]

If a bank sees a bigger threat in the risk of something like an insider obtaining or misusing or leaking the key, fine. They are perfectly welcome to that design. However *I* see a bigger security risk in my chip glitching and losing my data (not to mention the *staggering* non-security issues I described in my last post). As the OVERWHELMING MAJORITY of these chips are expected to be in home PC's and consumer electronics the weighting of risks for the vast majority of chips will be in the same direction, for the owner to have his key. Grandma is more vunlerable to data loss than to an Intel manufacturing plant insider reading her e-mail and pudding recipies. So even on a purely risk basis, most chips should coming with the keys.

Nor does you bank and military example in any way justify forbidding me the option to buy the kind of chip I want.

Furthermore your such argument would be absolutely dwarfed by the issue I pointed out of having readily available cracking services to extract keys. Keyless chips are more secure if there are no established bulk chip cracking services ripping chips for a few bucks. Cracking one chip is extremely difficult. A business to crack 10,000 chips for a few bucks each is asy. Having an install base of a hundred million TPM PCs will create a demand for chip ripping and will establish the techniques and expertice for routinely doing so. Making key+chips available in the first place would nullify the demand for such a service and eliminate the risk introduced the the existance of such a service.

Now how about addressing all of my points from my last post? You haven't responded at all to anything I wrote.

-

Re:Essential links....

[swillden]

Now how about addressing all of my points from my last post? You haven't responded at all to anything I wrote.

There's no point. I've tried repeatedly in the past to get you to understand the intrinsic security value of never-revealed keys, and the fact that the flexibility obtained by extracting keys is practically nil. It's not a matter of whether or not some insider can get at the key, it's that any security decisions that are based on the security of the keys are inherently, irrevocably weakened if the key is ever revealed to anyone. And there's simply no need to accept this weakening.

The existence of an easy way to destructively extract keys doesn't really change this fact, it just means that TPMs won't provide security against attackers who have the machine in their possession. And, actually, even that can be addressed by using a separate, external secure token like a smart card. The combination of TPM+smart card can produce a very high level of security, even against physical attacks, which neither device could achieve alone (my interest in TPMs actually derives from years of frustration with trying to create secure systems built on smart cards when the machines they're talking to are completely untrustworthy).

I would actually encourage companies to build TPM-breaking technology. It would limit the effectiveness of DRM without significantly decreasing the security obtainable by those who have unbroken TPMs.

Re:Essential links....

[Minna Kirai]

If you hash all application software into the TPM state, no new software can be added without changing the hash. If you hash only selected software, the user can simply use something else, unless you lock down the system to prevent all software installation.

Both true, both irrelevant.

. Please describe the mechanism, based on the features provided by a TCPA TPM.

GIYF

Re:Essential links....

[Minna Kirai]

Among all of the high-security crypto devices on the market, the devices used by banks, by government agencies, by corporate PKI systems, every single one of them has a master key which is generated inside the device and never, ever divulged.

Can you tell the difference between "never, ever divulged" and "held in a lab in California for use by the MPAA"?

There is no sane comparison between a key which exists ONLY inside the tamper-proof hardware wherein it was created, and a key secretly held in escrow by a 3rd party whose goals might differ dramatically from those of the hardware's current owner.

Why is it that none of those entities, the device makers and the device buyers, want to be able to get those keys out of the devices, to have a copy for "safekeeping"?

That's a misleading question. If the device buyers want additional keys for safekeeping, they have no need to extract them from the device- they can simply request additional copies at the time of purchase. The man holding the key obeys the legal owner of the hardware.

The situation is entirely different with Trusted Computing, because the buyer of a personal computer will not be able to ask the salesman for a printed copy of the key along with purchase. The man holding the key refuses to talk to the legal owner of the hardware.

I've tried repeatedly in the past to get you to understand the intrinsic security value of never-revealed keys, and the fact that the flexibility obtained by extracting keys is practically nil.

"Extracting keys" is not the point. Someone working for the bank has the key at some point and signs their stuff. If no agent of the bank could EVER get the key AT ALL, then they'd move to another hardware vendor.

In fact, although the bank might be happy if the key is destroyed just as soon as the few important things are signed with it, they absolutely wouldn't enjoy the idea of a music executive sitting around with the keys to their data.

Re:Essential links....

[Minna Kirai]

Why is it that the users of these devices demand that they *not* be able to get the key?

To the extent they do demand that (and it is true by some interpretations), it is so that nobody can see the key. The reason they don't want to be able to see it is so that they won't screw up and accidently expose it to an enemy.

But regarding TCPA, that's a moot point. Outsiders already have the key.

TCPA is not a competitor to the RSA PKI products. If you want products to enhance your security, they are already for sale.

Re:Essential links....

[swillden]

Both true, both irrelevant.

How are they not relevant?

GIYF

This does not explain how "a corporation could send emails to an employee's home PC, and still have guarantees that he won't view it with any unapproved software."

Particularly since Microsoft's NGSCB requires more than just a TPM in the way of hardware support.

Re:Essential links....

[swillden]

Can you tell the difference between "never, ever divulged" and "held in a lab in California for use by the MPAA"?

Okay, this is my best evidence to date that you have no understanding whatsoever of what a TPM actually does.

A TPM's master keys would not even be useful to the MPAA. There is quite literally no way for them to effectively apply this knowledge.

What would be useful to them is a private key (that is held securely in the TPM and bound to a particular, known, and MPAA-vetted system configuration) for which they have a copy of the corresponding public key.

There is no sane comparison between a key which exists ONLY inside the tamper-proof hardware wherein it was created, and a key secretly held in escrow by a 3rd party whose goals might differ dramatically from those of the hardware's current owner.

Agreed (minus the words "tamper-proof" -- there is no such thing as "tamper-proof". "Tamper-resistant", yes, and high-security devices are "tamper-reactive", but there is no "tamper-proof". Current TPMs are mildly tamper-resistant, BTW). But there are no escrowed keys in TPMs. The other facilities in a TPM could be used to import securely a key which is escrowed elsewhere, but actually that would not serve any MPAA or RIAA purpose either.

I realize the points I'm making probably sound to you like technical trivia, picking at minor errors in your post, but they're not minor, they're fundamental. Until you understand what a TPM actually does or does not do, you cannot reasonably debate whether or not the device is dangerous.

If the device buyers want additional keys for safekeeping, they have no need to extract them from the device- they can simply request additional copies at the time of purchase. The man holding the key obeys the legal owner of the hardware.

Umm, no. If the device buyers want additional keys, they tell the device to generate additional keys. "The man holding the keys" is the piece of hardware, and, yes, it does obey its owner.

The same is true of a TPM. A TPM holds keys that it generated internally and which never exist anywhere outside of that TPM. And the TPM obeys the system owner, which is established by sending the TPM a "take ownership command". This command wipes the previous master key and generates a new one, so the previous owner's data is not revealed to the new owner.

If no agent of the bank could EVER get the key AT ALL, then they'd move to another hardware vendor.

100% incorrect. If any agent of the bank could EVER get the key AT ALL, then they'd move to another hardware vendor.

The keys stay inside the device, and you send commands to the device asking it to use those keys to, say, digitally sign documents, or encrypt data (or keys) or whatever you need. You configure the device so that it will refuse to perform these operations unless the user properly authenticates him/herself with valid credentials that are allowed to use those particular keys in those particular ways. You futher configure the device such that some keys may not be used in certain ways no matter who the user is.

See, if the keys stay inside the device, then you know, with complete certainty, that the only people who can use those keys are people who have access to the device. And you further know that those keys will only be used in accordance with the security policies the device enforces. Then, by defining appropriate policies and access control, you can have a high degree of certainty as to exactly how those keys will or will not be used.

If you ever allow the keys out of the device, then all of your careful security design is compromised.

In fact, although the bank might be happy if the key is destroyed just as soon as the few important things are signed with it, they absolutely wouldn't enjoy the idea of a music executive sitting around with the keys to their data.

They don't want *anyone* sitting around with those keys. They want them inside that device and nowhere else.

Re:Essential links....

[swillden]

But regarding TCPA, that's a moot point. Outsiders already have the key.

As I've said in other posts, this is simply not true.

The TPM really only has two keys stored inside it: A device key pair, which is an RSA key pair generated by the device and the public half signed by the TPM manufacturer and a master key, which is a three-key 3DES key generated inside the device and used to encrypt other keys. The "take ownership" command can be used to ask the device to generate a new master key at any time (effectively destroying anything encrypted with the old master key).

That's it. The TPM can generate other keys, encrypting them with the master key so that they can be stored securely externally. And those keys can be cryptographically "bound" to a particular system state as represented by a hash value in a register.

You really do have to understand what the device does in order to argue about it effectively. Please read the specification, then we can discuss this intelligently.

Re:Essential links....

[Alsee]

Ok, lets see which one of use who does not understand. Which one of us who is making this discussion pointless.

You are spending all your time explaining why some people would want keyless chips. You claiming that I do not "understand" this.

You are wrong. I do understand. I do not deny some people would want to buy keyless chips.

I have never argued against such chips. Your arguments are invalid to the actual dispute, a complete waste of your time and mine. You have used this invalid argument to excuse ignoring the actual issue and ignoring every single argument, ignoring entire posts. An excuse for failing to answer anything.

You have not justified denying people a choice. You have not even attempted to justify denying people a choice. Not only have you lost the argument, you never even engaged in the actual argument.

Banks and the military and the like may certainly want keyless chips, however they would never buy these commodity chips anyway! It is a completely different market that is still going to be purchasing custom hardware with custom specifications anyway. The fraction of the actual market for these chips that woupld preffer keyless chips is minisule, but even that does not matter. I do not object to keyless chips. Even if 90% wanted keyless chips, fine let them have keyless chips. There's still no justification to deny a choice.

I've tried repeatedly in the past to get you to understand the intrinsic security value of never-revealed keys

For the vast majority of the intended market that value is exactly nil. Grandma's PC and grandma's TV have exactly nil value in denying grandma the option to have her key. And grandma's PC and grandma's TV are indeed the primary intended and expected market for these TPMs.

the fact that the flexibility obtained by extracting keys is practically nil

Just plain wrong.
For the vast majority of the intended market this is not merely valuable, but CRITICALLY IMPORTANT. There is security value in ensuring data can be backed up and recovered (if the owner wishes it) against the risk of chip failure or against theft. That is a question of weighing security considerations. Banks may certainly weigh the remote risk of an insider manging to alter data as a bigger threat than the loss of data. However for my PC I consider the risk of data loss to be a far greater threat than the risk of an insider gettign the key and altering my data.

It is also critically important to avoid interoperability lock out and vendor lock in and all sorts of appalling implications as I have already listed. In denying people control over their own machines.

I would actually encourage companies to build TPM-breaking technology.

Then what is the point of PROHIBITING some chips from coming with their key in the first place?

A company could buy mass quantities of such systems and extract the keys and sell them as identical to systems with the keys initially included. This makes them more expensive, it is going to be attacked as somehow criminal, and any such systems will be actively discriminated against and placed on 'revokation lists' and locked out in actual ordinary home use.

-

Re:Essential links....

[swillden]

You have not justified denying people a choice. You have not even attempted to justify denying people a choice.

You have steadfastly refused to understand that you want to offer a choice with **ZERO** value. A security chip that will divulge its master key to anyone is worthless from security standpoint.

You are wrong. I do understand. I do not deny some people would want to buy keyless chips.

You are wrong. You do not understand, as the above statement proves. It's not that "some people would want to buy keyless chips", it's that "chips that can reveal their keys are worthless for security". TPMs that can hand out their keys are of no value to anyone trying to build secure systems. What you want to do would make them worthless to the segment of the market for which they have actual value. In order to prevent a scenario you fear, you argue that the devices should be emasculated to the point that they may as well not be used at all. I grant that making them useless would achieve the goal of preventing them from being used for DRM. Making all hammers out of lightweight, flexible foam rubber would prevent them from being used to kill people, too, but would have the unfortunate side effect of making them incapable of pounding nails.

How can I be any clearer?

If you're concerned about someone using that chip to take control of your machine away from you, what you want to do is not to get the chip to give you a copy of the key, what you want is to disable the chip. Or, you want to ensure that you have control of the policies that are implemented using the chip (that's what I want, actually).

Banks and the military and the like may certainly want keyless chips, however they would never buy these commodity chips anyway!

First, it's clear that you didn't understand my point about the devices which banks and militaries use. I wasn't saying that these TPMss are for them, I was pointing out that entities who have significant data security experience understand that a security device is only valuable if it's certain that its keys have never and will never be revealed.

Corporations that need reliable security, but not the level that justifies purchasing high end devices, are the primary market for TPMs. Why do you think IBM begain by selling them in high-end Thinkpads?

And corporations most certainly will buy these chips, and lots of them. They're already in many high-end laptops and in some high-end workstations and servers as well. I expect they'll end up in consumer mainboards primarily as a side effect, because it's cheaper to include the chip in all mainboards than it is to double your product lines.

Then what is the point of PROHIBITING some chips from coming with their key in the first place?

And how, exactly, would the chip manufacturers obtain those keys so that they can deliver them alongside the chips? There are only two ways: either the key must be generated outside of the chip and loaded, or it must be possible to request the key from the chip. If either of those scenarios is possible, then the chip is worthless for security applications. In the case keys are loaded into the chip, how does one know that they weren't revealed during the loading process, or replaced between the time the manufacturer loaded them and the owner received them? In the case the chip is willing to hand the key over to someone who asks, how does one know that an attacker will not be able to request the key?

If you choose to answer those questions, keep in mind that bugs will always exist. The history of security tokens is littered with devices which a clever attacker was able to trick into revealing its keys even when the device was supposed to refuse to divulge them under any circumstances. And these were not "clueless programmer" bugs -- smart people who thought very hard about the possible attacks designed them. In most cases there isn't even an API that allows an attacker to *ask* for the keys, yet devices are still tricked into divulging them. If it's so difficult to reliably implement "Just say NO!", how much harder is it to securely implement "Say no except when conditions A, B and C are met"?

Re:Essential links....

[swillden]

BTW, Alsee, what part of the world do you live in? We've been talking past one another on this topic for quite some time, and it occurs to me that it might be interesting to go to lunch and see if we can't make ourselves understood. I live in Utah, but I travel a fair amount so there's a significant chance that I might be in your neck of the woods sometime.

Re:Essential links....

[Alsee]

Making ***ALL*** hammers out of lightweight, flexible foam rubber

Straw man!

I am asked you to justify denying people a CHOICE. To allow both kinds to be sold, and to allow people to buy either kind without penalty. The specification revolves around (1) denying people that choice, and (2) hunting down and locking out anyone with such a system.

It is not about securing your system for you as you validly advocate, but about enabling Remote Attestation and for you to be able to Trust that my system is secured against me.

what you want is to disable the chip. Or, you want to ensure that you have control of the policies that are implemented using the chip

Remote Attestation is designed to prohibit that, to effectively deny that choice.

You are 'free' to do so, but the penalty is to be imprisoned in a virtual prison cell. It will be impossible to install any of the new software or read any of the new files or access any of the new webservers, and the industry/government expectation is that somewhere between 2011 and 2015 Trusted-routers will deny you any internet access at all. Of course I'm just repeating myself. Repeating what you ignored before.

If you believe it won't or can't happen, we can certainly address that. Thus far you have just ignored it.

Actually you have already supported me on this point: it's cheaper to include the chip in all mainboards. In just a few years it becomes extremely 'reasonable' for ISPs to use the Trust system to check for a mandated and approved firewall etc as a condition of access. This exact sort of router is a documented project, and it is advocated by the US department for Cyber Security.

It's not that "some people would want to buy keyless chips", it's that "chips that can reveal their keys are worthless for security".

As I said, they are perfectly welcome to buy chips that do not reveal their keys. You can still buy the exact chip you are advocating. You still get everything you are arguing for.

What you want to do would make them worthless to the segment of the market for which they have actual value.

The only thing you are losing is the assumtion that *MY* chip won't tell me my key. If that is the 'actual value' you desire then I reject that goal. And considering that you say a commercial service to rip my key out of my chip is OK, then that goal is already defeated.

you argue that the devices should be emasculated

No, I am advocating both versions be available. I am not demanding your chip be "emasculated". You may consider the version I would like to buy to be "emasculated", but I consider it to be valuable additional functionality. One that can be used to secure my data and my computer for me without securing my data and my computer against me. One where I can be certain I can back up and recover all of my data if I want/need to.

Different people and different applications have different security needs and different security priorities. For the vast majority of the expected market - grandma's PC and grandma's TV - the appropriate choice is to have your key. Data loss alone is a far greater threat than manufacturing plant worker attacks, not to mention the threats of lock in and lock out.

either the key must be generated outside of the chip and loaded, or it must be possible to request the key from the chip. If either of those scenarios is possible, then the chip is worthless for security applications.

Weee! I win! Chuckle. You have just stated that the current TPM specification is "worthless for security applications".

The current specification says that the keys may be generated on chip, *or* they may be generated externally and squirted into the chips. (I believe the word "squirted" is the exact word used in the specs.) I can dig up the exact page number from the specification if you wish.

If it's so difficult to reliably implement "

Re:Essential links....

[Alsee]

Long Island, NY.
While such a lunch would certainly be interesting, it would be kinda awkward for me for... the indeterminate future. Some things I need to take care of interfering with general life.

-

Re:Essential links....

[swillden]

Long Island, NY

Hmm. I was in Manhattan two weeks ago. No trips to NY planned in the near future, though.

While such a lunch would certainly be interesting, it would be kinda awkward for me for... the indeterminate future. Some things I need to take care of interfering with general life.

I'm not sure precisely what you mean, but that's okay. In any case, next time I'm going to be in NY I'll respond to one of your posts and see if you're interested. If not, that's cool.

Unstable

[Britz]

There is no 2.7 yet and Linux Torvalds still maintains the 2.6 kernel. All these new features just proove once more that 2.6 is not yet the stable kernel. Good that Sarge will come out with a solid 2.4. Even though I only operate a couple desktops I had my problems with 2.6 and actually went back to 2.4 on some machines. I sincerely hope that 2.6 will become stable sometimes soon.

Cheers

Re:Unstable

[sloanster]

I've been running 2.6 since it was beta, and have found it to be more stable than 2.4 - and much snappier for those great 3D FPS games. Come to think of it, our data center contains suse linux servers running the 2.6 kernel and dayum, they are stable!

As for sarge, IIRC it defaults to a 2.4 kernel in typical debian fashion (woody installs an ancient 2.2 kernel, right?) but even debian offers the choice of a 2.6 kernel in sarge.

Re:They've cleaned up some legal isues

[SCPRedMage]

Gah, I hate responding to trolls, but this needs said.

Sony put Linux on the PS2 themselves. Don't go blaming the Linux community for doing something immoral to get Linux on it, cause the company is responsible for the PS2 is also responsible putting Linux on it. Hell, the site you point to was set up by SONY as a community site.

Food for thought.

What about wireless device drivers?

[0olong]

Why are so many of the often used (and often needed) wireless drivers not included in the kernel?

Making wireless cards work in Linux is often a real hassle for the less knowledgeable folks. Wouldn't it be a good idea to smoothing things up a bit on that front. (I'd like to volunteer myself as soon as I have enough experience in this field - which will take a while..)

Re:What about wireless device drivers?

[0olong]

No, you miss my point. I'm talking about devices for which linux drivers already have been written (wlan-ng, Hostap, madwifi, etc.) but which aren't incorporated into the kernel.

Re:What about wireless device drivers?

[utamaru]

Some wireless drivers such as Atheros requires a binary only module for the hardware access layer. I don't think DRM binary modules would make it into the kernel.

Re:What about wireless device drivers?

[0olong]

> Why not have a kernel that loads only > the drivers it needs? D'oh.. surely I meant for the kernel drivers to be loaded as modules when needed. This of course is already the default for most kernel drivers, so basically I have no clue what you're talking about...

Re:Linus retiring?

[duffbeer703]

Why would they do that?

The kernel crew is making good coin at various companies or by consulting, working on a project that they enjoy.

Heh.

[ggvaidya]

so hardware 'just works'

Begun, the Just Works wars have ...

Re:Heh.

[HG2]

Just works... after we have destroyed all of the world's hardware...

Latency and preempt

[Anonymous Coward]

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.

FSF Standing ovation

[child_of_mercy]

As someone who was there I can tell you that the highlight of the conference was Eben Moglen from the FSF's speech, and the double standing ovation that followed.

Re:FSF Standing ovation

[Todesmetall]

So what did he talk about?

Re:FSF Standing ovation

[child_of_mercy]

It started out as a dry discussion of software licences, swung by the establishment of a center to give free legal advice to free software developers (funded by the industry players who want to use free software in their products), and finished with a rousing explanation of why it all matters.

there should be video soon.

http://linux.conf.au/

Re:Linus retiring?

[MichaelSmith]

Have they considered moving to a model like FreeBSD uses instead for the kernel?

Maybe not but since you suggested it, go ahead.

It is free software, after all.

Re:And then...

[NotThatKindOfDoctor]

What I meant by the above post is...I appreciate the rapid development, but the kernel has of late become a moving target. Doesn't anyone else out there wish the releases would slow down? I would like infrequent releases of a stable kernel rather than rapid bugfixes.

What a waste of effort...

[hanssprudel]

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...

Re:What a waste of effort...

[Professor_UNIX]

What is interesting is that "Trusted" used to be a label applied to systems like Trusted Solaris that implemented mandatory access controls (similar to what SELinux does for Linux). Which version of Trusted computing are they talking about? Mandatory access controls or the DRM nonsense?

Re:What a waste of effort...

[Slashcrap]

Your post is as incoherent and paranoid as it is long.

The problem with what you understand as Trusted Computing is that someone else gets the keys. They can decide what your computer can run and what it can't. Obviously this is bad and justifies the acute paranoia from which you seem to be suffering.

With the Linux implementation, you get the keys. So you can sign all of the executables you normally use and tell the kernel to only run them. Anything unsigned (e.g trojans, rootkits etc..) won't run.

It's a useful security feature. It's not about the RIAA preventing you from running that Britney Spears mp3 that you downloaded from Kazaa.

Re:What a waste of effort...

[OeLeWaPpErKe]

An atom bomb is equally scary if I have the button to make it blow up in my own hand.

So is Trusted computing.

Re:What a waste of effort...

[Todesmetall]

Maybe it's better to call one of these two versions Treacherous Computing then?

Re:What a waste of effort...

[marcosdumay]

TCPA is not DRM, like several TCPA opponents say. Also, TCPA is not completelly independent of DRM either (like some TCPA defendors - read IBM - say), one of its goals is to improve DRM.

That beeing said, I disagree of your reasoning. TCPA have the downside of making it possible to enforce DRM, but have several upsides too (if it didn't have upsides, nobody would fear it). The best way of fighting its downsides is offering clear implementations of the upsides, so, nobody will need to use the evil implementations.

Re:What a waste of effort...

[Antique Geekmeister]

Unfortunately, you can expect CD and DVD drives to require "trusted computing" access within 3 years, primarily to support DRM. Linux needs to look at this problem early to support video/audio/hardware access in the future.

Re:What a waste of effort...

[Minna Kirai]

With the Linux implementation, you get the keys.

No, no you don't. That is the WHOLE danger with trusted computing. There is a key known only to the hardware vendor, which the end user is not allowed to see.

If you don't know about that key, then it's understandable that you wouldn't grasp the implications of Trusted Computing at all.

With the Linux implementation, you get the keys.

No. Major computer vendors get the keys, and they sign OSes with them to guarrantee that the system is crippled so that music files can't be copied. Then when you run Linux, the RIAA can see that you aren't using an approved OS, and will forbid you from downloading their content. (And then later on, all publishers will do that, even just HTML websites)

Prehaps there will be some Linux distros that cripple their file copying and get that keysigning stamp of approval. But if you edit the source code even slightly, and even for an irrelevant bugfix, you can no longer play your WMA songs.

Re:What a waste of effort...

[Alsee]

You are mistaken, and the other poster Minna Kirai was basically correct.

The Trusted Computing specification forbids you to have your keys. The specification says teh master key are locked inside the chip and you may not see the, The master key is used to lock the file and application keys, and you are forbidden to see these either. In fact the chip is required to selfdestruct and destroy the keys and effectively destroy your data if it detects you attempting to get access to your keys.

The problem with what you understand as Trusted Computing is that someone else gets the keys. They can decide what your computer can run and what it can't.

Wrong. Trusted Computing does not restrict what you can run. It does however prevent software from working in many cases. The system does two things, (1) the chip reports exactly what software you are running to other people. You cannot control or modify this spy report. You can turn this report off, but if you do then the software will not work. (2) The chip prevents you from reading your own files except through the exact unmodified software tied to that file, and with the permission of that software and under the conditions imposed by that software.

The chipo does not allow you to see your own key to you own file, does not allow you to decrypt your own file. The chip will not allow you to access your file at all if you attempt to modify the software tied to that file.

So you can sign all of the executables you normally use and tell the kernel to only run them. Anything unsigned (e.g trojans, rootkits etc..) won't run.

Signing executables has absolutely nothing to do with Trusted Computing. That is a widespread missinformation. You can certainly use Trusted Computing *and* make use of signing stuff, but there really is no connection between them. Trusted Computing does what it does perfectly well even if you never sign a single EXE.

If you want to sign executables and restrict what can run, well you have always been able to do that with a simple patch. Just patch the EXE loader to do a check. You don't need Trusted Computing to do that.

It's not about the RIAA preventing you from running that Britney Spears mp3 that you downloaded from Kazaa.

Well at least you got that right. It will not prevent you from playing an MP3. The purpose of Trusted Computing to prevent the owner from getting at his keys. An MP3 has no key. An MP3 player has not key. You can run any MP3 player and play any MP3 just fine.

You will not be able to install commercial software without going through an activation process, and the Trust system will secure that application's key against you. You will not be able to read any keyed files that application chooses to create. You will not be able to connect to an ordinary website except with a Trusted compliant browser. Teh Trust chip will report if you try to run any sort of adblocker or anything. If your system is not compliant, if your system is not going to disply the website ads, then the Trust system will prevent your computer from being able to display that Website.

To make up a date, in 2015 when you attempt to connect to the internet, the Trust system will report to your ISP what software you are running. The ISP terms of service will be that you must runn an approved firewall software and approved and uptdate virus scanner and you must have all of teh latest operating system patches (all to secure their network against viruses of course). Oh, and if you are not running a Trusted Compliant system then you cannot authenticate that you are running the approved and mandated software. If you are not runnign a Trusted Compliant system then you will not be able to get any internet access at all. And yes, this is a very real potential situation. The President's Cyber Security Advisor gave a speech at the Washington DC Global Tech Summit calling on ISPs to plan on making exactly this sort of system a mandatory pary of their Terms of Service in the future. A call to secure the National Information Infrastructure against viruses and worms and against terrorist attack. He lterally went so far as to call for such a system to protect us against Osama Bin Laden himself.

-

Re:What a waste of effort...

[Alsee]

You could get all of the upsides and none of the downsides with identical hardware - the only difference being that the owner is given a copy of his master key. If he is allowed to know his key locked inside the chip.

Forbidding the owner to know his key has no upside. It is pure 'evil'. Trusted Computing is all about denying you the alternative system, a system with all of the benefits and where you know your key and actually control your computer.

Any attempt to promot the benefits of TCPA/Trusted Computing benefits is bogus. It's like trying to promote the vitamins of an apple with a poison pill inside. The vitamin argument is totally worthless to defend the poison pill apples, it is actually an argument for the normal apples they are denying you.

-

Re:And then...

[FidelCatsro]

This is why the bug fixes are passed back through the kernel releases.
If you constantly upgrade to the latest release then ofcourse you will bump into glitches now and then.
The highest number is not a gaurentee of stability , if you want stable then keep your system on a kernel a few releases back and just keep it patched.
The very latest releases feature ,mainly improvments and aditions to the functionality of the kernel.

2.6.12 will be "bleeding edge" when its released and i wouldnt trust my working system to it unless i really needed something that was part of the kernel . Generaly its a good idea to wait untill 2.6.12 has had its fair share of testing before commiting to using it

Re:Solutions in search of a problem

[mi]

If you're having problems scaling poll/select, you probably need more hardware.

kqueue lets me know, when the file grows. For example, tail(1) on FreeBSD uses it (with -f and -F switches). How would you do that with select/poll?

What the fuck for?

Is this language normal for Linux-related discourse?

And extending a file via mmap() is effectively impossible. If you don't think so, you don't understand what mmap() really does.

Funny, it works on FreeBSD -- once you ftruncate the file beyond its end, you can mmap it and have the storage allocated automatically, when (and if) you write to it...

Don't post anonymously if you want a reply.

Re:Modules that work with different kernel version

[toggles]

I don't mean to nitpick, but your spelling sucks

> What the fuck for?

the correct spelling would be

> What the fsck for?

Re:orinoco

[gfunicus]

Here here!

rtfm

[marafa]

rtfa - this is a developer on the kernel team .. not a maintainer.
and he claims xen n reiserfs4 etc are gonna be in 2.6.12..
R I G H T !

OTOH

[Compact Dick]

I have used your mum's box, and it was a pleasant experience. I must admit gaining root access was a laugh, even though bitchchecker had no luck :-)

Why is this in the GNU section?

[QuantumG]

I mean, WTF? People really are confused about GNU/Linux aint they? When the FSF asks you to refer to the entire system as GNU/Linux they are not asking you to refer to the kernel as GNU/Linux. So if you're going to post a story on Slashdot it that is 100% entirely about the kernel then it makes absolutely no sense to put it in the GNU section.

Re:Why is this in the GNU section?

[SolusSD]

i second the parent post. this IS LINUX. the kernel itself. not GNU anything

Trusted computing is OK, *IF*

[wowbagger]

Trusted computing is OK, if you can trust the OS, and the OS trusts YOU.

I have no problem with Linux supporting the TPA, as I can trust Linux to do what I want it to do. I can trust Linux to not lock out apps that aren't signed by somebody I don't control (e.g. Microsoft) - in other words I can trust Linux to allow ME to specify who may/must sign my apps.

In such a situation, the acceleration provided by having hardware encryption routines is great!

Now, if I cannot trust the OS to trust me (*cough*Longhorn*cough*), then I definitely do not trust Trusted Computing.

Re:Already available

[Matt Clare]

I've only seen it on Red Hat boxes (and had not interest in forcing on myself in other boxes). Was it a Red Hat patch until this release?

Re:Already available

[erlenic]

I thought it was a separate kernel patch. I took this announcement to mean it's been merged into the main kernel tree. Someone correct me if I'm wrong.

Boycott Trusted Computing

[wikinerd]

I do not agree with Trusted Computing. Recently I was offered to buy a brand new IBM sub-notebook at a very low price and I refused because it supported Trusted Computing. If 2.6.12 supports Trusted Computing I will never upgrade to it. I boycott it. There are more evil uses of Trusted Computing than good uses, so I see no reason why I should empower the corporations to dictate what software I should run on my computer.

Re:Boycott Trusted Computing

[lachlan76]

How can it be used for evil if you control the key?

Re:Boycott Trusted Computing

[vhogemann]

You can upgrade to 2.6.12 ... just don't include the fscking module.

Also, what are those evil uses that you talk about? And, since Linux puts YOU in control, how can Trusted Computing taints it?!?

Re:Boycott Trusted Computing

[delire]

Is it possible you are mistaking Trusted Computing for Digital Rights Management?

Firstly, TC in the Linux kernel is optional, an option for you, the administrator to define who uses what and to what extent on your machine.

I realise the term may have been dressed up like the villianous accomplice of DRM, but frankly they are mutually exclusive from the perspective of a Linux user. At worst, if SuSE was to ship their distribution with TC and you didn't like this, then either switch distro or grab the kernel source.

Re:Boycott Trusted Computing

[UnapprovedThought]

TC is more sinister than DRM. DRM attempts to prevent you from copying data, by "managing" your digital copying rights away from you. TC however, sets aside an area inside your computer that only trusted code has control over (and that certainly doesn't include YOU). Such a scheme may have some benefits but it also may become the perfect hotbed for unremovable viruses. If a trusted process cannot be affected by the user in any way (e.g. ignores all signals), vendor-sponsored malware will be able to reign supreme.

"At worst, if SuSE was to ship their distribution with TC and you didn't like this, then either switch distro or grab the kernel source."

Not all users are able to upgrade their kernel. You and I may be able to do that, but think about it. The average user will just have to swallow whatever the major distros put out. That's not very "optional."

Gathering steam, eventually TC may become required in order just to enable the most basic things, or at least things that the average user considers basic, such as acroread, for example. At some point even you and I may be stuck with it.

That being said, it's complex to determine which approach will work best. With no techie users helping to test it or submitting valid bug reports, hopefully the thing will never work right and will be dropped entirely. The hardware vendors can fund it all they want, but I'm just not going to purchase or support hardware capable of TC. Vendors can't just bribe me into it with lower prices. I don't want uncontrollable crap on my system at all, and if I were an ordinary user, I would be suspicious of anything that even smacks of it, and justifiably so.

Before I ever download this kernel, I first want to download only the TC module and read through it. Hopefully that is still possible? Does their CVS system still work, or is it a "trusted" CVS system now? I hope I'm really wrong about this, but until I read that code I won't be sure.

Re:Boycott Trusted Computing

[delire]

DRM attempts to prevent you from copying data, by "managing" your digital copying rights away from you.

The only way this will happen with the 2.6.12 kernel is if you decide that you want to remove rights from yourself (to copy to a given device). Read the kernel-dev mailing lists - it seems you have a tainted view of TC, one more in line with the 'Palladium' project - which was to be a M$'s implementation of TC to the ends of ensure pirate copies of their OS could not be installed to the given device. TC in itself is not innately evil, though of course it can be used for evil.

Re:Boycott Trusted Computing

[UnapprovedThought]

The only way this will happen with the 2.6.12 kernel is if you decide that you want to remove rights from yourself

*sigh* OK... what if I didn't know how to set kernel options and such? Wouldn't I be stuck with it?

A better solution then is just not to purchase TC hardware.

New features within an old stable line?

[Daedalon]

Why is the already released stable kernel line getting new features? Why isn't it so that once announced stable kernel lines get feature-frozen and the x.x.xx updates would only correct problems, never introduce new features.

Isn't that the whole purpose of having separate unstable and stable lines? Each stable standing for certain features, the subnumber telling how many fixes have been applied, and the newest unstable being the ground where new features are introduced and tested before releasing them in the next stable line.

Re:New features within an old stable line?

[nagora]

Isn't that the whole purpose of having separate unstable and stable lines?

Yes, it would be if that was how it was done. The stable/unstable branching hasn't been used since 2.6 came in quite some time ago.

I think the reasoning was that the vast majority of users are using kernels supplied by their distro and those aren't bumped up until the distro maintainers are happy that they are stable anyway, so why bother with two branches, especially since many innovations end up having to be backported to the stable branch because of user demand?

TWW

Re:Just use Solaris

[omega9]

How are any of these feature `revolutionary' or any sort of significant milestone? Maybe it is in the Linux world..
SELinux, please. Solaris has had..
Reiser 4!? C'mon! Solaris 10 will have..
Xen you say? Eh, not to burst your bubbles but Solaris 10 now features...

Isn't that the exact point? This is noteworthy because these are features of LINUX, which LINUX didn't have before. By your arguements there would be no reason to ever start a new OS project. "Oh shit, we're adding harddisk support. That's been done, so... we can stop here."

I'm glad you're a fan of Solaris. So am I to an extent. But if we could get the same capabilities under the development and openness model of Linux, then how cool would that be? Sun likes to try and talk a big game, but they're never going to open up Solaris as much as Linux is.

Re:New features?

[nb caffeine]

Agreed. Having random pieces of semi obscure hardware makes it importnat that the kernal (and distro) "just work" for my server and laptop. Both have debian with lots of customisation, but the kicker is my weird ide controller, some laptop stuff, etc, all working. Smoothly. and for now they do.

I've had no problems at all.

[anti-NAT]

I'm running a circa-1999 machine, and have been running 2.6 since 2.6.0, and am currently running 2.6.11. I use it everyday, so it isn't just sitting idle. Here is my current uptime :

23:13:10 up 29 days, 5:21, 5 users, load average: 0.26, 0.29, 0.25

At the risk of starting a religious war, are you running any binary modules ? They can cause some stability problems.

I avoid binary modules, or rather, make sure that the hardware I buy is supported by official kernel device drivers. Back in 1993, when I first started to use Linux, you didn't have a choice - it was open source device drivers or the hardware just wouldn't work.

Here are some brief specs on my machine.

>cat /proc/cpuinfo
processor : 0
vendor_id : GenuineIntel
cpu family : 6
model : 7
model name : Pentium III (Katmai)
stepping : 3
cpu MHz : 448.172
cache size : 512 KB
fdiv_bug : no
hlt_bug : no
f00f_bug : no
coma_bug : no
fpu : yes
fpu_exception : yes
cpuid level : 2
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 mmx fxsr sse
bogomips : 886.78

>free
total used free shared buffers cached
Mem: 385796 380076 5720 0 25692 93820
-/+ buffers/cache: 260564 125232
Swap: 1999736 224860 1774876

>lspci
0000:00:00.0 Host bridge: Intel Corp. 440BX/ZX/DX - 82443BX/ZX/DX Host bridge (rev 03)
0000:00:01.0 PCI bridge: Intel Corp. 440BX/ZX/DX - 82443BX/ZX/DX AGP bridge (rev 03)
0000:00:0d.0 Ethernet controller: Standard Microsystems Corp [SMC] 83c170 EPIC/100 Fast Ethernet Adapter (rev 06)
0000:00:0e.0 RAID bus controller: Silicon Image, Inc. (formerly CMD Technology Inc) PCI0680 Ultra ATA-133 Host Controller (rev 02)
0000:00:0f.0 Ethernet controller: National Semiconductor Corporation DP83815 (MacPhyter) Ethernet Controller
0000:00:10.0 Multimedia video controller: Brooktree Corporation Bt878 Video Capture (rev 02)
0000:00:10.1 Multimedia controller: Brooktree Corporation Bt878 Audio Capture (rev 02)
0000:00:14.0 ISA bridge: Intel Corp. 82371AB/EB/MB PIIX4 ISA (rev 02)
0000:00:14.1 IDE interface: Intel Corp. 82371AB/EB/MB PIIX4 IDE (rev 01)
0000:00:14.2 USB Controller: Intel Corp. 82371AB/EB/MB PIIX4 USB (rev 01)
0000:00:14.3 Bridge: Intel Corp. 82371AB/EB/MB PIIX4 ACPI (rev 02)
0000:01:00.0 VGA compatible controller: ATI Technologies Inc RV280 [Radeon 9200 SE] (rev 01)
0000:01:00.1 Display controller: ATI Technologies Inc RV280 [Radeon 9200 SE] (Secondary) (rev 01)

OpenGL isn't fully working on my Radeon 9200 yet, following the dri-development mailing list, there seems to be some bugs that are causing it to lock up. I've had glxgears run for about 4 minutes, then X locks up. If I desperately need it, I'll put my Matrox G550 back in.

In my experience, 2.6 has been as stable as 2.4.

Re:Reiser 4?

[Neil Watson]

I deployed a test Reiser4 server at work. The data is stable and I have not lost anything. However, the Reiser4 partition is also an NFS share. This share regulary stops working. Only a reboot of the system returns the NFS server to a working state.

Re:Enhanced Security???

[speculatrix]

> You mean to tell me Linux is already
> the most secure, bulletproof OS available?
> What could they possibly have to improve?

well, there were quite a few bugs introduced into 2.6.11 since 2.6.10, such as breaking IP networking over USB (something that caused quite a problem for many people (including me!).

am I the only person who things that the break-neck introduction of more features (bloat) into the kernel is taking priority over stability and testing?

I Wish firewire would just work

[t35t0r]

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.

Re:I Wish firewire would just work

[evilviper]

There are some serious issues with firewire on linux. It is nowhere as mature as it is on winxp or macosx.

No doubt I'm opening myself up to a Troll/Flamebait mod, but...

FreeBSD's Firewire support is much better than Linux's. FreeBSD had firewire support before Linux, and it was considered stable and released in the default kernel before Linux even had it's unstable Firewire drivers available as an option, IIRC.

Having good firewire support leads to other interesting developments too, like the ability to debug a crashed system over firewire.

Go to the source

[Corbet]

Should you be curious, I've posted the slides to my talk on LWN.net.

I want, I want, I want these!

[nighty5]

Once I heard about a new notifer system I started to get a bit excited.

What would be nice is:

A system that detects when I insert any USB device, and it knows if its a filesystem drive - and mount it! Pops up a bubble or something in my GUI to let me knows its under control.

When new hardware is inserted, whatever interface, my desktop notifies me - and tells me its been configured and installed.

The future is bright!

Re:I want, I want, I want these!

[XanC]

You can get close to that with supermount. At the library I administer, I use the ck patches including supermount, and it lets people stick in their USB filesystem devices without having to mount or unmount.

Re:I want, I want, I want these!

[BenjyD]

The USB storage device auto-detect thing is what happens with most distros isn't it? Certainly with Ubuntu, FC3 and SuSE it automatically pops up an icon on the desktop whenever you insert a storage device.

Re:I want, I want, I want these!

[Blakey Rat]

Yeah, Knoppix pops the new icon up *exactly* on top of one of the existing drive icons so it took me forever to figure out why the hell my USB flash drive "wasn't showing up."

Not that the kernel's to blame, but lots of Linux distros have plain *stupid* bugs that would have been fixed with more than 10 minutes of QA.

Re:I want, I want, I want these!

[SPY_jmr1]

and you can nearly cure brain tumors with leaches, too...

Gamers: Configurable USB Mouse Polling Rate!

[Jagasian]

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.

Re:PCHDTV drivers finally! w00 h00!!

[stuffisgood]

Umm...as far as I was aware Intel wireless drivers ARE in the kernel... I mean I have used my Intel Pro Wireless card successfully in both Ubuntu and Mepis...

Re:Gamers: Configurable USB Mouse Polling Rate!

[Second_Derivative]

I'm curious; how does this yield a visible advantage when the screen's refresh rate is 100Hz tops?

Virus

[Chemisor]

> since it started cheating on me and got a virus :-(

Maybe it got it from those porn sites you keep dragging it to...

Re:Already available

[qkslvrwolf]

Its a kernal patch developed originally by the NSA.
SELinux

I don'b believe it

[spitzak]

All your options where the user can sign their own software could be done with no hardware support. The kernel could check these sums just as easy before running the program.

The idea of hardware to do encryption is nice, but this is the same industry that thought it was a good idea to save $3 by making the CPU do all the calculations formerly done by the modem chip (at a time when those calculations required 20% of the CPU power). So in no way are they adding this chip because it will speed things up.

The purpose of Trusted Computing is to introduce a public-key encryption where only the manufacturer knows the private key. There is literally a type of data that you *cannot* create, but the manufacturer can, and a simple test to see if a file is that type of data. The purpose is to make it impossible to write software for your own computer. Anything else is a smokescreen.

Overuse of Signatures

[EXTomar]

Arg, people are constantly overusing signatures and "signed code". Signed code just signifies that the contents of the package match what the packager packaged (ie. no tinkering). It does not by itself stop malware. A packager can unwittingly package malware or worse a packager can knowingly package malware, sign it and get people to run it.

I feel that measures like this need to be used carefully less you want to get into a situation Windows is currently in. So many tools and so many mechanisms that are convoluted and not exactly integrated with each other make for an unusable security system that users would rather defeat than enable.

I do easily admit that there are places where trusted implementations of Linux make sense. Off the top of my head "sealed" embedded Linux kernels would make great use of this mechanism. However most Linux desktops do not need another set of tools to lock down security. The kernel should offer the generic facilities but I'll be disappointed if it is forced enabled on all kernels.

Re:Just use Solaris

[iggymanz]

I've used Solaris/SunOS for over 15 years, and there are some ways in which Solaris is inferior to most Linux distros: not nearly as many hardware devices supported in the x86 world, not as many foreign file systems supported, and only runs on sparc and x86. As for ZFS and some of the other future things you've mentioned, it doesn't count until it's released. So I would say go plug your Solaris 10 into your laptop with wireless card and USB camera and see how well it works. Then install it into your high end HP or IBM x86 server with fancy RAID card and dual gigabit ethernet, and see how it works. It *won't* work.

My favorite part...

[Grendel Drago]

... is how "This should come as no surprise to anyone who has followed the Linux movement from the day Linux wrote the kernel." Take that, proprietary software! Linux is so advanced, it writes itself!

--grendel drago

Re:They've cleaned up some legal isues

[SCPRedMage]

Reality is for people who can't handle fantasy.

But I think what he was aiming at with the font issue is "stealing" MS fonts and using them with Linux, an issue he mentions seperately from the SCO crap. Of course, the only thing he mentions are instructions on how to use the fonts, meaning users would have to have them already... implying that they would already have a liscence to use them...

Modules.

[Grendel Drago]

Dude. Take a deep breath. Then repeat the word "modularity" to yourself until you understand it. Then go install tiny-linux, and also---I only say this because I care---consider switching to decaf, 'kay?

--grendel drago

Re:Reiser 4?

[Slashcrap]

It scares me to still hear Reiser 4 being described as "having problems". Anyone knows more?

I know that you don't have to use it if it scares you so badly.

I don't think they're going to have to remove Ext2 from the kernel to make room for Reiser4.

"Sometime soon" ???

[naily]

What is this? Windows??

Ah no, that would be "Definitely in 2003, no 2004, I mean 2005, no 2006" etc.

Another benefit of open source is that it doesn't need marketing spin, because often the underlying gist is 'whenever we can'.

Re:"Sometime soon" ???

[spectecjr]

What is this? Windows??

No, because Windows has had all of those inotify features for about 9 years now.

Re:"Sometime soon" ???

[Minna Kirai]

No, because Windows has had all of those inotify features for about 9 years now.

No. A few years ago at least, there was a moderately low limit on the number of file notifications that could be active at once. It was easy for a big directory to exceed the quantity that could be watched. (Maybe this has been fixed in XP, but that's fewer than 9 years old)

Feel free.

[Anonymous Coward]

Feel free to fork your own and release AClux or whatever you want to call it. Then your API can bash it out with Linus's, and the best one will win.

Just sayin'.

This is especially nice for

[infernalC]

This is especially nice for folks running webservers, etc. - now you can force people to only run CGI programs that you have signed (and thus inspected). I wonder how many webservers have been hacked because someone left their personal copy of the php or perl binary in an open cgi-bin.

Re:This is especially nice for

[ultranova]

This is especially nice for folks running webservers, etc. - now you can force people to only run CGI programs that you have signed (and thus inspected). I wonder how many webservers have been hacked because someone left their personal copy of the php or perl binary in an open cgi-bin.

Um, if you want the webserver to only run certain scripts, then why don't you just put those scripts into a directory, make it read-only, and configure the webserver to only execute scripts in that directory ?

Why do you need signatures for this ?

And why do you have a writable cgi-bin directory if you don't want users to add or alter scripts on their own ?

Re:This is especially nice for

[infernalC]

I didn't say it was required. I said it was nice. It never hurts to have an extra layer of security.

Re:Gamers: Configurable USB Mouse Polling Rate!

[BenjyD]

Because this one goes to eleven, see?

Re:Gamers: Configurable USB Mouse Polling Rate!

[alyandon]

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.

Re:Already available

[temojen]

SELinux is in the main tree, it's just not turned on by default. Same with the kernel preemption feature. I'm not sure what the article is on about.

286 ?

[ultranova]

When I saw this story on the front page, it had 286 comments. Very appropriate, since the purpose of "Trusted Computing" is to turn the clock back to the bad old days.

Re:286 ?

[Blakey Rat]

When somebody figures out the link between the number of comments, trusted computing, and the "bad old days," could they please drop me an email so I know WHAT THE HELL THIS GUY IS TALKING ABOUT?

Re:286 ?

[Tharkban]

Haven't you heard of the ancient art of Trusted Computing?

newbs.... :P

Re:286 ?

[Minna Kirai]

When somebody figures out the link between the number of comments, trusted computing, and the "bad old days,"

It wasn't a very useful thing to say, but the reasoning is like this:

There were 286 comments.

The "286" model of Intel CPUs was widely used 25 years ago. It was incapable of running Linux.

25 years ago, there was little progress in Free Software. PC operators had little choice but to execute programs written by a far-away company, and had no power to make small alterations to make the software serve you better. If a program included a feature which was intentionally hostile to the user, you had few other options. Trusted Computing is an attempt to reclaim some of the control of PC software that has filtered out to end-users over that time.

Also 25 years ago, there was no high speed Internet access or CD-R drives. Widespread infringement of Intellectual Property was difficult and slow. The "Napster effect" couldn't happen then. Trusted Computing is an attempt to go back to before it was easy to send any digital file across the planet.

ACPI Roadmap?

[Vagary]

Anybody know when we can expect to see full and relatively bug-free acpi support? I'm tired of using hacks like radeontool.

new versioning system

[MenTaLguY]

Linus adopted a new versioning system. Instead of having 2.6.x be the stable releases, and 2.7.x being the development releases, now 2.6.x is the development release and 2.6.x.y are the stable releases.

So, instead of changes piling up in a long-lived development series, we get a new stable series based off of every development release.

Re:Just use Solaris

[iggymanz]

I dig this crap up from my job. As far as HP product line, we mainly sell DL-580, 585 and DL 380 to customers. OpenSolaris, heheh, let's see Sun release that first.

As an aside, I'd like to tell the world how badly Solaris 9 sucked installing on Sun's very own V20Z, didn't detect the video settings AT ALL and gave a crappy 640x480 X11 display. And with either Solaris 9 or 10 the power supply ran very loudly at full tilt, never adjusted downward for very cool environment i had that thing in.....getting the feeling Sun is rushing stuff out the door in x86 land over here.

Re:PCHDTV drivers finally! w00 h00!!

[pyite69]

ipw2100, 2200. afaik you still have to build these separately.

And how about a way to build NVIDIA 3d into the kernel.

Re:Gamers: Configurable USB Mouse Polling Rate!

[Anonymous Coward]

I'm curious; how does this yield a visible advantage when the screen's refresh rate is 100Hz tops?

(a) You mean you aren't overclocking your screen?

(b) Then it obviously yields an invisible advantage.

Release date confirmed!

[HogynCymraeg]

It's in 2006: The Year of Linux on the Desktop(TM)

The Point of Trusted Computing on Linux

[MooseGuy529]

Many people are complaining about what Trusted Computing can/will be used for. Quit whining, for two reasons:

First, Linux is open-source, so you can modify or disable whatever you want. Unlike a binary kernel, you can remove code you don't like, and the rest of the kernel will work without it (if you remove it cleanly). In other words, it's not being forced upon you by the OS distributors. If a company decides to make software that requires it, that will be their decision to make and their problem to solve.

Second, TC has uses other than the oft-cited "make sure the computer only has $OMINOUS_ADJECTIVE software here", for Orwellian values of $OMINOUS_ADJECTIVE such as "permitted", "approved", and so on. In fact, Trusted Gentoo is setting up a system that uses the TPM (Trusted Platform Module--"the chip") to make sure your kernel and bootloader hasn't been tampered with and keep your SSH keys from being compromised. "Trusted" simply means that there is an uncompromisable encryption and verification (signing) system in the computer. It can be used for good or evil. Linux gives you that choice.

Re:The Point of Trusted Computing on Linux

[Minna Kirai]

Unlike a binary kernel, you can remove code you don't like, and the rest of the kernel will work without it (if you remove it cleanly).

Wrong. If I remove code I don't like, the kernel will still boot, but it will no longer match the keysigning checked by the Trusted chip on the motherboard. So when I use this kernel to download a video I've bought online, it will refuse to play. Thus, the system is no longer completely working.

(An alternative interpretation is that the system is still working as advertised, but that the goals it is working towards are against the desires of the end-user)

Re:The Point of Trusted Computing on Linux

[MooseGuy529]

My point is that, while Windows will probably be extremely restrictive, that Linux will not restrict what you can do itself. The kernel will never work against you.

If you buy a video online, any problems you have are the fault of the company from which you bought the video.

Re:The Point of Trusted Computing on Linux

[Minna Kirai]

Linux will not restrict what you can do itself. The kernel will never work against you.

If that's true- and it might be- then Linux will never be able to view the majority of content end-users need to see. Most of the nascent free software world, especially as pertaining to desktop PCs, will be absolutely crippled.

If you buy a video online, any problems you have are the fault of the company from which you bought the video.

Assigning blame doesn't fix problems.

Re:Solutions in search of a problem

[mi]

In your example, you're just filling in a sparse file that's already logically X bytes long.

Yes. And my example works on FreeBSD, but -- for some reason -- not on Linux -- can't even mmap the input, much less grow the output. Which was the whole point of my original post.

Do you see any value in your participation in this thread?

Re:Just use Solaris

[Lemming Mark]

I'm afraid you'll have to educate us - how do Solaris' MAC facilities measure up against SELinux? Are they as flexible? Do they offer any more features? In what way are they better?

Xen and Zones are different things. Yes they both provide virtual servers but in different ways. Both have strengths - the ideal system would support both.

Xen:
* virtually no performance penalty
* supports live migration of virtual servers
* runs Linux 2.4 / 2.6, FreeBSD 5.3, NetBSD 2.0, Plan 9 in guests
* can live-migrate virtual machines between physical hosts
* greater isolation of virtual servers for better security / robustness
* can almost certainly run on more hardware than Solaris
* can run device drivers in fault-resistant sandboxes
* can be used to debug guest OS kernels

Zones:
* lower memory footprint than Xen (and more flexible in memory usage)
* even lower performance penalty, approaching zero (if Sun have Done It Right)
* lighter weight virtual servers than Xen, with better resource sharing between virtual servers

A combination of the two would be really useful - use Xen where you need migration, high assurance isolation, etc. Use VServers where you are less concerned about these issues and want lighter-weight virtualisation.

Neither is "better" than the other without considering the use case.

Re:Solutions in search of a problem

[davi_slashdot]

This also works in linux. You just need to call mremap after the ftruncate call.

Re:Gamers: Configurable USB Mouse Polling Rate!

[Jagasian]

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.

Re:Gamers: Configurable USB Mouse Polling Rate!

[Jagasian]

I should also add that even if an advantage is not visually apparent, it can still be an advantage. The fact that the mouse movement is logically updated more frequently can also lead to additional advantages. Take an extreme case using an bitmap drawing tool like Gimp or Photoshop. If I drag the drawing tool in a circle, the smoothness of the circle that is drawn is not determined by my CRT's refresh rate, it is determined by my mouse's polling rate as each poll returns an X-axis and Y-axis movement delta. The slower the rate, the more "jaggy" and unsmooth the drawn circle.

In the extreme case, the CRT can not refresh at all, say by turning it off or by breaking it so that it continues to display the same beginning image permenantly. Obviously the circle won't be any different, keeping the movement of the mouse constant.

Re:Solutions in search of a problem

[mi]

You just need to call mremap after the ftruncate call.

Neither FreeBSD, nor Solaris, nor AIX have mremap. It seems to be a Linux-only thing.

Anyway, try to get my little program to work on Linux (without local buffers) and send me the diff...

Factoring large primes, eh?

[Jerk City Troll]

cryptographically, so no spoofing it unless you are really good at factoring large primes

Give me any prime number, I don't care how big it is. I will instantly factor it with nothing more than my brain! Which is, of course, why I can defeat crypto systems just be looking at them! Amazing, isn't it?

(I love it when people who don't really know cryptography start spouting off canned lines with the keywords factor (verb) and prime.)

Re:Factoring large primes, eh?

[finkployd]

Funny, I already explained I mistyped in another post. Being accused of not knowing cryptography is quite amusing :)

Finkployd

Re:Factoring large primes, eh?

[finkployd]

In fairness, no I cannot blame you. This place is not known for its vast knowledge of cryptography :)

Finkployd

Re:Solutions in search of a problem

[davi_slashdot]

I dunno if you are just kidding, or if you really cannot do this. The program does not need mremap because you ftruncate before mmap and after munmap.
First, You need to make sure that your size parameter is page aligned. Besides that, you cannot mmap a file opened O_WRONLY. You need O_RDWR.
Diff at http://www.dcc.ufmg.br/~davi/mzip.diff

OOM Killer and overcommit

[Sxooter]

Any chance the OOM killer / overcommit issues will be fixed? They've been keeping the 2.6 series out of the hosting center since day one.

Re:cle266

[repvik]

I though the cle266 drivers has been included in the kernel for a while? VIA opensourced them a while back IIRC.

Nearly!

[r00t]

"once supported always supported"

Linux just recently dropped support for PC-XT hard disks, including MFM and RLL. (the "xd" driver, for /dev/xda and /dev/xdb) These drives would be 20 years old now; surely they have all died.

Of course, PC-XT hard disks were long obsolete before Linux was invented. They were nice back around the time that people were transitioning from the 8088 to the 80286 or using the V20 and V30 clones.

PC-XT disks were weird. The controller would use an 8-bit (short ISA) slot. There was a shared data cable, with a connector for the controller and one for each drive. There were also point-to-point control cables. So the controller card had 3 connectors on it, and the drives had two (or 3 if you count power).

FreeBSD violating the UNIX standard

[r00t]

Look, a UNIX OS is not allowed to behave this way.
It says so in the UNIX spec, which FreeBSD so often
violates.

Re:Gamers: Configurable USB Mouse Polling Rate!

[kasperd]

because the monitor is not synchronized with the mouse

I think this is the most important point in your comment. If the mouse polling was synchronized with the monitor you'd get a better result than by polling at 500Hz, and you'd use less CPU power as well. This is one of the cases where the Amiga hardware was superior to the PC, and still is. I mean about 20 years ago the Amiga got timing of input, video and sound exactly right. How come the PC still doesn't do this right?

Re:"just works"

[speedplane]

I would also like to mention that everyone gives Microsoft s#!@ for mentioning a phrase like that ("nothing they do ever works, haha"...lame), but when linux developers mention it, then everyone rejoices.

Re:Solutions in search of a problem

[mi]

I dunno if you are just kidding, or if you really cannot do this.

Khmm, your diff works (except for the MAP_SHARED/MAP_PRIVATE hunk -- you need to keep the MAP_SHARED or else no output is ever written to disk). The requirements for the size alignment and O_RDWR are odd, but not show-stopping.

I wonder, what the problem was, when I last tried this on Linux... Probably, it was that I tried a non-aligned output size and O_WRONLY and blamed the error on the lack of real backing store (unfairly).

Alright, one down, one more to go. Can epoll be used to make tail -f better, the way kqueue is used on FreeBSD?

Re:Solutions in search of a problem

[Brandybuck]

Is this language normal for Linux-related discourse?

Apparently so. Most non-kernel projects are quite polite, but I've seen some kernel (and GNU) discussions that would make even Theo blush. It's what happens when immovable egos collide in Linuxland. The casual vulgarities and insults may have kept the kernel from forking, but it hasn't done much to enhance the maturity level of the participants.

As long as it's a module

[Coder7]

As long as Trusted Computing is a module, I don't see why so many people are complaining about it. That's the nice thing about linux, you can turn just about any "feature" off. My only complaint would be that the developers could probably have spent their time doing something more useful, but I'm not paying them to do it so what right do I have to argue with what they implement.

Re:Gamers: Configurable USB Mouse Polling Rate!

[grmoc]

It can make sense to have them decoupled.

If, for instance, the card can render faster than the monitor can display, then you can do things like motion blur to account for some of the perceptual difference.

This implies that having the mouse sampled at a higher frequency than the output device is still useful.

no control ( as bad religion said )

[loveboat]

great.. now linux is really starting to windowsify. when they write "it just works" they really mean "we will attempt to predict what you want and run any number of automated tasks and relieve you of all control you might have had" -- it's never to late to give up

Re:Enhanced Security???

[spauldo]

Who claimed it was the most secure, bulletproof OS?

There are much, much more secure systems out there than linux. Check out MULTICS sometime. Note that no one uses it anymore, since it requires special hardware to run.

You will never need these features until you find yourself working with massive multiuser machines or classified processing. It's a government project, go figure.

Read up on the SELinux docs on more info, and why the target audience for windows/desktop linux/macos would never care. Most people making claims about linux's security as opposed to other OS's are comparing it to windows, and in terms of vulnerabilities. That's a whole 'nother ball of wax.

Re:orinoco

[spauldo]

There! There!

Where Where?

Re:Solutions in search of a problem

[slamb]

kqueue lets me know, when the file grows. For example, tail(1) on FreeBSD uses it (with -f and -F switches). How would you do that with select/poll?

Switch to using FAM (File Activity Monitor) on both systems. It's a daemon implemented on top of kqueue (on *BSD) or dnotify/inotify (on Linux). It talks to instances on other machines to work properly across network filesystems. It also abstracts the underlying API for you. It just gives you a file handle to plug into your monitoring loop, and an API to call when it has input. No need to care if it's using kqueue, dnotify/inotify, or (in the worst-case scenario) a timed loop on the backend.

There's your practical answer. If you'd like to know why you can't directly see when a file handle grows with select/poll, read on.

The thing is that regular files and socket/pipes/character devices are treated in a fundamentally different way on Unix systems. Sockets have nonblocking IO and select/poll. Regular files have much less support - a separate, nasty async API on some systems, and inotify/dnotify on Linux/kqueue on BSD for notifications. (Something on IRIX...they built fam there, after all.) This doesn't make a lot of sense and people like DJB have argued that this doesn't have to be, but...well, that's still how it is.

kqueue is no exception. They've grouped a number of things into the same system call and made it more convenient to safely wait for several types of events at the same time, but you still can't treat them in the same way. On Linux the equivalent of kqueue is accomplished through:

• epoll
• dnotify/inotify signal handlers
• ptrace? I don't remember how you watch processes off-hand.
• more signals for async IO

The biggest pain there is handling signals and epoll stuff simultaneously in a correct manner. If you need to, I urge you to check out the documentation for my sigsafe library. It describes some things not to do plus a couple good ways: the self-pipe trick (a popular way if you're using select/poll/epoll) and my own sigsafe_* signal call wrappers.

Probably a change since 2.6.10

[anti-NAT]

I was running bridging between multiple Qemu instances (around 5), using tun/tap interfaces on a 2.6.9 kernel. There were some problems and I reported them to the netdev mailing list. It was suggested that I try out the then current 2.6.10-rc, and they disappeared.

Here is the URL for my post to the list :

[2.6.9] Networking crash, slightly exotic setup, bridged tap/tun

Have you reported the problems to the netdev mailing list, or possibly the bridge maintainers ? Here are the bridge details from the MAINTAINERS file in the linux kernel source :

ETHERNET BRIDGE
P: Stephen Hemminger
M: shemminger@osdl.org
L: bridge@osdl.org
W: http://bridge.sourceforge.net/
S: Maintained

and the netdev list

NETWORKING [GENERAL]
P: Networking Team
M: netdev@oss.sgi.com
L: linux-net@vger.kernel.org
S: Maintained

sigsafe

[Jamie Lokier]

The biggest pain there is handling signals and epoll stuff simultaneously in a correct manner. If you need to, I urge you to check out the documentation for my sigsafe library. It describes some things not to do plus a couple good ways: the self-pipe trick (a popular way if you're using select/poll/epoll) and my own sigsafe_* signal call wrappers.

Interesting library.

By the way, there is somewhat portable way to do the same thing that doesn't need syscall wrappers or cpu-specific and os-specific assembly language. That is to call dup2 in the signal handler, to replace the fd that's about to be blocked on with a non-blocking pipe writer whose read partner is closed (dup2 is specified as async-signal-safe, and generally is). You can't write and can't read it, so those operations return without blocking or changing the pipe's state. Afterwards you can use dup2 again to restore the original descriptor.

Enjoy :)
-- Jamie "portable code 'r' us :)"

Re:sigsafe

[slamb]

Interesting. I'd never seen that way before, but it's similar to the self-pipe trick (which is also portable).

sigsafe's advantage is that it works with a lot more syscalls than just the file polling ones, and (hopefully) your code is simpler. The porting's not as bad as you'd think, either. There's no hope of it running on a new system without writing new code, but there's not a lot of code to write. I've got it working on a bunch of systems.

Re:Just use Solaris

[dbIII]

C'mon! Solaris 10 will have..

Things like NFS on linux may still be crap in comparison the Solaris, but the wide range of drivers let you run linux on a wide variety of hardware. In a lot of situations linux is still a better choice - but when it comes down to it the same applications usually run on both.

Re:Just use Solaris

[WindBourne]

You know, 8 years ago, Solaris was on x86, and all the source code was released. Then Sun thought that they were winning. So they pulled the source code, and they pulled it off x86. Then they withered. Now, they ported back to x86 with a half ass port and license. Cool, that is their choice.

But 5 years ago, I told a friend of mine who is a solaris kernel hacker that Sun (just as you are a Sun employee) would go down for that and other reasons. But now, Sun will stay down due to people like you and McNealy. Learn some humility as well as some reasoning. Until your ZFS is out, it is worthless.

Back in Linux 2.0, I had extended ext2 with many of the capabilities that rfs 4.0 has now. Tsu rejected it, but liked it and suggested that I move it out of the filesystem and make it adopt on top. Made sense. rfs will do the same in the end. At that point, It think that Linux fs will be killing solaris.

Your in-house benchmark in networking showed that Solaris pre-10 was getting creamed by Linux 2.6, so many of the core ideas of Linux networking was adopted into Solaris 10. In fact, Solaris 10 was so late due to the rewriting of the network.

You may continue to act like a MS sales person from the mid 90's, but a number of OSs have fallen before true OSS systems. I suspect that Solaris will simply be another.

Re:Solutions in search of a problem

[mi]

Thanks for the informative reply, but it merely provides a workaround. kqueue offered a solution, but Linux could not just adapt it, it had to grow something else, that is, apparently, still not in the production kernels -- that's my grudge...

Also, last time I checked (about a year ago?) fam was, sadly, not using kqueue on FreeBSD. In fact, fam-2.6.9 on my FreeBSD-5.x box is using almost 10% of dual Xeon 450MHz right now... But that is a problem for fam-port maintainers.

Re:Solutions in search of a problem

[slamb]

Thanks for the informative reply, but it merely provides a workaround. kqueue offered a solution, but Linux could not just adapt it, it had to grow something else, that is, apparently, still not in the production kernels -- that's my grudge...

dnotify is in the production kernels and has been since...before 2.4.x, anyway. It's not as shiny as inotify, but it will do what you want.

Re:Just use Solaris

[JonAnderson]

I am a bit late to the party but what the hell. On bigger SPARCS Sun also have dynamic system domains which allow you to split the machine up physically into a subset of fault tolerant entities. Unlike LPARS/uPARS on P-series you also get electrical isolation. This coupled with zones gives you virtually as much granularity as you need. Unlike IBM's virtualization, Solaris Zones also work on single CPU X86 machines. Oh, and it's free.

Re:Gamers: Configurable USB Mouse Polling Rate!

[Jagasian]

Why hasn't the PC done it, while the Amiga did 20 years ago? Well, the Amiga was designed, while the PC as we know it today evolved, many times in a very ad-hoc manner. Similarly, compare a natural language such as English with one of the many psuedo natural languages like Lojban. Why are things this way? Legacy. PC's are popular because of legacy-technology reasons, and they are also flawed because of their support for this legacy technology. The same goes for natural languages like English, versus designed languages like Lojban.

Is IBM's Okay?

[Vagary]

It would be nice if the kernel had a bug tracker so I could see who's to blame for this stuff...

Re:Reiser 4?

[Pflipp]

Try to imagine that I *want* to use it.

Fixed in Tiger

[Macka]

ArsTechnia have done a stunning write up on changes in Tiger, and they report ....

"Thanks to the kernel hooks that make Spotlight so magically responsive, the Tiger Finder can no longer be surprised. It reflects file system changes instantly, regardless of their source." ... and then they have a Quicktime demo showing a finder view, and a Terminal (shell) view of the same directory with files created in the shell appearing in the Finder window.

Re:Fixed in Tiger

[Ford Prefect]

ArsTechnia have done a stunning write up on changes in Tiger

Yeah, I saw that too - I wondered about posting something to this thread, but didn't think anyone would read it. :-)

I wonder if the new Linux inotify stuff can be upgraded for use as the basis for Spotlight-style stuff...

Re:give it up.

[mi]

your code is broken, your OS is broken, and your API is broken.

Yeah, BSD is dying, is not it? :-)

NIH is not the reason. "totally broken" is the reason its not implemented.

If it were "totally broken", why was it "considered" in 2001 -- and rejected due to, supposedly, imperefections in implementation? Oops...

here's a hint: you'll only sigbus on a read if you pagefault.

Whatever. I'm waiting for Jamie Lokier to show me the exploit, that he claimed to have...