The Raspberry Pi Foundation has released a tiny $5 fan combined with a small heatsink for the Raspberry Pi 4. TechCrunch reports: It works with the official case, below the top cover. That accessory should prevent the Raspberry Pi from overheating. According to the foundation, the tiny fan should be enough to prevent throttling. "It draws air in over the USB and Ethernet connectors, passes it over a small finned heatsink attached to the processor, and exhausts it through the SD card slot," the Raspberry Pi Foundation says. It's a cheap stopgap solution, but I hope the Foundation will prioritize heat dissipation for the next iteration of the Raspberry Pi.

Read more of this story at Slashdot.

On October 23rd GitHub initially complied with a takedown request for the open-source project youtube-dl — and then after 24 days, reinstated it. "If there's a silver lining to the episode, it's that GitHub is implementing new policies to avoid a repeat of a repeat situation moving forward," reports Engadget: First, it says a team of both technical and legal experts will manually evaluate every single section 1201 claim. In instances where there's any ambiguity to a claim, the company says it will err on the side of developers and leave their repository online. If the company's technical and legal teams ultimately find any issues with a project, GitHub will give its owners the chance to address those problems before it takes down their work. Following a takedown, it will continue to give people the chance to recover their data — provided it doesn't include any offending code. GitHub is also establishing a $1 million defense fund to provide legal aid to developers against suspect section 1201 claims, as well as doubling down on its lobbying work to amend the DMCA and other similar copyright laws across the world.

Read more of this story at Slashdot.

Reader shanen shares a report (and offers this commentary): When the open source concept emerged in the '90s, it was conceived as a bold new form of communal labor: digital barn raisings. If you made your code open source, dozens or even hundreds of programmers would chip in to improve it. Many hands would make light work. Everyone would feel ownership. Now, it's true that open source has, overall, been a wild success. Every startup, when creating its own software services or products, relies on open source software from folks like Jacob Thornton: open source web-server code, open source neural-net code. But, with the exception of some big projects -- like Linux -- the labor involved isn't particularly communal. Most are like Bootstrap, where the majority of the work landed on a tiny team of people. Recently, Nadia Eghbal -- the head of writer experience at the email newsletter platform Substack -- published Working in Public, a fascinating book for which she spoke to hundreds of open source coders. She pinpointed the change I'm describing here. No matter how hard the programmers worked, most "still felt underwater in some shape or form," Eghbal told me. Why didn't the barn-raising model pan out? As Eghbal notes, it's partly that the random folks who pitch in make only very small contributions, like fixing a bug. Making and remaking code requires a lot of high-level synthesis -- which, as it turns out, is hard to break into little pieces. It lives best in the heads of a small number of people. Yet those poor top-level coders still need to respond to the smaller contributions (to say nothing of requests for help or reams of abuse). Their burdens, Eghbal realized, felt like those of YouTubers or Instagram influencers who feel overwhelmed by their ardent fan bases -- but without the huge, ad-based remuneration. Sometimes open source coders simply walk away: Let someone else deal with this crap. Studies suggest that about 9.5 percent of all open source code is abandoned, and a quarter is probably close to being so. This can be dangerous: If code isn't regularly updated, it risks causing havoc if someone later relies on it. Worse, abandoned code can be hijacked for ill use. Two years ago, the pseudonymous coder right9ctrl took over a piece of open source code that was used by bitcoin firms -- and then rewrote it to try to steal cryptocurrency.

Read more of this story at Slashdot.

