Linus Torvalds announced on Sunday that he was sorry for how he treated the community over the years. Torvalds, 48, said he planned to make some changes to how he conducted himself, and on that part, he said he would be taking some time off from Linux kernel development work. The New Yorker has published a story on Torvalds today in which it notes that it reached out to Torvalds days before he made the big announcement. From the story, which may be paywalled for some readers: Torvalds's decision to step aside came after The New Yorker asked him a series of questions about his conduct for a story on complaints about his abusive behavior discouraging women from working as Linux-kernel programmers. In a response to The New Yorker, Torvalds said, "I am very proud of the Linux code that I invented and the impact it has had on the world. I am not, however, always proud of my inability to communicate well with others -- this is a lifelong struggle for me. To anyone whose feelings I have hurt, I am deeply sorry."

Torvalds's response was conveyed by the Linux Foundation, which supports Linux and other open-source programming projects and paid Torvalds $1.6 million in annual compensation as of 2016. The foundation said that it supported his decision and has encouraged women to participate but that it has little control over how Torvalds runs the coding process. "We are able to have varying degrees of impact on these outcomes in newer projects," the statement said. "Older more established efforts like the Linux kernel are much more challenging to influence."

Linux's elite developers, who are overwhelmingly male, tend to share their leader's aggressive self-confidence. There are very few women among the most prolific contributors, though the foundation and researchers estimate that roughly ten per cent of all Linux coders are women. "Everyone in tech knows about it, but Linus gets a pass," Megan Squire, a computer-science professor at Elon University, told me, referring to Torvalds's abusive behavior. "He's built up this cult of personality, this cult of importance."

LLVM release manager Hans Wennborg announced Wednesday the official availability of LLVM 7.0 compiler stack as well as associated sub-projects including the Clang 7.0 C/C++ compiler front-end, Compiler-RT, libc++, libunwind, LLDB, and others. From a report: There is a lot of LLVM improvements ranging from CPU improvements for many different architectures, Vega 20 support among many other AMDGPU back-end improvements, the new machine code analyzer utility, and more. The notable Clang C/C++ compiler has picked up support for function multi-versioning (FMV), initial OpenCL C++ support, and many other additions. See my LLVM 7.0 / Clang 7.0 feature overview for more details on the changes with this six-month open-source compiler stack update. Wennborg's release statement can be read on the llvm-announce list.

Liam Tung reporting for ZDNet: Ubuntu maintainer Canonical and Microsoft have teamed up to release an optimized Ubuntu Desktop image that's available through Microsoft's Hyper-V gallery. The Ubuntu Desktop image should deliver a better experience when running it as a guest on a Windows 10 Pro host, according to Canonical. The optimized version is Ubuntu Desktop 18.04.1 LTS release, also known as Bionic Beaver. Microsoft's work with Canonical was prompted by its users who wanted a "first-class experience" on Linux virtual machines (VMs) as well as Windows VMs. To achieve this goal, Microsoft worked with the developers of XRDP, an open-source remote-desktop protocol (RDP) for Linux based on Microsoft's RDP for Windows. Thanks to that work, XRDP now supports Microsoft's Enhanced Session Mode, which allows Hyper-V to use the open-source implementation of RDP to connect to Linux VMs. This in turn gives Ubuntu VMs on Windows hosts a better mouse experience, an integrated clipboard, windows resizing, and shared folders for easier file transfers between host and guest. Microsoft's Hyper-V Quick Create VM setup wizard should also help improve the experience. "With the Hyper-V Quick Create feature added in the Windows 10 Fall Creators Update, we have partnered with Ubuntu and added a virtual machine image so in a few quick minutes, you'll be up and developing," said Clint Rutkas, a senior technical product manager on Microsoft's Windows Developer Team. "This is available now -- just type 'Hyper-V Quick Create' in your start menu."

