Slashdot Mirror

Linus Torvalds has announced the general availability of v4.20 of the Linux kernel. In a post to the Linux Kernel Mailing List, Torvalds said that there was no point in delaying the release of the latest stable version of the kernel just because so many people are taking a break for the holiday season. From a report: He says that while there are no known issues with the release, the shortlog is a little longer than he would have liked. However "nothing screams 'oh, that's scary'", he insists. The most notable features and changes in the new version includes: New hardware support! New hardware support includes bringing up the graphics for AMD Picasso and Raven 2 APUs, continued work on bringing up Vega 20, Intel has continued putting together its Icelake Gen 11 graphics support, there is support for the Hygon Dhyana CPUs out of China based upon AMD Zen, C-SKY 32-bit CPU support, Qualcomm Snapdragon 835 SoC enablement, Intel 2.5G Ethernet controller support for "Foxville", Creative Sound Blaster ZxR and AE-5 sound card support, and a lot of smaller additions.

Besides new hardware support when it comes to graphics processors, in the DRM driver space there is also VCN JPEG acceleration for Raven Ridge, GPUVM performance work resulting in some nice Vulkan gaming boosts, Intel DRM now has full PPGTT support for Haswell/IvyBridge/ValleyView, and HDMI 2.0 support for the NVIDIA/Nouveau driver. On the CPU front there are some early signs of AMD Zen 2 bring-up, nested virtualization now enabled by default for AMD/Intel CPUs, faster context switching for IBM POWER9, and various x86_64 optimizations. Fortunately the STIBP work for cross-hyperthread Spectre V2 mitigation was smoothed out over the release candidates that the performance there is all good now.

Btrfs performance improvements, new F2FS features, faster FUSE performance, and MDRAID improvements for RAID10 round out the file-system/storage work. One of the technical highlights of Linux 4.20 that will be built up moving forward is the PCIe peer-to-peer memory support for device-to-device memory copies over PCIe for use-cases like data going directly from NICs to SSD storage or between multiple GPUs.

An anonymous reader writes: Linus Torvalds has released Linux 4.16. Linux 4.16 integrates more of the VirtualBox guest drivers into the kernel, provides AMDGPU DC multi-display synchronization, continues with mitigation improvements for Spectre and Meltdown mitigation, tightens up access to /dev/mem by default, and many other improvements and changes.

An anonymous reader writes: On the Linux Kernel Mailing List, Linus Torvalds ended up responding to a long-time kernel developer (and former Intel engineer) who'd been describing a new microcode feature addressing Indirect Branch Restricted Speculation "where a future CPU will advertise 'I am able to be not broken' and then you have to set the IBRS bit once at boot time to *ask* it not to be broken."

Linus calls it "very much part of the whole 'this is complete garbage' issue. The whole IBRS_ALL feature to me very clearly says 'Intel is not serious about this, we'll have a ugly hack that will be so expensive that we don't want to enable it by default, because that would look bad in benchmarks'. So instead they try to push the garbage down to us. And they are doing it entirely wrong, even from a technical standpoint. I'm sure there is some lawyer there who says 'we'll have to go through motions to protect against a lawsuit'. But legal reasons do not make for good technology, or good patches that I should apply."
Later Linus says forcefully that these "complete and utter garbage" patches are being pushed by someone "for unclear reasons" -- and adds another criticism. The whole point of having cpuid and flags from the microarchitecture is that we can use those to make decisions. But since we already know that the IBRS overhead is huge on existing hardware, all those hardware capability bits are just complete and utter garbage. Nobody sane will use them, since the cost is too damn high. So you end up having to look at "which CPU stepping is this" anyway. I think we need something better than this garbage.

An anonymous reader writes: On the Linux Kernel Mailing List, Linus Torvalds ended up responding to a long-time kernel developer (and former Intel engineer) who'd been describing a new microcode feature addressing Indirect Branch Restricted Speculation "where a future CPU will advertise 'I am able to be not broken' and then you have to set the IBRS bit once at boot time to *ask* it not to be broken."

Linus calls it "very much part of the whole 'this is complete garbage' issue. The whole IBRS_ALL feature to me very clearly says 'Intel is not serious about this, we'll have a ugly hack that will be so expensive that we don't want to enable it by default, because that would look bad in benchmarks'. So instead they try to push the garbage down to us. And they are doing it entirely wrong, even from a technical standpoint. I'm sure there is some lawyer there who says 'we'll have to go through motions to protect against a lawsuit'. But legal reasons do not make for good technology, or good patches that I should apply."
Later Linus says forcefully that these "complete and utter garbage" patches are being pushed by someone "for unclear reasons" -- and adds another criticism. The whole point of having cpuid and flags from the microarchitecture is that we can use those to make decisions. But since we already know that the IBRS overhead is huge on existing hardware, all those hardware capability bits are just complete and utter garbage. Nobody sane will use them, since the cost is too damn high. So you end up having to look at "which CPU stepping is this" anyway. I think we need something better than this garbage.