Dan Kohn, leader of the Linux Foundation's Public Health (LFPH) initiative and former executive director at the Cloud Native Computing Foundation (CNCF), has passed away of complications from colon cancer. Linux Foundation Executive Director Jim Zemlin wrote yesterday (via LFPH): Dan played a special role at the Linux Foundation. He helped establish the organization that we are today and oversaw the fastest growing open source community in history, the Cloud Native Computing Foundation. Dan was also a pioneer. In 1994 he conducted the first secure commercial transaction on the internet after building the first web shopping cart. What you may not know about Dan was his lifelong desire to help others. From serving as a volunteer firefighter in college to stepping aside from his role in the Cloud Native Computing Foundation to incubate and found the Linux Foundation Public Health initiative which is helping authorities around the world combat Covid19; Dan could always be counted on in a crisis. Dan leaves behind his wife Julie and two young boys, Adam and Ellis... We will be creating a scholarship fund for his children and will send out information in the coming days as to how folks can contribute. LFPH has set up a card for the community to sign to forward to his family when the time is right. You may sign it here. Alex Williams from The New Stack has also paid tribute to Kohn.

Read more of this story at Slashdot.

The Wikimedia Foundation, the American non-profit organization that owns the internet domain names of many movement projects and hosts sites like Wikipedia, has decided to migrate their code repositories from Gerrit to Gitlab. Slashdot reader nfrankel shares the announcement: For the past two years, our developer satisfaction survey has shown that there is some level of dissatisfaction with Gerrit, our code review system. This dissatisfaction is particularly evident for our volunteer communities. The evident dissatisfaction with code review, coupled with an internal review of our CI tooling and practice makes this an opportune moment to revisit our code review choices. While Gerrit's workflow is in many respects best-in-class, its interface suffers from usability deficits, and its workflow differs from mainstream industry practices. This creates barriers to entry for the community and slows onboarding for WMF technical staff. In addition, there are a growing number of individuals and teams (both staff and non-staff) who are opting to forgo the use of Gerrit and instead use a third-party hosted option such as GitHub. Reasons vary for the choice to use third-party hosting but, based on informal communication, there are 3 main groupings: lower friction to create new repositories; easier setup and self-service of Continuous Integration configuration; and more familiarity with pull-request style workflows. All these explanations point to friction in our existing code-review system slowing development rather than fostering it. The choice to use third-party code-hosting hurts our collaboration (both internal and external), adds to the confusion of onboarding, and makes it more difficult to maintain code standards across repositories. At the same time, there is a requirement that all software which is deployed to Wikimedia production is hosted and deployed from Gerrit. If we fail to address the real usability problems that users have with Gerrit, people will continue to launch and build projects on whatever system it is they prefer -- Wikimedia's GitHub already contains 152 projects, the Research team has 127 projects. This raises the question: if Gerrit has identifiable problems, why can't we solve those problems in Gerrit? Gerrit is open source (Apache licensed) software; modifications are a simple matter of programming. [...] Upstream has improved the UI in recent releases, and releases have become more frequent; however, upgrade path documentation is often lacking. The migration from Gerrit 2 to Gerrit 3, for example, required several upstream patchsets to avoid the recommended path of several days of downtime. This is the effort required to maintain the status quo. Even small improvements require effort and time as, often, our use-case is very different from the remainder of the Gerrit community.

Read more of this story at Slashdot.

