Matt Klein, a member of the Go steering committee recently apologized for the angst caused to some people by "the try() kerfuffle... Change is hard, but sometimes it's for the best."

Tech columnist Mike Melanson covers the kerfuffle over the newly-proposed feature, while trying "not to over-dramatize what is happening." There is disagreement and conflicting views, but working through those views is how the open source sausage is made, is it not? Of course, in the Go community, how the core team receives those opposing views may be a point of soreness among some who vehemently opposed the vgo package versioning for Go and felt that, in the end, it was rammed through despite their objections. As one Gopher points out, it is better to debate now than summarily accept and then later deprecate...

As Go makes its way to Go 2.0, with Go 1.14 currently taking center stage for debate, there is, again, as Klein points out, some kerfuffle about a newly proposed feature called try(), which is "designed specifically to eliminate the boilerplate if statements typically associated with error handling in Go." According to the proposal, the "minimal approach addresses most common scenarios while adding very little complexity to the language" and "is easy to explain, straightforward to implement, orthogonal to other language constructs, and fully backward-compatible" as well as extensible for future needs.

Much of the disagreement around try() comes in the form of whether or not the resultant code is more or less readable than current implementations of error handling. Beyond that, however, some say that even if try() were accepted, it has faults that would prevent them from recommending or even allowing its use among their teams. Meanwhile, another point of contention is offered in an open letter to the Go team about try by William Kennedy who often writes about Go, and focuses on not style or function, but rather whether or not a solution is needed at all. According to Kennedy, "the perceived error handling complaints are perhaps overblown and these changes are not what the majority of Go developers want or need" and that try() may be a solution searching for a problem, and even the cause of more problems than it solves."Since this new mechanic is going to cause severe inconsistencies in code bases, disagreements on teams, and create an impossible task for product owners to enforce consistent guidelines, things need to be slowed down and more data needs to be gathered," Kennedy writes.

He goes on to point out those very sensitivities that may have lingered from previous discussions in the Go community. "This is a serious change and it feels like it's being pushed through without a concerted effort to understand exactly what those 5% of Go developers meant when they said they wanted improved error handling...."

From a blog post: For 25 years, the Robots Exclusion Protocol (REP) was only a de-facto standard. This had frustrating implications sometimes. On one hand, for webmasters, it meant uncertainty in corner cases, like when their text editor included BOM characters in their robots.txt files. On the other hand, for crawler and tool developers, it also brought uncertainty; for example, how should they deal with robots.txt files that are hundreds of megabytes large? Today, we announced that we're spearheading the effort to make the REP an internet standard. While this is an important step, it means extra work for developers who parse robots.txt files.

We're here to help: we open sourced the C++ library that our production systems use for parsing and matching rules in robots.txt files. This library has been around for 20 years and it contains pieces of code that were written in the 90's. Since then, the library evolved; we learned a lot about how webmasters write robots.txt files and corner cases that we had to cover for, and added what we learned over the years also to the internet draft when it made sense.

Linux founder Linus Torvalds "warns that managing software is about to become a lot more challenging, largely because of two hardware issues that are beyond the control of DevOps teams," reports DevOps.com.

An anonymous reader shares their report about Torvalds remarks at the KubeCon + CloudNative + Open Source Summit China conference: The first, Torvalds said, is the steady stream of patches being generated for new cybersecurity issues related to the speculative execution model that Intel and other processor vendors rely on to accelerate performance... Each of those bugs requires another patch to the Linux kernel that, depending on when they arrive, can require painful updates to the kernel, Torvalds told conference attendees. Short of disabling hyperthreading altogether to eliminate reliance on speculative execution, each patch requires organizations to update both the Linux kernel and the BIOS to ensure security. Turning off hyperthreading eliminates the patch management issue, but also reduces application performance by about 15 percent.

The second major issue hardware issue looms a little further over the horizon, Torvalds said. Moore's Law has guaranteed a doubling of hardware performance every 18 months for decades. But as processor vendors approach the limits of Moore's Law, many developers will need to reoptimize their code to continue achieving increased performance. In many cases, that requirement will be a shock to many development teams that have counted on those performance improvements to make up for inefficient coding processes, he said.

"Linux frontman Linus Torvalds thinks he's 'more self-aware' these days and is 'trying to be less forceful' after his brief absence from directing Linux kernel developers because of his abusive language on the Linux kernel mailing list," reports ZDNet.