Every page on LKML.org is currently displaying this error message along with a picture of Flits the cat. What started out as a power outage while I was on vacation (leading to the computer hosting the backend of this site being unable to boot) became a larger issue as the mainboard in that computer appears to be broken.

Not wanting to let you wait for a spare part to arrive, I'm currently (while being assisted by our cat Flits) busy copying over all data to a VPS, and getting things working from there. The rsync is progressing slowly, having copied over the first 50% in three hours (at 14:30 CET). Please check back later for status updates.

troublemaker_23 shares an article from ITWire: Linux creator Linus Torvalds has had some harsh words for Intel in the course of a discussion about patches for two bugs that were found to affect most of the company's processors... Torvalds was clearly unimpressed by Intel's bid to play down the crisis through its media statements, saying: "I think somebody inside of Intel needs to really take a long hard look at their CPUs, and actually admit that they have issues instead of writing PR blurbs that say that everything works as designed... Or is Intel basically saying 'we are committed to selling you shit forever and ever, and never fixing anything'?" he asked. "Because if that's the case, maybe we should start looking towards the ARM64 people more."
Elsewhere Linus told ZDNet that "there's no one number" for the performance drop users will experience after patches. "It will depend on your hardware and on your load. I think 5 percent for a load with a noticeable kernel component (e.g. a database) is roughly in the right ballpark. But if you do micro-benchmarks that really try to stress it, you might see double-digit performance degradation. A number of loads will spend almost all their time in user space, and not see much of an impact at all."

An anonymous reader quotes a report from TechCrunch: In a blog post published minutes ago, Google's Security team announced what they have done to protect Google Cloud customers against the chip vulnerability announced earlier today. They also indicated their Project Zero team discovered this vulnerability last year (although they weren't specific with the timing). The company stated that it informed the chip makers of the issue, which is caused by a process known as "speculative execution." This is an advanced technique that enables the chip to essentially guess what instructions might logically be coming next to speed up execution. Unfortunately, that capability is vulnerable to malicious actors who could access critical information stored in memory, including encryption keys and passwords. According to Google, this affects all chip makers, including those from AMD, ARM and Intel (although AMD has denied they are vulnerable). In a blog post, Intel denied the vulnerability was confined to their chips, as had been reported by some outlets. The Google Security team wrote that they began taking steps to protect Google services from the flaw as soon as they learned about it.

According to The Register, "A fundamental design flaw in Intel's processor chips has forced a significant redesign of the Linux and Windows kernels to defang the chip-level security bug." From the report: Programmers are scrambling to overhaul the open-source Linux kernel's virtual memory system. Meanwhile, Microsoft is expected to publicly introduce the necessary changes to its Windows operating system in this month's Patch Tuesday: these changes were seeded to beta testers running fast-ring Windows Insider builds in November and December. Crucially, these updates to both Linux and Windows will incur a performance hit on Intel products. The effects are still being benchmarked, however we're looking at a ballpark figure of five to 30 per cent slow down, depending on the task and the processor model. More recent Intel chips have features -- specifically, PCID -- to reduce the performance hit. Similar operating systems, such as Apple's 64-bit macOS, will also need to be updated -- the flaw is in the Intel x86 hardware, and it appears a microcode update can't address it. It has to be fixed in software at the OS level, or buy a new processor without the design blunder. Details of the vulnerability within Intel's silicon are under wraps: an embargo on the specifics is due to lift early this month, perhaps in time for Microsoft's Patch Tuesday next week. Indeed, patches for the Linux kernel are available for all to see but comments in the source code have been redacted to obfuscate the issue. The report goes on to share some details of the flaw that have surfaced. "It is understood the bug is present in modern Intel processors produced in the past decade," reports The Register. "It allows normal user programs -- from database applications to JavaScript in web browsers -- to discern to some extent the contents of protected kernel memory. The fix is to separate the kernel's memory completely from user processes using what's called Kernel Page Table Isolation, or KPTI."

