Slashdot Mirror

Five candidates now are running to be Debian's project leader for the coming year. But earlier this week, Slashdot reader Seven Spirals shared LWN's story about what a difficult election it's been: This year, the call for nominations was duly sent out by project secretary Kurt Roeckx on March 3. But, as of March 10, no eligible candidates had put their names forward... There is nobody there to do any campaigning.

This being Debian, the constitution naturally describes what is to happen in this situation: the nomination period is extended for another week... Should this deadline also pass without candidates, it will be extended for another week; this loop will repeat indefinitely until somebody gives in and submits their name... In the absence of a project leader, the chair of the technical committee and the project secretary are empowered to make decisions -- as long as they are able to agree on what those decisions should be. Since Debian developers are famously an agreeable and non-argumentative bunch, there should be no problem with that aspect of things...

One might well wonder, though, why there seems to be nobody who wants to take the helm of this project for a year. The fact that it is an unpaid position requiring a lot of time and travel might have something to do with it. If that were indeed to prove to be part of the problem, Debian might eventually have to consider doing what a number of similar organizations have done and create a paid position to do this work.

At Open Source Summit Europe in Edinburgh, Scotland, Linus Torvalds is meeting with Linux's top 40 or so developers at the Maintainers' Summit. This is his first step back in taking over Linux's reins. From a report: A little over a month ago, Torvalds stepped back from running the Linux development community. In a note to the Linux Kernel Mailing List (LKML), Torvalds said, "I need to change some of my behavior, and I want to apologize to the people that my personal behavior hurt and possibly drove away from kernel development entirely. I am going to take time off and get some assistance on how to understand people's emotions and respond appropriately." That time is over. Torvalds is back.

Whether he'll be a kinder and gentler Torvalds remains to be seen. In the Linux 4.19 announcement, Greg Kroah-Hartman, Linux's temporary leader and maintainer of the stable branch, wrote: "Linus, I'm handing the kernel tree back to you. You can have the joy of dealing with the merge window :)"

Hewlett-Packard's Enterprise blog summarizes a talk by Linux kernel developer Kees Cook at the North America edition of the 2018 Linux Security Summit. Its title? "Making C Less Dangerous." "C is a fancy assembler. It's almost machine code," said Cook, speaking to an audience of several hundred peers, who understood and appreciated the application speed resulting from C... Over time, Cook and the people he worked with discovered numerous native C problems. To deal with these weaknesses, the Kernel Self Protection Project has worked slowly and steadily on protecting the Linux kernel from attack. In the process, it has worked to remove troublesome code from Linux....

With its operational baggage and weak standard libraries, C contains a great deal of undefined behavior. Cook cited -- and agreed with -- Raph Levien's blog post "With Undefined Behavior, Anything Is Possible." Cook gave concrete examples. "What are the contents of 'uninitialized' variables? Whatever was in memory from before! Void pointers have no type, yet we can call typed functions through them? Sure! Assembly doesn't care: Everything can be an address to call! Why does memcpy() have no 'max destination length' argument? Just do what I say; memory areas are all the same!" Some of these idiosyncracies are relatively easy to deal with. Cook commented, "Linus [Torvalds] likes the idea of always initializing local variables. So, you should 'just do it....'"

The long-term solution? More security-savvy open source developers... While at times, the idea of coming up with a Linux C dialect has been attractive, that's not going to happen. The real issue behind the problem of dangerous code is "people don't want to do the work to clean up code -- not just bad code, but C itself," he said. As with all open source projects, "we need more dedicated developers, reviewers, testers, and backporters."
LWN.net has its own run-down of Cook's talk, as well as a link to a PDF file of his slides.

"Sound good," posted one of their commenters, "though ultimately I'd like kernel devs to adopt Rust as their main Linux kernel development language. Beats the crap out of C and C++ combined."

There's a new version of the 42-year-old libre text editor with over 2,000 built-in commands, reports LWN.net: Highlights include a built-in Lisp threading mechanism that provides some concurrency, double buffering when running under X, a redesigned flymake mode, 24-bit color support in text mode, and a systemd [user] unit file.
The Free Software Foundation has released a 10,653-word description of all the new features in Emacs 26.1. Here's a couple more:

• The Emacs server now has socket-launching support. This allows socket based activation, where an external process like systemd can invoke the Emacs server process upon a socket connection event and hand the socket over to Emacs... This new functionality can be disabled with the configure option '--disable-libsystemd'.

• The new function 'call-shell-region' executes a command in an inferior shell with the buffer region as input.

• Intercepting hotkeys on Windows 7 and later now works better.

• The new user variable 'electric-quote-chars' provides a list of curved quotes for 'electric-quote-mode', allowing user to choose the types of quotes to be used.

An anonymous reader quotes The Register: Late last month, open-source contributor Raymond Nicholson proposed a change to the manual for glibc, the GNU implementation of the C programming language's standard library, to remove "the abortion joke," which accompanied the explanation of libc's abort() function... The joke, which has been around since the 1990s and is referred to as a censorship joke by those supporting its inclusion, reads as follows:

25.7.4 Aborting a Program... Future Change Warning: Proposed Federal censorship regulations may prohibit us from giving you information about the possibility of calling this function. We would be required to say that this is not an acceptable way of terminating a program.

On April 30, the proposed change was made, removing the passage from the documentation. That didn't sit well with a number of people involved in the glibc project, including the joke's author, none other than Free Software Foundation president and firebrand Richard Stallman, who argued that the removal of the joke qualified as censorship... Carlos O'Donnell, a senior software engineer at Red Hat, recommended avoiding jokes altogether, a position supported by many of those weighing in on the issue. Among those voicing opinions, a majority appears to favor removal.
But in a post to the project mailing list, Stallman wrote "Please do not remove it. GNU is not a purely technical project, so the fact that this is not strictly and grimly technical is not a reason to remove this." He added later that "I exercise my authority over glibc very rarely -- and when I have done so, I have talked with the official maintainers. So rarely that some of you thought that you are entirely autonomous. But that is not the case. On this particular question, I made a decision long ago and stated it where all of you could see it."

The Register reports that "On Monday, the joke was restored by project contributor Alexandre Oliva, having taken Stallman's demand as approval to do so."

Free software/Linux news site LWN.net just celebrated its 20th birthday, with publisher Jonathan Corbet calling the last two decades "an amazing journey." LWN published the first edition of their weekly newsletter on January 22, 1998, and Corbet (who also contributes to the Linux kernel) writes today that "It has been quite a ride. We in the free-software community set out to change the world, and we succeeded beyond our wildest expectations."

Here's how he described their second edition the next week... We were arguably helped by the lead news in that edition: Netscape's decision to open-source its "Communicator" web browser. That quickly brought the world's attention to open-source software, though that term would not be invented for a few months yet, and to Linux in particular. LWN was a shadow of what it is now, but it was evidently good enough to ride on that wave and establish itself as a part of the Linux community.
Corbet reviews the highlights. ("Companies discovered our little hobbyist system and invested billions into it, massively accelerating development at all levels of the system...") But he also adds that "Through all of this, we also got to learn some lessons about successfully running a community information source on the net." For the last 16 years the site has supported itself with $7.00-a-month subscriptions, offering early access to their Weekly Edition plus subscriber-only mailing lists, "allowing our content to quickly become part of the community record."

Plus, through events around the world, "we have met -- and become friends with -- many of our readers and many people in the community as a whole. This community is an amazing group of people; it has been a honor and a joy to be a part of it..."

"The free-software community's work is not done, and neither is ours. "

