Slashdot reader The8re still remembers the Y2K bug. Now he shares a New Scientist article explaining how it led directly to this year's Y2020 bug -- which affected more than just parking meters: WWE 2K20, a professional wrestling video game, also stopped working at midnight on 1 January 2020. Within 24 hours, the game's developers, 2K, issued a downloadable fix. Another piece of software, Splunk, which ironically looks for errors in computer systems, was found to be vulnerable to the Y2020 bug in November. The company rolled out a fix to users the same week -- which include 92 of the Fortune 100, the top 100 companies in the US....

The Y2020 bug, which has taken many payment and computer systems offline, is a long-lingering side effect of attempts to fix the Y2K, or millennium bug. Both stem from the way computers store dates. Many older systems express years using two numbers -- 98, for instance, for 1998 -- in an effort to save memory. The Y2K bug was a fear that computers would treat 00 as 1900, rather than 2000. Programmers wanting to avoid the Y2K bug had two broad options: entirely rewrite their code, or adopt a quick fix called "windowing", which would treat all dates from 00 to 20, as from the 2000s, rather than the 1900s. An estimated 80 percent of computers fixed in 1999 used the quicker, cheaper option. "Windowing, even during Y2K, was the worst of all possible solutions because it kicked the problem down the road," says Dylan Mulvin at the London School of Economics....

Another date storage problem also faces us in the year 2038. The issue again stems from Unix's epoch time: the data is stored as a 32-bit integer, which will run out of capacity at 3.14 am on 19 January 2038.

Which programming language saw the biggest jump on TIOBE's index of language popularity over the last year?

Unlike last year -- it's not Python. An anonymous reader quotes TIOBE.com: It is good old language C that wins the award this time with an yearly increase of 2.4%... The major drivers behind this trend are the Internet of Things (IoT) and the vast amount of small intelligent devices that are released nowadays...

Runners up are C# (+2.1%), Python (+1.4%) and Swift (+0.6%)...

