An anonymous reader shares a report: Satoshi didn't leave much behind when he decided to leave the scene for good back in April, 2011. But, he did leave enough for us to conduct a thorough research into his whereabouts when he was working on Bitcoin. To conduct this research, we gathered data from the following:
Satoshi's Bitcointalk account (539 available posts)
His 34 emails on the cryptography and Bitcoin mailing lists
His 169 commits on SourceForge
The metadata from Bitcoin whitepaper versions from 2008 (PDF) and 2009 (PDF)
The Genesis block
Various Wayback Machine archives

The data-driven part of the research focuses on timestamps from Satoshi's Bitcointalk posts, SourceForge commits, and emails, which represent a total of 742 activity instances from 206 days (not consecutive). The timestamp data starts from October 31, 2008, when he first announced Bitcoin on the cryptography mailing list, and ends on December 13, 2010, when he sent his last email that is known to be UTC timestamped. Using that data we compiled scatter charts in different suspect time zones to see when he was active and when he was not. We then used other data we gathered to further confirm the most likely location he called home. Common suspect locations are the UK (GMT), US Eastern (EST), US Pacific (PST), Japan (JST), and Australia (AEST). The last two were easy to debunk, but the first three prospects needed further examination.

Programming columnist Mike Melanson assesses the news that Guido Van Rossum, the creator of the Python programming language, has come out of retirement to join Microsoft's developer division: The news brought a flurry of congratulations and feature requests, though a few of the suggested features indeed, already exist. Others still were met with informative responses that make the resulting threads worth a perusal, especially if you're looking for a quick "who's who" on Twitter for the world of programming languages. Microsoft's Miguel de Icaza pointed out that this addition adds to the company's now growing list of language designers and contributors:

"The developer division at Microsoft now employs the language designers and contributors to Python, Java, JavaScript, Typescript, F# C#, C++. We just need some PHP, Rust and Swift magic to complete the picture."

[Microsoft senior software engineer Kat Marchán added "We actually have some early ex-moz Rust people too!"]

So, what can we expect from all of this? Is it a corporate takeover of open source, as some further down in the long list of replies always seem to suggest? Or is Microsoft planning the Frankenstein of all languages, with a little bit of this, a little bit of that? In all likelihood, you Python developers using Microsoft products probably have some good features to look forward to in the near future, and that's that, but there's always lingering fears...especially when it comes to Microsoft. As van Rossum suggests, stay tuned.
After Slashdot's earlier story, long-time reader alexgieg posted his own theory: "Several months ago the Excel folk within Microsoft asked users whether they'd like to have Python as an alternative scripting language in Office. Support for that was overwhelming, but nothing more was said on the matter since then. I guess this is Microsoft's answer."

An anonymous reader shares an excerpt from a report via VICE: Like other gig work giants, DoorDash has admitted in its IPO documents that its own business model -- and the way it treats and pays workers -- are major "risks" to its business. In its S-1 filing with the Securities and Exchanges Commission, there's little to no evidence DoorDash can achieve let alone sustain profitability (in fact, that it may never be profitable is another "risk"), and lots of evidence that its business model is largely based on taking advantage of both restaurants and drivers.

Included in "risks" are the two following statements, which are wonders to behold: "Our success, or perceived success, and increased visibility may also drive some businesses that perceive our business model negatively to raise their concerns to local policymakers and regulators. These businesses and their trade association groups or other organizations may take actions and employ significant resources to shape the legal and regulatory regimes in jurisdictions where we may have, or seek to have, a market presence in an effort to change such legal and regulatory regimes in ways intended to adversely affect or impede our business and the ability of merchants, consumers, and Dashers to use our platform." What this means is that restaurants might want DoorDash to take less of a cut from their commission, which is understandable. Even with cuts to DoorDash's commission rates during the pandemic, many restaurants are still struggling to scrape by.