Google has released a Chrome OS 69 update that introduces a range of new features. From a report: Most notably, there's now support for running Linux apps. You'll need a supported machine (a handful of machines from Acer, ASUS, HP, Lenovo, Samsung and Google itself). Still, this could be more than a little helpful if you want to run a conventional desktop app or command line terminal without switching to another PC or a virtual environment. The new software also adds the long-in-the-making Night Light mode to ease your eyes at the end of the day. Voice dictation is now available in any text field, and there's a fresh Files interface that can access Play files and Team Drives.

An anonymous reader shares a report: Over on the EEVblog, someone noticed an interesting chip that's been apparently flying under our radar for a while. This is an ARM processor capable of running Linux. It's hand-solderable in a TQFP package, has a built-in Mali GPU, support for a touch panel, and has support for 512MB of DDR3. If you do it right, this will get you into the territory of a BeagleBone or a Raspberry Pi Zero, on a board that's whatever form factor you can imagine. Here's the best part: you can get this part for $1 USD in large-ish quantities. A cursory glance at the usual online retailers tells me you can get this part in quantity one for under $3. This is interesting, to say the least.

The chip in question, the Allwinner A13, is a 1GHz ARM Cortex-A8 processor. While it's not much, it is a chip that can run Linux in a hand-solderable package. There is no HDMI support, you'll need to add some more chips (that are probably in a BGA package), but, hey, it's only a dollar. If you'd like to prototype with this chip, the best options right now are a few boards from Olimex, and a System on Module from the same company. That SoM is an interesting bit of kit, allowing anyone to connect a power supply, load an SD card, and get this chip doing something. Currently, there aren't really any good solutions for a cheap Linux system you can build at home, with hand-solderable chips.

Following Linus Torvalds' public apology for his behavior over the years, the Linux Community said it will be adopting a new "Code of Conduct", which pledges to make "participation in our project and our community a harassment-free experience for everyone, regardless of age, body size, disability, ethnicity, sex characteristics, gender identity and expression, level of experience, education, socio-economic status, nationality, personal appearance, race, religion, or sexual identity and orientation."

On Sunday, Linus Torvalds spoke about the confusion he had regarding Maintainer's Summit, but more importantly, how this incident gave him a chance to realize "that I really had been ignoring some fairly deep-seated feelings in the community." In an email to the Linux Kernel Mailing List, Torvalds apologized for hurting people with his behavior over the years, and possibly driving some people "away from kernel development entirely." On that end, said Torvalds, "I am going to take time off and get some assistance on how to understand people's emotions and respond appropriately." He wrote: [...] It's one thing when you can ignore these issues. Usually it's just something I didn't want to deal with. This is my reality. I am not an emotionally empathetic kind of person and that probably doesn't come as a big surprise to anybody. Least of all me. The fact that I then misread people and don't realize (for years) how badly I've judged a situation and contributed to an unprofessional environment is not good. This week people in our community confronted me about my lifetime of not understanding emotions. My flippant attacks in emails have been both unprofessional and uncalled for. Especially at times when I made it personal. In my quest for a better patch, this made sense to me. I know now this was not OK and I am truly sorry.

The above is basically a long-winded way to get to the somewhat painful personal admission that hey, 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.

Put another way: When asked at conferences, I occasionally talk about how the pain-points in kernel development have generally not been about the _technical_ issues, but about the inflection points where development flow and behavior changed. These pain points have been about managing the flow of patches, and often been associated with big tooling changes - moving from making releases with "patches and tar-balls" (and the _very_ painful discussions about how "Linus doesn't scale" back 15+ years ago) to using BitKeeper, and then to having to write git in order to get past the point of that no longer working for us. We haven't had that kind of pain-point in about a decade. But this week felt like that kind of pain point to me. To tie this all back to the actual 4.19-rc4 release (no, really, this_is_ related!) I actually think that 4.19 is looking fairly good, things have gotten to the "calm" period of the release cycle, and I've talked to Greg to ask him if he'd mind finishing up 4.19 for me, so that I can take a break, and try to at least fix my own behavior.