The former Executive Director of the Free Software Foundation -- and Slashdot user #41121 -- contacted Slashdot with this announcement. bkuhn -- now president of the Software Freedom Conservancy -- writes: Software Freedom Conservancy, home of the GPL Compliance Project for Linux Developers, publicly applauded today the proposal of the Linux Kernel Enforcement Statement, which adds a per-copyright-holder-opt-in additional permission to the termination provisions of Linux's GPLv2-only license.
It apparently addresses a developer who "made claims based on ambiguities in the GPL-2.0 that no one in our community has ever considered part of compliance," according to a statement from some of the kernel developers who drafted the statement. While the kernel community has always supported enforcement efforts to bring companies into compliance, we have never even considered enforcement for the purpose of extracting monetary gain... [W]e are aware of activity that has resulted in payments of at least a few million Euros. We are also aware that these actions, which have continued for at least four years, have threatened the confidence in our ecosystem. Because of this, and to help clarify what the majority of Linux kernel community members feel is the correct way to enforce our license, the Technical Advisory Board of the Linux Foundation has worked together with lawyers in our community, individual developers, and many companies that participate in the development of, and rely on Linux, to draft a Kernel Enforcement Statement to help address both this specific issue we are facing today, and to help prevent any future issues like this from happening again. It adopts the same termination provisions we are all familiar with from GPL-3.0 as an Additional Permission giving companies confidence that they will have time to come into compliance if a failure is identified.

An anonymous reader quotes ZDNet: If you know anything about Linus Torvalds, you know he's the mastermind and overlord of Linux. If you know him at all well, you know he's also an enthusiastic scuba diver and author of SubSurface, a do-it-all dive log program. And, if you know him really well, you'd know, like many other developers, he loves gadgets. Now, he's starting his own gadget review site on Google+: Working Gadgets...

"[W]hile waiting for my current build to finish, I decided to write a note about some of the gadgets I got that turned out to work, rather than all the crazy crap that didn't. Because while 90% of the cool toys I buy aren't all that great, there's still the ones that actually do live up to expectations. So the rule is: no rants. Just good stuff. Because this is about happy gadgets."
So far Linus has reviewed an automatic cat litter box, a scuba diving pressure regulator, and a Ubiquiti UniFi Wi-Fi access point that complements his Google WiFi mesh network.

Linus will be great at this. Just last week I saw him recommending a text editor.

Long-time Slashdot reader jawtheshark writes: In a recent Linux Kernel Mailing List post, Linux Torvalds finishes his mail with a little poke towards a certain init system. It is a very faint criticism, compared to his usual style. While Linus has no direct influence on the "choices" of distro maintainers, his opinion is usually valued.
In a discussion about how to set rlimit default values for setuid execs, Linus concluded his email by writing, "And yes, a large part of this may be that I no longer feel like I can trust "init" to do the sane thing. You all presumably know why."

An anonymous reader writes: The Linux 4.6-rc1 kernel has been released. New to the Linux 4.6 kernel are a significant number of new features including NVIDIA GeForce GTX 900 open-source 3D support when using the closed-source firmware files, Dell XPS 13 Skylake laptop support, a fix for laptops that were limiting their own performance due to incorrectly thinking they were overheating, AHCI runtime power management support, Intel graphics power management features enabled by default, a new file-system (OrangeFS), and a range of other improvements.

prisoninmate writes: Yes, you're reading it right, after being in development for the past two months, Linux kernel 4.5 is finally here in its final production version. It is internally dubbed "Blurry Fish Butt" and received a total of seven RC builds since January 25, 2016. Prominent features of Linux kernel 4.5 include the implementation of initial support for the AMD PowerPlay power management technology, bringing high performance to the AMDGPU open-source driver for Radeon GPUs, scalability improvements in the free space handling of the Btrfs file system, and better epoll multithreaded scalability. The sources are now available for download from kernel.org. Update: 03/14 13:24 GMT by T : Reader diegocg lists some other notable features (a new copy_file_range() system call that allows to make copies of files without transferring data through userspace; support GCC's Undefined Behavior Sanitizer (-fsanitize=undefined); Forwarded Error Correction support in the device-mapper's verity target; support for the MADV_FREE flag in madvise(); the new cgroup unified hierarchy is considered stable; scalability improvements for SO_REUSEPORT UDP sockets; scalability improvements for epoll, and better memory accounting of sockets in the memory controller), and links to an explanation of the changes at Kernel Newbies.

