RedMonk has released its latest quarterly rankings of popular programming languages, arguing that "The idea is not to offer a statistically valid representation of current usage, but rather to correlate language discussion and usage in an effort to extract insights into potential future adoption trends."

Their methodology? "We extract language rankings from GitHub and Stack Overflow, and combine them for a ranking that attempts to reflect both code (GitHub) and discussion (Stack Overflow) traction." Below are this quarter's results:

1. JavaScript
2. Python
3. Java
4. PHP
5. C#
6. CSS
7. C++
7. TypeScript
9. Ruby
10. C
11. Swift
12. R
12. Objective-C
14. Shell
15. Scala
15. Go
17. PowerShell
17. Kotlin
19. Rust
19. Dart

Their analysis of the latest rankings note "movement is increasingly rare.... the top 20 has been stable for multiple runs. As has been speculated about in this space previously, it seems increasingly clear that the hypothesis of a temporary equilibrium of programming language usage is supported by the evidence.... [W]e may have hit a point of relative — if temporary — contentment with the wide variety of languages available for developers' usage."

And yet this quarter TypeScript has risen from #8 to #7, now tied with C++, benefiting from attributes like its interoperability with an existing popular language with an increased availability of security-related features. "There is little suggestion at present that the language is headed anywhere but up. The only real question is on what timeframe." Unlike TypeScript, Go's trajectory has been anything but clear. While it grew steadily and reasonably swiftly as languages go, it has appeared to be stalled, never placing higher than 14th and having dropped into 16 for the last three runs. This quarter, however, Go rose one spot in the rankings back up to 15. In and of itself, this is a move of limited significance, as the further one goes down the rankings the less significant the differences between them are, ranking-wise. But it has been over a year since we've seen movement from Go, which raises the question of whether there is any room for further upward ascent or whether it will remain hovering in the slot one would expect from a technically well regarded but not particularly versatile (from a use case standpoint) language.

Like Go, Kotlin had spent the last three runs in the same position. It and Rust had been moving in lockstep in recent quarters, but while Rust enters its fourth consecutive run in 19th place, Kotlin managed to achieve some separation this quarter jumping one spot up from 18 to 17.

"Starting with the Ubuntu 16.04 edition and including the later LTS versions, Canonical will offer expanded security coverage for critical, high, and medium Common Vulnerabilities and Exposures (CVEs) to all of Ubuntu's open-source applications and toolchains for ten years," reports ZDNet.

"Yes, you read that right, you get security patches not just for the operating system, but for all of Ubuntu's open-source applications for a decade." Most of these are server programs, such as Ansible, Apache Tomcat, Drupal, Nagios, Redis, and WordPress. But, it also includes such developer essentials as Docker, Node.js, phpMyAdmin, Python 2, and Rust. Altogether, Canonical is supporting more than 23,000 packages. Indeed, it's now offering security for, as Mark Shuttleworth, Canonical's CEO, said, "Security coverage to every single package in the Ubuntu distribution."

Canonical isn't doing this on its own. It's offering free, improved security in partnership with the security management company Tenable. Robert Huber, Tenable's Chief Security Officer, said, "Ubuntu Pro offers security patch assurance for a broad spectrum of open-source software. Together, we give customers a foundation for trustworthy open source."

Beyond ordinary security, Canonical is backporting security fixes from newer application versions. This enables Ubuntu Pro users to use the Ubuntu release of their choice for long-term security without forced upgrades. Happy to keep using Ubuntu 20.04? No problem. You can run it until April 2030. Knock yourself out....

Users can obtain a free personal Ubuntu Pro subscription at ubuntu.com/pro for up to five machines. This free tier is for personal and small-scale commercial use.
Mark Shuttleworth, CEO of Ubuntu's parent company company Canonical, explains in a new video that Ubuntu "is now the world's most widely used Linux..."

"What makes most proud, though, is that we have found a way to make this available free of charge to anybody for their personal and for small-scale commercial use.... full commercial use for you, and any business you own, on up to five machines."

"The Rust programming language is getting so popular that the team behind it is creating a team that's dedicated to defining the default Rust coding style," reports ZDNet: Each language has style guides and, if they're popular enough, may have multiple style guides from major users, like Google, which has its guide for C++ — the language Chrome is written in. Python's Guido van Rossum's posted his styling conventions here.

Rust, which reached version 1.0 in 2015, has a style guide in the "rustfmt" or 'Rust formatting tool' published on GitHub. The tool automatically formats Rust code to let developers focus on output and aims to reduce the steep learning curve confronting new Rust developers. The guide instructs developers to "Use spaces, not tabs" and says "each level of indentation must be 4 spaces", for example....