This is not some kind of "I'm burnt out, I need to just go away" break. I'm not feeling like I don't want to continue maintaining Linux. Quite the reverse. I very much *do* want to continue to do this project that I've been working on for almost three decades. This is more like the time I got out of kernel development for a while because I needed to write a little tool called "git". I need to take a break to get help on how to behave differently and fix some issues in my tooling and workflow.

And yes, some of it might be "just" tooling. Maybe I can get an email filter in place so at when I send email with curse-words, they just won't go out. Because hey, I'm a big believer in tools, and at least _some_ problems going forward might be improved with simple automation. [...]

Here's an analysis of the Linux kernel repository that attempts to find some fresh numbers on the current kernel development trends. He writes: The kernel repository is at 782,487 commits in total from around 19.009 different authors. The repository is made up of 61,725 files and from there around 25,584,633 lines -- keep in mind there is also documentation, Kconfig build files, various helpers/utilities, etc. So far this year there has been 49,647 commits that added 2,229,836 lines of code while dropping 2,004,759 lines of code. Or a net gain of just 225,077 lines. Keep in mind there was the removal of some old CPU architectures and other code removed in kernels this year so while a lot of new functionality was added, thanks to some cleaning, the kernel didn't bloat up as much as one might have otherwise expected. In 2017 there were 80,603 commits with 3,911,061 additions and 1,385,507 deletions. Given just over one quarter to go, on a commit and line count 2018 might come in lower than the two previous years.

Linus Torvalds remains the most frequent committer at just over 3% while the other top contributions to the kernel this year are the usual suspects: David S. Miller, Arnd Bergmann, Colin Ian King, Chris Wilson, and Christoph Hellwig. So far in 2018 there were commits from 3,320 different email addresses. This is actually significantly lower than in previous years.

Longtime Slashdot reader DrYak writes: Phoronix is reporting that multiple users who all use Wine and DXVK compatibility layers have seen their Overwatch accounts banned by Blizzard. Previously, Blizzard has stated: "playing on Linux or even a Mac while on an emulated Windows environment is not bannable." But users report on Reddit getting banned simply after testing some rendering options. Tech support has answered that they are escalating the ticket and trying to take a closer look, hoping to avoid this from happening to other Linux users. According to Phoronix, the most common explanation for the bans "is a false-positive from Blizzard's anti-cheat technology having issue with DXVK."

An anonymous reader quotes a report from ZDNet: Users of Kodi, a popular media player and platform designed for TVs and online streaming, have been the targets of a malware campaign, ZDNet has learned from cyber-security firm ESET. According to a report that will be published later today and shared with ZDNet in advance, the company's malware analysts have uncovered that at least three popular repositories of Kodi add-ons have been infected and helped spread a malware strain that secretly mined cryptocurrency on users' computers.

ESET researchers say they found malicious code hidden in some of the add-ons found on three add-on repositories known as Bubbles, Gaia, and XvBMC, all offline at the time of writing, after receiving copyright infringement complaints. Researchers said that some of the add-ons found on these repositories would contain malicious code that triggered the download of a second Kodi add-on, which, in turn, would contain code to fingerprint the user's OS and later install a cryptocurrency miner. While Kodi can run on various platforms, ESET says that the operators of this illicit cryptocurrency mining operation only delivered a miner for Windows and Linux users. The crooks reportedly mined for Monero, infecting over 4,700 victims and generating over 62 Monero coins, worth today nearly $7,000.

Designed to run on minimal hardware, Elive is very much a passion project of its leader, Samuel F Baggen. Based on Debian, the first version took a bow in 2005. The second stable version made an appearance in 2010 and it has been a long eight years for the third stable version to become available. The Register: Elive has an impressively low bar to entry, with hardware requirements for the distribution coming in at 256 MB RAM and a 500 MHz CPU, meaning that some very elderly silicon is theoretically going to be able to enjoy the highly polished Enlightenment desktop. "Theoretically" because after The Register took Elive 3.0.0 out for a spin on a relatively low-powered laptop, we'd frankly baulk at running it on anything much slower than a 533MHz Core 2 with at least 512 MB RAM. However, the Enlightenment UI is undeniably an attractive desktop, particularly if a macOS-alike dock is your thing, and runs at an impressive lick even on hardware that lacks graphics acceleration.