jones_supa writes: Paolo Valente from University of Modena has submitted a Linux kernel patchset which replaces CFQ (Completely Fair Queueing) I/O scheduler with the last version of BFQ (Budget Fair Queuing, a proportional-share scheduler). This patchset first brings CFQ back to its state at the time when BFQ was forked from CFQ. Paolo explains: "Basically, this reduces CFQ to its engine, by removing every heuristic and improvement that has nothing to do with any heuristic or improvement in BFQ, and every heuristic and improvement whose goal is achieved in a different way in BFQ. Then, the second part of the patchset starts by replacing CFQ's engine with BFQ's engine, and goes on by adding current BFQ improvements and extra heuristics." He provides a link to the thread in which it is agreed on this idea, and a direct link to the e-mail describing the steps.

An anonymous reader writes: The Linux 4.3 kernel was released as stable today. The Linux 4.3 kernel brings Intel Skylake support, reworked NVIDIA open-source graphics support, and many other changes with the code count hitting 20.6 million lines of code.

An anonymous reader writes: Bcachefs is a new open-source file-system derived from the bcache Linux kernel block layer cache. Bcachefs was announced by Kent Overstreet, the lead Bcache author. Bcachefs hopes to provide performance like XFS/EXT4 while having features similar to Btrfs and ZFS. The bachefs on-disk format hasn't yet been finalized and the code isn't yet ready for the Linux kernel. That said, initial performance results are okay and "It probably won't eat your data — but no promises." Features so far for Bcachefs are support for multiple devices, built-in caching/tiering, CRC32C checksumming, and Zlib transparent compression. Support for snapshots is to be worked on.

An anonymous reader writes: Linus Torvalds ended the Linux 4.2 kernel merge window today by releasing Linux 4.2-rc1. He quickly wrote, "I thought this release would be one of the biggest ones ever, but it turns out that it will depend on how you count." By most metrics, Linux 4.2 is shaping up to be a very large release. Linux 4.2 is bringing plenty of new features including the new 'AMDGPU' kernel graphics driver, Intel Broxton support, NCQ TRIM improvements, F2FS file-system encryption, new ARM CPU/board support, Renesas R8/300 arch support, and many other additions.

jones_supa writes: Dave Jones from Red Hat has written a wrap-up of the strange bug that has made some machines running Linux to freeze. (Previous discussion.) Right down to his final week at Red Hat before Dave gave all his hardware back, Linus Torvalds managed to reproduce similar symptoms, by scribbling directly to the HPET timer. He came up with a hack that at least made the kernel survive for him. When Dave tried the same patch, the machine ran for three days before he interrupted it, which was a promising result. The question remains, what was scribbling over the HPET in his case? The only two plausible scenarios Dave could think of were that Trinity generated 0xFED000F0 as a random address and passed that to a syscall which wrote to it, or a hardware bug. That's where the story ends for now. Linus' hacky workaround didn't get committed, but him and John Stultz continue to back and forth on hardening the clock management code in the face of screwed up hardware, so maybe soon we'll see something real get committed on that area.

jones_supa writes: Dave Jones from Red Hat has written a wrap-up of the strange bug that has made some machines running Linux to freeze. (Previous discussion.) Right down to his final week at Red Hat before Dave gave all his hardware back, Linus Torvalds managed to reproduce similar symptoms, by scribbling directly to the HPET timer. He came up with a hack that at least made the kernel survive for him. When Dave tried the same patch, the machine ran for three days before he interrupted it, which was a promising result. The question remains, what was scribbling over the HPET in his case? The only two plausible scenarios Dave could think of were that Trinity generated 0xFED000F0 as a random address and passed that to a syscall which wrote to it, or a hardware bug. That's where the story ends for now. Linus' hacky workaround didn't get committed, but him and John Stultz continue to back and forth on hardening the clock management code in the face of screwed up hardware, so maybe soon we'll see something real get committed on that area.

jones_supa writes: Dave Jones from Red Hat has written a wrap-up of the strange bug that has made some machines running Linux to freeze. (Previous discussion.) Right down to his final week at Red Hat before Dave gave all his hardware back, Linus Torvalds managed to reproduce similar symptoms, by scribbling directly to the HPET timer. He came up with a hack that at least made the kernel survive for him. When Dave tried the same patch, the machine ran for three days before he interrupted it, which was a promising result. The question remains, what was scribbling over the HPET in his case? The only two plausible scenarios Dave could think of were that Trinity generated 0xFED000F0 as a random address and passed that to a syscall which wrote to it, or a hardware bug. That's where the story ends for now. Linus' hacky workaround didn't get committed, but him and John Stultz continue to back and forth on hardening the clock management code in the face of screwed up hardware, so maybe soon we'll see something real get committed on that area.