Free software/Linux news site LWN.net just celebrated its 20th birthday, with publisher Jonathan Corbet calling the last two decades "an amazing journey." LWN published the first edition of their weekly newsletter on January 22, 1998, and Corbet (who also contributes to the Linux kernel) writes today that "It has been quite a ride. We in the free-software community set out to change the world, and we succeeded beyond our wildest expectations."

Here's how he described their second edition the next week... We were arguably helped by the lead news in that edition: Netscape's decision to open-source its "Communicator" web browser. That quickly brought the world's attention to open-source software, though that term would not be invented for a few months yet, and to Linux in particular. LWN was a shadow of what it is now, but it was evidently good enough to ride on that wave and establish itself as a part of the Linux community.
Corbet reviews the highlights. ("Companies discovered our little hobbyist system and invested billions into it, massively accelerating development at all levels of the system...") But he also adds that "Through all of this, we also got to learn some lessons about successfully running a community information source on the net." For the last 16 years the site has supported itself with $7.00-a-month subscriptions, offering early access to their Weekly Edition plus subscriber-only mailing lists, "allowing our content to quickly become part of the community record."

Plus, through events around the world, "we have met -- and become friends with -- many of our readers and many people in the community as a whole. This community is an amazing group of people; it has been a honor and a joy to be a part of it..."

"The free-software community's work is not done, and neither is ours. "

Free software/Linux news site LWN.net just celebrated its 20th birthday, with publisher Jonathan Corbet calling the last two decades "an amazing journey." LWN published the first edition of their weekly newsletter on January 22, 1998, and Corbet (who also contributes to the Linux kernel) writes today that "It has been quite a ride. We in the free-software community set out to change the world, and we succeeded beyond our wildest expectations."

Here's how he described their second edition the next week... We were arguably helped by the lead news in that edition: Netscape's decision to open-source its "Communicator" web browser. That quickly brought the world's attention to open-source software, though that term would not be invented for a few months yet, and to Linux in particular. LWN was a shadow of what it is now, but it was evidently good enough to ride on that wave and establish itself as a part of the Linux community.
Corbet reviews the highlights. ("Companies discovered our little hobbyist system and invested billions into it, massively accelerating development at all levels of the system...") But he also adds that "Through all of this, we also got to learn some lessons about successfully running a community information source on the net." For the last 16 years the site has supported itself with $7.00-a-month subscriptions, offering early access to their Weekly Edition plus subscriber-only mailing lists, "allowing our content to quickly become part of the community record."

Plus, through events around the world, "we have met -- and become friends with -- many of our readers and many people in the community as a whole. This community is an amazing group of people; it has been a honor and a joy to be a part of it..."

"The free-software community's work is not done, and neither is ours. "

Free software/Linux news site LWN.net just celebrated its 20th birthday, with publisher Jonathan Corbet calling the last two decades "an amazing journey." LWN published the first edition of their weekly newsletter on January 22, 1998, and Corbet (who also contributes to the Linux kernel) writes today that "It has been quite a ride. We in the free-software community set out to change the world, and we succeeded beyond our wildest expectations."

Here's how he described their second edition the next week... We were arguably helped by the lead news in that edition: Netscape's decision to open-source its "Communicator" web browser. That quickly brought the world's attention to open-source software, though that term would not be invented for a few months yet, and to Linux in particular. LWN was a shadow of what it is now, but it was evidently good enough to ride on that wave and establish itself as a part of the Linux community.
Corbet reviews the highlights. ("Companies discovered our little hobbyist system and invested billions into it, massively accelerating development at all levels of the system...") But he also adds that "Through all of this, we also got to learn some lessons about successfully running a community information source on the net." For the last 16 years the site has supported itself with $7.00-a-month subscriptions, offering early access to their Weekly Edition plus subscriber-only mailing lists, "allowing our content to quickly become part of the community record."

Plus, through events around the world, "we have met -- and become friends with -- many of our readers and many people in the community as a whole. This community is an amazing group of people; it has been a honor and a joy to be a part of it..."

"The free-software community's work is not done, and neither is ours. "

Linux kernel developer (and LWN.net co-founder) Jonathan Corbet recently posted an essay with a tantalizing title: "Is it time for open processors?" He cited several "serious initiatives", including the OpenPOWER effort, OpenSPARC, and OpenRISC, adding that "much of the momentum" appears to be with the RISC-V architecture. An anonymous reader quotes LWN.net: The [RISC-V] project is primarily focused on the instruction-set architecture, rather than on specific implementations, but free hardware designs do exist. Western Digital recently announced that it will be using RISC-V processors in its storage products, a decision that could lead to the shipment of RISC-V by the billion. There is a development kit available for those who would like to play with this processor and a number of designs for cores are available... RISC-V seems to have quite a bit of commercial support behind it -- the RISC-V Foundation has a long list of members. It seems likely that this architecture will continue to progress for some time.
Here's some of the reasons that Corbet argues open souce hardware "would certainly offer some benefits, but it would be no panacea."

• "While compilers can be had for free, the same is not true of chip fabrication facilities, especially the expensive fabs needed to create high-end processors... It will never be as easy or as cheap as typing 'make'..."

• "Without some way of verifying underlying design of an actual piece of hardware, we'll never really know if a given chip implements the design that we're told it does..."

• "Even if RISC-V becomes successful in the marketplace, chances are good that the processors we can actually buy will not come with freely licensed designs..."

• "Finally, even if we end up with entirely open processors, that will not bring an end to vulnerabilities at that level. We have a free kernel, but the kernel vulnerabilities come just the same. Open hardware may give us more confidence in the long term that we can retain control of our systems, but it is certainly not a magic wand that will wave our problems away."

"None of this should prevent us from trying to bring more openness and freedom to the design of our hardware, though. Once upon a time, creating a free operating system seemed like an insurmountably difficult task, but we have done it, multiple times over. Moving away from proprietary hardware designs may be one of our best chances for keeping our freedom; it would be foolish not to try."

Linux kernel developer (and LWN.net co-founder) Jonathan Corbet recently posted an essay with a tantalizing title: "Is it time for open processors?" He cited several "serious initiatives", including the OpenPOWER effort, OpenSPARC, and OpenRISC, adding that "much of the momentum" appears to be with the RISC-V architecture. An anonymous reader quotes LWN.net: The [RISC-V] project is primarily focused on the instruction-set architecture, rather than on specific implementations, but free hardware designs do exist. Western Digital recently announced that it will be using RISC-V processors in its storage products, a decision that could lead to the shipment of RISC-V by the billion. There is a development kit available for those who would like to play with this processor and a number of designs for cores are available... RISC-V seems to have quite a bit of commercial support behind it -- the RISC-V Foundation has a long list of members. It seems likely that this architecture will continue to progress for some time.
Here's some of the reasons that Corbet argues open souce hardware "would certainly offer some benefits, but it would be no panacea."

• "While compilers can be had for free, the same is not true of chip fabrication facilities, especially the expensive fabs needed to create high-end processors... It will never be as easy or as cheap as typing 'make'..."

• "Without some way of verifying underlying design of an actual piece of hardware, we'll never really know if a given chip implements the design that we're told it does..."

• "Even if RISC-V becomes successful in the marketplace, chances are good that the processors we can actually buy will not come with freely licensed designs..."

• "Finally, even if we end up with entirely open processors, that will not bring an end to vulnerabilities at that level. We have a free kernel, but the kernel vulnerabilities come just the same. Open hardware may give us more confidence in the long term that we can retain control of our systems, but it is certainly not a magic wand that will wave our problems away."

