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?

While we know that Linux app support is coming to a range of Chromebooks from Lenovo, Acer, Dell and others, a post on the Chromium Gerrit reveals that devices running Linux 3.14 or older will miss out. BetaNews: Chrome OS is able to run Linux apps through the use of containers which help to keep the rest of the operating system safe from harm. As container support requires features that are only found in more recent versions of the Linux kernel, it means that many Chromebooks -- whose kernels are usually not updated -- will not be able to run Linux apps.

Here's the full list of Chromebooks that won't be getting the Linux love: AOpen Chromebase Mini (Feb 2017; tiger, veyron_pinky), AOpen Chromebox Mini (Feb 2017; fievel, veyron_pinky), ASUS Chromebook C201 (May 2015; speedy, veyron_pinky), Acer C670 Chromebook 11 (Feb 2015; paine, auron), Acer Chromebase 24 (Apr 2016; buddy, auron), Acer Chromebook 15 (Apr 2015; yuna, auron), Acer Chromebox CXI2 (May 2015; rikku, jecht), Asus Chromebit CS10 (Nov 2015; mickey, veyron_pinky), Asus Chromebook Flip C100PA (Jul 2015; minnie, veyron_pinky), Asus Chromebox CN62 (Aug 2015; guado, jecht), Dell Chromebook 13 7310 (Aug 2015; lulu, auron), Google Chromebook Pixel (Mar 2015; samus), Lenovo ThinkCentre Chromebook (May 2015; tidus, jecht), Toshiba Chromebookk 2 (Sep 2015; gandof, auron).

Slack developer Felix Rieseberg has made Windows 95 into an electron app that you can run on macOS, Windows, and Linux. The source code and app installers are available on GitHub. According to The Verge, "apps like Wordpad, phone dialer, MS Paint, and Minesweeper all run like you'd expect," but "Internet Explorer isn't fully functional as it simply refused to load pages." From the report: The app is only 129MB in size and you can download it over at Github for both macOS and Windows. Once it's running it surprisingly only takes up around 200MB of RAM, even when running all of the old Windows 95 system utilities, apps, and games. If you run into any issues with the app you can always reset the Windows 95 instance inside the app and start over again. Enjoy this quirky trip down memory lane.

Long-time Slashdot reader Bruce Perens writes: The Register reports that Debian is rejecting a new Intel microcode update because of a new license term prohibiting the use of the CPU for benchmarks and profiling.

There is a new license term applied to the new microcode: "You will not, and will not allow any third party to (i) use, copy, distribute, sell or offer to sell the Software or associated documentation; (ii) modify, adapt, enhance, disassemble, decompile, reverse engineer, change or create derivative works from the Software except and only to the extent as specifically required by mandatory applicable laws or any applicable third party license terms accompanying the Software; (iii) use or make the Software available for the use or benefit of third parties; or (iv) use the Software on Your products other than those that include the Intel hardware product(s), platform(s), or software identified in the Software; or (v) publish or provide any Software benchmark or comparison test results." UPDATE:: Intel has reworked the license to no longer prohibit benchmarking. Imad Sousou, corporate VP and general manager of Intel Open Source Technology Center, tweeted on Thursday: "We have simplified the Intel license to make it easier to distribute CPU microcode updates and posted the new version here. As an active member of the open source community, we continue to welcome all feedback and thank the community."

Steam Play -- Valve's name for its cross-platform initiative -- is getting a major update, adding built-in tools that would allow users to run Windows games on Linux. It's now available in beta. From a report: The new tools run on Proton, which is custom distribution of the widely-used Wine compatibility tool. In the most practical terms, this means you can now download and install Windows games directly from the Steam client without any further fuss. Valve is currently checking "the entire Steam catalog" and whitelisting games that run without issue, but you can turn off those guidelines and install whatever you want, too.

Proton should provide enhanced performance over Wine in many cases, according to Valve. DirectX 11 and 12 implementations are now based on Vulkan, and performance in multi-threaded games "has been greatly improved compared to vanilla Wine." You'll also see better fullscreen and controller support with Proton. It's also fully open source.

Long-time Slashdot reader Mike Bouma shares a paper (via OS News) making the case for "a small microkernel as the core of the trusted computing base, with OS services separated into mutually-protected components (servers) -- in contrast to 'monolithic' designs such as Linux, Windows or MacOS." While intuitive, the benefits of the small trusted computing base have not been quantified to date. We address this by a study of critical Linux CVEs [PDF] where we examine whether they would be prevented or mitigated by a microkernel-based design. We find that almost all exploits are at least mitigated to less than critical severity, and 40% completely eliminated by an OS design based on a verified microkernel, such as seL4....

Our results provide very strong evidence that operating system structure has a strong effect on security. 96% of critical Linux exploits would not reach critical severity in a microkernel-based system, 57% would be reduced to low severity, the majority of which would be eliminated altogether if the system was based on a verified microkernel. Even without verification, a microkernel-based design alone would completely prevent 29% of exploits...

The conclusion is inevitable: From the security point of view, the monolithic OS design is flawed and a root cause of the majority of compromises. It is time for the world to move to an OS structure appropriate for 21st century security requirements.