"But true to his word, he's still not necessarily diplomatic in his communications with maintainers..." Torvalds' post-hiatus outburst was directed at Dave Chinner, an Australian programmer who maintains the Silicon Graphics (SGI)-created XFS file system supported by many Linux distros. "Bullshit, Dave," Torvalds told Chinner on a mailing list. The comment from Chinner that triggered Torvalds' rebuke was that "the page cache is still far, far slower than direct IO" -- a problem Chinner thinks will become more apparent with the arrival of the newish storage-motherboard interface specification known as Peripheral Express Interconnect Express (PCIe) version 4.0. Chinner believes page cache might be necessary to support disk-based storage, but that it has a performance cost....

"You've made that claim before, and it's been complete bullshit before too, and I've called you out on it then too," wrote Torvalds. "Why do you continue to make this obviously garbage argument?" According to Torvalds, the page cache serves its correct purpose as a cache. "The key word in the 'page cache' name is 'cache'," wrote Torvalds.... "Caches work, Dave. Anybody who thinks caches don't work is incompetent. 99 percent of all filesystem accesses are cached, and they never do any IO at all, and the page cache handles them beautifully," Torvalds wrote.

"When you say the page cache is slower than direct IO, it's because you don't even see or care about the *fast* case. You only get involved once there is actual IO to be done."
"The thing is," reports the Register, "crucially, Chinner was talking in the context of specific IO requests that just don't cache well, and noted that these inefficiencies could become more obvious as the deployment of PCIe 4.0-connected non-volatile storage memory spreads."

Here's how Chinner responded to Torvalds on the mailing list. "You've taken one single statement I made from a huge email about complexities in dealing with IO concurrency, the page cache and architectural flaws in the existing code, quoted it out of context, fabricated a completely new context and started ranting about how I know nothing about how caches or the page cache work."

The Register notes their conversation also illustrates a crucial difference from closed-source software development. "[D]ue to the open nature of the Linux kernel, Linus's rows and spats play out in public for everyone to see, and vultures like us to write up about."

In honor of FreeDOS's 25th birthday, project founder and coordinator Jim Hall agreed to answer the 10 best questions submitted by Slashdot readers. You asked and he answered! Read on for Jim's interview.

"Let's abandon the notion that open source is exclusively charity," writes Havoc Pennington, a free software engineer (and former Red Hat engineer) who's now a co-founder of Tidelift: Look around. We do have a problem, and it's time we do something about it.... The lack of compensation isn't just bad for individual developers -- it also creates social problems, by amplifying existing privilege.... The narrative around open source is that it's completely OK -- even an expectation -- that we're all doing this for fun and exposure; and that giant companies should get huge publicity credit for throwing peanuts-to-them donations at a small subset of open source projects.

There's nothing wrong with doing stuff for fun and exposure, or making donations, as an option. It becomes a problem when the free work is expected and the donations are seen as enough... What would open source be like if we had a professional class of independent maintainers, constantly improving the code we all rely on?
The essay suggests some things consider, including asking people to pay for:

• Support requests

• Security audits/hardening and extremely good test coverage

• Supporting old releases

• License-metadata-annotation practices that are helpful for big companies trying to audit the code they use, but sort of a pain in the ass and nobody cares other than these big companies.

"Right now many users expect, and demand, that all of this will be free. As an industry, perhaps we should push back harder on that expectation. It's OK to set some boundaries..."

"Of course this relates to what we do at Tidelift -- the company came out of discussions about this problem, among others... In our day-to-day right now we're specifically striving to give subscribers a way to pay maintainers of their application dependencies for additional value, through the Tidelift Subscription. But we hope to see many more efforts and discussions in this area.... [I]n between a virtual tip jar and $100 million in funding, there's a vast solution space to explore."

Red Hat technology evangelist Gordon Haff explains why it's hard to say exactly when the MIT license created. Citing input from both Jim Gettys (author of the original X Window System) and Keith Packard (a senior member on the X Windows team), he writes that "The best single answer is probably 1987. But the complete story is more complicated and even a little mysterious."

An anonymous reader quotes his article at OpenSource.com, which begins with the X Window System at MIT's "Project Athena" (first launched in 1983): X was originally under a proprietary license but, according to Packard, what we would now call an open source license was added to X version 6 in 1985... According to Gettys, "Distributing X under license became enough of a pain that I argued we should just give it away." However, it turned out that just placing it into the public domain wasn't an option. "IBM would not touch public domain code (anything without a specific license). We went to the MIT lawyers to craft text to explicitly make it available for any purpose. I think Jerry Saltzer probably did the text with them. I remember approving of the result," Gettys added.