But the team responsible for writing the style guide between 2016 and 2018 has "by design" come to end, so now it's now been decided to create the Rust style team, consisting of Josh Triplett, Caleb Cartwright, Michal Goulet, and Jane Lusby. The crew will first tackle a "backlog of new language constructs that lack formatting guidance" and move on to "defining and implementing the mechanisms to evolve the default Rust style, and then begin introducing style improvements."

The work includes minor language changes, big structural changes, and backwards compatibility and the style team wants to craft the tool to make it current for easier coding in Rust, and help adoption.
New constructs "by default, get ignored and not formatted by rustfmt," according to a blog post by the Rust style team, "and subsequently need formatting added. Some of this work has fallen to the rustfmt team in recent years, but the rustfmt team would prefer to implement style determinations made by another team rather than making such determinations itself."

The post also notes that the backwards compatibility maintained by rustfmt "also prevents evolving the Rust style to take community desires into account and improve formatting over time." rustfmt provides various configuration options to change its default formatting, and many of those options represent changes that many people in the community would like enabled by default... but [rustfmt] cannot make this the default without causing continuous integration failures in existing projects. We need a way to evolve the default Rust style compatibly, similar in spirit to the mechanisms we use for Rust editions: allowing existing style to continue working, and allowing people to opt into new style.

To solve both of these problems, RFC 3309 has revived the Rust style team, with three goals:

- Making determinations about styling for new Rust constructs
- Evolving the existing Rust style
- Defining mechanisms to evolve the Rust style while taking backwards compatibility into account

We don't plan to make any earth-shattering style changes; the look and feel of Rust will remain largely the same. Evolutions to the default Rust style will largely consist of established rustfmt options people already widely enable, or would enable if they were stable. We expect that the initial work of the style team will focus on clearing a backlog of new language constructs that lack formatting guidance. Afterwards, we will look towards defining and implementing the mechanisms to evolve the default Rust style, and then begin introducing style improvements.

The short answers are "yes" and "no." America's Constitution prohibits government intervention into public expression, reports the business-news radio show Marketplace, "protecting free speech and expression "through, for example.... writing, protesting and coding languages like JavaScript, HTML, Python and Perl."

Specifically protecting code started with the 1995 case of cryptographer Daniel Bernstein, who challenged America's "export controls" on encryption (which regulated it like a weapon). But they also spoke to technology lawyer Kendra Albert, a clinical instructor at Harvard Law School's Cyberlaw Clinic, about the specific parameters of how America protects code as a form of expression: Albert: I think that the reality was that the position that code was a form of expression is in fact supported by a long history of First Amendment law. And that it, you know, is very consistent with how we see the First Amendment interpreted across a variety of contexts.... [O]ne of the questions courts ask is whether a regulation or legislation or a government action is specifically targeting speech, or whether the restrictions on speech are incidental, but not the overall intention. And that's actually one of the places you see kind of a lot of these difficulties around code as speech. The nature of many kinds of regulation may mean that they restrict code because of the things that particular forms of software code do in the world. But they weren't specifically meant to restrict the expressive conduct. And courts end up then having to sort of go through a test that was originally developed in the context of someone burning a draft card to figure out — OK, is this regulation, is the burden that it has on this form of expressive speech so significant that we can't regulate in this way? Or is this just not the focus, and the fact that there are some restrictions on speech as a result of the government attempting to regulate something else should not be the focus of the analysis?

Q: Congress and federal agencies as well as some states are looking to tighten regulations around cryptocurrencies and blockchain technology. What role do you think the idea of code as speech will play in this environment moving forward?

Albert: The reality is that the First Amendment is not a total bar to regulation of speech. It requires the government meet a higher standard for regulating certain kinds of speech. That runs, to some extent, in conflict with how people imagine what "code is speech" does as sort of a total restriction on the regulation of software, of code, because it has expressive content. It just means that we treat code similarly to how we treat other forms of expression, and that the government can regulate them under certain circumstances.

Recently the authors of Elements of Publishing shared an update. "After ten years in print, our publisher decided against further printings and has reverted the rights to us. We are publishing Elements of Programming in two forms: a free PDF and a no-markup paperback."

And that's not the only old book that's getting a new life on the web...

22 years ago, long-time Slashdot reader Stephen T. Satchell (satch89450) co-authored Linux IP Stacks Commentary, a book commenting the TCP/IP code in Linux kernel 2.0.34. ("Old-timers will remember the Lion's Unix Commentary, the book published by University xerographic copies on the sly. Same sort of thing.") But the print edition struggled to update as frequently as the Linux kernel itself, and Satchell wrote a Slashdot post exploring ways to fund a possible update.

At the time Slashdot's editors noted that "One of the largest complaints about Linux is that there is a lack of high-profile documentation. It would be sad if this publication were not made simply because of the lack of funds (which some people would see as a lack of interest) necessary to complete it." But that's how things seemed to end up — until Satchell suddenly reappeared to share this update from 2022: When I was released from my last job, I tried retirement. Wasn't for me. I started going crazy with nothing significant to do. So, going through old hard drives (that's another story), I found the original manuscript files, plus the page proof files, for that two-decade-old book. Aha! Maybe it's time for an update. But how to keep it fresh, as Torvalds continues to release new updates of the Linux kernel?