The systems and database administrator for a Fortune 500 company notes that while NFS is "decades old and predating Linux...the most obvious feature missing from NFSv4 is native, standalone encryption." emil (Slashdot reader #695) summarizes this article from Linux Journal: NFS is the most popular remote file system in the Linux, UNIX, and greater POSIX community. The NFS protocol pushes file traffic over cleartext connections in the default configuration, which is poison to sensitive information.

TLS can wrap this traffic, finally bringing wire security to files vulnerable to compromise in transit. Before using a cloud provider's toolset, review NFS usage and encrypt where necessary.
The article's author complains that Google Cloud "makes no mention of data security in its documented procedures," though "the performance penalty for tunneling NFS over stunnel is surprisingly small...."

"While the crusade against telnet may have been largely won, Linux and the greater UNIX community still have areas of willful blindness. NFS should have been secured long ago, and it is objectionable that a workaround with stunnel is even necessary."

BrianFagioli writes: Debian is one of the most important open source projects ever. The Debian Linux operating system is extremely popular in its own right, but also, it is used as the base for countless other distributions. Ubuntu, for instance -- one of the most-used distros -- is Debian-based. Even Linux Mint, which is based on Ubuntu, also has a Debian edition. Not to mention, Raspbian -- the official Raspberry Pi OS -- which is based on Debian too.

Today, Debian is celebrating a very important milestone -- a 25th birthday! Yes, it is seriously that old -- its development was announced on August 16, 1993. When the late Ian Murdock announced 25 years ago in comp.os.linux.development, the imminent completion of a brand-new Linux release, [...] the Debian Linux Release', nobody would have expected the 'Debian Linux Release' would become what's nowadays known as the Debian Project, one of the largest and most influential free software projects. "Its primary product is Debian, a free operating system (OS) for your computer, as well as for plenty of other systems which enhance your life. From the inner workings of your nearby airport to your car entertainment system, and from cloud servers hosting your favorite websites to the IoT devices that communicate with them, Debian can power it all," says Ana Guerrero Lopez of Debian. Further reading: Slackware, Oldest Actively Maintained GNU/Linux Distribution, Turns 25.

"Valve appears to be working on a set of 'compatibility tools,' called Steam Play, that would allow at least some Windows-based titles to run on Linux-based SteamOS systems," writes Kyle Orland from Ars Technica. From the report: Yesterday, Reddit users noticed that Steam's GUI files (as captured by SteamDB's Steam Tracker) include a hidden section with unused text related to the unannounced Steam Play system. According to that text, "Steam Play will automatically install compatibility tools that allow you to play games from your library that were built for other operating systems." Other unused text in the that GUI file suggests Steam Play will offer official compatibility with "supported tiles" while also letting users test compatibility for "games in your library that have not been verified with a supported compatibility tool." That latter use comes with a warning that "this may not work as expected, and can cause issues with your games, including crashes and breaking save games."

fstack writes: Linus Torvalds has released Linux 4.18 as the newest kernel bringing a Steam Controller kernel driver, Spectre updates for ARM64, power management updates, a "Restartable Services" system call, AMD Radeon graphics driver improvements, V3D DRM as Broadcom's new graphics driver, DM writecache support, USB 3.2 support, and many other updates. Linus Torvalds wrote of the 4.18 final release: "It was a very calm week, and arguably I could just have released on schedule last week, but we did have some minor updates. Mostly networking, but some vfs race fixes (mentioned in the rc8 announcement as 'pending') and a couple of driver fixes (scsi, networking, i2c). Some other minor random things (arm crypto fix, parisc memory ordering fix)." In a separate article, Phoronix details all the changes and new features available in this release.

New submitter rokahasch writes: Starting today, August 10th, most users of the Dropbox desktop app on Linux have been receiving notifications that their Dropbox will stop syncing starting November. Over at the Dropbox forums, Dropbox have declared that the only Linux filesystem supported for storage of the Dropbox sync folder starting the 7th of November will be on a clean ext4 file system. This basically means Dropbox drops Linux support completely, as almost all Linux distributions have other file systems as their standard installation defaults nowadays -- not to mention encryption running on top of even an ext4 file system, which won't qualify as a clean ext4 file system for Dropbox (such as eCryptfs which is the default in, for example, Ubuntu for encrypted home folders).

The thread is trending heavily on Dropbox' forums with the forum's most views since the thread started earlier today. The cries from a large amount of Linux users have so far remained unanswered from Dropbox, with most users finding the explanation given for this change unconvincing. The explanation given so far is that Dropbox requires a file system with support for Extended attributes/Xattrs. Extended attributes however are supported by all major Linux/Posix complaint file systems. Dropbox has, up until today, supported Linux platforms since their services began back in 2007. A number of users have taken to Twitter to protest the move. Twitter user troyvoy88 tweets: "Well, you just let the shitstorm loose @Dropbox dropping support for some linux FS like XFS and BTRFS. No way in hell im going to reformat my @fedora #development station and removing encryption no way!"

Another user by the name of daltux wrote: "It will be time to say goodbye then, @Dropbox. I won't store any personal files on an unencrypted partition."

Hollywood now has its very own open source organization: The Academy of Motion Picture Arts and Sciences has teamed up with the Linux Foundation to launch the Academy Software Foundation, which is dedicated to advance the use of open source in film making and beyond. From a report: The association's founding members include Animal Logic, Autodesk, Blue Sky Studios, Cisco, DNEG, DreamWorks, Epic Games, Foundry, Google Cloud, Intel, SideFX, Walt Disney Studios and Weta Digital. Together, they want to promote open source, help studios and others in Hollywood with open source licensing issues and manage open source projects under the helm of the Software Foundation. The cooperation between the Academy and the Linux Foundation began a little over two years ago, when the Academy's Science and Technology Council began to look into Hollywood's use of open source software. "It's the culmination of a couple of years of work," said Industrial Light & Magic (ILM) head Rob Bredlow in an interview with Variety this week.

One of the findings of that investigation: Almost everyone in Hollywood is using open source software in one way or another. An internal survey found that 80 percent of all companies were using open source. "It's a really big component of the motion picture industry," Bredlow said. Linux Foundation executive director Jim Zemlin argued that this kind of cooperation could be transformative for Hollywood. "I've seen this movie before in other industries," he punned, explaining that automotive companies had seen huge benefits from working together on open source projects.