There's some ambiguity about when exactly the early license language stabilized; as Gettys writes, "we weren't very consistent on wording." However, the license that Packard indicates was added to X Version 6 in 1985 appears to have persisted through X Version 11, Release 5. A later version of the license language seems to have been introduced in X Version 11, Release 6 in 1994... But the story doesn't end there. If you look at the license used for X11 and the approved MIT License at the Open Source Initiative (OSI), they're not the same. Similar in spirit, but significantly different in the words used.

The "modern" MIT License is the same as the license used for the Expat XML parser library beginning in about 1998. The MIT License using this text was part of the first group of licenses approved by the OSI in 1999. What's peculiar is that, although the OSI described it as "The MIT license (sometimes called called [sic] the 'X Consortium license')," it is not in fact the same as the X Consortium License. How and why this shift happened -- and even if it happened by accident -- is unknown. But it's clear that by 1999, the approved version of the MIT License, as documented by the OSI, used language different from the X Consortium License.
He points out that to this day, this is why "some, including the Free Software Foundation," avoid the term "MIT License" altogether -- "given that it can refer to several related, but different, licenses."

An anonymous reader shares a report: Elastic isn't the only open source cloud tool company currently looking over its shoulder at AWS. In 2018 alone, at least eight firms have made similar "rule changes" designed to ward off what they see as unfair competition from a company intent on cannibalizing their services. In his blog post, Adrian Cockcroft, VP of cloud architecture strategy at Amazon Web Services (AWS), argued that by making part of its product suite proprietary, Elastic was betraying the core principles of the open source community. "Customers must be able to trust that open source projects stay open," Cockcroft wrote. "When important open source projects that AWS and our customers depend on begin restricting access, changing licensing terms, or intermingling open source and proprietary software, we will invest to sustain the open source project and community."

AWS's announcement did not attract the immediate attention of the Democratic presidential candidates or the growing cadre of antitrust activists who have recently set their sights on Amazon. But in the world of open source and free software, where picayune changes in arcane language can spark the internet equivalent of the Hundred Years War, the release of AWS's Open Distro for Elasticsearch launched a heated debate. [...] Sharone Zitzman, a respected commentator on open source software and the head of developer relations at AppsFlyer, an app development company, called Amazon's move a "hostile takeover" of Elastic's business. Steven O'Grady, co-founder of the software industry analyst firm RedMonk, cited it as an example of the "existential threat" that open source companies like Elastic believe a handful of cloud computing giants could pose.

"Big changes are here," writes the official blog for Bluecherry: In 2010 we released our multi-port MPEG4 video capture card with an open source driver (solo6x10) and in 2011 updated the driver to support our multi-port H.264 capture cards. Later, this open source driver was later added into the mainline Linux kernel. In 2013 we released our multi-platform surveillance application client with an open source (GPL) license.

We are proud to announce that Effective April 18, 2019 we have released the entire Bluecherry software application open source with a GPL license.
An anonymous reader writes: This includes the Linux based server application and the Windows / Linux / OS X client.

Bluecherry's GitHub repo is now open for public viewing.