An anonymous reader writes Linus Torvalds released Linux 3.17-rc2 today in commemoration of the 23rd anniversary of the original kernel announcement. It was on 25 August 1991 that he announced his new OS project to the Minix users list.

diegocg writes "Linux kernel 3.13 has been released. This release includes nftables (the successor of iptables); a revamp of the block layer designed for high-performance SSDs; a framework to cap power consumption in Intel RAPL devices; improved squashfs performance; AMD Radeon power management enabled by default and automatic AMD Radeon GPU switching; improved NUMA and hugepage performance; TCP Fast Open enabled by default; support for NFC payments; support for the High-Availability Seamless Redundancy protocol; new drivers; and many other small improvements. Here's the full list of changes."

darthcamaro writes "Yesterday the stable Linux 3.10 kernel was updated twice — an error was made, forcing a quick re-issue. 'What happened was that a patch that was reported to be broken during the RC [release candidate] review process, went into the release, because I mistakenly didn't pull it out in time,' Greg Kroah-Hartman said. The whole incident however is now sparking debate on the Linux Kernel Mailing List about the speed of stable Linux kernel releases. Are they moving too fast?"

darthcamaro writes "Yesterday the stable Linux 3.10 kernel was updated twice — an error was made, forcing a quick re-issue. 'What happened was that a patch that was reported to be broken during the RC [release candidate] review process, went into the release, because I mistakenly didn't pull it out in time,' Greg Kroah-Hartman said. The whole incident however is now sparking debate on the Linux Kernel Mailing List about the speed of stable Linux kernel releases. Are they moving too fast?"

sfcrazy writes "Quite a lot of people raised their eyebrows the way ex-Red Hat developer Matthew Garrett made Microsoft the 'universal' control of any desktops PCs running with UEFI secure boot. Though the intentions of Garrett were clear — to enable GNU/Linux to be able to run Linux on Windows 8 certified PCs with secure boot; it was clearly putting Microsoft in a very powerful position. Linus, while a supporter of secure boot, exploded at Garrett and Howells when they proposed its inclusion in the kernel. Linus responded: 'Guys, this is not a d*#@-sucking contest. If you want to parse PE binaries, go right ahead. If Red Hat wants to deep-throat Microsoft, that's *your* issue. That has nothing what-so-ever to do with the kernel I maintain. It's trivial for you guys to have a signing machine that parses the PE binary, verifies the signatures, and signs the resulting keys with your own key. You already wrote the code, for chissake, it's in that f*cking pull request.'" Update: 02/25 17:24 GMT by U L : The headline/article are misleading, since mjg seems to agree that the patch is a bit complicated : "(I mean, *I'm* fine with the idea that they're *@#$ing idiots and deserve to be miserable, but apparently there's people who think this is a vital part of a business model)". The issue at hand is a set of patches to load and store keys inside of a UEFI PE binary which is then passed to the kernel, which then extracts the keys from the binary. It's absurd, it's messy, and it's only needed because Microsoft will only sign PE binaries so not supporting it makes restricted boot even more difficult to support.

sfcrazy writes "Quite a lot of people raised their eyebrows the way ex-Red Hat developer Matthew Garrett made Microsoft the 'universal' control of any desktops PCs running with UEFI secure boot. Though the intentions of Garrett were clear — to enable GNU/Linux to be able to run Linux on Windows 8 certified PCs with secure boot; it was clearly putting Microsoft in a very powerful position. Linus, while a supporter of secure boot, exploded at Garrett and Howells when they proposed its inclusion in the kernel. Linus responded: 'Guys, this is not a d*#@-sucking contest. If you want to parse PE binaries, go right ahead. If Red Hat wants to deep-throat Microsoft, that's *your* issue. That has nothing what-so-ever to do with the kernel I maintain. It's trivial for you guys to have a signing machine that parses the PE binary, verifies the signatures, and signs the resulting keys with your own key. You already wrote the code, for chissake, it's in that f*cking pull request.'" Update: 02/25 17:24 GMT by U L : The headline/article are misleading, since mjg seems to agree that the patch is a bit complicated : "(I mean, *I'm* fine with the idea that they're *@#$ing idiots and deserve to be miserable, but apparently there's people who think this is a vital part of a business model)". The issue at hand is a set of patches to load and store keys inside of a UEFI PE binary which is then passed to the kernel, which then extracts the keys from the binary. It's absurd, it's messy, and it's only needed because Microsoft will only sign PE binaries so not supporting it makes restricted boot even more difficult to support.

