Beta
×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

2.6.19 Linux Kernel Released

kdawson posted more than 7 years ago | from the come-and-get-it dept.

Operating Systems 51

diegocgteleline.es writes, "After two months, Linux 2.6.19 has been released. It includes the clustering GFS2 filesystem, Ecryptfs, the first developer-oriented version of EXT4, support for the Atmel AVR32 architecture, sleepable RCU, improvements for NUMA-based systems, an "-o flush" mount option aimed at FAT-based hotpluggable media devices (mp3), physical CPU hotplug and memory hot-add in x86-64, support for compiling x86 kernels with the GCC stack protection, and many other things. You can check the full list of changes in LinuxChanges."

cancel ×

51 comments

Sorry! There are no comments related to the filter you selected.

This release has been pronounced perfect (1, Offtopic)

smitty_one_each (243267) | more than 7 years ago | (#17052948)

This release has been pronounced perfect
It's one of those rare "perfect" kernels. So if it doesn't happen to compile with your config (or it does compile, but then does unspeakable acts of perversion with your pet dachshund), you can rest easy knowing that it's all your own d*mn fault, and you should just fix your evil ways.
Note the marketing prowess on display.
Sex sells, even if it's just an allusion to the "lookin' for love in all the ronngg places" variety.
Stand by for the premiere of 2.6.20 on YouTube, where Linus, speech slurring from too many milkshakes, makes a poopy joke at a puppet show while a cel phone camera is accidentally pointed at him.

Re:This release has been pronounced perfect (0)

Anonymous Coward | more than 7 years ago | (#17054762)

Wow, you really need to lighten up.

Re:This release has been pronounced perfect (0)

Anonymous Coward | more than 7 years ago | (#17055008)

Well, it was intended to be funny, but survey seems to say it came off stupid. The perils of first post.

Re:This release has been pronounced perfect (0)

Anonymous Coward | more than 7 years ago | (#17059776)

Sorry, mistook it for a troll, that guy doesn't seem to be around.

Atmel AVR32 (1)

mattnuzum (839319) | more than 7 years ago | (#17053054)

I've never heard of it... a quick peek on their website shows [atmel.com] :
For example, the AVR32 can execute quarter-VGA MPEG4 decoding at 30 frames per second (fps) running at just 100 MHz while comparable architectures require 260 MHz and more to decode the same movie stream.
Sounds sweet... how do I get one? Free samples?

Re:Atmel AVR32 (2, Informative)

porkThreeWays (895269) | more than 7 years ago | (#17053206)

The Atmel AVR butterfly is an insanely cheap development platform (20 dollars). It comes with more things than you can shake your fist at. They are also extremely popular and sell out quick so good luck finding one! Speaking of... what do they mean by "AVR support"? They are true microcontrollers with very low clock speeds and very low amounts of storage and memory. Do they mean linux can now run natively on an ATMEGA in the same manner it runs on say a gumstix?! SWEET!!!!

Re:Atmel AVR32 (1)

porkThreeWays (895269) | more than 7 years ago | (#17053252)

Nevermind... it supports the 32bit arch not the 8bit one. BIG difference.

Re:Atmel AVR32 (1)

mattnuzum (839319) | more than 7 years ago | (#17053298)

They are true microcontrollers with very low clock speeds and very low amounts of storage and memory. Do they mean linux can now run natively on an ATMEGA

No, it looks like this is a new platform. Something different, to compete with ARM - you can tell because they talk about core licensing and IP in the description (ARM's biggest weakness, in some peoples opinion). The benefit here appears to be more horsepower per clock cycle, which should lower power consumptions (more MHz == more power usually).

I can't wait to see!

Re:Atmel AVR32 (4, Informative)

plcurechax (247883) | more than 7 years ago | (#17054050)

Most people are familiar with the 8-bit Atmel AVR [atmel.com] microcontrollers, similar to the Microchip 8-bit PIC [microchip.com] microcontollers. The AVR32 [atmel.com] is a 32-bit microcontoller. I believe it was developed by Atmel to be a easy to mirgrate to target to compete with Freescale's 32-bit [freescale.com] offerings, and various manufacturers' low cost 32-bit ARM [arm.com] processors.

Atmel AVR32 not AVR butterfly (2, Informative)

FuzzyDaddy (584528) | more than 7 years ago | (#17054466)

The AVR butterfly is from the 8 bit line of microcontrollers. The AVR32 is a much more power beast - the dev kit [atmel.com] sells for $499 ($544 at Digikey [digikey.com] ).

Don't get me wrong, I love the AVR microcontrollers - but we're talking a few K of RAM, 8 to 128K of Flash for the program, a smattering of EEPROM and a top speed of 16MHz. I would be impressed if you could run the Linux kernel on that.

Re:Atmel AVR32 (4, Informative)

drinkypoo (153816) | more than 7 years ago | (#17053258)

You can get the starter kit from Digi-Key here [digikey.com] . I only knew about this because I bought the AVR starter kit (not AVR32) which was dramatically cheaper - $100 rather than $550. Not sure if this even comes with an AVR32 chip, probably not, but they have that too (133MHz for $37.63 [digikey.com] .) Not sure how hard these are to program, but the normal AVR has support for serial in-system programming and if you know your way around an AVR you might be able to use an AVR to make an ISP chip for an AVR32. :)

Re:Atmel AVR32 (0)

IthnkImParanoid (410494) | more than 7 years ago | (#17054700)

The AVR starter kit for $79 comes with an 8 bit processor, so I'm not sure you can take the AVR32 (a 32 bit processor) and expect it to work with the older board. I'm not a big micro-controller hobbiest/programmer, though. Would be nice if you could. :)

Re:Atmel AVR32 (1)

drinkypoo (153816) | more than 7 years ago | (#17055108)

No, that's not what I'm saying. I'm quite sure you're right that you can't use the AVR starter kit with the AVR32. However, the AVR can be programmed with a fairly simple in-system programmer, using a serial interface between the programmer and the AVR. All you need is power, and I think you tie some line on the chip high to perform a write enable. What I'm saying is that if the AVR32 has the same in-system programming (ISP) functionality, it might be possible to make an ISP using a normal AVR in order to program the AVR32. I spent $100 a while back for the AVR starter kit with the 8 bit AVR; I also bought an additional AVR and the "Butterfly" demo product for which you get both code and schematics. I've hardly done anything with it, though, certainly nothing useful.

Re:Atmel AVR32 (0)

Anonymous Coward | more than 7 years ago | (#17053300)

You might be able to sample them if you can convince them that it's worth their while.

Or buy them from a parts supplier. You might want a dev board too.

GFS2 (2, Interesting)

C_Kode (102755) | more than 7 years ago | (#17053162)

Anyone know if any reviews of GFS2 in actual use compared to other clustered filesystems?

Hotplugging CPU and Memory?!?!? (1)

StarWreck (695075) | more than 7 years ago | (#17053488)

All I can say is :-O

Re:Hotplugging CPU and Memory?!?!? (1)

bcmm (768152) | more than 7 years ago | (#17053804)

AFAIK, CPU hotplugging is for special hardware, and always involves more than one CPU.

Re:Hotplugging CPU and Memory?!?!? (2, Informative)

Abcd1234 (188840) | more than 7 years ago | (#17055158)

Meh, enterprise platforms like Solaris has been doing this for years. If you want to do real HA, it's a very important feature to have.

Re:Hotplugging CPU and Memory?!?!? (1)

fimbulvetr (598306) | more than 7 years ago | (#17057560)

Except that real HA doesn't come with SPARC hardware because they can't even put ECC on the cpu's cache. This generally causes a reboot which introduces the potential for dataloss. Sometimes it will just be an error though, which only occasionally causes dataloss.

HA? Sparc procs? Not bloodly likely.

Re:Hotplugging CPU and Memory?!?!? (1)

dasunt (249686) | more than 7 years ago | (#17062280)

This is somewhat off-topic, but I killed an older Sparc running Solaris 10 within a few minutes of installing.

Someone I know needed to test out a program on Solaris 10/Sparc. Since we had a smaller sparc (I believe it was the E4000) not being used, I installed Solaris 10 on it, doing the default install.

Then I copied the code over, and uncompressed it in /tmp.

The machine died.

Ah ha, you are going to say -- you ran out of disk space in /tmp, and the machine couldn't make the temporary files it needed.

Kinda.

The default install I did made the /tmp partition out of a ramdisk. So when I filled up /tmp, I starved the machine of memory.

Whoopsie.

(This is probably why the other sparcs are running Linux.)

In Solaris's defense, I know very little about the OS. I still find it humorous that I managed to bring an enterprise machine to its knees accidentally.

Re:Hotplugging CPU and Memory?!?!? (1)

diegocgteleline.es (653730) | more than 7 years ago | (#17057734)

notice that this is *physical* hotplug, you already were able to enable/disable CPUs at runtime with /sys/devices/system/cpu/cpu1/online (if you enable CPU hotplugging)

Sounds like fun (2, Funny)

i_should_be_working (720372) | more than 7 years ago | (#17053808)

From TF post:
It's one of those rare "perfect" kernels. So if it doesn't happen to compile with your config (or it does compile, but then does unspeakable acts of perversion with your pet dachshund), you can rest easy knowing that it's all your own d*mn fault, and you should just fix your evil ways.

You could send me and the kernel mailing list a note about it anyway, of course. (And perhaps pictures, if your dachshund is involved. Not that we'd be interested, of course. No. Just so that we'd know to avoid it next time).


So.. Who has a dachshund and a camera? And what does a kernel doing unspeakable acts of perversion with a dog look like anyway?

Re:Sounds like fun (5, Funny)

Anonymous Coward | more than 7 years ago | (#17054530)

And what does a kernel doing unspeakable acts of perversion with a dog look like anyway?

i'd describe it but, it's unspeakable.

this linux thingy must be taking off... (4, Funny)

advocate_one (662832) | more than 7 years ago | (#17053886)

there's a torrent of it on torrentspy...

Do you have no shame? (5, Funny)

Kadin2048 (468275) | more than 7 years ago | (#17054882)

Dude, pirating Linux off of bittorrent ... how low can you get?

It's people like you that make "Linux Genuine Advantage" necessary.

Re:this linux thingy must be taking off... (1)

howlingmadhowie (943150) | more than 7 years ago | (#17055310)

anyone want to have a go at justifying the thought that just occurred to me, that the release of a new linux kernel is probably more important than the release of vista?

oh btw, totally of topic but i've just realised that if you search for something in firefox 2.0 it doesn't give you the choice of moving to the next result in the text like in firefox 1.5. i imagine this is a simple setting in about:config. anybody know which?

Re:this linux thingy must be taking off... (1)

nonsequitor (893813) | more than 7 years ago | (#17055740)

I'd say the release of Vista is less relevant than the release of Duke Nukem Forever, but more relevant than another point release of the Linux Kernel.

A better faster linux kernel is a dog bites man story.

Microsoft finally getting another OS out the door 5 years after Windows XP after countless delays and feature killfests is more in the realm of man bites dog.

firefox 2.0 find vs quick find (1)

ville (29367) | more than 7 years ago | (#17055994)

Howdy,

If you hit ctrl-f you get find with the [x]/next/previous/highlight all/match case widgets. If you hit / you activate quick find functionality which doesn't have those. No idea if there's a config setting to force quick find to have those widgets as well. // ville

Re:this linux thingy must be taking off... (1)

SiChemist (575005) | more than 7 years ago | (#17057584)

After you type the text you want to find, hit F3 to advance to the next instance of it.

TPM encryption (4, Interesting)

Pausanias (681077) | more than 7 years ago | (#17054136)

Very interesting how ecryptfs [lwn.net] uses the TPM module for encryption. While there is plenty to worry about regarding treacherous computing [wikipedia.org] , it is nice to see that the TPM can be put to uses that actually bolster privacy. This still does not prevent a possible future dystopia [gnu.org] , but it still goes to show that devices such as TPM are not necessarily "pure evil."

Re:TPM encryption (0)

Anonymous Coward | more than 7 years ago | (#17054452)

Storing the key in a TPM is not making it safe... where did you get that idea? Store it on a USB key, and make sure you take it out when you aren't using it.

THAT IS SAFER. Storing it in the TPM doesn't make it safe unless the rest of your machine is running locked down software -- which is exactly where the abuse of Trusted Computing comes into it.

Re:TPM encryption (1)

swillden (191260) | more than 7 years ago | (#17062134)

Storing the key in a TPM is not making it safe... where did you get that idea? Store it on a USB key, and make sure you take it out when you aren't using it.

That is incorrect. The TPM provides secure storage that a USB key cannot.

The thing that makes a TPM secure is the way that the secrets it stores can be bound to a particular system configuration. The basic idea is that each piece of software in the boot process feeds the next piece to the TPM before loading it. For example, the BIOS feeds the MBR to the TPM, and then loads and executes it; the MBR feeds the boot loader to the TPM, then loads and executes it; the boot loader feeds the kernel to the TPM, then loads and executes it. And so on.

The TPM simply hashes all of this data that is fed into it, storing the running hash in a control register. Now suppose you generate an AES/256 key, encrypt your ultra-secret tinfoil hat design with it and then tell the TPM to store it. The TPM will XOR the current control register contents with its internal master key (a symmetric key that is generated inside the TPM and which the TPM will never divulge) and uses the result to encrypt your AES key, which can then be stored on your hard drive.

This means that in order for anyone to retrieve your AES key, they exact same sequence of bits has to first be fed into the TPM (barring some fairly serious hardware hacking). Assuming the BIOS does its job and none of the other components have exploitable weaknesses (note: *NOT* a trivial assumption), the only way to do that is to boot the system into the same state it was in when the AES key was stored. Assuming that your OS has no exploitable weaknesses (ha!) and properly verifies your identity prior to retrieving the AES key from the TPM, you can be certain your key is safe.

For even better security, use the USB key in addition to the TPM. Cryptographically split your AES key into two halves, store one on the USB key and have the TPM store the other. Then to retrieve the key, and the tinfoil hat design, you need to have the same TPM, on the same machine, booted into the same configuration, *and* have the USB key.

Storing it in the TPM doesn't make it safe unless the rest of your machine is running locked down software -- which is exactly where the abuse of Trusted Computing comes into it.

Also wrong. Your machine doesn't have to be running "locked down software", it has to be running the software it was running when the key was bound to the TPM state. That software can be anything you want. Of course, there are some companies out there who want it to be what *they* want, not what you want, but that's a separate issue.

The TPM is simply a tool, and it's a very good one. The effect of its use depends upon its user.

Re:TPM encryption (1)

arose (644256) | more than 7 years ago | (#17062556)

Don't know about you, but I want my data to be recoverable in the event of hardware failure.

Re:TPM encryption (1)

swillden (191260) | more than 6 years ago | (#17064488)

Don't know about you, but I want my data to be recoverable in the event of hardware failure.

Security engineering, like all engineering, is all about tradeoffs.

That said, you can arrange for the data to be recoverable. The best way is to securely back up the key that is bound to the TPM. There are a variety of mechanisms for doing that. Keep in mind that TPMs do not do bulk encryption well, so the actual data encryption keys are available to the operating system for performing operations using the main CPU. This means that the software that uses the keys can be written to export them in any way you like. The TPM's ability to authenticate itself as a legitimate TPM makes it easy to design and implement a protocol for securely exporting sensitive keys to another machine and binding them to its TPM. Other options are all of the traditional key management key backup techniques.

Note that none of this is easy. Security isn't easy. Binding a key to a particular TPM device and system state means that not only does broken hardware potentially eliminate your access to your data, but so does something as simple as installing a new kernel, or any other piece of software that is hashed by the TPM as part of the system state. Installing new software becomes a rather complicated and error-prone process. You essentially have to:

  1. Install the new software without removing the old.
  2. Boot into the new state, generate a transport key pair, bind the private key to the current TPM state and have the TPM sign the public key to authenticate the transport key to itself.
  3. Boot back into the old state, retrieve the encryption key(s) you need to move and encrypt them with the tranport key after validating the transport key and validating the current user's authority to request such a key export operation.
  4. Boot back into the new state and decrypt and bind the encryption keys to the new TPM state.

Essentially, just installing new software requires a key export process very similar to what you'd use to back up the keys to a different TPM.

These complexities, as well as questions about exactly what needs to be hashed by the TPM, are why we don't already have TPM-enabled Linux distributions. They're coming, but they require a lot of hard work. To really make them secure, we not only need the TPM support, but we also need mandatory access control mechanisms to ensure that access to the TPM is tightly controlled. Making a high-security system out of a general-purpose PC running a general-purpose OS is non-trivial at best. It's well worth the effort, though, IMO.

Re:TPM encryption (0)

Anonymous Coward | more than 7 years ago | (#17063926)

That is incorrect. The TPM provides secure storage that a USB key cannot

Secure storage that a USB key that is not kept with the PC cannot. Sure it does. TPMs, in your scenario, do nothing beyond lock data to a machine... not something that is valuable to 99.99999% of the population, and considering the abuses it allows... not valuable at all.

And yes... you do need to be running locked down signed software in order to ensure that TPM stored keys are safe. You were just flat out lying about that.

Re:TPM encryption (1)

swillden (191260) | more than 7 years ago | (#17064280)

Secure storage that a USB key that is not kept with the PC cannot.

But that USB key must be kept somewhere, and unless you have a safe to keep it in, it's never going to be very secure.

TPMs, in your scenario, do nothing beyond lock data to a machine... not something that is valuable to 99.99999% of the population

Nonsense. It's extremely useful to lots of the population. Not really home users, but businesses have *lots* of uses for it. I design and build high-security applications for a living, primarily around smart cards and PCI-based crypto coprocessors, and TPMs provide a solution to dozens of otherwise insoluble (actually, too-expensive-to-solve) problems.

And yes... you do need to be running locked down signed software in order to ensure that TPM stored keys are safe. You were just flat out lying about that.

I really shouldn't even respond to a statement like this, especially from an AC, but you're dead wrong. What I described is exactly how TPMs work, and there are already a couple of projects to build high-security Linux systems that make use of a TPM in this way. Signing of software is irrelevant. I'm not sure what you mean by "locked down" software. In order to get useful security out of a TPM you do have to ensure that your software is sufficiently secure that an unauthorized person can't use your TPM when the machine is booted into the correct configuration. That sort of locking down is necessary, and very hard to achieve.

If you want to understand, in great detail, exactly what TPM's do, the specs [trustedcom...ggroup.org] are online. If signed, "locked down" software is really required, by all means point out the section of the spec that describes it.

Re:TPM encryption (0)

Anonymous Coward | more than 7 years ago | (#17055170)

I think it was mandated by pentagon, and congress has been thinking about it too. In order to make Linux compatible with these platforms, it will have to support some of these features. But I don't seeing it abused on the Linux end at least.

Re:TPM encryption (4, Interesting)

Marillion (33728) | more than 7 years ago | (#17055824)

TPM is neither good nor bad

How operating systems and applications use TPM can be good or evil

In all that I've read about TPM, I've concluded that TPM is not much more than a glorified hardware based public/private key management system. The reference implementations I seen attach to the same slow hardware buses that PS/2 keyboard and mice sit. There is not enough bandwidth on that bus to encrypt/decrypt whole disks in real time.

Re:TPM encryption (1)

gillbates (106458) | more than 7 years ago | (#17057856)

Except that TPM could easily hide weaknesses, backdoors, or worse from the user. Furthermore, the nature of TPM would prevent the user from ever discovering said "features".

No, not pure evil. But still not trustworthy, either. This is the kind of thing the NSA would love to have in every computer.

Really a shame (0, Funny)

Anonymous Coward | more than 7 years ago | (#17054192)

It's really a shame they never wrote Linux right the first time. It would save a lot of people the difficulty of having to upgrade their systems all the time.

Re:Really a shame (1)

fimbulvetr (598306) | more than 7 years ago | (#17057596)

We're still waiting for your kernel. Just release it when it's perfect, that's fine with us.

Re:Really a shame (1)

Jesus_666 (702802) | more than 6 years ago | (#17065362)

They certainly didn't make that mistake with Hurd.

Slashdot anti-Linux bias (4, Funny)

commodoresloat (172735) | more than 7 years ago | (#17055646)

Once again, slashdot reveals its pro-Microsoft, anti-Linux bias. Two stories, one about a new Linux kernel release, and one about Dvorak commenting on a not-quite-as-new Windows release. Which one gets a full story on the front page? I'm getting tired of all the Linux-bashing on this site.

Re:Slashdot anti-Linux bias (2, Funny)

BiggyP (466507) | more than 7 years ago | (#17060980)

Has anyone read that changes document yet?
First item under USB is Add Playstation 2 Trance Vibrator driver [kernelnewbies.org]

Is this the first sex toy to be officially supported by the Linux kernel?! Surely that's enough for front page news.

Re:Slashdot anti-Linux bias (1)

dylan_- (1661) | more than 7 years ago | (#17063876)

Is this the first sex toy to be officially supported by the Linux kernel?! Surely that's enough for front page news.
Did you submit this as a story? You've even got the traditional slashdot question to end on!

Re:Slashdot anti-Linux bias (1)

n3tcat (664243) | more than 7 years ago | (#17062156)

I believe you missed the point of the Vista article. They make Dvorak's articles all big and obvious for two reasons. First, people who enjoy his articles haven't yet figured out that those miniature headlines are actually links to full articles. Second, they want to make sure that everyone gets a regulated selection of a couple of sentences from his garbage articles to prevent accidental ingestion of an entire screen's worth before realizing who the author is.

Re:Slashdot anti-Linux bias (1)

DeviousDevil (1021597) | more than 7 years ago | (#17062752)

You are seriously joking right? SlashDot and the majority of it's readers are the most anti-Microsoft people any where. Whenever there is an article on here about MS it immediately gets jumped on by the Linux/Unix/OSX fan boys and ripped to shreads. In fact if MS wiped out world hunger most people on here would still not have a good comment to add to the post. But I'm sure your post was a joke, just a very bad one.

Re:Slashdot anti-Linux bias (1)

dargaud (518470) | more than 7 years ago | (#17063464)

Your comment was probably intended as funny, but if not, display depends on your settings. On mine, the front page wsa Vista, while the kernel news was hidden on the Linux page.

[FWIW] cryptfs (1)

Black Parrot (19622) | more than 7 years ago | (#17058596)

FWIW, I just started using the dm-crypt based cryptfs on my Gentoo system over the past week. (I'm actually running it on top of LVM, which in turn runs on top of the kernel's RAID1.)

Pretty easy to set up, and no trouble so far, but annoying that it asks for the passphrase for each encrypted volume twice during boot, and and doesn't fail gracefully if you mistype anything.

*sniff* (1)

HomelessInLaJolla (1026842) | more than 7 years ago | (#17061514)

and I don't even have a system available that I can try it out on.

This homeless thing can be real inconvenient.

Vista? (2, Funny)

Marton (24416) | more than 7 years ago | (#17063170)

Way to steal Microsoft's thunder!
Check for New Comments
Slashdot Login

Need an Account?

Forgot your password?

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>