And then there's this, which explicitly says the company's own pay model for drivers is a risk to its further existence: "Our ability to provide a cost-effective local logistics platform is also dependent on Dasher pay, which is a significant cost and subject to a number of risks..." That's a mouthful, but says that DoorDash's pay model for delivery drivers is algorithmic, which leads to an "inconsistency in earnings" which is likely to piss off both its workforce and its customers to the point where it may be challenged both in court and by regulators, and reported on in the media. This problem is even worse when you consider the labor patterns of gig companies: they require a large reserve of idle labor to keep wait times low and to fight extremely high turnover rates, but they also rely on a core of full-time gig workers to do the vast majority of work. As a result, the workers hurt the most by this "inconsistency in earnings" are the most precarious and vulnerable workers who rely on DoorDash to make ends meet.

Long-time Slashdot reader fahrbot-bot shared this report from the New York Times: A decade ago, a band of astronomers set out to investigate one of the oldest questions taunting philosophers, scientists, priests, astronomers, mystics and the rest of the human race: How many more Earths are out there, if any? How many far-flung planets exist that could harbor life as we know it?

Their tool was the Kepler spacecraft, which was launched in March 2009 on a three-and-a-half year mission to monitor 150,000 stars in a patch of sky in the Milky Way. It looked for tiny dips in starlight caused by an exoplanet passing in front of its home star. "It's not E.T., but it's E.T.'s home," said William Borucki when the mission was launched in March 2009. It was Dr. Borucki, an astronomer now retired from NASA's Ames Research Center, who dreamed up the project and spent two decades convincing NASA to do it. Before the spacecraft finally gave out in 2018, it had discovered more than 4,000 candidate worlds among those stars. So far, none have shown any sign of life or habitation. (Granted, they are very far away and hard to study.) Extrapolated, that figure suggests that there are billions of exoplanets in the Milky Way galaxy. But how many of those are potentially habitable?

After crunching Kepler's data for two years, a team of 44 astronomers led by Steve Bryson of NASA Ames has landed on what they say is the definitive answer, at least for now. Their paper has been accepted for publication in the Astronomical Journal... The team calculated that at least one-third, and perhaps as many as 90 percent, of stars similar in mass and brightness to our sun have rocks like Earth in their habitable zones, with the range reflecting the researchers' confidence in their various methods and assumptions. That is no small bonanza, however you look at it.

According to NASA estimates there are at least 100 billion stars in the Milky Way, of which about 4 billion are sunlike. If only 7 percent of those stars have habitable planets — a seriously conservative estimate — there could be as many as 300 million potentially habitable Earths out there in the whole Milky Way alone.

On average, the astronomers calculated, the nearest such planet should be about 20 light-years away, and there should be four of them within 30 light-years or so of the sun...
"The new result means that the galaxy is at least twice as fertile as estimated in one of the first analyses of Kepler data, in 2013."

"Security firm Kaspersky said Friday that it discovered a Linux version of the RansomEXX ransomware," reports ZDNet, "marking the first time a major Windows ransomware strain has been ported to Linux to aid in targeted intrusions." RansomEXX is a relatively new ransomware strain that was first spotted earlier this year in June. The ransomware has been used in attacks against the Texas Department of Transportation, Konica Minolta, U.S. government contractor Tyler Technologies, Montreal's public transportation system, and, most recently, against Brazil's court system (STJ)...

The RansomEXX gang creating a Linux version of their Windows ransomware is in tune with how many companies operate today, with many firms running internal systems on Linux, and not always on Windows Server. A Linux version makes perfect sense from an attacker's perspective; always looking to expand and touch as much core infrastructure as possible in their quest to cripple companies and demand higher ransoms. What we see from RansomEXX may soon turn out to be an industry-defining trend, with other big ransomware groups rolling out their Linux versions in the future as well.

And, this trend appears to have already begun. According to cyber-security firm Emsisoft, besides RansomEXX, the Mespinoza (Pysa) ransomware gang has also recently developed a Linux variant from their initial Windows version.