At its core, Elive is based on the Debian 8 distribution (aka Jessie), using the 3.16 kernel and version 0.17.6 of the Enlightenment X11 Window Manager. It comes replete with a full set of applications, including the ubiquitous LibreOffice and Gimp, along with a variety of productivity and entertainment tools, some of which are Elive's own. Unlike the previous version of Elive, 3.0.0 removes the requirement of donating to the project in order to install the thing locally (although Baggen was quick to tell The Reg that cost-free alternatives existed, but often with annoying processes).

At this year's Open Source Summit, Linus Torvalds sat for a wide-ranging "keynote" interview with Dirk Hohndel, chief open source officer at VMWare, which has been partially transcribed below. And Linus explained, among other things, why the last merge window was harder than others: One of the issues we have is when we've had these hardware security issues, and they've kept happening now, the last year -- they're kept under wraps. So we knew about the issue for the last several months, but because it was secret and we weren't allowed to talk about it, we couldn't do our usual open development model. We do the best we can, and people really care deeply about getting a good product out, but when you have to do things in secret, and when you can't use all the nice infrastructure for development and for testing that we have for all the usual code, it just is way more painful than it should be. And then that just means that, especially when the information becomes public during what is otherwise a busy period anyway, it's just annoying...

I still love speculative execution. Don't get me wrong. I used to work for a CPU company. We did it in software, back when I worked there. I think a CPU has to do speculative execution. It's somewhat sad that then people didn't always think about or didn't always heed the warnings about what can go wrong when you take a few shortcuts in the name of making it slightly simpler for everybody, because you're going to throw away all that work anyway, so why bother to do it right. And that's when the security -- every single security problem we've had has been basically of that kind, where people knew that "Hey, this is speculative work. If something goes wrong we'll throw all the data away, so we don't need to be as careful as we would otherwise." I think it was a good lesson for the industry, but it was certainly not a fun lesson for us on the OS side, where we had to do a lot of extra work for problems that weren't our problems.

It feels somehow unfair. I mean, when we have a security bug that was our own fault, it's like, "Okay, it was us screwing up. It's fair that we have to do all the work to then fix our own bugs." But it feels slightly less fair when you have to fix somebody else's...
"The good news -- I mean the really good news, and I'm serious about this -- is that the bugs have become clearly more and more esoteric," Linus adds. "So it impacts fewer and fewer cases, and clearly hardware people at Intel and other places are now so aware of it that I'm hoping we're really getting to the dregs of the hardware security bugs, and going forward we'll have much fewer of them. I think we're going to the better days, when A.) we got the bugs fixed, and B.) people were thinking about them beforehand."

There's a lot more, so read on for more excerpts...

From The Linux Foundation's mailing list: Last Friday (just before Labor Day) I learned that Linus had gotten confused about when and where the Maintainer's Summit was going to be held this year. And most unfortunately, he has already scheduled a family vacation overlapping with the week of the Maintainer's Summit. Over the weekend, I've been conferring with folks from the Linux Foundation, Linus, and the Maintainer's / Kernel Summit program committee. We explored a lot of options, but ultimately there were only two choices that were workable:
1) Have the Maintainer's Summit in Vancouver, without Linus.
2) Move the Maintainer's Summit to Edinburgh, with Linus.

Curiously enough, Linus suggested option #1. And while holding the Maintainer's Summit without Linus might be an interesting experiment, ultimately, the Program Committee had a strong consensus that moving it Summit to Edinburgh was the better option.