Publish it on the Web. Carefully.

After four months (and three job interviews) I have the beginnings of the second edition up and available for reading. At the moment it's an updated, corrected, and expanded version of the "gray matter", the exposition portions of the first edition....

The URL for the alpha-beta version of this Web book is satchell.net/ipstacks for your reading pleasure. The companion e-mail address is up and running for you to provide feedback. There is no paywall.
But there's also an ingenious solution to the problem of updating the text as the code of the kernel keeps changing: Thanks to the work of Professor Donald Knuth (thank you!) on his WEB and CWEB programming languages, I have made modifications, to devise a method for integrating code from the GIT repository of the Linux kernel without making any modifications (let alone submissions) to said kernel code. The proposed method is described in the About section of the Web book. I have scaffolded the process and it works. But that's not the hard part.

The hard part is to write the commentary itself, and crib some kind of Markup language to make the commentary publishing quality. The programs I write will integrate the kernel code with the commentary verbiage into a set of Web pages. Or two slightly different sets of web pages, if I want to support a mobile-friendly version of the commentary.

Another reason for making it a web book is that I can write it and publish it as it comes out of my virtual typewriter. No hard deadlines. No waiting for the printers. And while this can save trees, that's not my intent. The back-of-the-napkin schedule calls for me to to finish the expository text in September, start the Python coding for generating commentary pages at the same time, and start the writing the commentary on the Internet Control Message Protocol in October. By then, Linus should have version 6.0.0 of the Linux kernel released.

I really, really, really don't want to charge readers to view the web book. Especially as it's still in the virtual typewriter. There isn't any commentary (yet). One thing I have done is to make it as mobile-friendly as I can, because I suspect the target audience will want to read this on a smartphone or tablet, and not be forced to resort to a large-screen laptop or desktop. Also, the graphics are lightweight to minimize the cost for people who pay by the kilopacket. (Does anywhere in the world still do this? Inquiring minds want to know.)

I host this web site on a Protectli appliance in my apartment, so I don't have that continuing expense. The power draw is around 20 watts. My network connection is AT&T fiber — and if it becomes popular I can always upgrade the upstream speed.

The thing is, the cat needs his kibble. I still want to know if there is a source of funding available.

Also, is it worthwhile to make the pages available in a zip file? Then a reader could download a snapshot of the book, and read it off-line.

The IEEE's official publication, IEEE Spectrum, has released its ninth annual ranking of the top programming languages. The results? Python remains on top but is closely followed by C. Indeed, the combined popularity of C and the big C-like languages — C++ and C# — would outrank Python by some margin.

