On Wednesday Phoronix cited a blog post by C++ game developer Malte Skarupke claiming his spinlocks experiments had discovered the Linux kernel had a scheduler issue affecting developers bringing games to Linux for Google Stadia.

Linus Torvalds has now responded: The whole post seems to be just wrong, and is measuring something completely different than what the author thinks and claims it is measuring.

First off, spinlocks can only be used if you actually know you're not being scheduled while using them. But the blog post author seems to be implementing his own spinlocks in user space with no regard for whether the lock user might be scheduled or not. And the code used for the claimed "lock not held" timing is complete garbage.

It basically reads the time before releasing the lock, and then it reads it after acquiring the lock again, and claims that the time difference is the time when no lock was held. Which is just inane and pointless and completely wrong...

[T]he code in question is pure garbage. You can't do spinlocks like that. Or rather, you very much can do them like that, and when you do that you are measuring random latencies and getting nonsensical values, because what you are measuring is "I have a lot of busywork, where all the processes are CPU-bound, and I'm measuring random points of how long the scheduler kept the process in place".

And then you write a blog-post blamings others, not understanding that it's your incorrect code that is garbage, and is giving random garbage values...

You might even see issues like "when I run this as a foreground UI process, I get different numbers than when I run it in the background as a batch process". Cool interesting numbers, aren't they?

No, they aren't cool and interesting at all, you've just created a particularly bad random number generator...