sfcrazy writes "Quite a lot of people raised their eyebrows the way ex-Red Hat developer Matthew Garrett made Microsoft the 'universal' control of any desktops PCs running with UEFI secure boot. Though the intentions of Garrett were clear — to enable GNU/Linux to be able to run Linux on Windows 8 certified PCs with secure boot; it was clearly putting Microsoft in a very powerful position. Linus, while a supporter of secure boot, exploded at Garrett and Howells when they proposed its inclusion in the kernel. Linus responded: 'Guys, this is not a d*#@-sucking contest. If you want to parse PE binaries, go right ahead. If Red Hat wants to deep-throat Microsoft, that's *your* issue. That has nothing what-so-ever to do with the kernel I maintain. It's trivial for you guys to have a signing machine that parses the PE binary, verifies the signatures, and signs the resulting keys with your own key. You already wrote the code, for chissake, it's in that f*cking pull request.'" Update: 02/25 17:24 GMT by U L : The headline/article are misleading, since mjg seems to agree that the patch is a bit complicated : "(I mean, *I'm* fine with the idea that they're *@#$ing idiots and deserve to be miserable, but apparently there's people who think this is a vital part of a business model)". The issue at hand is a set of patches to load and store keys inside of a UEFI PE binary which is then passed to the kernel, which then extracts the keys from the binary. It's absurd, it's messy, and it's only needed because Microsoft will only sign PE binaries so not supporting it makes restricted boot even more difficult to support.

diegocg writes "Linux kernel 3.8 has been released. This release includes support in Ext4 for embedding very small files in the inode, which greatly improves the performance for these files and saves some disk space. There is also a new Btrfs feature that allows for quick disk replacement, a new filesystem F2FS optimized for SSDs; support for filesystem mount, UTS, IPC, PID, and network namespaces for unprivileged users; accounting of kernel memory in the memory resource controller; journal checksums in XFS; an improved NUMA policy redesign; and, of course, the removal of support for 386 processors. Many small features and new drivers and fixes are also available. Here's the full list of changes."

An anonymous reader points out just how thick a skin it takes to be a kernel developer sometimes, linking to a chain of emails on the Linux Kernel Mailing List in which Linus lets loose on a kernel developer for introducing a change that breaks userspace apps (in this case, PulseAudio). "Shut up, Mauro. And I don't _ever_ want to hear that kind of obvious garbage and idiocy from a kernel maintainer again. Seriously. I'd wait for Rafael's patch to go through you, but I have another error report in my mailbox of all KDE media applications being broken by v3.8-rc1, and I bet it's the same kernel bug. And you've shown yourself to not be competent in this issue, so I'll apply it directly and immediately myself. WE DO NOT BREAK USERSPACE! Seriously. How hard is this rule to understand? We particularly don't break user space with TOTAL CRAP. I'm angry, because your whole email was so _horribly_ wrong, and the patch that broke things was so obviously crap. ... The fact that you then try to make *excuses* for breaking user space, and blaming some external program that *used* to work, is just shameful. It's not how we work," writes Linus, and that's just the part we can print. Maybe it's a good thing, but there's certainly no handholding when it comes to changes to the heart of Linux.

The wait is over; diegocg writes "Linux kernel 3.7 has been released. This release adds support for the new ARM 64-bit architecture, ARM multiplatform — the ability to boot into different ARM systems using a single kernel; support for cryptographically signed kernel modules; Btrfs support for disabling copy-on-write on a per-file basis using chattr; faster Btrfs fsync(); a new experimental 'perf trace' tool modeled after strace; support for the TCP Fast Open feature in the server side; experimental SMBv2 protocol support; stable NFS 4.1 and parallel NFS; a vxlan tunneling protocol that allows to transfer Layer 2 ethernet packets over UDP; and support for the Intel SMAP security feature. Many small features and new drivers and fixes are also available. Here's the full list of changes."

In October, Linus Torvalds expressed concerns that udev was making "...changes that were known to be problematic, and are pure and utter stupidity." Several Gentoo developers were also concerned about the removal of features and uncooperative nature of udev maintained by the systemd developers, so they've announced a fork: "After speaking with several other Gentoo developers that share Linus' concerns, I have decided to form a team to fork udev. Our plan is to eliminate the separate /usr requirement from our fork, among other things. We will announce the project later this week." The project name (for now) is udev-ng, and you can grab the code from Github. Update: 11/16 21:29 GMT by U L : One of the developers commented that this isn't yet an official Gentoo project (but hopefully it will be!). There's also an informative flamewar about the fork on debian-devel.