"None of this should prevent us from trying to bring more openness and freedom to the design of our hardware, though. Once upon a time, creating a free operating system seemed like an insurmountably difficult task, but we have done it, multiple times over. Moving away from proprietary hardware designs may be one of our best chances for keeping our freedom; it would be foolish not to try."

Bufferbloat is that "undesirable latency that comes from a router or other network equipment buffering too much data," according to the site for an ongoing project trying to address it. Now long-time Slashdot reader mtaht writes:Inside the lede-project, two core new bufferbloat-fighting techniques are poised to enter the linux mainline kernel and thousands of routers -- the first being a fq-codel'd and airtime fair scheduler for wifi, and the second, the new "cake" qdisc, which outperforms fq_codel across the board for shaping inbound and outbound connections.
His submission ends with a question for Slashdot readers. "It's been nearly six years since the start of the bufferbloat project. Have you or has your ISP fixed your bufferbloat yet?"

"As expected, today, December 11, 2016, Linus Torvalds unleashed the final release of the highly anticipated Linux 4.9 kernel," reports Softpedia. prisoninmate shares their article: Linux kernel 4.9 entered development in mid-October, on the 15th, when Linus Torvalds decided to cut the merge window short by a day just to keep people on their toes, but also to prevent them from sending last-minute pull requests that might cause issues like it happened with the release of Linux kernel 4.8, which landed just two weeks before first RC of Linux 4.9 hit the streets... There are many great new features implemented in Linux kernel 4.9, but by far the most exciting one is the experimental support for older AMD Radeon graphics cards from the Southern Islands/GCN 1.0 family, which was injected to the open-source AMDGPU graphics driver...

There are also various interesting improvements for modern AMD Radeon GPUs, such as virtual display support and better reset support, both of which are implemented in the AMDGPU driver. For Intel GPU users, there's DMA-BUF implicit fencing, and some Intel Atom processors got a P-State performance boost. Intel Skylake improvements are also present in Linux kernel 4.9.
There's also dynamic thread-tracing, according to Linux Today. (And hopefully they fixed the "buggy crap" that made it into Linux 4.8.) LWN.net calls this "by far the busiest cycle in the history of the kernel project."

Two days after Linus Torvalds announced the release of Linux 4.8, he began apologizing for a bug fix gone bad. The Register reports: "I'm really sorry I applied that last series from Andrew just before doing the 4.8 release, because they cause problems, and now it is in 4.8 (and that buggy crap is marked for stable too)." The "crap" in question is an attempt to fix a bug that's been present in Linux since version 3.15. Torvalds rates the fix for that bug "clearly worse than the bug it tried to fix, since that original bug has never killed my machine!" Torvalds isn't happy with kernel contributor Andrew Morton, who he says is debugging with a known bad use of BUG_ON(). "I've ranted against people using BUG_ON() for debugging in the past. Why the f*ck does this still happen?" Torvalds writes, pointing to a 2002 post to the kernel mailing list outlining how to do BUG_ON() right. He later adds "so excuse me for being upset that people still do this shit almost 15 years later."

Reader JImbob0i0 writes: After almost another year without a release and another major CVE leaving users vulnerable for that year the Chairman of the Project Management Committee has started public discussions on what it will entail to retire the project, following the Apache Board showing concern at the poor showing.
It's been a long battle which would have been avoided if Oracle had not been so petty. Did this behaviour actually help get momentum in the community underway though? What ifs are always hard to properly answer. Hopefully this long drawn out death rattle will finally come to a close and the wounds with LibreOffice can heal with the last few contributors to AOO joining the rest of the community.

Rick Zeman writes: The Washington Post has a lengthy article on Linus Torvalds and his thoughts on Linux security. Quoting: "...while Linux is fast, flexible and free, a growing chorus of critics warn that it has security weaknesses that could be fixed but haven't been. Worse, as Internet security has surged as a subject of international concern, Torvalds has engaged in an occasionally profane standoff with experts on the subject. ...

His broader message was this: Security of any system can never be perfect. So it always must be weighed against other priorities — such as speed, flexibility and ease of use — in a series of inherently nuanced trade-offs. This is a process, Torvalds suggested, poorly understood by his critics. 'The people who care most about this stuff are completely crazy. They are very black and white,' he said ... 'Security in itself is useless. The upside is always somewhere else. The security is never the thing that you really care about.'"

Of course, contradictory points of view are presented, too: "While I don't think that the Linux kernel has a terrible track record, it's certainly much worse than a lot of people would like it to be," said Matthew Garrett, principal security engineer for CoreOS, a San Francisco company that produces an operating system based on Linux. At a time when research into protecting software has grown increasingly sophisticated, Garrett said, "very little of that research has been incorporated into Linux."

basscomm writes: For years (as seen on Slashdot) the Linux Standard Base has been developed as an attempt to reduce the differences between Linux distributions in an effort significant effort. However, Debian Linux has announced that they are dropping support for the Linux Standard Base due to a lack of interest.

From the article: "If [Raboud's] initial comments about lack of interest in LSB were not evidence enough, a full three months then went by with no one offering any support for maintaining the LSB-compliance packages and two terse votes in favor of dropping them. Consequently, on September 17, Raboud announced that he had gutted the src:lsb package (leaving just lsb-base and lsb-release as described) and uploaded it to the "unstable" archive. That minimalist set of tools will allow an interested user to start up the next Debian release and query whether or not it is LSB-compliant—and the answer will be 'no.'"

Last Thursday you had a chance to ask Linus Torvalds about programming, hardware, and all things Linux. You can read his answers to those questions below. If you'd like to see what he had to say the last time we sat down with him, you can do so here. Productivity
by DoofusOfDeath

You've somehow managed to originate two insanely useful pieces of software: Linux, and Git. Do you think there's anything in your work habits, your approach to choosing projects, etc., that have helped you achieve that level of productivity? Or is it just the traditional combination of talent, effort, and luck?

Linus: I'm sure it's pretty much always that "talent, effort and luck". I'll leave it to others to debate how much of each...

I'd love to point out some magical work habit that makes it all happen, but I doubt there really is any. Especially as the work habits I had wrt the kernel and Git have been so different.

With Git, I think it was a lot about coming at a problem with fresh eyes (not having ever really bought into the traditional SCM mindset), and really trying to think about the issues, and spending a fair amount of time thinking about what the real problems were and what I wanted the design to be. And then the initial self-hosting code took about a day to write (ok, that was "self-hosting" in only the weakest sense, but still).

And with Linux, obviously, things were very different - the big designs came from the outside, and it took half a year to host itself, and it hadn't even started out as a kernel to begin with. Clearly not a lot of thinking ahead and planning involved ;). So very different circumstances indeed.

What both the kernel and Git have, and what I think is really important (and I guess that counts as a "work habit"), is a maintainer that stuck to it, and was responsive, responsible and sane. Too many projects falter because they don't have people that stick with them, or have people who have an agenda that doesn't match reality or the user expectations.

But it's very important to point out that for Git, that maintainer was not me. Junio Hamano really should get pretty much all the credit for Git. Credit where credit is due. I'll take credit for the initial implementation and design of Git - it may not be perfect, but ten years on it still is very solid and very clearly the same basic design. But I'll take even _more_ credit for recognizing that Junio had his head screwed on right, and was the person to drive the project. And all the rest of the credit goes to him.