"The new Fieldbus system has been deemed ready to be released into the staging area of the Linux kernel," writes jwhyche (Slashdot reader #6,192).

Phoronix reports: This newest subsystem for the Linux kernel benefits industrial systems. Fieldbus is a set of network protocols for real-time distributed control of automated industrial systems. Fieldbus is used for connecting different systems/components/instruments within industrial environments. Fieldbus is used for connecting facilities ranging from manufacturing plants up to nuclear energy facilities. The Fieldbus specification has been around for decades while now seeing a formal subsystem within the Linux kernel.

The subsystem allows for devices to exchange data over a Fieldbus whether it be Profinet, FLNet, or one of the other implementations. The subsystem provides a generic framework for exposing switches, lights, actuators, motors, and other hardware... The Linux kernel's Fieldbus subsystem has gone through over ten rounds of public revisions in recent months and has been deemed ready to premiere with Linux 5.2 [which] should debut in July.

"I believe that, as Microsoft keeps moving Windows to a Desktop-as-a-Service model, Linux will be the last traditional PC desktop operating system standing," writes ZDNet contributing editor Steven J. Vaughan-Nichols.

"But that doesn't mean I'm blind to its problems." First, even Linus Torvalds is tired of the fragmentation in the Linux desktop. In a recent [December 2018] TFiR interview with Swapnil Bhartiya, Torvalds said, "Chromebooks and Android are the path toward the desktop." Why? Because we don't have a standardized Linux desktop. For example, better Linux desktops, such as Linux Mint, provide an easy way to install applications, but under the surface, there are half-a-dozen different ways to install programs. That makes life harder for developers. Torvalds wishes "we were better at having a standardized desktop that goes across the distributions."

Torvalds thinks there's been some progress. For software installation, he likes Flatpak. This software program, like its rival Snap, lets you install and maintain programs across different Linux distros. At the same time, this rivalry between Red Hat (which supports Flatpak) and Canonical (which backs Snap) bugs Torvalds. He's annoyed at how the "fragmentation of the different vendors have held the desktop back." None of the major Linux distributors -- Canonical, Red Hat, SUSE -- are really all that interested in supporting the Linux desktop. They all have them, but they're focused on servers, containers, the cloud, and the Internet of Things (IoT). That's, after all, is where the money is.
Linux desktop distros "tend to last for five or six years and then real life gets in the way of what's almost always a volunteer effort..." the article argues. "It is not easy building and supporting a Linux desktop. It comes with a lot of wear and tear on its developers with far too little reward."

His solution? Having a foundation create a common desktop for all Linux distros, so the Linux world could finally reap the benefits of standardization. "This would mean that many more Linux desktop developers could make a living from their work. That would improve the Linux desktop overall quality.

"It's a virtuous cycle, which would help everyone."

arnieswap quotes TFIR's report on the black hole image: Free and Open Source software was at the heart of this image. The team used three different imaging software libraries to achieve the feat. Out of the three, two were fully open source libraries. The source code of the software is publicly available on GitHub.

Richard M Stallman, the founder of the GNU Project will be glad to see that both libraries (Sparselab and ehtim) are released under GNU GPL v3. Yes, you read it right – GNU GPL v3.

This weekend SlashGear published "Reasons to Abandon Windows For Linux," making their case to "Windows users who are curious about the state of Linux for mainstream computing." It tries to enumerate specific reasons why Linux might be the better choice, arguing among other things that:

• Updates on Linux are fast and "rarely call for a restart" -- and are also more complete. "Updates are typically downloaded through a 'Software Updater' application that not only checks for operating system patches, but also includes updates for the programs that you've installed from the repository."

• Windows "tries to serve a variety of markets...cramming in a scattered array of features" -- and along those lines, that Microsoft "has gradually implemented monetization schemes and methods for extracting user data." And yet you're still paying for that operating system, while Linux is less bloated and "free forever."

• "Because less people use Linux, the platform is less targeted by malware and tends to be more secure than Windows"

The article also touches on a few other points (including battery life), and predicts that problems with Windows are "bound to get worse over time and will only present more of a case for making the switch to Linux."

Long-time Slashdot reader shanen shared the article, along with some new thoughts on why people really stay with Windows:

I think the main "excuse" is the perception of reliability, which is really laughable if you've actually read the EULA. Microsoft certainly doesn't have to help anyone at all. I would argue that Windows support is neither a bug nor a feature, but just a marketing ploy.

Their original submission suggests that maybe Linux needs to buttress the perception of its reliability with a better financial model -- possibly through a new kind of crowd funding which could also be extended to all open source software, or even to journalism).

mfilion shares a report from Android Police: A new "experimental containerized Android environment" from a company called Collabora allows Android apps to run in floating windows alongside native applications on desktop Linux. You can read all the technical details at the source link, but put simply, 'SPURV' creates a virtual Android device on your Linux computer, much like Bluestacks and other similar tools. There are various components of SPURV that allow the Android environment to play audio, connect to networks, and display hardware-accelerated graphics through the underlying Linux system.

The most interesting part is 'SPURV HWComposer,' which renders Android applications in windows, alongside the windows from native Linux applications. This is what sets SPURV apart from (most) other methods of running Android on a computer. For this to work, the Linux desktop has to be using the Wayland display server (some Linux-based OSes use X11). Pre-built binaries for SPURV are not currently available -- you have to build it yourself from the source code. Still, it's an interesting proof-of-concept, and hopefully someone turns it into a full-featured product.

According to the Wall Street Journal, Goldman Sachs is planning to release on GitHub some of the code that its traders and engineers use to price securities and analyze and manage risk. "The bank also is offering $100,000 in annual funding for engineers to build new applications using the bank's code," the report adds. "Goldman will own the resulting intellectual property, plus get an early look to invest in promising technology." From the report: It is Goldman's latest move to shed some of its trademark secrecy and share its once closely guarded technology. It is part of a broader shift at Wall Street firms to emulate Silicon Valley giants like Google and Facebook, which have opened up their technology to a community of enthusiastic developers. By letting outsiders tinker with its code, Goldman hopes to crowdsource new uses for it and earn the loyalty of computer-driven "quant" traders who have taken the investing world by storm.