sfcrazy writes "A very serious argument erupted on the Linux kernel mailing list when Andy Grover, a Red Hat SCSI target engineer, requested that Nicholas A. Bellinger, the Linux SCSI target maintainer, provide proof of non-infringement of the GPL. Nick is developer at Rising Tide Systems, a Red Hat competitor, and a maker of advanced SCSI storage systems. Nick's company recently produced a groundbreaking technology involving advanced SCSI commands which will give Rising Tide Systems a lead in producing SCSI storage systems. Now, RTS is blocking Red Hat from getting access to that code as it's proprietary. What's uncertain is whether RTS' code is covered by GPL or not — if it is then Red Hat has all the rights to get access to it and it's a serious GPL violation."

An anonymous reader writes "An EXT4 file-system data corruption issue has reached the stable Linux kernel. The latest Linux 3.4, 3.5, 3.6 stable kernels have an EXT4 file-system bug described as an apparent serious progressive ext4 data corruption bug. Kernel developers have found and bisected the kernel issue but are still working on a proper fix for the stable Linux kernel. The EXT4 file-system can experience data loss if the file-system is remounted (or the system rebooted) too often."

sfcrazy writes "Samsung has created a new Linux file system called F2FS. Jaegeuk Kim of Samsung writes on the Linux Kernel Mailing List: F2FS is a new file system carefully designed for the NAND flash memory-based storage devices. We chose a log structure file system approach, but we tried to adapt it to the new form of storage. Also we remedy some known issues of the very old log structured file system, such as snowball effect of wandering tree and high cleaning overhead."

diegocg writes "Linux 3.6 has been released. It includes new features in Btrfs: subvolume quotas, quota groups and snapshot diffs (aka 'send/receive'). It also includes support for suspending to disk and memory at the same time, a TCP 'Fast Open' mode, a 'TCP small queues' feature to fight bufferbloat; support for safe swapping over NFS/NBD, better Ext4 quota support, support for the PCIe D3cold power state; and VFIO, which allows safe access from guest drivers to bare-metal host devices. Here's the full changelog."

diegocg writes "Linux 3.5 has been released. New features include support for metadata checksums in Ext4, userspace probes for performance profiling with systemtap/perf, a simple sandboxing mechanism that can filter syscalls, a new network queue management algorithm designed to fight bufferbloat, support for checkpointing and restoring TCP connections, support for TCP Early Retransmit (RFC 5827), support for android-style opportunistic suspend, btrfs I/O failure statistics, and SCSI over Firewire and USB. Here's the full changelog."

jrepin writes with news of today's release (here's Linus's announcement) of Linux 3.4: "This release includes several Btrfs updates: metadata blocks bigger than 4KB, much better metadata performance, better error handling and better recovery tools. There are other features: a new X32 ABI which allows to run in 64 bit mode with 32 bit pointers; several updates to the GPU drivers: early modesetting of Nvidia Geforce 600 'Kepler', support of AMD RadeonHD 7xxx and AMD Trinity APU series, and support of Intel Medfield graphics; support of x86 cpu driver autoprobing, a device-mapper target that stores cryptographic hashes of blocks to check for intrusions, another target to use external read-only devices as origin source of a thin provisioned LVM volume, several perf improvements such as GTK2 report GUI and a new 'Yama' security module."

diegocg writes "Linux 3.3 has been released. The changes include the merge of kernel code from the Android project. There is also support for a new architecture (TI C6X), much improved balancing and the ability to restripe between different RAID profiles in Btrfs, and several network improvements: a virtual switch implementation (Open vSwitch) designed for virtualization scenarios, a faster and more scalable alternative to the 'bonding' driver, a configurable limit to the transmission queue of the network devices to fight bufferbloat, a network priority control group and per-cgroup TCP buffer limits. There are also many small features and new drivers and fixes. Here's the full changelog."

diegocg writes "Linux 3.2 has been released. New features include support for Ext4 block size bigger than 4KB and up to 1MB, btrfs has added faster scrubbing, automatic backup of critical metadata and tools for manual inspection; the process scheduler has added support to set upper limits of CPU time; the desktop responsiveness in presence of heavy writes has been improved, TCP has been updated to include an algorithm which speeds up the recovery of connection after lost packets; the profiling tool 'perf top' has added support for live inspection of tasks and libraries. The Device Mapper has added support for 'thin provisioning' of storage, and a support for a new architecture has been added: Hexagon DSP processor from Qualcomm. New drivers and small improvements and fixes are also available in this release. Here's the full list of changes."