Of course, that kind of segues into something else the kernel and Git do have in common: while I still maintain the kernel, I did end up finding a lot of smart people to maintain all the different parts of it. So while one important work habit is that "stick to it" persistence that you need to really take a project from a not-quite-usable prototype to something bigger and better, another important work-habit is probably to also "let go" and not try to own and control the project too much. Let other people really help you - guide the process but don't get in their way.



init system
by lorinc

There wasn't a decent unix-like kernel, you wrote one which ultimately became the most used. There wasn't a decent version control software, you wrote one which ultimately became the most love. Do you think we already have a decent init system, or do you have plan to write one that will ultimately settle the world on that hot topic?

Linus: You can say the word "systemd", It's not a four-letter word. Seven letters. Count them.

I have to say, I don't really get the hatred of systemd. I think it improves a lot on the state of init, and no, I don't see myself getting into that whole area.

Yeah, it may have a few odd corners here and there, and I'm sure you'll find things to despise. That happens in every project. I'm not a huge fan of the binary logging, for example. But that's just an example. I much prefer systemd's infrastructure for starting services over traditional init, and I think that's a much bigger design decision.

Yeah, I've had some personality issues with some of the maintainers, but that's about how you handle bug reports and accept blame (or not) for when things go wrong. If people thought that meant that I dislike systemd, I will have to disappoint you guys.



Can Valve change the Linux gaming market?
by Anonymous Coward

Do you think Valve is capable of making Linux a primary choice for gamers?

Linus: "Primary"? Probably not where it's even aiming. I think consoles (and all those handheld and various mobile platforms that "real gamers" seem to dismiss as toys) are likely much more primary, and will stay so.

I think Valve wants to make sure they can control their own future, and Linux and ValveOS is probably partly to explore a more "console-like" Valve experience (ie the whole "get a box set up for a single main purpose", as opposed to a more PC-like experience), and partly as a "second source" against Microsoft, who is a competitor in the console area. Keeping your infrastructure suppliers honest by making sure you have alternatives sounds like a good strategy, and particularly so when those suppliers may be competing with you directly elsewhere.

So I don't think the aim is really "primary". "Solid alternative" is I think the aim. Of course, let's see where it goes after that.

But I really have not been involved. People like Greg and the actual graphics driver guys have been in much more direct contact with Valve. I think it's great to see gaming on Linux, but at the same time, I'm personally not really much of a gamer.



The future of RT-Linux?
by nurhussein

According to Thomas Gleixner, the future of the realtime patchset to Linux is in doubt, as it is difficult to secure funding from interested parties on this functionality even though it is both useful and important: What are your thoughts on this, and what do you think we need to do to get more support behind the RT patchset, especially considering Linux's increasing use in embedded systems where realtime functionality is undoubtedly useful.

Linus: So I think this is one of those things where the markets decide how important rtLinux ends up being, and I suspect there are more than enough companies who end up wanting and using rtLinux that the project isn't really going anywhere. The complaints by Thomas were - I think - a wake-up call to the companies who end up wanting the extended hard realtime patches.

So I suspect there are companies and groups like OSADL that end up funding and helping with rtLinux, and that it isn't going away.



Rigor and developments
by hcs_$reboot

The most complex program running on a machine is arguably its OS, especially the kernel. Linux (kernel) reached the top level in terms of performance, reliability and versatility. You have been criticized quite a few times for some virulent mails addressed to developers. Do you think Linux would be where it is without managing the project with an iron fist? To go further, do you think some other main OSS project would benefit from a more rigorous management approach?

Linus: One of the nice things about open source is how it allows people to really concentrate on what they are good at, and it has been a huge advantage for Linux that we've had people who are interested in the marketing side and selling Linux, as well as the legal side etc.

And that is all in addition, of course, to the original "we're motivated by the technology" people like me. And even within that "we're motivated by technology" group, you most certainly don't need to find _everything_ interesting, you can find the area you are passionate about and really care about and want to work on.

That's _fundamentally_ how open source works.

Now, if somebody is passionate about some "good management" thing, go wild, and try to get involved, and try to manage things. It's not what _I_ am interested in, but hey, the proof is in the pudding - anybody who thinks they have a new rigorous management approach that they think will help some part of the process, go wild.

Now, I personally suspect that it wouldn't work - not only are tech people an ornery lot to begin with (that whole "herding cats" thing), just look at all the crazy arguments on the internet. And ask yourself what actually holds an open source project like the kernel together? I think you need to be very oriented towards the purely technical solutions, simply because then you have tangible and real issues you can discuss (and argue about) with fairly clear-cut hard answers. It's the only thing people can really agree on in the big picture.

So the Linux approach to "management" has been to put technology first. That's rigorous enough for me. But as mentioned, it's a free-for-all. Anybody can come in and try to do better. Really.

And btw, it's worth noting that there are obviously specific smaller development teams where other management models work fine. Most of the individual developers are parts of teams inside particular companies, and within the confines of that company, there may well be a very strict rigorous management model. Similarly, within the confines of a particular productization effort there may be particular goals and models for that particular team that transcend that general "technical issues" thing.

Just to give a concrete example, the "development kernel" tree that I maintain works fundamentally differently and with very different rules from the "stable tree" that Greg does, which in turn is maintained very differently from what a distribution team within a Linux company does inside its maintenance kernel team.

So there's certainly room for different approaches to managing those very different groups. But do I think you can "rigorously manage" people on the internet? No.



Functional languages?
by EmeraldBot

While historically you've been a C and Assembly guy (and the odd shell scripting and such), what do you think of functional languages such as Lisp, Closure, Haskell, etc? Do you see any advantages to them, or do you view them as frivolous and impractical? If you decide to do so, thanks for taking the time to answer my question! You're a legend at what you do, and I think it's awesome that the significantly less interesting me can ask you a question like this.