"Boeing's much-maligned 737 Max jet could be cleared to fly again in just a few weeks," reports SFGate, adding that one U.S. airline plans to carry passengers "as early as December." Although the Federal Aviation Administration has not disclosed a public timeline for the Max's return to service, approval to lift the grounding could come as early as mid-November, according to Reuters. Boeing executives said they expect to gain FAA recertification before the end of the year. The company will also need to get approval from the European Union Aviation Safety Agency and Transport Canada, which are conducting their own respective reviews...

American Airlines said it plans to operate one daily Boeing 737 Max roundtrip from Dec. 29 through Jan. 4 between its Miami hub and New York's LaGuardia Airport. If it takes off, American will be the first US carrier to bring back the Max...

Other U.S. airlines operating the Max are taking a wait-and-see approach before assigning the fleet type to flights.

According to Phoronix, a Dell privacy driver is is being prepared for the Linux kernel. From the report: Beginning in Dell's 2021 laptop models they are providing hardware-based "privacy buttons" to disable microphone and camera support. These new Dell privacy buttons are basically hardware kill switches for the microphone and web camera video stream. The Dell privacy driver sent out on Tuesday for the Linux kernel is about manipulating the relevant LEDs and tracking the status of the hardware-based controls where as the actual toggling of the audio/video support is handled by the hardware.

The Dell privacy driver in its current form is talked about for the camera and microphone support but the patch does also note a "PRIVACY_SCREEN_STATUS" bit as well. Presumably they will be extending this privacy driver as well for privacy screen handling around reducing the horizontal/vertical viewing angles of the display. The dell-privacy Linux driver in its initial form can be found via the kernel mailing list. It's great seeing Dell working on this driver punctually for Linux ahead of their next-gen laptops.

AmiMoJo writes: As we roll into 2021 the Free Software Foundation is looking to update its high priority free software projects list. These are the software projects that should be incorporating "the most important threats, and most critical opportunities, that free software faces in the modern computing landscape." For now the FSF is looking for help deciding what to include. The FSF high priority projects list is what once included PowerVR reverse engineering as being very important albeit never happened prior to PowerVR graphics becoming less common. In fact, many FSF high priority projects never panned out as they weren't contributing much in the way of resources to the causes but just calling attention to them. PDF support was among their high priority projects as well as another example as well as the likes of an open-source Skype replacement and reverse-engineering other popular technologies.

They overhauled the list in 2017 after forming a committee to maintain the list while now as 2021 is just around the corner they are looking to revise their high priority projects focus once more. They have issued a call for input to share with the High Priority Free Software Projects committee what you feel should belong on the list. Feedback is being collected through early January. Currently on the list are different "areas" they feel are high priority for free software as opposed to previously focusing on particular projects.

In preparation for next year's Xe HPG graphics cards, Intel's open-source developers have begun publishing their patches enabling their "ANC" Vulkan Linux driver to support Vulkan ray-tracing. Phoronix reports: Jason Ekstrand as the lead developer originally on the Intel ANV driver has posted today the initial ray-tracing code for ANV in order to support VK_KHR_ray_tracing for their forthcoming hardware. Today is the first time Intel has approved of this open-source code being published and more is on the way. The code today isn't enough for Vulkan ray-tracing but more is on the way and based against the latest internal Khronos ray-tracing specification. At the moment they are not focusing on the former NVIDIA-specific ray-tracing extension but may handle it in the future if game vendors continue targeting it rather than the forthcoming finalized KHR version.

Among other big ticket items still to come in the near-term includes extending the ANV driver to support compiling and dispatching OpenCL kernels, new SPIR-V capabilities, and generic pointer support. Also needed is the actual support for compiling ray-tracing pipelines, managing acceleration structures, dispatching rays, and the platform support. The actual exposing of the support won't come until after The Khronos Group has firmed up their VK_KHR_ray_tracing extension. Some of this Intel-specific Vulkan ray-tracing code may prove useful to Mesa's Radeon Vulkan "RADV" driver as well. Intel engineers have been testing their latest ray-tracing support with ANV internally on Xe HPG.