[Y]ou should never ever think that you're clever enough to write your own locking routines.. Because the likelihood is that you aren't (and by that "you" I very much include myself -- we've tweaked all the in-kernel locking over decades, and gone through the simple test-and-set to ticket locks to cacheline-efficient queuing locks, and even people who know what they are doing tend to get it wrong several times).

There's a reason why you can find decades of academic papers on locking. Really. It's hard.
"It really means a lot to me that Linus responded," the blogger wrote later, "even if the response is negative." They replied to Torvalds' 1,500-word post on the same mailing list -- and this time received a 1900-word response arguing "you did locking fundamentally wrong..." The fact is, doing your own locking is hard. You need to really understand the issues, and you need to not over-simplify your model of the world to the point where it isn't actually describing reality any more...

Dealing with reality is hard. It sometimes means that you need to make your mental model for how locking needs to work a lot more complicated...

Phoronix reports that on New Year's Day, the Linux kernel's Git source tree showed 27,852,148 lines of code, divided among 66,492 files (including docs, Kconfig files, user-space utilities in-tree, etc).

Over its lifetime there's been 887,925 commits, and around 21,074 different authors: During 2019, the Linux kernel saw 74,754 commits, which is actually the lowest point since 2013. The 74k commits is compares to 80k commits seen in both 2017 and 2018, 77k commits in 2016, and 75k commits in both 2014 and 2015. Besides the commit count being lower, the author count for the year is also lower. 2019 saw around 4,189 different authors to the Linux kernel, which is lower than the 4,362 in 2018 and 4,402 in 2017.

While the commit count is lower for the year, on a line count it's about average with 3,386,347 lines of new code added and 1,696,620 lines removed...

Intel and Red Hat have remained the top companies contributing to the upstream Linux kernel.

During a campaign event on Monday, U.S. presidential candidate Joe Biden "suggested coal miners could simply learn to code to transition to 'jobs of the future,'" reports Newsweek: "Anybody who can go down 300 to 3,000 feet in a mine, sure in hell can learn to program as well, but we don't think of it that way," he said... "Anybody who can throw coal into a furnace can learn how to program for God's sake..."

Many Twitter users criticized Biden's comments as reductive. "Telling people to find other work without a firm plan to help them succeed will never be popular," communications professional Frank Lutz wrote... Congressional candidate Brianna Wu tweeted that she was "glad to see the recognition that you don't need to be in your 20s to do this as a profession," but also called Biden's suggestion "tone-deaf and unhelpful."
Long-time Slashdot reader theodp notes the response this speech got from New York magazine's Sarah Jones: "Please Stop Telling Miners To Learn To Code." And in comments on the original submission, at least two Slashdot readers seemed to agree. "Not everyone can code and certainly not every coal miner or coal worker," wrote Slashdot reader I75BJC. "Vastly different skills."

Slashdot reader Iwastheone even shared a Fox News article in which rival presidential candidate Andrew Yang argued "Maybe Americans don't all want to learn how to code... Let them do the kind of work they actually want to do, instead of saying to a group of people that you all need to become coders."

But is there something elitist in thinking that coal miners couldn't learn to do what coders learned to do? It seems like an interesting question for discussion -- so leave your own thoughts in the comments.

Should coal miners be encouraged to learn to code?

Mazda says "incorrect programming" in its Smart Braking System (SBS) can make fourth-generation Mazda 3 vehicles falsely detect on object in their path while driving and automatically apply the brakes while driving. "The problem affects 35,390 2019 and 2020 model year cars in the U.S., but Mazda says it is not aware of any injuries or deaths as a result of the defect," reports Engadget. From the report: If the issue occurs, the driver will notice because their car has suddenly stopped, and also as an alarm sounds and a message is displayed on the in-car warning screen. Some Reddit posters report experiencing situations of the system activating while driving with nothing around, and note that while the system can be disabled, it appears to re-enable itself every time the car starts.

Autoblog reports that while some vehicles will simply need to have the system updated or reprogrammed, certain cars with early build dates might need to have their entire instrument cluster replaced or reprogrammed. It's a scary issue, but we've seen Mazda update its cars software to deal with real-life bugs, and the newly-redesigned Mazda3 has already seen a recall to make sure its wheels don't fall off.

Over 20,000 developers have shared what are their favorite JavaScript features, front-end frameworks and back-end frameworks in a new annual survey. The figures come from the fourth State of JavaScript survey, which included responses from 21,717 developers around the world. On the flavors front -- languages that compile to JavaScript -- most developers were satisfied with Microsoft-backed open-source JavaScript superset, TypeScript, followed by Reason, Elm, ClosureScript, and PureScript. But TypeScript also came out on top when ranking developers' interest as well as awareness. Some 58% of developers reported having used TypeScript and that they would use it again, compared to less than 5% for all other flavors of JavaScript.

Kubernetes (originally designed by Google) is a prominent open-source container-orchestration system for cloud computing with over 4.3 million lines of Go source code. Over 700,000 lines of that code are comments.

"We've been working on a project that surfaces TODO comments in a codebase to help developers do basic project management workflows within that codebase," reads a new essay on Medium. So what did the software learn from over 2,000 TODO comments on Kubernetes? Slashdot reader patrickdevivo writes: It finds that most TODOs are quite old (average age of 2+ years) and about a quarter of them have an assignee (so they're kind of like a ticket?)

The tool used to surface the information is called tickgit, and it looks for "project management metadata" in a codebase.

The data confirms what most developers intuitively understand -- many TODO comments are forgotten and typically not addressed in a reasonable amount of time. This also appears to be the case in Kubernetes, just on a larger scale.

At its developer conference in June this year, Apple introduced Project Catalyst that aims to help developers swiftly bring their iOS apps to Macs. Developers have had more than half a year to play with Catalyst. Here's where things stand currently: The crux of the issue in my mind is that iOS and Mac OS are so fundamentally different that the whole notion of getting a cohesive experience through porting apps with minimal effort becomes absurd. The problem goes beyond touch vs pointer UX into how apps exist and interact within their wider OSes. While both Mac OS and iOS are easy to use, their ease stem from very different conventions. The more complicated Mac builds ease almost entirely through cohesion. Wherever possible, Mac applications are expected to share the same shortcuts, controls, windowing behavior, etc... so users can immediately find their bearings regardless of the application. This also means that several applications existing in the same space largely share the same visual and UX language. Having Finder, Safari, BBEdit and Transmit open on the same desktop looks and feels natural.

By comparison, the bulk of iOS's simplicity stems from a single app paradigm. Tap an icon on the home screen to enter an app that takes over the entire user experience until exited. Cohesion exists and is still important, but its surface area is much smaller because most iOS users only ever see and use a single app at a time. For better and worse, the single app paradigm allows for more diverse conventions within apps. Having different conventions for doing the same thing across multiple full screen apps is not an issue because users only have to ever deal with one of those conventions at a given time. That innocuous diversity becomes incongruous once those same apps have to live side-by-side. Columnist John Gruber of DaringFireball adds: I think part of the problem is Catalyst itself -- it just doesn't feel like nearly a full-fledged framework for creating proper Mac apps yet. But I think another problem is the culture of doing a lot of nonstandard custom UI on iOS. As Wellborn points out, that flies on iOS -- we UI curmudgeons may not like it, but it flies -- because you're only ever using one app at a time on iOS. It cracks a bit with split-screen multitasking on iPadOS, but I've found that a lot of the iPad apps with the least-standard UIs don't even support split-screen multitasking on iPadOS, so the incongruities -- or incoherences, to borrow Wellborn's well-chosen word -- don't matter as much. But try moving these apps to the Mac and the nonstandard UIs stick out like a sore thumb, and whatever work the Catalyst frameworks do to support Mac conventions automatically doesn't kick in if the apps aren't even using the standard UIKit controls to start with. E.g. scrolling a view with Page Up, Page Down, Home, and End. Further reading: Apple's Merged iPad, Mac Apps Leave Developers Uneasy, Users Paying Twice (October 2019).

An anonymous reader quotes Mike Melanson's "This Week in Programming" column: WebAssembly is a binary instruction format for a stack-based virtual machine and this week, the World Wide Web Consortium (W3C) dubbed it an official web standard and the fourth language for the Web that allows code to run in the browser, joining HTML, CSS and JavaScript... With this week's news, WebAssembly has officially reached version 1.0 and is supported in the browser engines for Firefox, Chrome, Safari, and Internet Explorer, and the Bytecode Alliance launched last month to help ensure "a WebAssembly ecosystem that is secure by default" and for bringing WebAssembly to outside-the-browser use.

Of course, not everything is 100% rosy. As pointed out by an article in The Register, WebAssembly also brings with it an increased level of obfuscation of what exactly is going on, giving it an increased ability to perform some surreptitious actions. For example, they cite one study that "found 'over 50 percent of all sites using WebAssembly apply it for malicious deeds, such as [crypto] mining and obfuscation.'" Nonetheless, with WebAssembly gaining this designation by W3C, it is, indeed, time to pay closer attention to the newly nominated Web language standard.

Cade Metz from The New York Times pays tribute to Tony Brooker, the mathematician and computer scientist who designed the programming language for the world's first commercial computer. Brooker died on Nov. 20 at the age of 94. From the report: Mr. Brooker had been immersed in early computer research at the University of Cambridge when one day, on his way home from a mountain-climbing trip in North Wales, he stopped at the University of Manchester to tour its computer lab, which was among the first of its kind. Dropping in unannounced, he introduced himself to Alan Turing, a founding father of the computer age, who at the time was the lab's deputy director. When Mr. Brooker described his own research at the University of Cambridge, he later recalled, Mr. Turing said, "Well, we can always employ someone like you." Soon they were colleagues.

Mr. Brooker joined the Manchester lab in October 1951, just after it installed a new machine called the Ferranti Mark 1. His job, he told the British Library in an interview in 2010, was to make the Mark 1 "usable." Mr. Turing had written a user's manual, but it was far from intuitive. To program the machine, engineers had to write in binary code -- patterns made up of 0s and 1s -- and they had to write them backward, from right to left, because this was the way the hardware read them. It was "extremely neat and very clever but pretty meaningless and very unfriendly," Mr. Brooker said. In the months that followed, Mr. Brooker wrote a language he called Autocode, based on ordinary numbers and letters. It allowed anyone to program the machine -- not just the limited group of trained engineers who understood the hardware. This marked the beginning of what were later called "high-level" programming languages -- languages that provide increasingly simple and intuitive ways of giving commands to computers, from the IBM mainframes of the 1960s to the PCs of the 1980s to the iPhones of today.

"The crime scene DNA sequencing company Verogen announced yesterday that they've acquired the genomics database and website GEDmatch," reports The Verge. "GEDmatch was primarily used by genealogists until 2018, when police, the FBI, and a forensic genealogist identified the suspected Golden State Killer by tying crime scene DNA to relatives who had uploaded their genetic information to the site. Since then, the platform has helped identify around 70 people accused of violent crimes." From the report: The acquisition makes the relationship between the company and law enforcement explicit, but raises uncomfortable questions for users and experts about data privacy and the future direction of the platform. In response to privacy concerns, the company changed its terms and conditions last spring to only allow law enforcement access to data if users actively opted in. But until now, interaction with law enforcement was still a secondary function to the platform.

The announcement took many in the genetics and genealogy community by surprise, and many genealogists are leaving the platform. "There have simply been too many changes, all of them in the direction of making their data the product rather than the website a service," said lawyer and genealogist Judy Russell in an email to The Verge. GEDmatch users were prompted to accept new terms and conditions indicating the platform's new ownership, and could either agree and enter the site, or remove their data from the platform. Verogen will still allow users to keep their data from any use by law enforcement, CEO Brett Williams told BuzzFeed News, maintaining the opt-in approach. "It will be interesting to see in the future if the new owners will implement policy changes that will increase the number of individuals available for law enforcement searching," says James Hazel, postdoctoral fellow at the Center for Genetic Privacy and Identity in Community Settings at Vanderbilt University. The report notes, however, that "opt-in is not a foolproof system for data protection." Last month, a Florida detective announced at a police convention that he had obtained a warrant to penetrate GEDmatch and search its full database of nearly one million users.

An anonymous reader writes: Oracle has a huge commitment to the Bay Area. The software giant is based in Redwood Shores, a short drive south from San Francisco. It remains one of the largest employers in Northern California. And until recently, the Golden State Warriors were playing in Oracle Arena in Oakland. Just as the naming rights to that arena expired -- and the Warriors moved across the Bay to San Francisco -- Oracle bought the naming rights to the San Francisco Giants' stadium. For more than 20 years, Oracle has held its annual OpenWorld trade show in San Francisco, as well. The 2019 edition of the event, held in the Moscone Convention Center, drew 60,000 people to the already traffic clogged city, driving hotel prices to dizzying heights. But no more. Oracle today confirmed that starting next year it's moving OpenWorld to Caesars Forum, a new 550,000 square foot conference center in Las Vegas due to open next year. CNBC reports that the San Francisco Travel Association told members via email today that the decision reflects feedback from attendee complaints about high hotel rates and "poor street conditions."

WireGuard has now been committed to the mainline Linux kernel. "While there are still tests to be made and hoops to be jumped through, it should be released in the next major Linux kernel release, 5.6, in the first or second quarter of 2020," reports ZDNet. From the report: WireGuard has been in development for some time. It is a layer 3 secure VPN. Unlike its older rivals, which it's meant to replace, its code is much cleaner and simple. The result is a fast, easy-to-deploy VPN. While it started as a Linux project, WireGuard code is now cross-platform, and its code is now available on Windows, macOS, BSD, iOS, and Android. It took longer to arrive than many wished because WireGuard's principal designer, Jason Donenfeld, disliked Linux's built-in cryptographic subsystem on the grounds its application programming interface (API) was too complex and difficult. He suggested it be supplemented with a new cryptographic subsystem: His own Zinc library. Many developers didn't like this. They saw this as wasting time reinventing the cryptographic well.

But Donenfeld had an important ally. Torvalds wrote, "I'm 1000% with Jason on this. The crypto/ model is hard to use, inefficient, and completely pointless when you know what your cipher or hash algorithm is, and your CPU just does it well directly." In the end, Donenfeld compromised. "WireGuard will get ported to the existing crypto API. So it's probably better that we just fully embrace it, and afterward work evolutionarily to get Zinc into Linux piecemeal." That's exactly what happened. Some Zine elements have been imported into the legacy crypto code in the forthcoming Linux 5.5 kernel. This laid the foundation for WireGuard to finally ship in Linux early next year.

A former Oracle employee filed a lawsuit against the database giant on Tuesday claiming that he was forced out for refusing to lie about the functionality of the company's software. The civil complaint, filed on behalf of plaintiff Tayo Daramola in U.S. District Court in San Francisco, contends that Oracle violated whistleblower protections under the Sarbanes-Oxley Act and the Dodd-Frank Act, the RICO Act, and the California Labor Code.

According to the court filing, Daramola, a resident of Montreal, Canada, worked for Oracle's NetSuite division from November 30, 2016 through October 13, 2017. He served as a project manager for an Oracle cloud service known as the Cloud Campus BookStore initiative and dealt with US customers. Campus bookstores, along with ad agencies, and apparel companies are among the market segments targeted by Oracle and NetSuite. Daramola's clients are said to have included the University of Washington, the University of Oregon, the University of Texas at Austin, Brigham Young University and the University of Southern California.

The problem, according to the complaint, is that Oracle was asking Daramola to sell vaporware -- a charge the company denies. "Daramola gradually became aware that a large percentage of the major projects to which he was assigned were in 'escalation' status with customers because Oracle had sold his customers software products it could not deliver, and that were not functional," the complaint says. Daramola realized that his job "was to ratify and promote Oracle's repeated misrepresentations to customers" about the capabilities of its software, "under the premise of managing the customer's expectations." The ostensible purpose of stringing customers along in this manner was to buy time so Oracle could actually implement the capabilities it was selling, the court filing states.

As Daramola saw it, his job as project manager thus required him to participate "in a process of affirmative misrepresentation, material omission, and likely fraud."
"We don't agree with the allegations," Oracle told The Register "and intend to vigorously defend the matter."

The article also notes that in 2016 Oracle faced another whistleblower lawsuit, this one brought by a former senior finance manager at Oracle who'd said her bosses directed her to inflate the company's cloud sales. Oracle settled that lawsuit "while denying any wrongdoing."

In 1962, 24-year-old Donald Knuth began writing The Art of Computer Programming -- and 57 years later, he's still working on it. But he's finally released The Art of Computer Programming, Volume 4, Fascicle 5: Mathematical Preliminaries Redux; Introduction to Backtracking; Dancing Links.

An anonymous reader writes: On his personal site at Stanford, 81-year-old Donald Knuth promised this newly-released section "will feature more than 650 exercises and their answers, designed for self-study," and he shared an excerpt from "the hype on its back cover":

This fascicle, brimming with lively examples, forms the first third of what will eventually become hardcover Volume 4B. It begins with a 27-page tutorial on the major advances in probabilistic methods that have been made during the past 50 years, since those theories are the key to so many modern algorithms. Then it introduces the fundamental principles of efficient backtrack programming, a family of techniques that have been a mainstay of combinatorial computing since the beginning.

This introductory material is followed by an extensive exploration of important data structures whose links perform delightful dances. That section unifies a vast number of combinatorial algorithms by showing that they are special cases of the general XCC problem --- "exact covering with colors." The first fruits of the author's decades-old experiments with XCC solving are presented here for the first time, with dozens of applications to a dazzling array of questions that arise in amazingly diverse contexts...

Knuth is still offering his famous hexadecimal reward checks (now referred to as "reward certificates," since they're drawn on the imaginary Bank of San Serriffe) to any reader who finds a technical (or typographical) error. "Of course those exercises, like those in Fascicle 6, include many cutting-edge topics that weren't easy for me to boil down into their essentials. So again I'm hoping to receive 'Dear Don' letters...either confirming that at least somebody besides me believes that I did my job properly, or pointing out what I should really have said...."

And to make it easier he's even shared a list of the exercises where he's still "seeking help and reassurance" about the correctness of his answers. "Let me reiterate that you don't have to work the exericse first. You're allowed to peek at the answer; indeed, you're encouraged to do so, in order to verify that the answer is 100% correct."

"Users of an old version of the popular Python language face a reckoning at the end of the year," reports Wired, calling it a programmer's "own version of update hell." The developers who maintain Python, who work for a variety of organizations or simply volunteer their time, say they will stop supporting Python 2 on January 1, 2020 -- more than a decade after the introduction of Python 3 in December 2008. That means no more security fixes or other updates, at least for the official version of Python.

The Python team extended the initial deadline in 2015, after it became apparent that developers needed more time to make the switch.

It's hard to say how many organizations still haven't made the transition. A survey of developers last year by programming toolmaker JetBrains found that 75 percent of respondents use Python 3, up from 53 percent the year before. But data scientist Vicki Boykis points out in an article for StackOverflow that about 40 percent of software packages downloaded from the Python code management system PyPI in September were written in Python 2.7. For many companies, the transition remains incomplete. Even Dropbox, which employed Python creator Guido van Rossum until his retirement last month, still has some Python 2 code to update. Dropbox engineer Max Belanger says shifting the company's core desktop application from Python 2 to Python 3 took three years. "It wasn't a lot of absolute engineering work," Belanger says. "But it took a long time because stability is so important. We wanted to make sure our users didn't feel any effects of the transition."

The transition from Python 2 to 3 is challenging in part because of the number and complexity of other tools that programmers use. Programmers often rely on open source bundles of code known as "libraries" that handle common tasks, such as connecting to databases or verifying passwords. These libraries spare developers from having to rewrite these features from scratch. But if you want to update your code from Python 2 to Python 3, you need to make sure all the libraries you use also have made the switch. "It isn't all happening in isolation," Belanger says. "Everyone has to do it."

Today, the 360 most popular Python packages are all Python 3-compatible, according to the site Python 3 Readiness. But even one obscure library that hasn't updated can cause headaches.
Python's core team is now prioritizing smaller (but more frequent) updates to make it easier to migrate to newer versions, according to the article, noting that Guido Van Rossum "wrote last month that there might not ever be a Python 4. The team could just add features to Python 3 indefinitely that don't break backward compatibility."

The admission comes from the author of the snippet itself, Andreas Lundblad, a Java developer at Palantir, and one of the highest-ranked contributors to StackOverflow, a Q&A website for programming-related topics. From a report: An academic paper [PDF] published in 2018 identified a code snippet Lundblad posted on the site as the most copied Java code taken from StackOverflow and then re-used in open source projects. The code snippet was provided as an answer to a StackOverflow question posted in September 2010. The code snippet printed byte counts (123,456,789 bytes) in a human-readable format, like 123.5 MB. Academics found that this code had been copied and embedded in more than 6,000 GitHub Java projects, more than any other StackOverflow Java snippet. In a blog post published last week, Lundblad said that the code had a flaw as it incorrectly converted byte counts into human-readable formats. Lundblad said he revisited the code after learning of the academic paper and its results. He looked at the code again and published a corrected version on his blog.

Mark Wilson shares a report from BetaNews: When it comes to the extensive and invasive use of biometric data, the USA is one of the worst offenders in the world, faring only slightly better than China. According to research conducted by Comparitech, which rated 50 countries according to how, where and why biometrics were taken and how they are stored, the U.S. ranked as the fourth worst country. Topping the list is China, followed by Malaysia and Pakistan.

While Comparitech did not look at every country in the world, its study did compare 50 of them. To give a country a rating out of 25, each was rated out of five in four categories (storage, CCTV, workplace, and visas) according to how invasive and pervasive and the collection and use of biometrics is. Five questions were also applied to them, with each answer in the affirmative resulting in one point. [The five questions are available in the report.] The U.S. was assigned a score of 20/25 for its heavy use of biometrics, including growing use of facial recognition, without there being specific laws to protect citizens' data. There was concern at the growing use of biometrics in the workplace. At the other end of the league are Ireland and Portugal, both praised for their small or non-existent biometric databases. Both scored 11 points.

Ford will soon start using coffee chaff from McDonald's to manufacture auto parts like headlamp housings and other interior and exterior components. "In addition to making Ford vehicles a little bit 'greener,' the coffee chaff -- or the waste produced by coffee during the roasting process -- will apparently also help the company make parts that are 20 percent lighter," reports Engadget. From the report: Ford already uses various sustainable materials like soy and tree cellulose in an effort to only use recycled and renewable plastics in its vehicles. It has added coffee chaff to the list after its research team discovered that it can be turned into a durable product by heating it to high temperatures under low oxygen and mixing it with additives like plastic. The material will then be turned into pellets that can be formed into various shapes. During the team's tests, they found that the chaff-based material has "significantly better" heat properties than the current material Ford is using. They also discovered that it'll allow the company to enjoy 25 percent energy savings during the molding process. McDonald's is expected to earmark a significant portion of the coffee chaff its North American operations produce for this project. While it's not entirely clear how much chaff that is, McD's generates 62 million pounds of chaff a year in the continent alone, which is currently just used to make coal and garden mulch.

The Python security team removed two trojanized Python libraries from PyPI (Python Package Index) that were caught stealing SSH and GPG keys from the projects of infected developers. From a report: The two libraries were created by the same developer and mimicked other more popular libraries -- using a technique called typosquatting to register similarly-looking names. The first is "python3-dateutil," which imitated the popular "dateutil" library. The second is "jeIlyfish" (the first L is an I), which mimicked the "jellyfish" library. The two malicious clones were discovered on Sunday, December 1, by German software developer Lukas Martini. Both libraries were removed on the same day after Martini notified dateutil developers and the PyPI security team. While the python3-dateutil was created and uploaded on PyPI two days before, on November 29, the jeIlyfish library had been available for nearly a year, since December 11, 2018.

"On the 25th anniversary of the original Sony PlayStation, The Verge shares the story of the PlayStation supercomputers," writes Slashdot reader jimminy_cricket. From the report: Dozens of PlayStation 3s sit in a refrigerated shipping container on the University of Massachusetts Dartmouth's campus, sucking up energy and investigating astrophysics. It's a popular stop for tours trying to sell the school to prospective first-year students and their parents, and it's one of the few living legacies of a weird science chapter in PlayStation's history. Those squat boxes, hulking on entertainment systems or dust-covered in the back of a closet, were once coveted by researchers who used the consoles to build supercomputers. With the racks of machines, the scientists were suddenly capable of contemplating the physics of black holes, processing drone footage, or winning cryptography contests. It only lasted a few years before tech moved on, becoming smaller and more efficient. But for that short moment, some of the most powerful computers in the world could be hacked together with code, wire, and gaming consoles. "The game consoles entered the supercomputing scene in 2002 when Sony released a kit called Linux for the PlayStation 2," reports The Verge. Craig Steffen, senior research scientist at the National Center for Supercomputing Applications, and his group hooked up between 60 and 70 PlayStation 2s, wrote some code, and built out a library.

"The PS3 entered the scene in late 2006 with powerful hardware and an easier way to load Linux onto the devices," the report adds. "Researchers would still need to link the systems together, but suddenly, it was possible for them to imagine linking together all of those devices into something that was a game-changer instead of just a proof-of-concept prototype."