ghostoftiber writes "From the article: 'Tim Bird, a Sony engineering veteran and the chair of the Architecture Group of the Linux Foundation's CE Workgroup, has announced a new concerted effort to get Android's changes to the Linux kernel back into the mainline Linux kernel tree.' Android has been using Linux 2.6.x for its devices since its release, with patches from Google. To date they haven't been merged back into the kernel mainline but existed on kernel.org. Some of the features such as wakelocks would help with Linux tablet projects, but other features aren't fully realized and support remains spotty. The radio interface layer ... still exists as an ATI/Nvidia-esque shim loader scheme with modem 'drivers' being nothing more than ihex files loaded by open code."

An anonymous reader writes "The Linux kernel power bug that caused high power usage for many Intel Linux systems has finally been addressed. Matthew Garrett of Red Hat has devised a solution for the ASPM Linux power problem by mimicking Microsoft Windows' power behavior in the Linux kernel. A patch is on LKML for this solution to finally restore the battery life under Linux."

diegocg writes "Linux 3.1 has been released. The changes include support for the OpenRISC opensource CPU; performance improvements to the writeback throttling; some speedups in the slab allocator; a new iSCSI implementation; support for NFC chips; bad block management in the generic software RAID layer; a new 'cpupowerutils' utility for power management; filesystem barriers enabled by default in Ext3; Wii Controller support; and [the usual] new drivers and many small improvements."

An anonymous reader writes "Linux kernel developers have decided to mark the VirtualBox kernel driver as tainted crap for the significant number of problems this open-source driver has caused. The VirtualBox kernel driver reportedly causes memory corruption and other problems. With the driver being flagged as tainted crap, bug reports caused by the driver will be taken less seriously."

An anonymous reader writes "Linus Torvalds has announced that he will be distributing the Linux kernel via Github until kernel.org servers are fully operational following the recent server compromise. From the announcement: 'But hey, the whole point (well, *one* of the points) of distributed development is that no single place is really any different from any other, so since I did a github account for my divelog thing, why not see how well it holds up to me just putting my whole kernel repo there too?'"

sfcrazy writes "Linus Torvalds has announced the release of Linux kernel 3.1 rc2. He said '300+ commits for -rc2 is good, but please make me even happier for -rc3 by ONLY sending me real fixes. Think of it as "fairly late in the -rc series," because I really want to compensate for the merge window being fairly chaotic.'"

Suchetha writes "In a posting on his Google+ page Linus Torvalds announced the launch of Linux kernel 3.0. This follows the kernel missing the planned release date of the 19th because of 'a subtle bug.'"

diegocg writes "Version 2.6.37 of the Linux kernel has been released. This version includes SMP scalability improvements for Ext4 and XFS, the removal of the Big Kernel Lock, support for per-cgroup IO throttling, a networking block device based on top of the Ceph clustered filesystem, several Btrfs improvements, more efficient static probes, perf support to probe modules, LZO compression in the hibernation image, PPP over IPv4 support, several networking microoptimizations and many other small changes, improvements and new drivers for devices like the Brocade BNA 10GB ethernet, Topcliff PCH gigabit, Atheros CARL9170, Atheros AR6003 and RealTek RTL8712U. The fanotify API has also been enabled. See the full changelog for more details."

diegocg writes "Version 2.6.36 of the Linux kernel has been released. This version includes support for the Tilera architecture, a new filesystem notification interface called fanotify, CIFS local caching, support for Intel Intelligent Power Sharing in i3/5 systems, integration of the kernel debugger and KMS, inclusion of the AppArmor security system, a redesign of workqueues optimized for concurrency, and several new drivers and small improvements. See the full changelog here for more details."

diegocg writes "Linux 2.6.34 has been released. This version adds two new filesystem, the distributed filesystem Ceph and LogFS, a filesystem for flash devices. Other features are a driver for almost-native KVM network performance, the VMware balloon driver, the 'kprobes jump' optimization for dynamic probes, new perf features (the 'perf lock' tool, cross-platform analysis support), several Btrfs improvements, RCU lockdep, Generalized TTL Security Mechanism (RFC 5082) and private VLAN proxy arp (RFC 3069) support, asynchronous suspend/resume, several new drivers and many other small improvements. See the full changelog here."

diegocg writes "Version 2.6.33 of the Linux kernel has been released. This version includes the Nouveau driver, Nintendo Wii and Gamecube support, DRDB, TCP 'cookie transactions,' a syscall for batching recvmsg() calls, several new perf subcommands (perf probe, perf bench, perf kmem, perf diff), experimental support for cache compression through swap, Xen PV-on-HVM support, drivers for virtual network and graphic cards from VMWare and other improvements. See the full changelog here."