An anonymous reader quotes a report from Ars Technica: In recent years, the cost of solar and wind energy has declined precipitously, which has accelerated the growth of these renewable energy technologies. Increasingly, utilities are now planning for a future grid dominated by solar and wind. That will require changes in grid management and transmission upgrades as well as the addition of storage to smooth out the supply from variable generators. Grid storage is still pretty early days, but we're already seeing huge cost reductions as the industry matures. The US Energy Information Administration (EIA) highlighted this recently, showing that grid-scale battery-project costs in the United States dropped 70 percent in just a few years.

Between 2015 and 2018, average project costs decreased from $2,152 per kilowatt-hour of storage to $625. Costs will need to drop much more for grid batteries to scale, but that's a huge improvement in a short period of time. By the end of 2018, the US had 869 megawatts of battery power capacity and 1,236 megawatt-hours of energy capacity. (Power is the rate at which the batteries can supply electricity, while energy is the total amount it can supply when going from full charge to empty.) EIA also has installation data for 2019, which saw the addition of another 150 megawatts/450 megawatt-hours. And in just the first seven months of 2020, yet another 300 megawatts of power capacity were installed. EIA doesn't see this slowing down. It expects installed battery storage to increase by 6,900 megawatts "in the next few years" -- a figure ambiguous enough to allow for a rapid spike in planned projects.

An anonymous reader quotes a report from IEEE Spectrum: In April, Guoping Feng and colleagues at MIT, along with [Karl Deisseroth, a neuroscientist and bioengineer at Stanford University] demonstrated a minimally invasive optogenetic system that required drilling a small hole in the skull, then being able to control opsin-expressing neurons six millimeters deep into the brain using blue light. This approach used of a type of opsin that slowly activates neurons in a step-wise manner. In the most recent study [published in the journal Nature Biotechnology], Deisseroth and colleagues sought to instead enable both deep and fast optogenetics without surgery. The Stanford team expressed in the brain cells of mice a powerful new opsin called ChRmine (pronounced like the deep-red color "carmine"), discovered by Deisseroth's group last year in a marine organism. Then, they shined a red light outside the skull and were able to activate neural circuits in the midbrain and brainstem at depths of up to 7 millimeters. With the technique, the scientists turned on and off brain circuits with millisecond precision. "It really worked well, far better than we even expected might be possible," says Deisseroth.

The team then tested the effectiveness of the system. In one instance, they used light to quickly and precisely stop seizures in epileptic mice, and in another to turn on serotonin-producing neurons to promote social behavior in mice. Most optogenetic techniques involve injecting viruses with an opsin gene of choice directly into the brain with a needle. To avoid this, the Stanford team used a type of PHP virus developed at CalTech that can be injected in the blood. The virus then crosses the blood-brain barrier to deliver its payload, an opsin gene, to brain cells. In this case, even the delivery of the gene is noninvasive -- no needle penetrates the brain. Deisseroth's team is now testing the non-invasive technique in fish and collaborating with others to apply it to non-human primates. They're also working with the Seattle-based Allen Institute to develop mouse lines bred with ChRmine in their cells.

Phoronix ran a story this morning with this provocative headline: "It's Time To Admit It: The X.Org Server Is Abandonware." The last major release of the X.Org Server was in May 2018 but don't expect the long-awaited X.Org Server 1.21 to actually be released anytime soon. This should hardly be surprising but a prominent Intel open-source developer has conceded that the X.Org Server is pretty much "abandonware" with Wayland being the future. [Or, more specifically, that "The main worry I have is that xserver is abandonware without even regular releases from the main branch."]