emil (Slashdot reader #695) shares an article from Linux Journal re-visiting the saga of the btrfs file system (initially designed at Oracle in 2007): The btrfs filesystem has taunted the Linux community for years, offering a stunning array of features and capability, but never earning universal acclaim. Btrfs is perhaps more deserving of patience, as its promised capabilities dwarf all peers, earning it vocal proponents with great influence. Still, [while] none can argue that btrfs is unfinished, many features are very new, and stability concerns remain for common functions. Most of the intended goals of btrfs have been met. However, Red Hat famously cut continued btrfs support from their 7.4 release, and has allowed the code to stagnate in their backported kernel since that time. The Fedora project announced their intention to adopt btrfs as the default filesystem for variants of their distribution, in a seeming juxtaposition. SUSE has maintained btrfs support for their own distribution and the greater community for many years. For users, the most desirable features of btrfs are transparent compression and snapshots; these features are stable, and relatively easy to add as a veneer to stock CentOS (and its peers). Administrators are further compelled by adjustable checksums, scrubs, and the ability to enlarge as well as (surprisingly) shrink filesystem images, while some advanced btrfs topics (i.e. deduplication, RAID, ext4 conversion) aren't really germane for minimal loopback usage. The systemd init package also has dependencies upon btrfs, among them machinectl and systemd-nspawn . Despite these features, there are many usage patterns that are not directly appropriate for use with btrfs. It is hostile to most databases and many other programs with incompatible I/O, and should be approached with some care. The original submission drew reactions from three disgruntled btrfs users. But the article goes on to explore providers of CentOS-compatible btrfs-enabled kernels, ultimately opining that "There are many 'rough edges' that are uncovered above with btrfs capabilities and implementations, especially with the measures taken to enable it for CentOS. Still, this is far better than ext2/3/4 and XFS, discarding all the desirable btrfs features, in that errors can be known because all filesystem content is checksummed." It would be helpful if the developers of btrfs and ZFS could work together to create a single kernel module, with maximal sharing of "cleanroom" code, that implemented both filesystems... Oracle is itself unwilling to settle these questions with either a GPL or BSD license release of ZFS. Oracle also delivers a btrfs implementation that is lacking in features, with inapplicable documentation, and out-of-date support tools (for CentOS 8 conversion). Oracle is the impediment, and a community effort to purge ZFS source of Oracle's contributions and unify it with btrfs seems the most straightforward option... It would also be helpful if other parties refrained from new filesystem efforts that lack the extensive btrfs functionality and feature set (i.e. Microsoft ReFS). Until such a day that an advanced filesystem becomes a ubiquitous commodity as Linux is as an OS, the user community will continue to be torn between questionable support, lack of features, and workarounds in a fragmented btrfs community. This is an uncomfortable place to be, and we would do well to remember the parties responsible for keeping us here. So how do Slashdot's readers feel about btrfs?

Read more of this story at Slashdot.

An anonymous reader quotes a report from ZDNet: The writing was on the wall two years ago. The OpenStack Foundation was going to cover more than just the OpenStack Infrastructure-as-a-Service (IaaS) cloud. Today, that metamorphosis is complete. The Foundation now covers a wide variety of open-source cloud and container technologies as the Open Infrastructure Foundation. Why so long? COO Mark Collier said, "They wanted to be sure they did this right." One reason for this was to make sure they could differentiate their group from The Linux Foundation's Cloud Native Computing Foundation (CNCF), which covers much of the same ground. The Open Infrastructure Foundation executive director Jonathan Bryce said that, "OpenStack is still one of the top three most active open source projects in the world. It's just the landscape of infrastructure and there are many new exciting trends with open becoming more and more ubiquitous." To make use of all these different ways the cloud has evolved requires new software programs and that's where the Open Infrastructure Foundation comes in. The new Foundation's mission is to establish new open-source communities to help bring into production new emerging use cases. This includes AI/ML; CI/CD; container infrastructure; edge computing; 5G; and public, private and hybrid clouds.

Read more of this story at Slashdot.

ArchieBunker writes: The OpenBSD project has turned 25 years old and is celebrating this with release 6.8.

Read more of this story at Slashdot.

The official public repository for CUPS, an Apple open-source project widely used for printing on Linux, is all-but dormant since the lead developer left Apple at the end of 2019. From a report: Apple adopted CUPS for Mac OS X in 2002, and hired its author Michael Sweet in 2007, with Cupertino also acquiring the CUPS source code. Sweet continued to work on printing technology at Apple, including CUPS, until December 2019 when he left to start a new company. Asked at the time about the future of CUPS, he said: "CUPS is still owned and maintained by Apple. There are two other engineers still in the printing team that are responsible for CUPS development, and it will continue to have new bug fix releases (at least) for the foreseeable future." Despite this statement, Linux watcher Michael Larabel noted earlier this week that "the open-source CUPS code-base is now at a stand-still. There was just one commit to the CUPS Git repository for all of 2020." This contrasts with 355 commits in 2019, when Sweet still worked at Apple, and 348 the previous year. We asked Apple about its plans for CUPS and have yet to hear back.

Read more of this story at Slashdot.

Nvidia has debuted the Jetson Nano 2GB, a new developer kit for students and hobbyists with an interest in robotics. ZDNet reports: The Jetson Nano 2GB is geared towards robotics enthusiasts, students, and educators that want to enter the field of artificial intelligence (AI) and robotics. Nvidia says the entry-level Jetson Nano 2GB has been priced at $59 -- including online tutorials and certification -- to "make AI easily accessible for all." The Jetson Nano 2GB is a small package with a punch: not only supported by the Nvidia JetPack software development kit (SDK), the device also comes with Nvidia container runtime and a full Linux environment suitable for software development. In addition, the Jetson Nano 2GB is powered by CUDA-X, a collection of libraries and tools designed to support AI-based features, data processing, machine learning (ML), and deployment. Nvidia says that this combination "allows developers to package their applications for Jetson with all its dependencies into a single container that is designed to work in any deployment." Free online training and certification are on offer, alongside open source projects, tutorials, and how-tos already contributed by thousands of Jetson developers. It's currently available for pre-order, but orders won't start shipping until the end of the month.

Read more of this story at Slashdot.

Legendary horror game Amnesia: The Dark Descent and A Machine for Pigs is now open source, meaning that modders can dig in and see what lies underneath the hood of both games. Polygon reports: The full source code for The Dark Descent and A Machine for Pigs has been released on Github for folks who want to take a crack at modifying the game. It's relatively rare for developers to post their game codes themselves, though sometimes proprietary code can make its way online via leaks. "This doesn't mean that the game is suddenly free," Amnesia developer Frictional Games said in a blog post. "It just means that people are free to use the source however they want as long as they adhere to the GPL3 licence. The game and all of its content is still owned by Frictional Games. Just like before." Seeing how these classic games are built will also mean seeing things like flaws, and inefficiencies Frictional Games warned -- but it's all still functional and potentially useful to anyone learning game development. "I also hope this release can be of help to anyone wanting to create their own engine or just wanting to learn more about game programming," Frictional Games said. "While the code is not the greatest in places and the tech used is not the latest, it is a fully contained game engine in a fairly easy-to-understand package. It is also a testament that it is possible to do this sort of thing, even with a very limited team."

Read more of this story at Slashdot.

Slashdot reader Hmmmmmm quotes Ghacks: Raymond Hill, known online as gorhill, has set the status of the uMatrix GitHub repository to archived; this means that it is read-only at the time and that no updates will become available. The uMatrix extension is available for several browsers including Firefox, Google Chrome, and most Firefox and Chromium-based browsers. It is a privacy and security extensions for advanced users that provides firewall-like capabilities when it is installed... Hill suggests that developers could fork the extension to continue development under a new name. There is also the chance that Hill might resume development in the future but there is no guarantee that this is going to happen. For now, uMatrix is no longer in active development.

Read more of this story at Slashdot.

Esther Schindler (Slashdot reader #16,185), shares some thoughts from long-time tech reporter Steven J. Vaughan-Nichols: We'd like an easy way to judge open-source programs. It can be done. But easily? That's another matter... Plenty of people have created systems to collect, judge, and evaluate open-source projects, including information about a project's popularity, reliability, and activity. But each of those review sites — and their methodologies — have flaws. The article looks at a variety of attempts, including freshmeat.net; Eric Raymond's attempt to revive Freecode; GitHub's star (which Docker's co-founder calls a "bullshit metric"); Synopsys's Black Duck Open Hub (formerly Ohloh); and even Google Trends. But it wraps up by pointing out that Brian Profitt, Red Hat's Open Source Program Office (OSPO) manager, is working with others on "Project CHAOSS," a new Linux Foundation project to make it easy to evaluate open-source projects. This pulled together Grimoirelab and similar programs, such as Augur and Red Hat's own Prospector... Its metrics include what kinds of contributions are being made; when the contributions are made; and who's making the contributions. All of which are vital to understanding the overall health of a project. CHAOSS is still a work in progress. Its official release is scheduled for February 2021... Ultimately, this data will be available to all, from end users to the project leads. "In fact, I hope this happens a lot, because we can refine our models more quickly," says Profitt.

Read more of this story at Slashdot.

An anonymous reader shares an opinion piece from Wired, written by Kevin Xu and Jordan Schneider. Xu is the author of Interconnected, investor and advisor of open source startups at OSS Capital, and served in the Obama White House. Schneider is the author of the ChinaTalk newsletter and host of the ChinaTalk podcast, posted on Lawfare. From the report: Open source is a technology development and distribution methodology, where the codebase and all development -- from setting a roadmap to building new features, fixing bugs, and writing documentation -- is done in public. A governing body (a group of hobbyists, a company, or a foundation) publicly manages this work, which is most often done in a public repository on either GitHub or GitLab. Open source has two important, and somewhat counterintuitive, advantages: speed and security. These practices lead to faster technological developments, because a built-in global community of developers help them mature, especially if the technology is solving a real problem. Top engineers also prefer to work with and on open source projects. Wrongly cast as secretive automatons, they are more often like artists, who prefer to learn, work, collaborate, and showcase what they've built in public, even when they are barely compensated for that work. But doesn't keeping a technology's codebase open make it more vulnerable to attack? In fact, exposing the codebase publicly for security experts and hackers to easily access and test is the best way to keep the technology secure and build trust with end users for the long haul. Sunlight is the best disinfectant, and open source is that sunlight in technology. Linux, the operating system, and Kubernetes, the cloud container orchestration system, are two of the most prominent examples. [...] Using open source technology is now the fastest way new products get built and legacy technologies get replaced. Yet as US policymakers develop their industrial policy to compete with China, open source is conspicuously absent. By leaning on the advantages of open source, policymakers can pursue an industrial policy to help the US compete in the 21st century in line with our broader values. The alternative is to continue a top-down process that picks winners and losers based on not just technology but also political influence, which only helps individual firms secure market share, not sparking innovation more broadly. A few billion more dollars won't save Intel from its technical woes, but a healthier ecosystem leveraging open source technology and community would put the US in a better position for the future. Open source technology allows for vendor-neutrality. Whether you're a country or a company, if you use open source, you're not locked in to another company's technical stack, roadmap, or licensing agreements. After Linux was first created in 1991, it was widely adopted by large companies like Dell and IBM as a vendor neutral alternative to Microsoft's Windows operating system. In the future, chip designers won't be locked into Intel or ARM with RISC-V. With OpenRAN, 5G network builders won't be forced to buy from Huawei, Nokia, or Ericsson. [...] By doubling down on open source, America not only can address some of our most pressing technological challenges faster and more securely, but also revive relationships with our allies and deepen productive collaborations with the tech sector.

Read more of this story at Slashdot.

Matt Asay, a former COO of Canonical now working at AWS, argues that the question of open source sustainability "is really a people problem." But to make the case, he cites comments by Tobie Langel, formerly W3C's testing lead (and a former member of Facebook's Open Source and Web Standards Team) who's now founded an open-source strategies consulting firm whose clients include Mozilla, Intell, Google, and Microsoft. Much of the "open source sustainability" discussion has focused on the one thing that really needs no help being sustained: software. As Tobie Langel rightly points out, "Open source code isn't a scarce resource. It's the exact opposite, actually: It's infinitely reproducible at zero cost to the user and to the ecosystem." Nor is sustainability really a matter of funding, though this gets closer to the truth. No, open source sustainability is really a people problem. Or, as Langel highlights, "In open source, the maintainers working on the source code are the scarce resource that needs to be protected and nurtured." Over the past several weeks, I've interviewed a number of maintainers for popular open source projects. In every case, they talked about how they contribute because it's fun, but also acknowledged that some aspects of open source development can make it decidedly "un-fun" (e.g., demanding users who complain about missing features or existing bugs but don't contribute code or fixes). Most have found ways to turn their passion into financial independence, but Langel stresses that cash is critical to keeping open source humming along... "Without revenue, there is no maintenance, and without maintenance, the commons becomes toxic very quickly... As new security issues are discovered, open source code that isn't updated becomes a security risk..." Langel is absolutely correct to argue, "In an ecosystem with infinite resources, the attention needs to be on the people taking care of and maintaining that resource, because that's where the bottleneck is." Again, that's partly a question of money, but it's even more a question of treating people with dignity and respect, while making open source communities a fun, welcoming place.

Read more of this story at Slashdot.

Slashdot reader #16,185 wrote regularly for the newsletter of a small-town computer users group. Now they've written an article for Ars Technica reminding readers that "The Homebrew Computer Club where the Apple I got its start is deservedly famous — but it's far from tech history's only community gathering centered on CPUs." Throughout the 70s and into the 90s, groups around the world helped hapless users figure out their computer systems, learn about technology trends, and discover the latest whiz-bang applications. And these groups didn't stick to Slacks, email threads, or forums; the meetings often happened in real life. But to my dismay, many young technically-inclined whippersnappers are completely unaware of computer user groups' existence and their importance in the personal computer's development. That's a damned shame... Computer groups celebrated the industry's fundamental values: a delight in technology's capabilities, a willingness to share knowledge, and a tacit understanding that we're all here to help one another... Two things primarily made user groups disappear: first was the Internet — and the BBSes that preceded them. If you could articulate a question, you could find a website with the answer. But computers also became easier to use. Once personal computers went mainstream, troubleshooting them stopped being an esoteric endeavor. The typical computer user group is gone now. For the exceptions, you can find an incomplete and mostly out-of-date list via the Association of PC User Groups, though online exploration may lead you to more options. For example, the Toronto PET Users Group (TPUG) is the longest continually operating Commodore user group. Washington Apple Pi is still going strong, as is the Triangle Linux Users Group. IBM's user group, SHARE, began in the 1950s and continues to support enterprise users, though it's primarily a conference these days... Hopefully tech will continue to inspire ways to get together with other people who share your enthusiasm, whether it's Raspberry Pi meetups, Maker days, or open source conferences such as Drupalcon or PyCon. You also continue the computer user group ethos by finding ways to help other tech enthusiasts locally. For example, Hack Club aims to teach skills to high school students. Hack Clubs are already in two percent of US high schools across 35 states and 17 countries, with about 10,000 students attending clubs and hackathons each year. So even if computer user groups largely are a thing of the past, their benefits live on. User groups were the precursor to the open source community, based on the values of sharing knowledge and helping one another. And who knows, without user groups promoting a cooperative viewpoint, the open source community might never have taken off like it did. The article includes photographs of the OS/2 community's magazine Extended Attributes, the M.A.C.E. Journal (for Atari users), the Commodore Eight Bit Boosters newsletter, and the 1979 publication Prog/80 ("dedicated to the serious programmer.") And it also includes video of a 1981 visit to the Boston Computer Society by a 25-year-old Bill Gates.

Read more of this story at Slashdot.

InfoQ reports on a new security group that launched last week: Supported by The Linux Foundation, the Open Source Security Foundation (OpenSSF) aims to create a cross-industry forum for a collaborative effort to improve open source software security. The list of initial members includes Google, Microsoft, GitHub, IBM, Red Hat, and more. "As open source has become more pervasive, its security has become a key consideration for building and maintaining critical infrastructure that supports mission-critical systems throughout our society. It is more important than ever that we bring the industry together in a collaborative and focused effort to advance the state of open source security. The world's technology infrastructure depends on it." Microsoft CTO for Azure Mark Russinovich explained clearly why open source security must be a community effort: "Open-source software is inherently community-driven and as such, there is no central authority responsible for quality and maintenance. [...] Open-source software is also vulnerable to attacks against the very nature of the community, such as attackers becoming maintainers of projects and introducing malware. Given the complexity and communal nature of open source software, building better security must also be a community-driven process." Also joining the group are Intel, IBM, Uber, and VMWare, according to Foundation's inaugural announcement, which promises its governance and decisions "will be transparent, and any specifications and projects developed will be vendor agnostic."

Read more of this story at Slashdot.