Java also remains popular, as does Javascript, the latter buoyed by the ever-increasing complexity of websites and in-browser tools (although it's worth noting that in some quarters, the cool thing is now deliberately stripped-down static sites built with just HTML and simple CSS).

But among these stalwarts is the rising popularity of SQL. In fact, it's at No. 1 in our Jobs ranking, which looks solely at metrics from the IEEE Job Site and CareerBuilder. Having looked through literally hundreds and hundreds of job listings in the course of compiling these rankings for you, dear reader, I can say that the strength of the SQL signal is not because there are a lot of employers looking for just SQL coders, in the way that they advertise for Java experts or C++ developers. They want a given language plus SQL. And lots of them want that "plus SQL...."

Job listings are of course not the only metrics we look at in Spectrum. A complete list of our sources is here, but in a nutshell we look at nine metrics that we think are good proxies for measuring what languages people are programming in. Sources include GitHub, Google, Stack Overflow, Twitter, and IEEE Xplore [their library of technical content]. The raw data is normalized and weighted according to the different rankings offered — for example, the Spectrum default ranking is heavily weighted toward the interests of IEEE members, while Trending puts more weight on forums and social-media metrics.
Python is still #1 in their "Trending" view of language popularity, but with Java in second place (followed by C, JavaScript, C++ and C# — and then SQL). PHP is next — their 8th-most-trending language, followed by HTML, Go, R, and Rust.

"Python seems to be unstoppable," argues the commentary on August's edition of the TIOBE index (which attempts to calculate programming-language popularity based on search results for courses, vendors, and "skilled engineers").

By that measure Python's "market share" rose another 2% in this month's index — to an all-time high of 15.42%. It is hard to find a field of programming in which Python is not used extensively nowadays. The only exception is (safety-critical) embedded systems because of Python being dynamically typed and too slow. That is why the performant languages C and C++ are gaining popularity as well at the moment.

If we look at the rest of the TIOBE index, not that much happened last month. Swift and PHP swapped places again at position 10, Rust is getting close to the top 20, Kotlin is back in the top 30, and the new Google language Carbon enters the TIOBE index at position 192.
InfoWorld notes it's been 10 months since Python first claimed the index's #1 spot last October, "becoming the only language besides Java and C to hold the No. 1 position." In the alternative Pypl Popularity of Programming Language index, which assesses language popularity based on Google searches of programming language tutorials, the top 10 rankings for August were:

1. Python, 28.11% share
2. Java, 17.35%
3. JavaScript, 9.48%
4. C#, 7.08%
5. C/C++, 6.19%
6. PHP, 5.47%
7. R, 4.35%
8. TypeScript, 2.79%
9. Swift, 2.09%
10. Objective-C, 2.03%

Matt Edmondson, a hacker and digital forensics expert, built a Raspberry Pi-powered anti-tracking tool that "scans for nearby devices and alerts you if the same phone is detected multiple times within the past 20 minutes," reports Wired. The device, which can be carried around or placed in a car, consists of parts that cost around $200 in total. From the report: The homemade system works by scanning for wireless devices around it and then checking its logs to see whether they also were present within the past 20 minutes. It was designed to be used while people are on the move rather than sitting in, say, a coffee shop, where it would pick up too many false readings. The anti-tracking tool, which can sit inside a shoebox-sized case, is made up of a few components. A Raspberry Pi 3 runs its software, a Wi-Fi card looks for nearby devices, a small waterproof case protects it, and a portable charger powers the system. A touchscreen shows the alerts the device produces. Each alert may be a sign that you are being tailed. The device runs Kismet, which is a wireless network detector, and is able to detect smartphones and tablets around it that are looking for Wi-Fi or Bluetooth connections. The phones we use are constantly looking for wireless networks around them, including networks they've connected to before as well as new networks.

Edmondson says Kismet makes a record of the first time it sees a device and then the most recent time it was detected. But to make the anti-tracking system work, he had to write code in Python to create lists of what Kismet detects over time. There are lists for devices spotted in the past five to 10 minutes, 10 to 15 minutes, and 15 to 20 minutes. If a device appears twice, an alert flashes up on the screen. The system can show a phone's MAC address, although this is not much use if it's been randomized. It can also record the names of Wi-Fi networks that devices around it are looking for -- a phone that's trying to connect to a Wi-Fi network called Langley may give some clues about its owner. "If you have a device on you, I should see it," he says. In an example, he showed WIRED that a device was looking for a network called SAMSUNGSMART.

To stop the system from detecting your own phone or those of other people traveling with you, it has an "ignore" list. By tapping one of the device's onscreen buttons, it's possible to "ignore everything that it has already seen." Edmondson says that in the future, the device could be modified to send a text alert instead of showing them on the screen. He is also interested in adding the capability to detect tire-pressure monitoring systems that could show recurring nearby vehicles. A GPS unit could also be added so you can see where you were when you were being tracked, he says. [...] Edmondson has no plans to make the device into a commercial product, but he says the design could easily be copied and reused by anyone with some technical knowledge. Many of the parts involved are easy to obtain or may be lying around the homes of people in tech communities. For those interested, Edmondson open-sourced its underlying code and plans to present the research project at the Black Hat security conference in Las Vegas this week.

JavaScript, the world's most popular programming language according to most surveys, has become a barrier to progress, according to Douglas Crockford, creator of the JSON (JavaScript Object Notation) specification used everywhere for serializing data in web applications.

Crockford made this assertion in an interview last month:

"The best thing we can do today to JavaScript is to retire it. Twenty years ago, I was one of the few advocates for JavaScript. Its cobbling together of nested functions and dynamic objects was brilliant. I spent a decade trying to correct its flaws. I had a minor success with ES5. But since then, there has been strong interest in further bloating the language instead of making it better. So JavaScript, like the other dinosaur languages, has become a barrier to progress. We should be focused on the next language, which should look more like E than like JavaScript."

According to a StackOverflow survey earlier this year, JavaScript is used by over 65% of developers, way ahead of second placed Python at 48 percent (ignoring HTML, CSS and SQL which are not general purpose languages).
Crockford also acknowledged there's be two difficulties in replacing browser-based JavaScript, according to the article. "First, we don't have the next language yet. It needs to be a minimal capability-based actor language that is designed specifically for secure distributed programming. Nothing less should be considered.

"Second, we need all of the browser makers to adopt it and to simultaneously replace the DOM with a well designed interface. Good luck with that."

For roughly a year and a half software engineer Pablo Galindo has been one of five members on the Python Steering Council, which took the reins when language creator Guido van Rossum stepped down. "The Python Steering Council attempts to reflect the decisions of the community, weighing up all the advantages and disadvantages [of each proposal]," Galindo explains in TechRadar's look at how the language now manages its evolution. (Alternate URL here.)

"Our responsibility is to make sure everyone is represented in a decision. It's not about what we think personally, it's about the community mind." So while static typing would've benefited one specific sub-community, the article argues, the necessary changes were ultimately "deemed by the council to have an overall detrimental effect," the article points out, "and were therefore rejected." Given the popularity of Python and size of the application base, the Steering Council has to exercise considerable caution when deciding upon changes to the language. Broadly, the goal is to improve the level of performance and range of functionality in line with the demands of the community, but doing so is rarely straightforward. "There is an important distinction between making a new language fast, versus increasing the performance of a 30-year-old language without breaking the code," noted Galindo. "That is extremely difficult; I cannot tell you how difficult it is."

"There are a number of industry techniques that everyone uses [to improve performance], but Python is incompatible with these methods. Instead, we have to develop entirely new techniques to achieve only similarly good results."

Separately, the team has to worry about the knock-on effects of a poorly-implemented change, of which there could be many. As an example, Galindo gestured towards the impact of a drop-off in language performance on energy usage (and therefore carbon emissions). "When you make changes in the language, it can be daunting," he said. "How many CPU cycles will I cost the planet with a mistake...?"

Despite the various headwinds, the Python Steering Council has lofty ambitions for the language, with the next major release (version 3.11) set to go live in October. Apparently, speed is the first item on the agenda. Galindo told us the aim is to improve performance by up to 60% (depending on the workload) with Python 3.11 and again with version 3.12. In the longer term, meanwhile, the goal is to make the language between two and five times faster within the next decade.

The council will also continue to focus on improving the quality of error messages generated by the Python Interpreter in an effort to make debugging much simpler, a pet project of Galindo's and a major focus during his time on the council.

This year's "State of WebAssembly" report has been published by Colin Eberhardt (CTO at the U.K.-based software consultancy Scott Logic). Hundreds of people were surveyed for the report, notes this article by Visual Studio Magazine.

Published by B2B media company 1105 Media, the magazine notes that Eberhardt's survey included some good news for Rust — and for Microsoft's free open source framework Blazor (for building web apps using C# and HTML): This year, like last year, Rust was found to be the most frequently used and most desired programming language for WebAssembly development.... "Rust once again comes out on top, with 45 percent saying they use it frequently or sometimes," Eberhardt said. "WebAssembly and Rust do have quite a close relationship, most WebAssembly runtimes are written in Rust, as are the various platforms based on wasm. It also enjoys some of the best tooling, so this result doesn't come as a big surprise."

While Rust usage and desirability has continued to climb, the Blazor web-dev framework is coming on strong in the report, which treats Blazor as a programming language, though it's not. On that desirability scale, Blazor climbed from sixth spot in 2021 to fourth this year among seven "programming languages" [based on] percentage of respondents who use a given language 'frequently,' or 'sometimes' [for WebAssembly development] compared to last year. Eberhardt said, "Rust has had a modest rise in desirability, but the biggest climber is Blazor, with Go following just behind."

Commenting on another graphic that shows which language people most want to use for WebAssembly development, Eberhardt said, "This shows that Rust usage has climbed steadily, but the biggest climbers are Blazor and Python.
While you can now compile WebAssembly from a variety of languages (including C, #C, and C++), the report also found that JavaScript has somehow become a viable WebAssembly language — sort of, and even though JavaScript itself can't be compiled to WebAssembly... There's a cunning workaround for this challenge; rather than compiling JS to Wasm, you can instead compile a JavaScript engine to WebAssembly then use that to execute your code.

This is actually much more practical than you might think.

An anonymous reader quotes a report from MIT Technology Review: "People are realizing now: wait a minute, literally everything we do is underpinned by Linux," says Dave Aitel, a cybersecurity researcher and former NSA computer security scientist. "This is a core technology to our society. Not understanding kernel security means we can't secure critical infrastructure." Now DARPA, the US military's research arm, wants to understand the collision of code and community that makes these open-source projects work, in order to better understand the risks they face. The goal is to be able to effectively recognize malicious actors and prevent them from disrupting or corrupting crucially important open-source code before it's too late. DARPA's "SocialCyber" program is an 18-month-long, multimillion-dollar project that will combine sociology with recent technological advances in artificial intelligence to map, understand, and protect these massive open-source communities and the code they create. It's different from most previous research because it combines automated analysis of both the code and the social dimensions of open-source software.

Here's how the SocialCyber program works. DARPA has contracted with multiple teams of what it calls "performers," including small, boutique cybersecurity research shops with deep technical chops. One such performer is New York -- based Margin Research, which has put together a team of well-respected researchers for the task. Margin Research is focused on the Linux kernel in part because it's so big and critical that succeeding here, at this scale, means you can make it anywhere else. The plan is to analyze both the code and the community in order to visualize and finally understand the whole ecosystem.

Margin's work maps out who is working on what specific parts of open-source projects. For example, Huawei is currently the biggest contributor to the Linux kernel. Another contributor works for Positive Technologies, a Russian cybersecurity firm that -- like Huawei -- has been sanctioned by the US government, says Aitel. Margin has also mapped code written by NSA employees, many of whom participate in different open-source projects. "This subject kills me," says d'Antoine of the quest to better understand the open-source movement, "because, honestly, even the most simple things seem so novel to so many important people. The government is only just realizing that our critical infrastructure is running code that could be literally being written by sanctioned entities. Right now." This kind of research also aims to find underinvestment -- that is critical software run entirely by one or two volunteers. It's more common than you might think -- so common that one common way software projects currently measure risk is the "bus factor": Does this whole project fall apart if just one person gets hit by a bus? SocialCyber will also tackle other open-source projects too, such as Python which is "used in a huge number of artificial-intelligence and machine-learning projects," notes the report. "The hope is that greater understanding will make it easier to prevent a future disaster, whether it's caused by malicious activity or not."

PyPI or the Python Package Index is giving away 4,000 Google Titan security keys as part of its move to mandatory two-factor authentication (2FA) for critical projects built in the Python programming language. ZDNet reports: PyPI, which is managed by the Python Software Foundation, is the main repository where Python developers can get third-party developed open-source packages for their projects. [...] One way developers can protect themselves from stolen credentials is by using two-factor authentication and the PSF is now making it mandatory for developers behind "critical projects" to use 2FA in coming months. PyPI hasn't declared a specific date for the requirement. "We've begun rolling out a 2FA requirement: soon, maintainers of critical projects must have 2FA enabled to publish, update, or modify them," the PSF said on its PyPI Twitter account.

As part of the security drive, it is giving away 4,000 Google Titan hardware security keys to project maintainers gifted by Google's open source security team. "In order to improve the general security of the Python ecosystem, PyPI has begun implementing a two-factor authentication (2FA) requirement for critical projects. This requirement will go into effect in the coming months," PSF said in a statement. "To ensure that maintainers of critical projects have the ability to implement strong 2FA with security keys, the Google Open Source Security Team, a sponsor of the Python Software Foundation, has provided a limited number of security keys to distribute to critical project maintainers.

PSF says it deems any project in the top 1% of downloads over the prior six months as critical. Presently, there are more than 350,000 projects on PyPI, meaning that more than 3,500 projects are rated as critical. PyPI calculates this on a daily basis so the Titan giveaway should go a long way to cover a chunk of key maintainers but not all of them. In the name of transparency, PyPI is also publishing 2FA account metrics here. There are currently 28,336 users with 2FA enabled, with nearly 27,000 of them using a 2FA app like Microsoft Authenticator. There are over 3,800 projects rated as "critical" and 8,241 PyPI users in this group. The critical group is also likely to grow since projects that have been designated as critical remain so indefinitely while new projects are added to mandatory 2FA over time. The 2FA rule applies to both project maintainers and owners.

15-year-old Ellis Pinsky stole $23.8 million worth of cryptocurrency — and his life was never the same. For example, Rolling Stone reports, in his last year of high school, "Four men wearing ski masks and gloves, armed with knives, rope, brass knuckles, and a fake 9 mm," crept around the back of his home in the suburbs: Two weeks before the break-in, a lawsuit had been filed against him, and news stories had circulated connecting him to the hack. He knew that the thieves wanted this money, the millions and millions of dollars he had stolen. He also knew that he couldn't give it to them. He didn't have it. Not anymore.
The magazine paints the portrait of "an anxious young man in Invisalign braces" who describes the revelation he'd had at the age of 13. "The internet held such secrets. All he had to do was uncover them." As he soon found, there were plenty of people working to uncover them all the time, and willing to share their methods — for a price.... Realizing that a lot of the information social engineers used came from hacked databases, he began teaching himself to program, particularly to do the Structured Query Language injections and cross-site scripting that allowed him to attack companies' database architecture. The terabyte upon terabyte of databases he extracted, traded, and hoarded made him valuable to OGUsers as well as to others, like the Russian hackers he was able to converse with thanks to his fluency with his mother's native language... By the time he was 14, he tells me, "I think it's fair to say I had the capabilities to hack anyone."
The article describes him as "attending high school by day and extracting the source code of major corporations by night.... He was 14 years old and taken with the thrill of possessing a hidden superpower, of spending his nights secretly tapping into an underground world where he was esteemed and even feared. And then, in the morning, being called downstairs to breakfast." He wrote a Python script to comb through social media networks and seek out any mentions of working for a [cellphone] carrier. Then he'd reach out with an offer of compensation for helping him with a task. Every fifth or sixth person — underpaid and often working a short-term contract — would say they were game, as Pinsky tells it. For a couple hundred dollars' worth of bitcoin, they'd be willing to do a SIM swap, no questions asked. Eventually, Pinsky says, he had employees at every major carrier also working for him. Then the stakes got even higher. It was only a matter of time before OG hackers, known to each other as "the Community," realized that if they could use the SIM-swapping method to steal usernames, they could just as easily use it to steal cryptocurrency...
In one massive heist Pinksky stole 10% of all the Trigger altcoins on the market from crypto impresario Michael Terpin. ("As Pinsky's money launderers were converting it, the market was crashing in real time.") Pinsky recruited a crew to launder the money — at least one of which simply kept it — but even with all the conversion fees, he still made off with millions. And then... For a while, he half-expected the FBI to knock on his door at any moment, just like in the movies; but as time passed, he grew less anxious.... He says he moved on to learning different types of programming. He ran a sneaker business that used bots and scripts to snap up limited pairs then flip them... He went to soccer practice. He and his friends had started hanging out with girls on the weekend, driving down to the docks where you could see the glowing lights from the Tappan Zee Bridge.
Until Terpin figured out it was Pinsky who'd robbed him: Pinsky and his legal team preempted his arrest by contacting the U.S. attorney directly and offering his cooperation. In February 2020, he voluntarily returned every last thing he says he got from the Terpin heist: 562 bitcoins, the Patek watch, and the cash he'd stored in the safe under his bed.... When I ask if he has also worked with the FBI to help bring down other hackers, he blinks quickly and then changes the subject.
Pinsky has not been criminally charged — partly because he was a minor, but also because of his cooperation with law enforcement. But filing a civil suit, Terpin wants to be compensated with triple the amount stolen, arguing that the teenager who robbed him was running an organized crime racket and that he should be heavily punished to set an example.

Rolling Stone's article raisees the question: what should happen next?

Yesterday, Phoronix reported that the lead developer of systemd, Lennart Poettering, left Red Hat. "It turns out he had joined Microsoft and [is] continuing his work on systemd," writes Phoronix's Michael Larabel in a new report. He continues: While some may not always align with his views or approaches to handling some things, there is no overstating his enormous contributions to the Linux/open-source world and his dedication to advancing the ecosystem over the years. This may take many by surprise but let's not forget Microsoft has over time employed a number of Linux developers and other prominent open-source developers... Microsoft currently employs Python creator Guido van Rossum, GNOME creator Miguel de Icaza had been employed by Microsoft from 2016 when they acquired Xamarin to earlier this year when he left, Nat Friedman as part of Xamarin-Microsoft served as GitHub CEO following Microsoft's acquisition, Gentoo Linux founder Daniel Robbins was previously employed by Microsoft, Steve French as the Linux CIFS/SMB2/SMB3 maintainer and Samba team member works for Microsoft, and Microsoft employs/previously-employed a large number of upstream Linux developers like Matteo Croce, Matthew Wilcox, Shyam Prasad N, Michael Kelley, and many others beyond just the usual immediately recognizable names to Linux enthusiasts/developers. It was also just earlier this year that Christian Brauner as another longtime Linux kernel developer joined Microsoft. Christian Brauner is Berlin-based like Lennart and moved on to Microsoft after the past half-decade at Canonical working on the Linux kernel, LXC, systemd, and more.

After many years of gradual improvement Vim now takes a big step with a major release. Besides many small additions the spotlight is on a new incarnation of the Vim script language: Vim9 script. Why Vim9 script: A new script language, what is that needed for? Vim script has been growing over time, while preserving backwards compatibility. That means bad choices from the past often can't be changed and compatibility with Vi restricts possible solutions. Execution is quite slow, each line is parsed every time it is executed.

The main goal of Vim9 script is to drastically improve performance. This is accomplished by compiling commands into instructions that can be efficiently executed. An increase in execution speed of 10 to 100 times can be expected. A secondary goal is to avoid Vim-specific constructs and get closer to commonly used programming languages, such as JavaScript, TypeScript and Java.

The performance improvements can only be achieved by not being 100% backwards compatible. For example, making function arguments available by creating an "a:" dictionary involves quite a lot of overhead. In a Vim9 function this dictionary is not available. Other differences are more subtle, such as how errors are handled. For those with a large collection of legacy scripts: Not to worry! They will keep working as before. There are no plans to drop support for legacy script. No drama like with the deprecation of Python 2.

For Stack Overflow's annual survey, "Over 73,000 developers from 180 countries each spent roughly 15 minutes answering our questions," a blog post announces: The top five languages for professional developers haven't changed: JavaScript is still the most used, and Rust is the most loved for a seventh year. The big surprise came in the most loved web framework category. Showing how fast web technologies change, newcomer Phoenix took the most loved spot from Svelte, itself a new entry last year.... Check out the full results from this year's Developer Survey here.
In fact, 87% of Rust developers said that they want to continue using Rust, notes SD Times' summary of the results: Rust also tied with Python as the most wanted technology in this year's report, with TypeScript and Go following closely behind. The distinction between most loved and most wanted is that most wanted includes only developers who are not currently developing with the language, but have an interest in developing with it.
Slashdot reader logankilpatrick writes, "It should come as no surprise to those following the growth and expansion of the Julia Programming Language ecosystem that in this year's Stack Overflow developer survey, Julia ranked in the top 5 for the most loved languages (above Python — 6th, MatLab — Last, and R — 33rd)."

And the Register shares more highlights: Also notable in the 71,547 responses regarding programming languages was a switch again between Python and SQL. In 2021, Python pushed out SQL to be the third most commonly used language. This year SQL regained third place, just behind second placed HTML /CSS.

And the most hated...

Unsurprisingly, developers still dread that tap on the shoulder from the finance department for a tweak to that bit of code upon which the entire company depends. Visual Basic for Applications and COBOL still lurk within the top three most dreaded technologies.

The operating system rankings were little changed: Windows won out for personal and professional use, although for professional use Linux passed macOS to take second place with 40 percent of responses compared to Apple's 33 percent. Most notable was the growth of Windows Subsystem for Linux, which now accounts for 14 percent of personal use compared with a barely registering 3 percent in 2021.
But SD Times noted what may be the most interesting statistic: Only 15% of developers work on-site full time. Forty-three percent are fully remote and 42% are hybrid. Smaller organizations with 2-19 employees are more likely to be in-person, while large organizations with over 10k employees are more likely to be hybrid, according to the survey.
InfoWorld delves into what this means: "The world has made the decision to go hybrid and remote, I have a lot of confidence given the data I have seen that that is a one-way train that has left the station," Prashanth Chandrasekar, CEO of Stack Overflow told InfoWorld.

Chandrasekar says that flexibility and the tech stack developers get to work with are the most important contributors to overall happiness at work. "Many developers drop out of the hiring process because of the tech stack they will be working with," he said... Organizational culture is also shifting, and cloud-native techniques have taken hold among Stack Overflow survey respondents. Most professional developers (70%) now use some form of CI/CD and 60% have a dedicated devops function....

Lastly, Web3 still has software developers torn, with 32% of respondents favorable, 31% unfavorable, and 26% indifferent. Web3 refers to the emerging idea of a decentralized web where data and content are registered on blockchains, tokenized, or managed and accessed on peer-to-peer distributed networks.

At its re:Mars conference, Amazon today announced the launch of CodeWhisperer, an AI pair programming tool similar to GitHub's Copilot that can autocomplete entire functions based on only a comment or a few keystrokes. From a report: The company trained the system, which currently supports Java, JavaScript and Python, on billions of lines of publicly available open-source code and its own codebase, as well as publicly available documentation and code on public forums. It's now available in preview as part of the AWS IDE Toolkit, which means developers can immediately use it right inside their preferred IDEs, including Visual Studio Code, IntelliJ IDEA, PyCharm, WebStorm and Amazon's own AWS Cloud 9. Support for the AWS Lambda Console is also coming soon. Ahead of today's announcement, Vasi Philomin, Amazon's VP in charge of its AI services, stressed that the company didn't simply create this in order to offer a copy of Copilot. He noted that with CodeGuru, its AI code reviewer and performance profiler, and DevOps Guru, its tool for finding operation issues, the company laid the groundwork for today's launch quite a few years ago.

"Besides new language features and other improvements, Python 3.11 performance is looking fantastic with very nice performance uplift over prior Python 3.x releases," writes Phoronix's Michael Larabel. From the report: Python 3.11 has been baking support for task groups in asyncio, fine-grained error locations in tracebacks, the self-type to return an instance of their class, TypeVarTuple for variadic generics, and various other features. Besides changes affecting the Python language itself, Python 3.11 has been landing performance work from the "Faster Cython Project" to speed-up the reference implementation. Python 3.11 is 10~60% faster than Python 3.10 according to the official figures and a 1.22x speed-up with their standard benchmark suite.

The Python Docs cover some of the significant performance improvements made for this upcoming release. The formal Python 3.11.0 release isn't expected until October while multiple betas will come through July and then at least two release candidates in the following months before early October.

Google has quietly banned deepfake projects on its Colaboratory (Colab) service, putting an end to the large-scale utilization of the platform's resources for this purpose. From a report: Colab is an online computing resource that allows researchers to run Python code directly through the browser while using free computing resources, including GPUs, to power their projects. Due to the multi-core nature of GPUs, Colab is ideal for training machine learning projects like deepfake models or for performing data analysis. Deepfakes can be trained to swap faces on video clips, adding realistic facial expressions to make the result appear genuine, although it's fake. They have been used for spreading fake news, creating revenge porn, or for fun. However, the lack of ethical limitations in their use has been the source of controversy and concern.