This comes as X.Org Server development hits a nearly two decade low, the X.Org Server is well off its six month release regimen in not seeing a major release in over two years, and no one is stepping up to manage the 1.21 release. A year ago was a proposal to see new releases driven via continuous integration testing but even that didn't take flight and as we roll into 2021 there isn't any motivation for releasing new versions of the X.Org Server by those capable of doing so.

Red Hat folks have long stepped up to manage X.Org Server releases but with Fedora Workstation using Wayland by default and RHEL working that way, they haven't been eager to devote resources to new X.Org Server releases. Other major stakeholders also have resisted stepping up to ship 1.21 or commit any major resources to new xorg-server versions.

The Python programming language "is a big hit for machine learning," read a headline this week at ZDNet, adding "But now it needs to change."

Python is the top language according to IEEE Spectrum's electrical engineering audience, yet you can't run Python in a browser and you can't easily run it on a smartphone. Plus no one builds games in Python these days. To build browser applications, developers tend to go for JavaScript, Microsoft's type-safety take on it, TypeScript, Google-made Go, or even old but trusty PHP. On mobile, why would application developers use Python when there's Java, Java-compatible Kotlin, Apple's Swift, or Google's Dart? Python doesn't even support compilation to the WebAssembly runtime, a web application standard supported by Mozilla, Microsoft, Google, Apple, Intel, Fastly, RedHat and others.

These are just some of the limitations raised by Armin Ronacher, a developer with a long history in Python who 10 years ago created the popular Flask Python microframework to solve problems he had when writing web applications in Python. Austria-based Ronacher is the director of engineering at US startup Sentry — an open-source project and tech company used by engineering and product teams at GitHub, Atlassian, Reddit and others to monitor user app crashes due to glitches on the frontend, backend or in the mobile app itself... Despite Python's success as a language, Ronacher reckons it's at risk of losing its appeal as a general-purpose programming language and being relegated to a specific domain, such as Wolfram's Mathematica, which has also found a niche in data science and machine learning...

Peter Wang, co-founder and CEO of Anaconda, maker of the popular Anaconda Python distribution for data science, cringes at Python's limitations for building desktop and mobile applications. "It's an embarrassing admission, but it's incredibly awkward to use Python to build and distribute any applications that have actual graphical user interfaces," he tells ZDNet. "On desktops, Python is never the first-class language of the operating system, and it must resort to third-party frameworks like Qt or wxPython." Packaging and redistribution of Python desktop applications are also really difficult, he says.

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?

The Linux 5.10 kernel's XFS file-system will have two new on-disk meta-data capabilities, reports Phoronix: 1. The size of inode btrees in the allocation group is now recorded. This is for increasing redundancy checks and also allowing faster mount times.

2. Support for timestamps now until the year 2486.

This "big timestamps" feature is the refactoring of their timestamp and inode encoding functions to handle timestamps as a 64-bit nanosecond counter and bit shifting to increase the effective size. This now allows XFS to run well past the Year 2038 problem (where storing the time since 1970 in seconds will no longer fit in a signed 32-bit integer and thus wraparound) to now the Year 2486. Making a new XFS file-system with bigtime enabled allows a timestamp range from December 1901 to July 2486 rather than December 1901 to January 2038. For preserving backwards compatibility, the big timestamps feature is not currently enabled by default.

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.

KDE's Plasma 5.20 is now available, bringing a bunch of refinements as well as some larger features. Some of the KDE Plasma 5.20 highlights include (via Phoronix): - Numerous fixes to the KWin window manager / compositor including a number of Wayland fixes. Among the Wayland work in Plasma 5.20 includes Klipper support and middle-click paste, mouse and touchpad support nearly on par to X11, window thumbnails in the task manager, crash fixes, and more.

- Improved notifications.

- Different redesigns and additions to the KDE System Settings from SMART monitoring to better looking interfaces.

- Redesigned on-screen displays.

- Various tack manager and system tray improvements. More information about KDE 5.20 is available here.

