Slashdot Mirror


Linux Kernel 2.6.30 Released

diegocgteleline.es writes "Linux kernel 2.6.30 has been released. The list of new features includes NILFS2 (a new, log-structured filesystem), a filesystem for object-based storage devices called exofs, local caching for NFS, the RDS protocol (which delivers high-performance reliable connections between the servers of a cluster), a new distributed networking filesystem (POHMELFS), automatic flushing of files on renames/truncates in ext3, ext4 and btrfs, preliminary support for the 802.11w drafts, support for the Microblaze architecture, the Tomoyo security MAC, DRM support for the Radeon R6xx/R7xx graphic cards, asynchronous scanning of devices and partitions for faster bootup, the preadv/pwritev syscalls, several new drivers and many other small improvements."

2 of 341 comments (clear)

  1. Thottle Capability by kenp2002 · · Score: 5, Interesting

    Still no support for SLA\95% throttling of processing power allocated to VMs.

    Case in Point:

    VM 1 : 80% Of processor utilization
    VM 2 : 20% of processor utilization
              : Can borrow up to 20% of VM1's allocation
              : if unused.

    The scheduler does great things don't get me wrong but when it comes to provisioning systems for various clients some want a garuntee on the level of processing power that is available at any time. This is true in test systems as well where yout Integration, Acceptance, and Performance virtual environments may share Bare Iron with some production VMs.

    Now this is old hat easy with mainframes (MIP allocation\weights between LPARS\SYSPLEX) but with more and more focus on VMs and hosted VMs SLAs on processing power is becoming more of an issue.

    Nice values are not enough when writing contracts... Great work Linux team but could we get some more granular control over VM provisioning with SLAs in mind? Yeah we can build user space systems to help manage VMs but kernel level provisioning and auditing is something we need with KVM. Gotta have the reports to show the customer you are meeting the agreeded upon SLAs.

    And for my own personal use, I'd love to be able to throttle a dos 6.22 VM to 486 speeds so some of those ancient programs can be ran for historical purposes. (Without bombing the processor with dummy NOP and other MOSLO crap so we keep our power consumption down.)

    Just some musings as Linux rolls along...

    --
    -=[ Who Is John Galt? ]=-
  2. Trusted Computing Slithered In? by Bob9113 · · Score: 5, Interesting

    Integrity Management Architecture

    Contributor: IBM

    Recommended LWN article: http://lwn.net/Articles/227937/

    The Trusted Computing Group(TCG) runtime Integrity Measurement Architecture(IMA) maintains a list of hash values of executables and other sensitive system files, as they are read or executed. If an attacker manages to change the contents of an important system file being measured, we can tell. If your system has a TPM chip, then IMA also maintains an aggregate integrity value over this list inside the TPM hardware, so that the TPM can prove to a third party whether or not critical system files have been modified.

    From the recommended article, the key dilemma:

    There are clear advantages to a structure like this. A Linux-based teller machine, say, or a voting machine could ensure that it has not been compromised and prove its integrity to the network. Administrators in charge of web servers can use the integrity code in similar ways. In general, integrity management can be a powerful tool for people who want to be sure that the systems they own (or manage) have not be reconfigured into spam servers when they weren't looking.

    The other side of this coin is that integrity management can be a powerful tool for those who wish to maintain control over systems they do not own. Should it be merged, the kernel will come with the tools needed to create a locked-down system out of the box. As these modules get closer to mainline confusion, we may begin to see more people getting worried about them. Quite a few kernel developers may oppose license terms intended to prevent "tivoization," but that doesn't mean they want to actively support that sort of use of their software. Certainly it would be harder to argue against the shipping of locked-down, Linux-based gadgets when the kernel, itself, provides the lockdown tools.

    OK, maybe this is overdramatic, but trading freedom from third-party oversight through trusted computing for the security of first-party oversight through trusted computing seems a little like:

    "They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." - Benjamin Franklin

    But I can see both sides. Pondering... what are your thoughts?