Goldman's proprietary trading engine, known as SecDB, once made its traders the smartest on Wall Street. It is credited with helping the firm weather the 2008 financial meltdown better than rivals. But a postcrisis ban on proprietary trading has made it more valuable as a service offered to clients than an in-house moneymaker. Over the past five years, Goldman has been building SecDB's capabilities into a web application called Marquee, which now has about 13,000 users roughly split between Goldman employees and clients. The code coming to GitHub will allow users to interact directly with Marquee's data feeds, pricing engines and other tools.

Wednesday CMU announced the open sourcing of its adaptive-learning software platform -- plus analytics and dozens of other related tools for improving college teaching -- as part of a national push "in an unusual move intended to shake up how college teaching is done around the world," writes EdSurge.

Long-time Slashdot reader jyosim shares their report: Officials estimate that developing the software has cost more than $100 million in foundation grants and university dollars. The goal of the software giveaway is to jump-start "learning engineering," the practice of applying findings from learning science to college classrooms. If it takes off, the effort could result in a free, open-source alternative to a growing number of commercial adaptive-learning and learning analytics tools aimed at colleges. One of the biggest concerns by college leaders about buying such tools from commercial vendors is whether colleges will have access to the underlying algorithmic logic -- or whether the systems will be a "black box...."

"We need a scientific revolution in education akin to the one that we had in medicine 150 years ago," said Michael Feldstein, coordinator of the Empirical Educator Project, in a statement. "This isn't a silver bullet, and it isn't charity. It's an invitation to the educators of the world for us all to solve big problems together."
CMU's Nobel prize-winning economics professor Herbert Simon once argued of colleges that "we must step back and view them with Martian eyes, innocent of their history, to appreciate fully how outrageous their operation is... [W]e find no one with a professional knowledge of the laws of learning, or of the techniques of applying them."

Kenneth R. Koedinger, a professor of human computer interaction and psychology at Carnegie Mellon, now argues that "we need to change higher ed from a solo sport to a collaborative research activity."

prpplague writes: Despite Linus Torvald's recent claims ARM won't win in the server space, there are very specific use cases where ARM is making advances into the datacenter. One of those is for use with software-defined storage with open-source projects like CEPH. In a recent The Register article, Softiron's CTO Phil Straw states about their ARM-based CEPH appliances: "It's a totally shitty computer, but what we are trying to do here is storage, and not compute, so when you look at the IO, when you look at the buffering, when you look at the data paths, there's amazing performance -- we can approach something like a quarter of a petabyte, at 200Gbps wireline throughput." Straw claimed that, on average, SoftIron servers run 25C cooler than a comparable system powered by Xeons." So... ARM in the datacenter might be saying, "I'm not quite dead yet!"

After being delayed for the better part of one month, LLVM 8.0 officially is finally available. From a report: LLVM release manager Hans Wennborg announced the release a few minutes ago and summed up this half-year update to LLVM and its sub-project as: "speculative load hardening, concurrent compilation in the ORC JIT API, no longer experimental WebAssembly target, a Clang option to initialize automatic variables, improved pre-compiled header support in clang-cl, the /Zc:dllexportInlines- flag, RISC-V support in lld. And as usual, many bug fixes, optimization and diagnostics improvements, etc."

Stephen O'Grady, co-founder of the industry analyst firm RedMonk, asks whether open source vendors are marching towards an inevitable and damaging war with big cloud providers: In the last twelve to eighteen months...a switch has been flipped. Companies have gone from regarding cloud providers like Amazon, Google or Microsoft as not even worth mentioning as competition to dreadful, existential threat. The fear of these cloud providers has become so overpowering, in fact, that commercial open source vendors have chosen -- against counsel, in many cases -- to walk down strategic paths that violate open source cultural norms, trigger massive and sustained negative PR and jeopardize relationships with developers, partners and customers. Specifically, commercial open source providers have increasingly turned to models that blur the lines between open source and proprietary software in an attempt to access the strengths of both, with the higher probability outcome of ending up with their weaknesses instead.

That commercial open source providers took these actions having been advised of these and other risks in advance says everything about how these businesses view their prospects in a world increasingly dominated by massive providers of cloud infrastructure and an expanding array of services that sit on top of that. The strategic decisions inarguably have major, unavoidable negative consequences, but commercial open source providers -- or their investors, at least -- believe that a lack of action would be even more damaging.

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.