An anonymous reader quotes a report from Motherboard: Decades before Twitter threads, Reddit forums, or Facebook groups, there was Usenet: an early-internet, pre-Web discussion system where one could start and join conversations much like today's message boards. Launched in 1980, Usenet is the creation of two Duke University students who wanted to communicate between decentralized, local servers -- and it's still active today. On Usenet, people talk about everything, from nanotech science to soap operas, wine, and UFOs. Jozef Jarosciak, a systems architect based in Ontario, had his first encounter with Usenet in 2000, when he found a full-time job in Canada thanks to a job posting there.

This week, Jarosciak uploaded some of the oldest Usenet posts available to the internet. Around 2.1 million posts from between February 1981 and June 1991 from Henry Spencer's UTZOO NetNews Archive are archived at the Usenet Archive for anyone to browse. This latest archive-dump is part of an even larger project by Jarosciak. He launched the Usenet Archive site last month, as a way to host groups in a way that'd be independent of Google Groups, which also holds archives of newsgroups like Usenet. It's currently archiving 317 million posts in 10,000 unique Usenet newsgroups, according to the site -- and Jarosciak estimates it'll eventually hold close to 1 billion posts.

FSGSBASE support in Linux "has the possibility of helping Intel/AMD CPU performance especially in areas like context switching that had been hurt badly by Spectre/Meltdown and other CPU vulnerability mitigations largely on the Intel side," Phoronix wrote back in August. As it started its journey into the kernel, they provided a preview on August 10: The FSGSBASE support that was finally mainlined a few days ago for Linux 5.9 is off to providing a nice performance boost for both Intel and AMD systems... FSGSBASE support for the Linux kernel has been around a half-decade in the making and finally carried over the finish line by one of Microsoft's Linux kernel engineers...

FSGSBASE particularly helps out context switching heavy workloads like I/O and allowing user-space software to write to the x86_64 GSBASE without kernel interaction. That in turn has been of interest to Java and others...On Linux 5.9 where FSGSBASE is finally mainlined, it's enabled by default on supported CPUs. FSGSBASE can be disabled at kernel boot time via the "nofsgsbase" kernel option.
Today on the Linux kernel mailing list, Linus Torvalds announced the release of Linux 5.9: Ok, so I'll be honest - I had hoped for quite a bit fewer changes this last week, but at the same time there doesn't really seem to be anything particularly scary in here. It's just more commits and more lines changed than I would have wished for.
And Phoronix reported: Linux 5.9 has a number of exciting improvements including initial support for upcoming Radeon RX 6000 "RDNA 2" graphics cards, initial Intel Rocket Lake graphics, NVMe zoned namespaces (ZNS) support, various storage improvements, IBM's initial work on POWER10 CPU bring-up, the FSGSBASE instruction is now used, 32-bit x86 Clang build support, and more. See our Linux 5.9 feature overview for the whole scoop on the many changes to see with this kernel.

Python has reached "a new all-time high" on TIOBE's index of programming language popularity. TechRadar reports: Java's days as the world's second most popular programming language could be numbered according to Tiobe's latest programming language rankings which show Python is becoming increasingly popular among developers. The firm's Index for October 2020 shows that Java has been overtaken by C as the world's most popular programming language when compared to the same period last year. Python remains in third place but it's quickly closing the gap between it and Java. According to Tiobe CEO Paul Jensen, C and Java have held the top two spots consistently for the past two decades. However, the 25-year-old programming language Java is approaching its "all time low" in popularity as it has fallen by 4.32 percentage points when compared to where it stood in October of last year. Tiobe ranks programming languages in its popularity index based on the number of hits each language gets across 25 search engines.
RedMonk's rankings already show Python as more popular than Java — the first time since 2012 that Java isn't one of their top two most popular languages. And TIOBE's CEO says "Let's see what will happen the next few months."

Here's their October rankings for the top 10 most popular programming languages.

• C
• Java
• Python
• C++
• C#
• Visual Basic
• JavaScript
• PHP
• R
• SQL

And coming in at #11 is Perl.