Linux on Chromebooks is Finally Coming Out of Beta (androidcentral.com) 32
Linus Torvalds Weighs in on Commercial Users of Open Source Code (tag1consulting.com) 87
But the second part offers some deeper insight into the way Torvalds thinks, some personal insight, what he'd share with other project maintainers — and some thoughts on getting corporations to contribute to open source development: While open source has been hugely successful, many of the biggest users, for example corporations, do nothing or little to support or contribute back to the very open source projects they rely on. Even developers of surprisingly large and successful projects (if measured by number of users) can be lucky to earn enough to buy coffee for the week. Do you think this is something that can be solved? Is the open source model sustainable?
Linus Torvalds: I really don't have an answer to this, and for some reason the kernel has always avoided the problem. Yes, there are companies that are pure "users" of Linux, but they still end up wanting support, so they then rely on contractors or Linux distributions, and those obviously then end up as one of the big sources of kernel developer jobs.
And a fair number of big tech companies that use the kernel end up actively participating in the development process. Sometimes they end up doing a lot of internal work and not being great at feeding things back upstream (I won't name names, and some of them really are trying to do better), but it's actually very encouraging how many big companies are very openly involved with upstream kernel development, and are major parts of the community.
So for some reason, the kernel development community has been pretty successful about integrating with all the commercial interests. Of course, some of that has been very much conscious: Linux has very much always been open to commercial users, and I very consciously avoided the whole anti-corporate mindset that you can most definitely find in some of the "Free Software" groups. I think the GPLv2 is a great license, but at the same time I've been very much against some of the more extreme forms of "Free Software", and I — and Linux — was very much part of the whole rebranding to use "Open Source".
Because frankly, some of the almost religious overtones of rms and the FSF were just nutty, and a certain portion of the community was actively driving commercial use away.
And I say that as somebody who has always been wary of being too tainted by commercial interests... I do think that some projects may have shot themselves in the foot by being a bit too anti-commercial, and made it really hard for companies to participate...
But is it sustainable? Yes. I'm personally 100% convinced that not only is open source sustainable, but for complex technical issues you really need open source simply because the problem space ends up being too complex to manage inside one single company. Even a big and competent tech company.
But it does require a certain openness on both sides. Not all companies will be good partners, and some developers don't necessarily want to work with big companies.
In the interview Torvalds also thanks the generous education system in Finland, and describes what it was like moving from Finland to America. And as for how long he'll continue working on Linux, Torvalds says, "I do enjoy what I do, and as long as I feel I'm actually helping the project, I'll be around...
"in the end, I really enjoy what I do. I'd be bored to tears without kernel development."
Linux Foundation Launches Open Source Agriculture Infrastructure Project (venturebeat.com) 20
As with just about every other industry in recent years, there has been a growing digital transformation across the agriculture sector that has ushered in new connected devices for farmers and myriad AI and automated tools to optimize crop growth and circumvent critical obstacles, such as labor shortages. Open source technologies bring the added benefit of data and tools that any party can reuse for free, lowering the barrier to entry and helping keep companies from getting locked into proprietary software operated by a handful of big players...
The AgStack Foundation will be focused on supporting the creation and maintenance of free and sector-specific digital infrastructure for both applications and the associated data. It will lean on existing technologies and agricultural standards; public data and models; and other open source projects, such as Kubernetes, Hyperledger, Open Horizon, Postgres, and Django, according to a statement.
"Current practices in AgTech are involved in building proprietary infrastructure and point-to-point connectivity in order to derive value from applications," AgStack executive director Sumer Johal told VentureBeat. "This is an unnecessarily costly use of human capital. Like an operating system, we aspire to reduce the time and effort required by companies to produce their own proprietary applications and for content consumers to consume this interoperably."
Why is F34 the Most Popular Fedora Linux in Years? (zdnet.com) 125
Why? Nick Gerace, a Rancher software engineer, thinks it's because "I've never seen the project in a better state, and I think GNOME 40 is a large motivator as well. Probably a combination of each, from anecdotal evidence." He's onto something. When Canonical released Ubuntu 21.04 a few days earlier, their developers opted to stay with the tried and true GNOME 39 desktop. Fedora's people decided to go with GNOME 40 for their default desktop even though it's a radical update to the GNOME interface. Besides boasting a new look, GNOME 40 is based on the new GTK 4.0 graphical toolkit. Under the pretty new exterior, this update also fixed numerous issues and smoothed out many rough spots.
If you'd rather have another desktop, you can also get Fedora 34 with the newest KDE Plasma Desktop, Xfce 4.16, Cinnamon, etc. You name your favorite Linux desktop interface, Fedora will almost certainly deliver it to you... Another feature I like is that, since Fedora 33, the default file system is Btrfs. I find it faster and more responsive than ext4, perhaps the most popular Linux desktop file system. What's different this time around is that it now defaults to using Btrfs transparent compression. Besides saving significant storage space — typically from 20 to 40% — Red Hat also claims this increases the lifespan of SSDs and other flash media.
Although the article does point out that most users will never reach the end of that SSD lifespan (approximately ten years of normal use), it suggests that "developers, who might for example compile Linux kernels every day, might reach that point before a PC's usual end of useful life."
In a possibly related note, Linus Torvalds said this week in a new interview that "I use Fedora on all my machines, not because it's necessarily 'preferred', but because it's what I'm used to. I don't care deeply about the distribution — to me it's mainly a way to get Linux installed on a machine and get all my tools set up, so that I can then replace the kernel and work on just that."
Linus Torvalds Reflects In New Interview on Linux's Earliest Days (tag1consulting.com) 51
But with all that, early on Torvalds also reflects that Linux began as a personal project at the age of 21, "not out of some big dream to create a new operating system." Instead it "literally grew kind of haphazardly from me initially just trying to learn the in-and-outs of my new PC hardware.
"So when I released the very first version, it was really more of a 'look at what I did', and sure, I was hoping that others would find it interesting, but it wasn't a real serious and usable OS. It was more of a proof of concept, and just a personal project I had worked on for several months at that time..."
This year, in August, Linux will celebrate its 30th anniversary! That's amazing, congratulations! At what point during this journey did you realize what you'd done, that Linux was so much more than "just a hobby"?
Linus Torvalds: This may sound a bit ridiculous, but that actually happened very early. Already by late '91 (and certainly by early '92) Linux had already become much bigger than I had expected.
And yeah, considering that by that point, there were probably just a few hundred users (and even "users" may be too strong — people were tinkering with it), it probably sounds odd considering how Linux then later ended up growing much bigger. But in many ways for me personally, the big inflection point was when I realized that other people are actually using it, and interested in it, and it started to have a life of its own. People started sending patches, and the system was actually starting to do much more than I had initially really envisioned....
That "anybody can maintain their own version" worried some people about the GPLv2, but I really think it's a strength, not a weakness. Somewhat unintuitively, I think it's actually what has caused Linux to avoid fragmenting: everybody can make their own fork of the project, and that's OK. In fact, that was one of the core design principles of "Git" — every clone of the repository is its own little fork, and people (and companies) forking off their own version is how all development really gets done.
So forking isn't a problem, as long as you can then merge back the good parts. And that's where the GPLv2 comes in. The right to fork and do your own thing is important, but the other side of the coin is equally important — the right to then always join back together when a fork was shown to be successful...
I very much don't regret the choice of license, because I really do think the GPLv2 is a huge part of why Linux has been successful.
Money really isn't that great of a motivator. It doesn't pull people together. Having a common project, and really feeling that you really can be a full partner in that project, that motivates people, I think.
New Malware Found Lurking In 64-Bit Linux Installs (zdnet.com) 85
At the time of discovery, there were no malware detections on VirusTotal for the file, despite four samples having been uploaded -- two in 2018, one in 2020, and another in 2021. Netlab researchers say the Linux malware changes its use of encryption to fly under the radar, including ZLIB compression and combinations of AES, XOR, and key rotation during its activities, such as the obfuscation of command-and-control (C2) server communication. At present, the team says that they do not know the malware's "true purpose" beyond a focus on compromising Linux systems.
There are 12 functions in total including exfiltrating and stealing data, file and plugin management -- including query/download/delete -- and reporting device information. However, the team cites a "lack of visibility" into the plugins that is preventing a more thorough examination of the malware's overall capabilities. In addition, RotaJakiro will treat root and non-root users on compromised systems differently and will change its persistence methods depending on which accounts exist.
Linux Stops Reverting Most University of Minnesota Patches, Admits Good Faith (lwn.net) 83
The writing of a paper on this research [PDF] was not the immediate cause of the recent events; instead, it was the posting of a buggy patch originating from an experimental static-analysis tool run by another developer at UMN. That led developers in the kernel community to suspect that the effort to submit intentionally malicious patches was still ongoing. Since then, it has become apparent that this is not the case, but by the time the full story became clear, the discussion was already running at full speed.
The old saying still holds true: one should not attribute to malice that which can be adequately explained by incompetence.
On April 22, a brief statement was issued by the Linux Foundation technical advisory board (TAB) stating that, among other things, the recent patches appeared to have been submitted in good faith.
Meanwhile, the Linux Foundation and the TAB sent a letter to the UMN researchers outlining how the situation should be addressed; that letter has not been publicly posted, but ZDNet apparently got a copy from somewhere. Among other things, the letter asked for a complete disclosure of the buggy patches sent as part of the UMN project and the withdrawal of the paper resulting from this work.
In response, the UMN researchers posted an open letter apologizing to the community, followed a few days later by a summary of the work they did [PDF] as part of the "hypocrite commits" project. Five patches were submitted overall from two sock-puppet accounts, but one of those was an ordinary bug fix that was sent from the wrong account by mistake. Of the remaining four, one of them was an attempt to insert a bug that was, itself, buggy, so the patch was actually valid; the other three (1, 2, 3) contained real bugs. None of those three were accepted by maintainers, though the reasons for rejection were not always the bugs in question.
The paper itself has been withdrawn and will not be presented in May as was planned...
One of the first things that happened when this whole affair exploded was the posting by Greg Kroah-Hartman of a 190-part patch series reverting as many patches from UMN as he could find... As it happens, these "easy reverts" also needed manual review; once the initial anger passed there was little desire to revert patches that were not actually buggy. That review process has been ongoing over the course of the last week and has involved the efforts of a number of developers. Most of the suspect patches have turned out to be acceptable, if not great, and have been removed from the revert list; if your editor's count is correct, 42 patches are still set to be pulled out of the kernel...
A look at the full set of UMN patches reinforces some early impressions, though. First is that almost all of them do address some sort of real (if obscure and hard to hit) problem...
Greg Kroah-Hartman Rejects Apology from University of Minnesota Researchers (kernel.org) 140
Late Saturday night, the kernel team's Greg Kroah-Hartman replied: Thank you for your response.
As you know, the Linux Foundation and the Linux Foundation's Technical Advisory Board submitted a letter on Friday to your University outlining the specific actions which need to happen in order for your group, and your University, to be able to work to regain the trust of the Linux kernel community.
Until those actions are taken, we do not have anything further to discuss about this issue.
thanks
University of Minnesota Researchers Send Apology to Linux Kernel Mailing List (kernel.org) 208
Today the professor in charge of that project, as well as two of its researchers, sent an email to the Linux kernel mailing list saying they "sincerely apologize for any harm our research group did to the Linux kernel community." Our goal was to identify issues with the patching process and ways to address them, and we are very sorry that the method used in the "hypocrite commits" paper was inappropriate. As many observers have pointed out to us, we made a mistake by not finding a way to consult with the community and obtain permission before running this study; we did that because we knew we could not ask the maintainers of Linux for permission, or they would be on the lookout for the hypocrite patches. While our goal was to improve the security of Linux, we now understand that it was hurtful to the community to make it a subject of our research, and to waste its effort reviewing these patches without its knowledge or permission.
We just want you to know that we would never intentionally hurt the Linux kernel community and never introduce security vulnerabilities. Our work was conducted with the best of intentions and is all about finding and fixing security vulnerabilities... We are a research group whose members devote their careers to improving the Linux kernel. We have been working on finding and patching vulnerabilities in Linux for the past five years...
This current incident has caused a great deal of anger in the Linux community toward us, the research group, and the University of Minnesota. We apologize unconditionally for what we now recognize was a breach of the shared trust in the open source community and seek forgiveness for our missteps. We seek to rebuild the relationship with the Linux Foundation and the Linux community from a place of humility to create a foundation from which, we hope, we can once again contribute to our shared goal of improving the quality and security of Linux software... We are committed to following best practices for collaborative research by consulting with community leaders and members about the nature of our research projects, and ensuring that our work meets not only the requirements of the Institutional Review Board but also the expectations that the community has articulated to us in the wake of this incident.
While this issue has been painful for us as well, and we are genuinely sorry for the extra work that the Linux kernel community has undertaken, we have learned some important lessons about research with the open source community from this incident. We can and will do better, and we believe we have much to contribute in the future, and will work hard to regain your trust.
Their email also says their work did not introduce vulnerabilities into the Linux code. ("The three incorrect patches were discussed and stopped during exchanges in a Linux message board, and never committed to the code.")
And the email also clarifies that their research was only done in August of 2020, and "All the other 190 patches being reverted and re-evaluated were submitted as part of other projects and as a service to the community; they are not related to the 'hypocrite commits' paper. These 190 patches were in response to real bugs in the code and all correct — as far as we can discern — when we submitted them... Our recent patches in April 2021 are not part of the 'hypocrite commits' paper either."
UPDATE (4/25): Late Saturday night the kernel team's Greg Kroah-Hartman rejected the apology, writing that "the Linux Foundation and the Linux Foundation's Technical Advisory Board submitted a letter on Friday to your University outlining the specific actions which need to happen in order for your group, and your University, to be able to work to regain the trust of the Linux kernel community.
"Until those actions are taken, we do not have anything further to discuss about this issue."
Latest Windows Preview Build Adds Support For Linux GUI Apps (windows.com) 94
Canonical Launches Ubuntu 21.04 'Hirsute Hippo' 46
Linux Bans University of Minnesota for Sending Buggy Patches in the Name of Research (neowin.net) 257
Debian Votes to Issue No Statement on Stallman's Return to the FSF Board (debian.org) 209
Seven options were considered, with the Debian project's 420 voting developers also asked to rank their preferred outcomes:
- Option 1: "Call for the FSF board removal, as in rms-open-letter.github.io"
- Option 2: "Call for Stallman's resignation from all FSF bodies"
- Option 3: "Discourage collaboration with the FSF while Stallman is in a leading position"
- Option 4: "Call on the FSF to further its governance processes"
- Option 5: "Support Stallman's reinstatement, as in rms-support-letter.github.io"
- Option 6: "Denounce the witch-hunt against RMS and the FSF"
- Option 7: "Debian will not issue a public statement on this issue"
While all seven options achieved a quorum of votes, two failed to achieve a majority — options 5 and 6. ("Support Stallman's reinstatement" and "Denounce the witch-hunt...") The option receiving the most votes was #7 (not issuing a public statement) — but it wasn't that simple. The vote's final outcome was determined by comparing every possible pair of options to determine which option would still be preferred by a majority of voters in each possible comparision.
In this case, that winner was still the option which had also received the most votes:
Debian will not issue a public statement on this issue.
The Debian Project will not issue a public statement on whether Richard Stallman should be removed from leadership positions or not.
Any individual (including Debian members) wishing to (co-)sign any of the open letters on this subject is invited to do this in a personal capacity.
The results are captured in an elaborate graph. Numbers inside the ovals show the final ratio of yes to no votes (so a number higher than 1.00 indicates a majority, with much higher numbers indicating much larger majorities). Numbers outside the ovals (along the lines) indicate the number of voters who'd preferred the winning choice over the losing choice (toward which the arrow is pointing).
The winning option is highlighted in blue.
Openwall Releases 'Linux Kernel Runtime Guard' 0.9.0 (linuxreviews.org) 7
The Linux Kernel Runtime Guard is an out-of-tree kernel module you can install as a kernel module, or, with the 0.9.0 release, build into your Linux kernel. It does run-time integrity checks to detect security vulnerability exploits against the Linux kernel.
An Openwall developer also notes in the announcement that "During LKRG development and testing I've found 7 Linux kernel bugs, 4 of them have CVE numbers."
Slackware Approaches 28th Birthday With New Beta Release (theregister.com) 58
The beta itself dropped on 12 April (with the 5.10.29 kernel) and Volkerding noted: "I'm going to go ahead and call this a beta even though there's still no fix for the illegal instruction issue with 32-bit mariadb. But there should be soon."
Tinkering has continued since, judging by the change log, although the beta tag brings hope there will be a release before long.
Linus Torvalds Says Rust Closer for Linux Kernel Development, Calls C++ 'A Crap Language' (itwire.com) 270
Linus Torvalds responded in a new interview with IT Wire (shared by Slashdot reader juul_advocate): The first patches for Rust support in the Linux kernel have been posted and the man behind the kernel says the fact that these are being discussed is much more important than a long post by Google about the language. Linus Torvalds told iTWire in response to queries that Rust support was "not there yet", adding that things were "getting to the point where maybe it might be mergeable for 5.14 or something like that..." Torvalds said that it was still early days for Rust support, "but at least it's in a 'this kind of works, there's an example, we can build on it'."
Asked about a suggestion by a commenter on the Linux Weekly News website, who said, during a discussion on the Google post, "The solution here is simple: just use C++ instead of Rust", Torvalds could not restrain himself from chortling. "LOL," was his response. "C++ solves _none_ of the C issues, and only makes things worse. It really is a crap language.
"For people who don't like C, go to a language that actually offers you something worthwhile. Like languages with memory safety and [which] can avoid some of the dangers of C, or languages that have internal GC [garbage collection] support and make memory management easier. C++ solves all the wrong problems, and anybody who says 'rewrite the kernel in C++' is too ignorant to even know that."
He said that when one spoke of the dangers of C, one was also speaking about part of what made C so powerful, "and allows you to implement all those low-level things efficiently".
Torvalds added that, while garbage collection is "a very good thing in most other situations," it's "generally not necessarily something you can do in a low-level system programming."
Reactions to Arch Linux's New Guided Installer (linuxreviews.org) 108
It is not very novice-friendly, or user-friendly, but it gets the job done and it will work fine for those with some basic GNU/Linux knowledge.
Tech Radar writes that previously Arch Linux had "a rather convoluted installation process, which has given rise to a stream of Arch-based distros that are easier to install," adding that the new installer "was reportedly promoted as an official installation mechanism back in January, and was actively worked upon leading to its inclusion in the installation medium." Users have been calling on Arch Linux for simplifying the installation process for a long time, to bring it in line with other Linux distros. However, the Arch philosophy has always been to put the users in charge of every aspect of their installation, which is the antithesis of automated installers.
Phoronix calls the new installer "very quick and easy," although "granted not as user-friendly / polished as say the Debian Installer, Red Hat's Anaconda installer, even Ubuntu's Subiquity, and other TUI/GUI Linux installers out there." They also note that Archinstall "does allow automatically partitioning the drive with your choice of file-system options, automatically installing a desktop environment if desired, configuring the network interfaces, and all the other basics." The method is quick enough that I'll likely use archinstall for future Arch Linux benchmarks on Phoronix as it also then applies a sane set of defaults for users... Five minutes or less and off to the races, ready for Arch Linux."
But Slashdot reader I75BJC still favors "scary commands in a terminal," leaving this comment on the original submission: If you can't type with the big adults, stay on your PlayStation.
Even Apple, with its very good GUI has a command line. The command line commands are more flexible, more specific, more subtle than the pointy-clicky GUI.
IBM Creates a COBOL Compiler For Linux On x86 (theregister.com) 188
[...]
But the announcement also suggests IBM doesn't completely believe this COBOL on x86 Linux caper has a future as it concludes: "This solution also provides organizations with the flexibility to move workloads back to IBM Z should performance and throughput requirements increase, or to share business logic and data with CICS Transaction Server for z/OS." The new offering requires RHEL 7.8 or later, or Ubuntu Server 16.04 LTS, 18.04 LTS, or later.
Results of Debian Vote On Stallman To Be Known By April 17 (itwire.com) 387
Six alternatives have been proposed. The proposals are:
- remove the entire FSF board as in an existing letter;
- seek Stallman's resignation from all FSF bodies;
- discourage collaboration with the FSF while Stallman remains in a leading position;
- ask FSF to further its governance processes;
- support Stallman's reinstatement;
- denounce the witch hunt against Stallman and the FSF; and
- issue no public statement on the issue. During the organization's LibrePlanet virtual event on March 19, Stallman announced that he was rejoining the board and does not intend to resign again. His return has drawn condemnation from many people in the free software community. Just days after his announcement, an open letter calling for Stallman to be removed again and for the FSF's entire board to resign was signed by hundreds of people.
Linux giant Red Hat has decided to pull funding, while the 'Open Source Initiative' said that it "will not participate in any events that include Richard M. Stallman," adding that it "cannot collaborate with the Free Software Foundation until Stallman is removed from the organization's leadership."