Other interesting winners of 2019 are Swift (from #15 to #9) and Ruby (from #18 to #11). Swift is a permanent top 10 player now and Ruby seems [destined] to become one soon.

Some languages that were supposed to break through in 2019 didn't: Rust won only 3 positions (from #33 to #30), Kotlin lost 3 positions (from #31 to #35), Julia lost even 10 positions (from #37 to #47) and TypeScript won just one position (from #49 to #48).
And here's the new top 10 programming languages right now, according to TIOBE's January 2020 index.

• Java
• C
• Python
• C++
• C# (up two positions from January 2019)
• Visual Basic .NET (down one position from January 2019)
• JavaScript (down one position from January 2019)
• PHP
• Swift (up six positions from January 2019)
• SQL (down one position from January 2019)

"Linux kernel head Linus Torvalds has warned engineers against adding a module for the ZFS filesystem that was designed by Sun Microsystems -- and now owned by Oracle -- due to licensing issues," reports ZDNet: As reported by Phoronix, Torvalds has warned kernel developers against using ZFS on Linux, an implementation of OpenZFS, and refuses to merge any ZFS code until Oracle changes the open-source license it uses.

ZFS has long been licensed under Sun's Common Development and Distribution License as opposed to the Linux kernel, which is licensed under GNU General Public License (GPL). Torvalds aired his opinion on the matter in response to a developer who argued that a recent kernel change "broke an important third-party module: ZFS". The Linux kernel creator says he refuses to merge the ZFS module into the kernel because he can't risk a lawsuit from "litigious" Oracle -- which is still trying to sue Google for copyright violations over its use of Java APIs in Android -- and Torvalds won't do so until Oracle founder Larry Ellison signs off on its use in the Linux kernel.

"If somebody adds a kernel module like ZFS, they are on their own. I can't maintain it and I cannot be bound by other people's kernel changes," explained Torvalds. "And honestly, there is no way I can merge any of the ZFS efforts until I get an official letter from Oracle that is signed by their main legal counsel or preferably by Larry Ellison himself that says that yes, it's OK to do so and treat the end result as GPL'd," Torvalds continued.

"Other people think it can be OK to merge ZFS code into the kernel and that the module interface makes it OK, and that's their decision. But considering Oracle's litigious nature, and the questions over licensing, there's no way I can feel safe in ever doing so."

At its CES 2020 keynote, Intel showed off its upcoming Xe discrete graphics chip and today, we're seeing exactly how that's going to be implemented. From a report: First off, Intel unveiled a standalone DG1 "software development vehicle" card that will allow developers to optimize apps for the new graphics system. It didn't reveal any performance details for the card, but did show it running the Warframe game. It also noted that it's now "sampling to ISVs (independent software vendors) worldwide... enabling developers to optimize for Xe." As far as we know right now, Intel's discrete graphics will be chips (not cards) installed together with the CPUs on a single package. However, it's interesting to see Intel graphics in the form of a standalone PCIe card, even one that will never be sold to consumers.

Speaking of Chromebooks, David Ruddock, opines at AndroidPolice: Chrome OS' problems really became apparent to me when Android app compatibility was introduced, around five years ago. Getting Android apps to run on Chrome OS was simultaneously one of the Chrome team's greatest achievements and one of its worst mistakes. In 2019, two things are more obvious than ever about the Android app situation on Chrome. The first is that the "build it and they will come" mantra never panned out. Developers never created an appreciable number of Android app experiences designed for Chrome (just as they never did for Android tablets). The second is that, quite frankly, Android apps are very bad on Chrome OS. Performance is highly variable, and interface bugs are basically unending because most of those apps were never designed for a point-and-click operating system. Sure, they crash less often than they did in the early days, but anyone saying that Android apps on Chrome OS are a good experience is delusional.

Those apps are also a crutch that Chrome leans on to this day. Chrome OS doesn't have a robust photo editor? Don't worry, you can download an app! Chrome doesn't have native integration with cloud file services like Box, Dropbox, or OneDrive? Just download the app! Chrome doesn't have Microsoft Office? App! But this "solution" has basically become an insult to Chrome's users, forcing them to live inside a half-baked Android environment using apps that were almost exclusively designed for 6" touchscreens, and which exist in a containerized state that effectively firewalls them from much of the Chrome operating system. As a result, file handling is a nightmare, with only a very limited number of folders accessible to those applications, and the task of finding them from inside those apps a labyrinthine exercise no one should have to endure in 2019. This isn't a tenable state of affairs -- it's computing barbarism as far as I'm concerned. And yet, I've seen zero evidence that the Chrome team intends to fix it. It's just how it is. But Android apps, so far as I can tell, are basically the plan for Chrome. Certainly, Linux environment support is great for enthusiasts and developers, but there are very few commonly-used commercial applications available on Linux, with no sign that will change in the near future. It's another dead end. And if you want an even more depressing picture of Chrome's content ecosystem, just look at the pitiable situation with web apps.

Folks at the Massachusetts Institute of Technology (MIT) have developed a new machine learning-based tool that will tell you how fast a code can run on various chips. This will help developers tune their applications for specific processor architectures. From a report: Traditionally, developers used the performance model of compilers through a simulation to run basic blocks -- fundamental computer instruction at the machine level -- of code in order to gauge the performance of a chip. However, these performance models are not often validated through real-life processor performance. MIT researchers developed an AI model called Ithmel by training it to predict how fast a chip can run unknown basic blocks. Later, it was supported by a database called BHive with 300,000 basic blocks from specialized fields such as machine learning, cryptography, and graphics. The team of researchers presented a paper [PDF] at the NeuralIPS conference in December to describe a new technique to measure code performance on various processors. The paper also describes Vemal, a new automatically generating algorithm that can be used to generate compiler optimizations.

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."