This means that the Maintainer's Summit will take place in Edinburgh, on Monday afternoon, October 22nd. As a reminder, the Maintainer's Summit is an invite-only workshop, with ~30 people attending. The focus of the Maintainer's Summit is process and development issues, *not* technical issues. The Kernel Summit track will still be held in Vancouver alongside Plumber's. Technical discussions will take place there; we simply won't have the time, or necessarily, the right people, to have technical discussions at the Maintainer's Summit.

This week in Vancouver, Linux kernel developer Greg Kroah-Hartman criticized Intel's slow initial response to the Spectre and Meltdown bugs in a talk at the Open Source Summit North America. An anonymous reader quotes eWeek: Kroah-Hartman said that when Intel finally decided to tell Linux developers, the disclosure was siloed.... "Intel siloed SUSE, they siloed Red Hat, they siloed Canonical. They never told Oracle, and they wouldn't let us talk to each other." For an initial set of vulnerabilities, Kroah-Hartman said the different Linux vendors typically work together. However, in this case they ended up working on their own, and each came up with different solutions. "It really wasn't working, and a number of us kernel developers yelled at [Intel] and pleaded, and we finally got them to allow us to talk to each other the last week of December [2017]," he said. "All of our Christmas vacations were ruined. This was not good. Intel really messed up on this," Kroah-Hartman said...

"The majority of the world runs Debian or they run their own kernel," Kroah-Hartman said. "Debian was not allowed to be part of the disclosure, so the majority of the world was caught with their pants down, and that's not good." To Intel's credit, Kroah-Hartman said that after Linux kernel developers complained loudly to the company in December 2017 and into January 2018, it fixed its disclosure process for future Meltdown- and Spectre-related vulnerabilities... "Intel has gotten better at this," he said.

An interesting side effect of the Meltdown and Spectre vulnerabilities is that Linux and Windows developers are now working together, since both operating systems face similar risks from the CPU vulnerabilities. "Windows and Linux kernel developers now have this wonderful back channel. We're talking to each other and we're fixing bugs for each other," Kroah-Hartman said. "We are working well together. We have always wanted that."

"Using the newly minted Linux 4.19 feature code, fresh benchmarks were carried out looking at the performance cost of Spectre/Meltdown/Foreshadow mitigations on Intel Xeon v. AMD EPYC CPUs," writes an anonymous Slashdot reader: Workloads affected by these CPU vulnerabilities mainly deal with I/O and frequent kernel calls while CPU bound tests are still found to be minimally impacted. When toggling these mitigations on Linux 4.19, Intel Xeon CPUs were found to be 10~15% slower with the default kernel while AMD EPYC CPUs dropped to about 5% slower.

darthcamaro writes: In a wide-ranging conversation at the Open Source Summit, Linus Torvalds admitted that he no longer knows everything that's in LInux. "Nobody knows the whole kernel anymore," Torvalds said. "Having looked at patches for many years, I know the big picture of all the areas in the kernel and I can look at a patch and know if it's right or wrong." Overall, he emphasized that being open source has enabled Linux to attract new developers that can pick up code and maintain all the various systems in Linux. In his view, the only way to deal with complexity is to be open. "When you have complexity you can't manage it in a closed environment, you need to have the people that actually find problems and give them the ability to get involved and help you to fix them," Torvalds said. "It's a complicated world and the only way to deal with complexity is the open exchange of ideas."