Linus: I may be a fan of C (with a certain fondness for assembly, just because it's so close to the machine), but that's very much about a certain context. I work at a level where those languages make sense. I certainly don't think that tools like Haskell etc are "frivolous and impractical" in general, although on a kernel level (or in a source control management system) I suspect they kind of are.

Many moons ago I worked on sparse (the C parser and analyzer), and one of my coworkers was a Haskell fan, and did incredible example transformations in very simple (well, to him) code - stuff that is just nasty to write in C because it's pretty high-level, there's tons of memory management, and you're really talking about implementing fairly abstract and high-level rules with pattern matching etc.

So I'm definitely not a functional language kind of guy - it's not how I learnt programming, and it really isn't very relevant to what I do, and I wouldn't recognize Haskell code if it bit me in the ass and called me names. But no, I wouldn't call them frivolous.



Critical software to the use of Linux
by TWX

Mr. Torvalds, For many uses of Linux such as on the desktop, other software beyond the kernel and the base GNU tools are required. What other projects would you like to see given priority, and what would you like to see implemented or improved? Admittedly I thought most about X-Windows when asking this question; but I don't doubt that other daemons or systems can be just as important to the user experience. Thank you for your efforts all these years.

Linus: Hey, I don't really have any particular project I would want to champion, largely because we all have so different requirements on the desktop. There's just no single thing that stands out as being hugely more important than others to me.

What I do wish particularly desktop developers cared about is "consistency of experience". And by that I don't mean some kind of enforced visual consistency between different applications to make things "look coherent". No, I'm just talking about the pain and uncertainty users go through with upgrades, and understanding that while your project may be the most important project to *you* (because it's what you do), to your users, your project is likely just a fairly small and irrelevant part of their experience, and it's not very central at all, and they've learnt the quirks about that thing they don't even care about, and you really shouldn't break their expectations. Because it turns out that that is how you really make people hate their desktop.

This is not at all Linux-specific, of course - just look at the less than enthusiastic reception that other operating system redesigns have received. But I really wish that we hadn't had *both* of the major Linux desktop environments have to learn this (well, I hope they learnt) the hard way, and both of them ending up blaming their users rather than themselves.



"anykernel"-style portable drivers?
by staalmannen

What do you think about the "anykernel" concept (invented by another Finn btw) used in NetBSD? Basically, they have modularized the code so that a driver can be built either in a monolithic kernel or for user space without source code changes ( rumpkernel.org ). The drivers are highly portable and used in Genode os (L4 type kernels), minix etc... Would this be possible or desirable for Linux? Apparently there is one attempt called "libos"...

Linus: So I have bad experiences with "portable" drivers. Writing drivers to some common environment tends to force some ridiculously nasty impedance matching abstractions that just get in the way and make things really hard to read and modify. It gets particularly nasty when everybody ends up having complicated - and differently so - driver subsystems to handle a lot of commonalities for a certain class of drivers (say a network driver, or a USB driver), and the different operating systems really have very different approaches and locking rules etc.

I haven't seen anykernel drivers, but from past experience my reaction to "portable device drivers" is to run away, screaming like little girl. As they say in Swedish "Bränt barn luktar illa".



Processor Architecture
by swv3752

Several years ago, you were employed by Transmeta designing the Crusoe processor. I understand you are quite knowledgeable about cpu architecture. What are your thoughts on the Current Intel and AMD x86 CPUs particularly in comparison with ARM and IBM's Power8 CPUs? Where do you see the advantages of each one?

Linus: I'm no CPU architect, I just play one on TV.

But yes, I've been close to the CPU both as part of my kernel work, and as part of a processor company, and working at that level for a long time just means that you end up having fairly strong opinions. One of the things that my experiences at Transmeta convinced me of, for example, was that there's definitely very much a limit to what software should care about. I loved working at Transmeta, I loved the whole startup company environment, I loved working with really smart people, but in the end I ended up absolutely *not* loving to work with overly simple hardware (I also didn't love the whole IPO process, and what that did to the company culture, but that's a different thing).

Because there's only so much that software can do to compensate.

Something similar happened with my kernel work on the alpha architecture, which also started out as being an overly simplified implementation in the name of being small and supposedly running really fast. While I really started out liking the alpha architecture for being so clean, I ended up detesting how fragile the architecture implementations were (and by the time that got fixed in the 21264, I had given up on alpha).

So I've come to absolutely detest CPU's that need a lot of compiler smarts or special tuning to go fast. Life is too short to waste on in-order CPU's, or on hardware designers who think software should take care of the pieces that they find to be too complicated to handle themselves, and as a result just left undone. "Weak memory ordering" is just another example.

Thankfully, most of the industry these days seems to agree. Yes, there are still in-order cores, but nobody tries to make excuses for them any more: they are for the truly cheap and low-end market.

I tend to really like the modern Intel cores in particular, which tend to take that "let's not be stupid" really to heart. With the kernel being so threaded, I end up caring a lot about things like memory ordering etc, and the Intel big-core CPU's tend to be in a class of their own there. As a software person who cares about performance and looks at instruction profiles etc, it's just so *nice* to see that the CPU doesn't have some crazy glass jaw where you have to be very careful.



GPU kernels
by maraist

Is there any inspiration that a GPU based kernel / scheduler has for you? How might Linux be improved to better take advantage of GPU-type batch execution models. Given that you worked transmeta and JIT compiled host-targeted runtimes. GPUs 1,000-thread schedulers seem like the next great paradigm for the exact type of machines that Linux does best on.

Linus: I don't think we'll see the kernel ever treat GPU threads the way we treat CPU threads. Not with the current model of GPU's (and that model doesn't really seem to be changing all that much any more).

Yes, GPU's are getting much better, and now generally have virtual memory and the ability to preempt execution, and you could run an OS on them. But the scheduling latencies are pretty high, and the threads are not really "independent" (ie they tend to share a lot of state - like the virtual address space and a large shared register set), so GPU "threads" don't tend to work like CPU threads. You'd schedule them all-or-nothing, so if you were to switch processes, you'd treat the GPU as one entity where you switch all the threads at once.

So it really wouldn't look like a thousand threads to the kernel. The GPU would still be scheduled as one single entity (or maybe a couple of entities depending on how the GPU is partitioned). The fact that that single entity works by doing a lot of things in massive parallelism is kind of immaterial for the kernel that doesn't end up seeing that parallelism as separate threads.



alleged danger of Artificial Intelligence
by peter303

Some computer experts like Marvin Minsky, Larry Page, Ray Kuzweil think A.I. will be a great gift to Mankind. Others like Bill Joy and Elon Musk are fearful of potential danger. Where do you stand, Linus?

Linus: I just don't see the thing to be fearful of.

We'll get AI, and it will almost certainly be through something very much like recurrent neural networks. And the thing is, since that kind of AI will need training, it won't be "reliable" in the traditional computer sense. It's not the old rule-based prolog days, when people thought they'd *understand* what the actual decisions were in an AI.

And that all makes it very interesting, of course, but it also makes it hard to productize. Which will very much limit where you'll actually find those neural networks, and what kinds of network sizes and inputs and outputs they'll have.

So I'd expect just more of (and much fancier) rather targeted AI, rather than anything human-like at all. Language recognition, pattern recognition, things like that. I just don't see the situation where you suddenly have some existential crisis because your dishwasher is starting to discuss Sartre with you.

The whole "Singularity" kind of event? Yeah, it's science fiction, and not very good SciFi at that, in my opinion. Unending exponential growth? What drugs are those people on? I mean, really..

It's like Moore's law - yeah, it's very impressive when something can (almost) be plotted on an exponential curve for a long time. Very impressive indeed when it's over many decades. But it's _still_ just the beginning of the "S curve". Anybody who thinks any different is just deluding themselves. There are no unending exponentials.



Is the kernel basically a finished project?
by NaCh0

Aside from adding drivers and refactoring algorithms when performance limits are discovered, is there anything left for the kernel? Maybe it's a failure of tech journalism but we never hear about the next big thing in kernel land anymore.

Linus: I don't think there's much of a "next big thing" in the kernel.

I wouldn't say that there is nothing but drivers (and architectures are kind of "CPU drivers) and improving scalability left, because I'm constantly amazed by how many new things people figure out are still good ideas. But they tend to still be pretty incremental improvements. An OS kernel doesn't look *that* radically different from what it was 40 years ago, and that's fine. I think radical new ideas are often overrated, and the thing that really matters in the end is that plodding detail work. That's how technology evolves.

And judging by how our kernel releases are going, there's no end in sight for that "plodding detail work". And it's still as interesting as it ever was.

HughPickens.com writes: Jake Edge writes at LWN.net that there is a myth that programming skill is somehow distributed on a U-shaped curve and that people either "suck at programming" or that they "rock at programming", without leaving any room for those in between. Everyone is either an amazing programmer or "a worthless use of a seat" which doesn't make much sense. If you could measure programming ability somehow, its curve would look like the normal distribution. According to Edge this belief that programming ability fits into a bi-modal distribution is both "dangerous and a myth". "This myth sets up a world where you can only program if you are a rock star or a ninja. It is actively harmful in that is keeping people from learning programming, driving people out of programming, and it is preventing most of the growth and the improvement we'd like to see." If the only options are to be amazing or terrible, it leads people to believe they must be passionate about their career, that they must think about programming every waking moment of their life. If they take their eye off the ball even for a minute, they will slide right from amazing to terrible again leading people to be working crazy hours at work, to be constantly studying programming topics on their own time, and so on.

The truth is that programming isn't a passion or a talent, says Edge, it is just a bunch of skills that can be learned. Programming isn't even one thing, though people talk about it as if it were; it requires all sorts of skills and coding is just a small part of that. Things like design, communication, writing, and debugging are needed. If we embrace this idea that "it's cool to be okay at these skills"—that being average is fine—it will make programming less intimidating for newcomers. If the bar for success is set "at okay, rather than exceptional", the bar seems a lot easier to clear for those new to the community. According to Edge the tech industry is rife with sexism, racism, homophobia, and discrimination and although it is a multi-faceted problem, the talent myth is part of the problem. "In our industry, we recast the talent myth as "the myth of the brilliant asshole", says Jacob Kaplan-Moss. "This is the "10x programmer" who is so good at his job that people have to work with him even though his behavior is toxic. In reality, given the normal distribution, it's likely that these people aren't actually exceptional, but even if you grant that they are, how many developers does a 10x programmer have to drive away before it is a wash?"

jrepin writes It has been roughly a year and a half since the last release of the GNU Hurd operating system, so it may be of interest to some readers that GNU Hurd 0.6 has been released along with GNU Mach 1.5 (the microkernel that Hurd runs on) and GNU MIG 1.5 (the Mach Interface Generator, which generates code to handle remote procedure calls). New features include procfs and random translators; cleanups and stylistic fixes, some of which came from static analysis; message dispatching improvements; integer hashing performance improvements; a split of the init server into a startup server and an init program based on System V init; and more.

jrepin writes It has been roughly a year and a half since the last release of the GNU Hurd operating system, so it may be of interest to some readers that GNU Hurd 0.6 has been released along with GNU Mach 1.5 (the microkernel that Hurd runs on) and GNU MIG 1.5 (the Mach Interface Generator, which generates code to handle remote procedure calls). New features include procfs and random translators; cleanups and stylistic fixes, some of which came from static analysis; message dispatching improvements; integer hashing performance improvements; a split of the init server into a startup server and an init program based on System V init; and more.

jrepin writes It has been roughly a year and a half since the last release of the GNU Hurd operating system, so it may be of interest to some readers that GNU Hurd 0.6 has been released along with GNU Mach 1.5 (the microkernel that Hurd runs on) and GNU MIG 1.5 (the Mach Interface Generator, which generates code to handle remote procedure calls). New features include procfs and random translators; cleanups and stylistic fixes, some of which came from static analysis; message dispatching improvements; integer hashing performance improvements; a split of the init server into a startup server and an init program based on System V init; and more.

First time accepted submitter bobo the hobo writesThe FreeBSD random number has been discovered to be generating possibly predictable SSH keys and SSL certificates for months. Time to regenerate your keys and certs if using FreeBSD-Current. A message to the freebsd-current mailing list reads in part: "If you are running a current kernel r273872 or later, please upgrade your kernel to r278907 or later immediately and regenerate keys. I discovered an issue where the new framework code was not calling randomdev_init_reader, which means that read_random(9) was not returning good random data. read_random(9) is used by arc4random(9) which is the primary method that arc4random(3) is seeded from."

First time accepted submitter Per Bothner (19354) writes "Kawa is a general-purpose Scheme-based programming language that runs on the Java platform. It combines the strengths of dynamic scripting languages (less boiler-plate, fast and easy start-up, a REPL, no required compilation step) with the strengths of traditional compiled languages (fast execution, static error detection, modularity, zero-overhead Java platform integration).

Version 2.0 was just released with many new features. Most notably is (almost) complete support for the latest Scheme specification, R7RS, which was ratified in late 2013. This LWN article contains a brief introduction to Kawa and why it is worth a look."

An anonymous reader writes "NFTables is queued up for merging into the Linux 3.13 kernel. NFTables is a four-year-old project by the creators of Netfilter to write a new packet filtering / firewall engine for the Linux kernel to deprecate iptables (though it now offers an iptables compatibility layer too). NFTables promises to be more powerful, simpler, reduce code complication, improve error reporting, and provide more efficient handling of packet filter rules. The code was merged into net-next for the Linux 3.13 kernel. Iptables will still be present until NFTables is finished, but it is possible to try it out now. LWN also has a writeup on NFTables."

Hugh Pickens DOT Com writes "Ed Felton writes about an incident, in 2003, in which someone tried to backdoor the Linux kernel. Back in 2003 Linux used BitKeeper to store the master copy of the Linux source code. If a developer wanted to propose a modification to the Linux code, they would submit their proposed change, and it would go through an organized approval process to decide whether the change would be accepted into the master code. But some people didn't like BitKeeper, so a second copy of the source code was kept in CVS. On November 5, 2003, Larry McAvoy noticed that there was a code change in the CVS copy that did not have a pointer to a record of approval. Investigation showed that the change had never been approved and, stranger yet, that this change did not appear in the primary BitKeeper repository at all. Further investigation determined that someone had apparently broken in electronically to the CVS server and inserted a small change to wait4: 'if ((options == (__WCLONE|__WALL)) && (current->uid = 0)) ...' A casual reading makes it look like innocuous error-checking code, but a careful reader would notice that, near the end of the first line, it said '= 0' rather than '== 0' so the effect of this code is to give root privileges to any piece of software that called wait4 in a particular way that is supposed to be invalid. In other words it's a classic backdoor. We don't know who it was that made the attempt—and we probably never will. But the attempt didn't work, because the Linux team was careful enough to notice that that this code was in the CVS repository without having gone through the normal approval process. 'Could this have been an NSA attack? Maybe. But there were many others who had the skill and motivation to carry out this attack,' writes Felton. 'Unless somebody confesses, or a smoking-gun document turns up, we'll never know.'"

An anonymous reader sends this quote from an article at Wired: "In a dramatic about-face on a key internet issue yesterday, Google told the FCC (PDF) that the network neutrality rules Google once championed don't give citizens the right to run servers on their home broadband connections, and that the Google Fiber network is perfectly within its rights to prohibit customers from attaching the legal devices of their choice to its network."

From Joe Armstrong comes news that Erlang will soon feature a new process flag for those processes that just really need memory, or else: "Too big to fail processes behave like regular processes until they get too big and memory congestion occurs. If a memory allocation error is triggered when a too_big_to_fail process needs more memory, then a random smaller process is killed, and the system reattempts memory allocation for the too_big_to_fail process. An interesting situation can occur if the too big to fail process has killed all other processes and still cannot get enough memory. In this case the node running the process tries to memory steal from other nodes." Read below for your FREE logged-in-reader's-eye view of the special rot-39 version!

Sebz Wbr Nezfgebat pbzrf arjf gung Reynat jvyy fbba srngher n arj cebprff synt sbe gubfr cebprffrf gung whfg ernyyl arrq zrzbel, be ryfr: "Gbb ovt gb snvy cebprffrf orunir yvxr erthyne cebprffrf hagvy gurl trg gbb ovt naq zrzbel pbatrfgvba bpphef. Vs n zrzbel nyybpngvba reebe vf gevttrerq jura n gbb_ovt_gb_snvy cebprff arrqf zber zrzbel, gura n enaqbz fznyyre cebprff vf xvyyrq, naq gur flfgrz ernggrzcgf zrzbel nyybpngvba sbe gur gbb_ovt_gb_snvy cebprff. Na vagrerfgvat fvghngvba pna bpphe vs gur gbb ovt gb snvy cebprff unf xvyyrq nyy bgure cebprffrf naq fgvyy pnaabg trg rabhtu zrzbel. Va guvf pnfr gur abqr ehaavat gur cebprff gevrf gb zrzbel fgrny sebz bgure abqrf."

From Joe Armstrong comes news that Erlang will soon feature a new process flag for those processes that just really need memory, or else: "Too big to fail processes behave like regular processes until they get too big and memory congestion occurs. If a memory allocation error is triggered when a too_big_to_fail process needs more memory, then a random smaller process is killed, and the system reattempts memory allocation for the too_big_to_fail process. An interesting situation can occur if the too big to fail process has killed all other processes and still cannot get enough memory. In this case the node running the process tries to memory steal from other nodes." Read below for your FREE logged-in-reader's-eye view of the special rot-39 version!

Sebz Wbr Nezfgebat pbzrf arjf gung Reynat jvyy fbba srngher n arj cebprff synt sbe gubfr cebprffrf gung whfg ernyyl arrq zrzbel, be ryfr: "Gbb ovt gb snvy cebprffrf orunir yvxr erthyne cebprffrf hagvy gurl trg gbb ovt naq zrzbel pbatrfgvba bpphef. Vs n zrzbel nyybpngvba reebe vf gevttrerq jura n gbb_ovt_gb_snvy cebprff arrqf zber zrzbel, gura n enaqbz fznyyre cebprff vf xvyyrq, naq gur flfgrz ernggrzcgf zrzbel nyybpngvba sbe gur gbb_ovt_gb_snvy cebprff. Na vagrerfgvat fvghngvba pna bpphe vs gur gbb ovt gb snvy cebprff unf xvyyrq nyy bgure cebprffrf naq fgvyy pnaabg trg rabhtu zrzbel. Va guvf pnfr gur abqr ehaavat gur cebprff gevrf gb zrzbel fgrny sebz bgure abqrf."

jrepin writes "On day two of the 2013 Embedded Linux Conference, Robert Rose of SpaceX spoke about the 'Lessons Learned Developing Software for Space Vehicles.' In his talk, he discussed how SpaceX develops its Linux-based software for a wide variety of tasks needed to put spacecraft into orbit—and eventually beyond. Linux runs everywhere at SpaceX, he said, on everything from desktops to spacecraft."

An anonymous reader writes "LWN.net is reporting that GNOME developer Matthias Clasen has announced that, with the upcoming demise of 'fallback mode,' the project will support a set of official GNOME Shell extensions to provide a more "classic" experience. 'And while we certainly hope that many users will find the new ways comfortable and refreshing after a short learning phase, we should not fault people who prefer the old way. After all, these features were a selling point of GNOME 2 for ten years!'"

Artefacto writes "The Ksplice team has made available a git repository with the changes Red Hat made to the kernel broken down. They are calling this project RedPatch. This comes in response to a policy change Red Hat had implemented in early 2011, with the goal of undercutting Oracle and other vendors' strategy of poaching Red Hat's customers. The Ksplice team says they've been working on these individual patches since then. They claim to be now making it public because they 'feel everyone in the Linux community can benefit from the work.' 'For Ksplice, we build individual updates for each change and rely on source patches that are broken-out, not a giant tarball. Otherwise, we wouldn't be able to take the right patches to create individual updates for each fix, and to skip over the noise — like a change that speeds up bootup — which is unnecessary for an already-running system.'"

DMA-BUF is a recent kernel feature that allows multiple GPUs to quickly copy data into each others' framebuffers. A use case would be the NVIDIA Optimus that pairs a fast GPU with an Intel integrated GPU, where the NVIDIA GPU writes into the Intel framebuffer when it is active. But, NVIDIA won't be able to use this infrastructure because it's GPL. Alan Cox replied on LKML to a request from one of their engineers to mark the API non-GPL: "NAK. This needs at the very least the approval of all rights holders for the files concerned and all code exposed by this change. Also I'd note if you are trying to do this for the purpose of combining it with proprietary code then you are still in my view as a (and the view of many other) rights holder to the kernel likely to be in breach of the GPL requirements for a derivative work. You may consider that formal notification of my viewpoint. Your corporate legal team can explain to you why the fact you are now aware of my view is important to them." The rest of the thread is worth a read (a guy from RedHat agrees that this code is GPL and cannot become non-GPL without relicensing from a major subset of graphics system contributors). This has a ripple effect: it means that all of the ARM SoC GPU drivers can't use it either, and it may prevent any proprietary drivers for the proposed DRI version 3.

DMA-BUF is a recent kernel feature that allows multiple GPUs to quickly copy data into each others' framebuffers. A use case would be the NVIDIA Optimus that pairs a fast GPU with an Intel integrated GPU, where the NVIDIA GPU writes into the Intel framebuffer when it is active. But, NVIDIA won't be able to use this infrastructure because it's GPL. Alan Cox replied on LKML to a request from one of their engineers to mark the API non-GPL: "NAK. This needs at the very least the approval of all rights holders for the files concerned and all code exposed by this change. Also I'd note if you are trying to do this for the purpose of combining it with proprietary code then you are still in my view as a (and the view of many other) rights holder to the kernel likely to be in breach of the GPL requirements for a derivative work. You may consider that formal notification of my viewpoint. Your corporate legal team can explain to you why the fact you are now aware of my view is important to them." The rest of the thread is worth a read (a guy from RedHat agrees that this code is GPL and cannot become non-GPL without relicensing from a major subset of graphics system contributors). This has a ripple effect: it means that all of the ARM SoC GPU drivers can't use it either, and it may prevent any proprietary drivers for the proposed DRI version 3.

MojoKid writes "Intel's next-generation CPU architecture, codenamed Haswell, puts heavy emphasis on reducing power consumption. Pushing Haswell down to a 10W TDP is an achievement, but hitting these targets requires collaboration. Haswell will offer finer-grained control over areas of logic that were previously either on or off, up to and including specific execution units. These optimizations are impressive, particularly the fact that idle CPU power is approaching tablet levels, but they're only part of the story. Operating system changes matter as well, and Intel has teamed up with Microsoft to ensure that Windows 8 takes advantage of current and future hardware. Haswell's 10W target will allow the chip to squeeze into many of the convertible laptop/tablet form factors on display at IDF, while Bay Trail, the 22nm, out-of-order successor to Clover Trail, arrives in 2013 as well. Not to mention the company's demonstration of the first integrated digital WiFi radio. Folks have been trading blows over whether Intel could compete with ARM's core power consumption. Meanwhile, Santa Clara has been busy designing many other aspects of the full system solution for low power consumption and saving a lot of wattage in the process." It's mildly amusing that Windows 8 is the first version to gain dynamic ticks, something Linux has had working since around 2007.

mtaht writes "Has anyone, besides those that worked on byte queue limits, and sfqred, had a chance to benchmark networking using these tools on the Linux 3.3 kernel in the real world? A dent, at least theoretically, seems to be have made in bufferbloat, and now that the new kernel and new iproute2 are out, should be easy to apply in general (e.g. server/desktop) situations." Dear readers: Have any of you had problems with bufferbloat that were alleviated by the new kernel version?

LinuxScribe writes with this bit from IT World: "In an effort to foil crackers' attempts to cover their tracks by altering text-based syslogs, and improve the syslog process as a whole, developers Lennart Poettering and Kay Sievers are proposing a new tool called The Journal. Using key/value pairs in a binary format, The Journal is already stirring up a lot of objections." Log entries are "cryptographically hashed along with the hash of the previous entry in the file" resulting in a verifiable chain of entries. This is being done as an extension to systemd (git branch). The design doesn't just make logging more secure, but introduces a number of overdue improvements to the logging process. It's even compatible with the standard syslog interface allowing it to either coexist with or replace the usual syslog daemon with minimal disruption.

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

Julie188 writes "Windows 8 PCs will use the next-generation booting specification known as Unified Extensible Firmware Interface (UEFI). In fact, Windows 8 logo devices will be required to use the secure boot portion of the new spec. Secure UEFI is intended to thwart rootkit infections by using PKI authentication before allowing executables or drivers to be loaded onto the device. Problem is, unless the device manufacturer gives a key to the device owner, it can also be used to keep the PC's owner from wiping out the current OS and installing another option, such as Linux."

halfaperson writes "In an interview with LinuxFr.org, Lennart Poettering speaks freely about his creations, PulseAudio, Avahi and systemd among other things. Naturally, what has stirred up most of the discussions online is Lennart's opinions on BSD. Following the recent proposal to make Gnome a Linux-exclusive desktop, Lennart explains that he thinks BSD support is holding back a lot of Free Software development. He says this while also taking a stab at Debian kFreeBSD: 'Debian kFreeBSD is a toy OS, people really shouldn't misunderstand that.'"

recoiledsnake writes "The upcoming release of Mac OS X 10.7 Lion Server will remove the formerly bundled open source Samba software and replace it with Apple's own tools for Windows file sharing and network directory services. In both Mac OS X Server and client editions, Samba enables Macs to share files with Windows clients on the network and access Windows file servers. It has also later allowed Mac OS X Server to work as an NT Domain Controller to manage network accounts and make roaming profiles and home directories available to Windows PC users. However, the Samba team has moved active development of the project to the more strict GPLv3 license, which prevents Apple from using the software commercially. Apple is now said to be recommending Active Directory to users who are still dependent upon the older NT Domain Controller network directory services. Apple has previously stopped contributing code to GCC and started looking at other options like LLVM because of GCC's switch to GPLv3."

mvar writes to point out a report from h-online about the Red Hat kernel source controversy. From the article: "Red Hat has changed the way it ships the source code for the Linux kernel. Previously, it was released as a standard kernel with a collection of patches which could be applied to create the source code of the kernel Red Hat used. Now though, the company ships a tarball of the source code with the patches already applied. This change, noted by Maxillian Attems and LWN.net, appears to be aimed at Oracle, who like others, repackage Red Hat's source as the basis for its Unbreakable Linux. Although targeted at Oracle, the changes will make work harder for distributions such as CentOS."

Josh Triplett writes "Intel announced the release of a BIOS Implementation Test Suite (BITS), a bootable pre-OS environment based on GNU GRUB2 that tests how well (or how badly) your BIOS has configured your platform hardware. BITS also includes Intel's official power management reference code, so you can override your BIOS's initialization with a known-good configuration. 'In addition to those changes to GRUB2 itself, BITS includes configuration files which build a menu exposing the various BITS functionality, including the test suites, hardware configuration, and exploratory tools. These scripts detect your system's CPU, and provide menu entries for all the available functionality on your hardware platform. You can also access all of the new commands we've added directly via the command line.'"

eldavojohn writes "Linus has announced the release of 2.6.35 for people to download and test after he found not a lot of changes between this week and last. The big features to look out for include: 'Transparent spreading of incoming network traffic load across CPUs, Btrfs improvements, KDB kernel debugger frontend, Memory compaction and Support for multiple multicast route tables' as well as various performance and graphics improvements. Linus also praised the community saying that 'regression changes only' after rc1 improved this time around and gave numbers to back it up saying 'in the 2.6.34 release, there were 3800 commits after -rc1, but in the current 35 release cycle we had less than 2000.' Good to see the process is becoming more refined and controlled after the first release candidate — hopefully there's no impending burnout."

Hugh Pickens writes "Katherine Noyes writes at LinuxInsider that it may be time for Linus Torvalds to share more of the responsibility for Linux that he's been shouldering. 'If Linux wants to keep up with the competition there is much work to do, more than even a man of Linus's skill [can] accomplish,' argues one user. The 'scalability of Linus' is the subject of a post by Jonathan Corbet wondering if there might there be a Linus scalability crunch point coming. 'The Linux kernel development process stands out in a number of ways; one of those is the fact that there is exactly one person who can commit code to the "official" repository,' Corbet writes. A problem with that scenario is the potential for repeats of what Corbet calls 'the famous "Linus burnout" episode of 1998' when everything stopped for a while until Linus rested a bit, came back, and started merging patches again. 'If Linus is to retain his central position in Linux kernel development, the community as a whole needs to ensure that the process scales and does not overwhelm him,' Corbet adds. But many don't agree. 'Don't be fooled that Linus has to scale — he has to work hard, but he is the team captain and doorman. He has thousands doing most of the work for him. He just has to open the door at the appropriate moment,' writes Robert Pogson, adding that Linus 'has had lots of practice and still has fire in his belly.'"

Josh Triplett writes "Last October, Mozilla accepted the China Internet Network Information Center as a trusted CA root (Bugzilla entry). This affects Firefox, Thunderbird, and other products built on Mozilla technologies. The standard period for discussion passed without comment, and Mozilla accepted CNNIC based on the results of a formal audit. Commenters in the bug report and the associated discussion have presented evidence that the Chinese government controls CNNIC, and surfaced claims of malware production and distribution and previous man-in-the-middle attacks in China via their secondary CA root from Entrust. As usual, please refrain from blindly chiming into the discussion without supporting evidence. Since Mozilla has already accepted CNNIC as a trusted root CA, the burden rests with those who argue for its removal."

postfail writes 'lwn.net coverage of the 2009 Linux Kernel Summit includes a recap of a presentation by Google engineers on how they use Linux. According to the article, a team of 30 Google engineers is rebasing to the mainline kernel every 17 months, presently carrying 1208 patches to 2.6.26 and inserting almost 300,000 lines of code; roughly 25% of those patches are backports of newer features.'

postfail writes 'lwn.net coverage of the 2009 Linux Kernel Summit includes a recap of a presentation by Google engineers on how they use Linux. According to the article, a team of 30 Google engineers is rebasing to the mainline kernel every 17 months, presently carrying 1208 patches to 2.6.26 and inserting almost 300,000 lines of code; roughly 25% of those patches are backports of newer features.'

H4x0r Jim Duggan writes "Veteran violation chasers Shane Coughlan and Armijn Hemel have summarized how license violations are caused in the consumer electronics market under time-to-market pressure and thin profit margins: 'This problem is compounded when one board with a problem appears in devices supplied to a number of western companies. A host of violation reports spanning a dozen European and American businesses may eventually point towards a single mistake during development at an Asian supplier.' They also discuss the helpful organizations which have sprung up and the documents and procedures now available."

diegocgteleline.es writes "Valerie Aurora, a Linux file system developer and ex-ZFS designer, has posted an article with great insight on how Btrfs, the file system that will replace Ext4, was created and how it works. Quoting: 'When it comes to file systems, it's hard to tell truth from rumor from vile slander: the code is so complex, the personalities are so exaggerated, and the users are so angry when they lose their data. You can't even settle things with a battle of the benchmarks: file system workloads vary so wildly that you can make a plausible argument for why any benchmark is either totally irrelevant or crucially important. ... we'll take a behind-the-scenes look at the design and development of Btrfs on many levels — technical, political, personal — and trace it from its origins at a workshop to its current position as Linus's root file system.'"