Will Townsend, a senior analyst at Moor Insights & Strategy research firm, writes: As it relates to networking, the Linux Foundation is currently focused on a number of projects that are bringing top networking vendors, operators, service providers, and users together. Among the top initiatives are the Open Network Automation Platform (ONAP) and Data Plane Development Kit (DPDK). In this article, I would like to dive into both of these initiatives and share my perspective on how each is transforming the nature of networking [Editor's note: the website may have auto-playing videos; an alternative link was not available].

It makes sense that ONAP's releases are named after global cities, considering the platform's growing global footprint. ONAP is aimed at bringing real-time automation and orchestration to both physical and virtualized network functions. The first release in the fall of 2017, named Amsterdam, delivered a unified architecture for providing closed-loop networking automation. The underlying framework ensured a level of modularity to facilitate future functionality as well as standards harmonization and critical upstream partner collaboration. Initial use cases centered on Voice Over LTE (VoLTE) services as well as Virtualized Consumer Premise Equipment (vCPE). Both are extremely cost disruptive from a deployment and management perspective and deliver enhanced service provider agility. What I find extremely compelling is that Amsterdam was only an eight-month development cycle from start to release. That's an amazing feat even in the fast-paced technology industry.

[...] DPDK was an effort initially led by Intel at its inception nearly eight years ago, but became a part of the Linux Foundation back in 2017. At a high level, the technology accelerates packet processing workloads running on a variety of CPU architectures. DPDK is aimed at improving overall network performance, delivering enhanced encryption for improved security and optimizing lower latency applications that require lightning-fast response time. The transformative power of 5G networks lies in their potential to deliver low latency for applications such as augmented/virtual reality and self-driving cars -- DPDK will further extend that performance for next-generation wireless wide area networks. I had the opportunity recently to speak to project chair Jim St. Leger after the fifth DPDK release, and I was impressed with the depth and breadth of the open source project. Over 25 companies and 160 technologists are involved in advancing the effort. With the proliferation of data, cord cutting at home, and growing consumption of video over wired and wireless networks, high-quality compression techniques will dramatically improve performance and reliability. DPDK appears to be poised to contribute significantly to that effort.

Jack Wallen, writing for TechRepublic: For a company to support Linux, they have to consider supporting: Multiple file systems, multiple distributions, multiple desktops, multiple init systems, multiple kernels. If you're an open source developer, focusing on a single distribution, that's not a problem. If you're a company that produces a product (and you stake your living on that product), those multiple points of entry do become a problem. Let's consider Adobe (and Photoshop). If Adobe wanted to port their industry-leading product to Linux, how do they do that? Do they spend the time developing support for ext4, btrfs, Ubuntu, Fedora, GNOME, Mate, KDE, systemd? You see how that might look from the eyes of any given company?

It becomes even more complicated when companies consider how accustomed to the idea of "free" (as in beer) Linux users are. Although I am very willing to pay for software on Linux, it's a rare occasion that I do (mostly because I haven't found a piece of must-have software that has an associated cost). Few companies will support the Linux desktop when the act of supporting means putting that much time and effort into a product that a large cross-section of users might wind up unwilling to pay the price of admission. That's not to say every Linux user is unwilling to shell out the cost for a piece of software. But many won't.

An anonymous reader writes: Linus Torvalds released on Sunday Linux 4.19-rc1 that he describes as a "fairly frustrating merge window" following the new features landing over the past two weeks. What does this "pretty big release" offer? Phoronix's Linux 4.19 feature overview sheds light on more Spectre CPU mitigations for x86/POWER/s390, the new EROFS read-only Android file-system, a Raspberry Pi voltage driver, ThinkPad calculator key support, an in-kernel GPS subsystem, the Google GASKET driver framework, virtual kernel mode-setting, Qualcomm Adreno 600 series support, and many other improvements.

It's been 27 years since Linus Torvalds let a group of people know about his "hobby" OS. OMGUbuntu blog writes: Did you know that Linux, like Queen Elizabeth II, actually has two birthdays? Some FOSS fans consider the first public release of (prototype) code, which dropped on October 5, 1991, as more worthy of being the kernel's true anniversary date. Others, ourselves included, take today, August 25, as the "birth" date of the project. And for good reason. This is the day on which, back in 1991, a young Finnish college student named Linus Torvalds sat at his desk to let the folks on comp.os.minix newsgroup know about the "hobby" OS he was working on. The "hobby OS" that wouldn't, he cautioned, be anything "big" or "professional." Even as Linux continues to have lion's share in the enterprise world, it has only managed to capture a tiny fraction of the consumer space. Further reading: Ask Slashdot: Whatever Happened To the 'Year of Linux on Desktop'?

Which Linux-based distro do you use? What changes, if any, would you like to see in it in the next three years?