An anonymous reader quotes a report from TechCrunch: A recent study finds that software engineers who use code-generating AI systems are more likely to cause security vulnerabilities in the apps they develop. The paper, co-authored by a team of researchers affiliated with Stanford, highlights the potential pitfalls of code-generating systems as vendors like GitHub start marketing them in earnest. The Stanford study looked specifically at Codex, the AI code-generating system developed by San Francisco-based research lab OpenAI. (Codex powers Copilot.) The researchers recruited 47 developers -- ranging from undergraduate students to industry professionals with decades of programming experience -- to use Codex to complete security-related problems across programming languages including Python, JavaScript and C.

Codex was trained on billions of lines of public code to suggest additional lines of code and functions given the context of existing code. The system surfaces a programming approach or solution in response to a description of what a developer wants to accomplish (e.g. "Say hello world"), drawing on both its knowledge base and the current context. According to the researchers, the study participants who had access to Codex were more likely to write incorrect and "insecure" (in the cybersecurity sense) solutions to programming problems compared to a control group. Even more concerningly, they were more likely to say that their insecure answers were secure compared to the people in the control.

Megha Srivastava, a postgraduate student at Stanford and the second co-author on the study, stressed that the findings aren't a complete condemnation of Codex and other code-generating systems. The study participants didn't have security expertise that might've enabled them to better spot code vulnerabilities, for one. That aside, Srivastava believes that code-generating systems are reliably helpful for tasks that aren't high risk, like exploratory research code, and could with fine-tuning improve in their coding suggestions. "Companies that develop their own [systems], perhaps further trained on their in-house source code, may be better off as the model may be encouraged to generate outputs more in-line with their coding and security practices," Srivastava said. The co-authors suggest vendors use a mechanism to "refine" users' prompts to be more secure -- "akin to a supervisor looking over and revising rough drafts of code," reports TechCrunch. "They also suggest that developers of cryptography libraries ensure their default settings are secure, as code-generating systems tend to stick to default values that aren't always free of exploits."

An anonymous reader quotes a report from Hackaday: Stabilizing an inverted pendulum is a classic problem in control theory, and if you've ever taken a control systems class you might remember seeing pages full of differential equations and bode diagrams just to describe its basic operation. Although this might make such a system seem terribly complicated, actually implementing all of that theory doesn't have to be difficult at all, as [Limenitis Reducta] demonstrates in his latest project. All you need is a 3D printer, some basic electronic skills and knowledge of Python. The components needed are a body, two wheels, motors to drive those wheels and some electronics. [Limenitis] demonstrates the design process in the video [here] (in Turkish, with English subtitles available) in which he draws the entire system in Fusion 360 and then proceeds to manufacture it. The body and wheels are 3D-printed, with rubber bands providing some traction to the wheels which would otherwise have difficulty on slippery surfaces.

Two stepper motors drive the wheels, controlled by a DRV8825 motor driver, while an MPU-9250 accelerometer and gyroscope unit measures the angle and acceleration of the system. The loop is closed by a Raspberry Pi Pico that implements a PID controller: another control theory classic, in which the proportional, integral and derivative parameters are tuned to adapt the control loop to the physical system in question. External inputs can be provided through a Bluetooth connection, which makes it possible to control the robot from a PC or smartphone and guide it around your living room. All design files and software are available on Limenitis' GitHub page.

Computer scientists from Stanford University have found that programmers who accept help from AI tools like Github Copilot produce less secure code than those who fly solo. From a report: In a paper titled, "Do Users Write More Insecure Code with AI Assistants?", Stanford boffins Neil Perry, Megha Srivastava, Deepak Kumar, and Dan Boneh answer that question in the affirmative. Worse still, they found that AI help tends to delude developers about the quality of their output. "We found that participants with access to an AI assistant often produced more security vulnerabilities than those without access, with particularly significant results for string encryption and SQL injection," the authors state in their paper.

"Surprisingly, we also found that participants provided access to an AI assistant were more likely to believe that they wrote secure code than those without access to the AI assistant." Previously, NYU researchers have shown that AI-based programming suggestions are often insecure in experiments under different conditions. The Stanford authors point to an August 2021 research paper titled "Asleep at the Keyboard? Assessing the Security of GitHub Copilot's Code Contributions," which found that given 89 scenarios, about 40 per cent of the computer programs made with the help of Copilot had potentially exploitable vulnerabilities.

That study, the Stanford authors say, is limited in scope because it only considers a constrained set of prompts corresponding to 25 vulnerabilities and just three programming languages: Python, C, and Verilog. The Stanford scholars also cite a followup study from some of the same NYU eggheads, "Security Implications of Large Language Model Code Assistants: A User Study," as the only comparable user study they're aware of. They observe, however, that their work differs because it focuses on OpenAI's codex-davinci-002 model rather than OpenAI's less powerful codex-cushman-001 model, both of which play a role in GitHub Copilot, itself a fine-tuned descendant of a GPT-3 language model.

For three years Stockholm-based games studio Embark has been working on the Rust-gpu project to make Rust "a first class language and ecosystem for GPU programming." The project's latest announcement? rust-gpu now supports ray-tracing.

Their original announcement explained the rationale for this years-long dvelopment effort: Historically in games GPU programming has been done through writing either HLSL, or to a lesser extent GLSL. These are simple programming languages that have evolved along with rendering APIs over the years. However, as game engines have evolved, these languages have failed to provide mechanisms for dealing with large codebases, and have generally stayed behind the curve compared to other programming languages.

In part this is because it's a niche language for a niche market, and in part this has been because the industry as a whole has sunk quite a lot of time and effort into the status quo. While over-all better alternatives to both languages exist, none of them are in a place to replace HLSL or GLSL. Either because they are vendor locked, or because they don't support the traditional graphics pipeline. Examples of this include CUDA and OpenCL. And while attempts have been made to create language in this space, none of them have gained any notable traction in the gamedev community.

Our hope with this project is that we push the industry forward by bringing an existing, low-level, safe, and high performance language to the GPU; namely Rust. And with it come some additional benefits that can't be overlooked: a package/module system that's one of the industry's best, built in safety against race-conditions or out of bounds memory access, a wide range of tools and utilities to improve programmer workflows, and many others!
Along with ray-tracing, this week they announced plans to keep rust-gpu on the same schedule as the stable Rust release, "so you can use your favorite new language features as new stable versions of Rust are being released, by just updating your rust-gpu version."

Thanks to Slashdot reader guest reader for sharing the news!

Walking like John Cleese's character, Mr. Teabag, in Monty Python's famous "Ministry of Silly Walks" skit requires considerably more energy expenditure than a normal walking gait because the movement is so inefficient, according to a new paper published in the annual Christmas issue of the British Medical Journal. From a report: In fact, just 11 minutes a day of walking like Mr. Teabag was equivalent to 75 minutes of vigorously intense physical activity per week, presenting a novel means of boosting cardiovascular fitness. "Half a century ago, the [Ministry of Silly Walks] skit might have unwittingly touched on a powerful way to enhance cardiovascular fitness in adults," the authors wrote. "Had an initiative to promote inefficient movement been adopted in the early 1970s, we might now be living among a healthier society."

The BMJ's Christmas issue is typically more lighthearted, though the journal maintains that the papers published therein still "adhere to the same high standards of novelty, methodological rigor, reporting transparency, and readability as apply in the regular issue." Past years have included papers on such topics as why 27 is not a dangerous age for musicians, the side effects of sword swallowing, and measuring the toxicity of the concoction brewed in Roald Dahl's 1981 book George's Marvelous Medicine. (It's very toxic indeed.) The most widely read was 1999's infamous "Magnetic resonance imaging of male and female genitals during coitus and female sexual arousal."

An anonymous reader quotes a report from KrebsOnSecurity: On Dec. 10, 2022, the relatively new cybercrime forum Breached featured a bombshell new sales thread: The user database for InfraGard, including names and contact information for tens of thousands of InfraGard members. The FBI's InfraGard program is supposed to be a vetted Who's Who of key people in private sector roles involving both cyber and physical security at companies that manage most of the nation's critical infrastructures -- including drinking water and power utilities, communications and financial services firms, transportation and manufacturing companies, healthcare providers, and nuclear energy firms. "InfraGard connects critical infrastructure owners, operators, and stakeholders with the FBI to provide education, networking, and information-sharing on security threats and risks," the FBI's InfraGard fact sheet reads.

KrebsOnSecurity contacted the seller of the InfraGard database, a Breached forum member who uses the handle "USDoD" and whose avatar is the seal of the U.S. Department of Defense. USDoD said they gained access to the FBI's InfraGard system by applying for a new account using the name, Social Security Number, date of birth and other personal details of a chief executive officer at a company that was highly likely to be granted InfraGard membership. The CEO in question -- currently the head of a major U.S. financial corporation that has a direct impact on the creditworthiness of most Americans -- did not respond to requests for comment. USDoD told KrebsOnSecurity their phony application was submitted in November in the CEO's name, and that the application included a contact email address that they controlled -- but also the CEO's real mobile phone number. "When you register they said that to be approved can take at least three months," USDoD said. "I wasn't expected to be approve[d]." But USDoD said that in early December, their email address in the name of the CEO received a reply saying the application had been approved. While the FBI's InfraGard system requires multi-factor authentication by default, users can choose between receiving a one-time code via SMS or email. "If it was only the phone I will be in [a] bad situation," USDoD said. "Because I used the person['s] phone that I'm impersonating."

USDoD said the InfraGard user data was made easily available via an Application Programming Interface (API) that is built into several key components of the website that help InfraGard members connect and communicate with each other. USDoD said after their InfraGard membership was approved, they asked a friend to code a script in Python to query that API and retrieve all available InfraGard user data. "InfraGard is a social media intelligence hub for high profile persons," USDoD said. "They even got [a] forum to discuss things." USDoD acknowledged that their $50,000 asking price for the InfraGard database may be a tad high, given that it is a fairly basic list of people who are already very security-conscious. Also, only about half of the user accounts contain an email address, and most of the other database fields -- like Social Security Number and Date of Birth -- are completely empty. [...] While the data exposed by the infiltration at InfraGard may be minimal, the user data might not have been the true end game for the intruders. USDoD said they were hoping the imposter account would last long enough for them to finish sending direct messages as the CEO to other executives using the InfraGuard messaging portal.

"Java is no longer among the top three most popular programming languages in the TIOBE Index," reports the Register, "one of several not particularly definitive yardsticks by which such things are measured." According to Paul Jansen, CEO of Netherlands-based TIOBE Software, the rising popularity of C++ has pushed Java down a notch. The index's rankings are now:

- Python in first place
- C second
- C++ third, and
- Java fourth.

C++ stepped up to third, and Java fell to fourth. "C++ surpassed Java for the first time in the history of the TIOBE Index, which means that Java is at position 4 now," said Jansen in the December update for the TIOBE Index. "This is the first time that Java is not part of the top 3 since the beginning of the TIOBE Index in 2001."

The surge in C++, perhaps in part helped by the stable release of C++ 20 in December 2020, is particularly ironic in light of the language's recent dismissal by Microsoft CTO Mark Russinovich, which coincides with industry evangelism for Rust and its capacity for memory safety.
The article points out that other rankings still show a slighty higher popularity for Java. And ZDNet notes the other languages rising quickly in popularity over the last 12 months: In a year-on-year comparison in Tiobe's index, the languages now in the top 20 that made significant gains over the period are: Rust (up from 27 to 20), Objective-C (up from 29 to 19), science-specialized MATLAB (20 to 14), and Google's Go language (up from 19 to 12).

DeepMind's new artificial intelligence system called AlphaCode was able to "achieve approximately human-level performance" in a programming competition. The findings have been published in the journal Science. Slashdot reader sciencehabit shares a report from Science Magazine: AlphaCode's creators focused on solving those difficult problems. Like the Codex researchers, they started by feeding a large language model many gigabytes of code from GitHub, just to familiarize it with coding syntax and conventions. Then, they trained it to translate problem descriptions into code, using thousands of problems collected from programming competitions. For example, a problem might ask for a program to determine the number of binary strings (sequences of zeroes and ones) of length n that don't have any consecutive zeroes. When presented with a fresh problem, AlphaCode generates candidate code solutions (in Python or C++) and filters out the bad ones. But whereas researchers had previously used models like Codex to generate tens or hundreds of candidates, DeepMind had AlphaCode generate up to more than 1 million.

To filter them, AlphaCode first keeps only the 1% of programs that pass test cases that accompany problems. To further narrow the field, it clusters the keepers based on the similarity of their outputs to made-up inputs. Then, it submits programs from each cluster, one by one, starting with the largest cluster, until it alights on a successful one or reaches 10 submissions (about the maximum that humans submit in the competitions). Submitting from different clusters allows it to test a wide range of programming tactics. That's the most innovative step in AlphaCode's process, says Kevin Ellis, a computer scientist at Cornell University who works AI coding.

After training, AlphaCode solved about 34% of assigned problems, DeepMind reports this week in Science. (On similar benchmarks, Codex achieved single-digit-percentage success.) To further test its prowess, DeepMind entered AlphaCode into online coding competitions. In contests with at least 5000 participants, the system outperformed 45.7% of programmers. The researchers also compared its programs with those in its training database and found it did not duplicate large sections of code or logic. It generated something new -- a creativity that surprised Ellis. The study notes the long-term risk of software that recursively improves itself. Some experts say such self-improvement could lead to a superintelligent AI that takes over the world. Although that scenario may seem remote, researchers still want the field of AI coding to institute guardrails, built-in checks and balances.

"Rust is awesome, for certain things. But think twice before picking it up for a startup that needs to move fast," Matt Welsh, co-founder and chief executive of Fixie.ai and former Google engineering director, writes in a blog post. From the post: I hesitated writing this post, because I don't want to start, or get into, a holy war over programming languages. (Just to get the flame bait out of the way, Visual Basic is the best language ever!) But I've had a number of people ask me about my experience with Rust and whether they should pick up Rust for their projects. So, I'd like to share some of the pros and cons that I see of using Rust in a startup setting, where moving fast and scaling teams is really important. Right up front, I should say that Rust is very good at what it's designed to do, and if your project needs the specific benefits of Rust (a systems language with high performance, super strong typing, no need for garbage collection, etc.) then Rust is a great choice. But I think that Rust is often used in situations where it's not a great fit, and teams pay the price of Rust's complexity and overhead without getting much benefit.

My primary experience from Rust comes from working with it for a little more than 2 years at a previous startup. This project was a cloud-based SaaS product that is, more-or-less, a conventional CRUD app: it is a set of microservices that provide a REST and gRPC API endpoint in front of a database, as well as some other back-end microservices (themselves implemented in a combination of Rust and Python). Rust was used primarily because a couple of the founders of the company were Rust experts. Over time, we grew the team considerably (increasing the engineering headcount by nearly 10x), and the size and complexity of the codebase grew considerably as well. As the team and codebase grew, I felt that, over time, we were paying an increasingly heavy tax for continuing to use Rust. Development was sometimes sluggish, launching new features took longer than I would have expected, and the team was feeling a real productivity hit from that early decision to use Rust. Rewriting the code in another language would have, in the long run, made development much more nimble and sped up delivery time, but finding the time for the major rewrite work would have been exceedingly difficult.

So we were kind of stuck with Rust unless we decided to bite the bullet and rewrite a large amount of the code. Rust is supposed to be the best thing since sliced bread, so why was it not working so well for us? [...] Despite being some of the smartest and most experienced developers I had worked with, many people on the team (myself included) struggled to understand the canonical ways to do certain things in Rust, how to grok the often arcane error messages from the compiler, or how to understand how key libraries worked (more on this below). We started having weekly "learn Rust" sessions for the team to help share knowledge and expertise. This was all a significant drain on the team's productivity and morale as everyone felt the slow rate of development. As a comparison point of what it looks like to adopt a new language on a software team, one of my teams at Google was one of the first to switch entirely from C++ to Go, and it took no more than about two weeks before the entire 15-odd-person team was quite comfortably coding in Go for the first time.

Vulnerabilities in mobile apps exposed Hyundai and Genesis car models after 2012 to remote attacks that allowed unlocking and even starting the vehicles. BleepingComputer reports: Security researchers at Yuga Labs found the issues and explored similar attack surfaces in the SiriusXM "smart vehicle" platform used in cars from other makers (Toyota, Honda, FCA, Nissan, Acura, and Infinity) that allowed them to "remotely unlock, start, locate, flash, and honk" them. At this time, the researchers have not published detailed technical write-ups for their findings but shared some information on Twitter, in two separate threads.

The mobile apps of Hyundai and Genesis, named MyHyundai and MyGenesis, allow authenticated users to start, stop, lock, and unlock their vehicles. After intercepting the traffic generated from the two apps, the researchers analyzed it and were able to extract API calls for further investigation. They found that validation of the owner is done based on the user's email address, which was included in the JSON body of POST requests. Next, the analysts discovered that MyHyundai did not require email confirmation upon registration. They created a new account using the target's email address with an additional control character at the end. Finally, they sent an HTTP request to Hyundai's endpoint containing the spoofed address in the JSON token and the victim's address in the JSON body, bypassing the validity check. To verify that they could use this access for an attack on the car, they tried to unlock a Hyundai car used for the research. A few seconds later, the car unlocked. The multi-step attack was eventually baked into a custom Python script, which only needed the target's email address for the attack.

Yuga Labs analysts found that the mobile apps for Acura, BMW, Honda, Hyundai, Infiniti, Jaguar, Land Rover, Lexus, Nissan, Subaru, and Toyota, use SiriusXM technology to implement remote vehicle management features. They inspected the network traffic from Nissan's app and found that it was possible to send forged HTTP requests to the endpoint only by knowing the target's vehicle identification number (VIN). The response to the unauthorized request contained the target's name, phone number, address, and vehicle details. Considering that VINs are easy to locate on parked cars, typically visible on a plate where the dashboard meets the windshield, an attacker could easily access it. These identification numbers are also available on specialized car selling websites, for potential buyers to check the vehicle's history. In addition to information disclosure, the requests can also carry commands to execute actions on the cars. [...] Before posting the details, Yuga Labs informed both Hyundai and SiriusXM of the flaws and associated risks. The two vendors have fixed the vulnerabilities.

Kite, a start-up that has been developing artificial intelligence technology to help developers write code for nearly a decade, is saying farewell and open-sourcing its code. Silicon Republic reports: Based in San Francisco, Kite was founded in 2014 as an early pioneer in the emerging field of AI that assists software developers in writing code -- an 'autocomplete' for programming of sorts. But now, after eight years of pursuing its vision to be a leader in AI-assisted programming, founder Adam Smith announced on the company website that the business is now wrapping up. According to him, even state-of-the-art machine learning models today don't understand the structure of code -- and too few developers are willing to pay for available services. "We failed to deliver our vision of AI-assisted programming because we were 10-plus years too early to market, ie, the tech is not ready yet," Smith explained. "You can see this in GitHub Copilot, which is built by GitHub in collaboration with OpenAI. As of late 2022, Copilot shows a lot of promise but still has a long way to go."

Copilot was first revealed in June 2021 as an AI assistant for programmers that essentially does for coding what predictive text does for writing emails. Developed in collaboration with OpenAI, GitHub had kept Copilot in technical preview until this summer, during which time it had been used by more than 1.2m developers. The AI was made available to all developers in June, at a cost of $10 a month or $100 a year. However, Smith said that the inadequacy of machine learning models in understanding the structure of code, such as non-local context, has been an insurmountable challenge for the Kite team. "We made some progress towards better models for code, but the problem is very engineering intensive. It may cost over $100m to build a production-quality tool capable of synthesizing code reliably, and nobody has tried that quite yet."

While the business could have still been successful without necessarily increasing developer productivity by 10 times using AI, Smith said he thinks that Kite's delay and unsuccessful attempt at monetizing the service prevented the start-up from taking flight. "We sequenced building our business in the following order: First we built our team, then the product, then distribution and then monetization," he explained, adding that Kite did not reach product-market fit until 2019, five years after starting the company. Despite the time taken to get to the market, Smith said Kite was able to capture 500,000 monthly active developers using its AI with "almost zero marketing spend." But the product failed to generate revenue because the developers refused to pay for it. Smith says most of their code has been open sourced on GitHub, including their "data-driven Python type inference engine, Python public-package analyzer, desktop software, editor integrations, GitHub crawler and analyzer, and more more."

Fedora 37 is now officially released. From a report: Fedora 37 brings the GNOME 43 desktop to Fedora Workstation 37, updated toolchain components like Glibc 2.36 and LLVM 15 and Binutils 2.38, official support for the Raspberry Pi 4, retiring 32-bit ARMv7 support, Fedora CoreOS has been promoted to a Fedora Edition, Perl 5.36, Python 3.11, RPM 4.18, LXQt 1.1, and a wealth of other updated packages.

While the popularity of jQuery is decreasing, React.JS "is currently the most widely used client-side framework," reports ZDNet, citing SlashData's 23rd State of the Developer Nation report (compiled from more than 26,000 developers last summer from 163 countries).

ZDNet believe it shows developers "experimenting less and sticking with what they know and what works." JavaScript remains the largest programming language community, SlashData found. According to its research, there are an estimated 19.6 million developers worldwide using JavaScript every day in everything from web development and mobile apps to backend coding, cloud and game design. Java, meanwhile, is growing rapidly. In the last two years, the size of the Java community has more than doubled from 8.3 million to 16.5 million, SlashData found. For perspective, the global developer population grew about half as fast over the same period....

Python also continued to grow strongly, adding about eight million new developers over the last two years, according to SlashData. It accredited the rise of data science and machine learning as "a clear factor in Python's growing popularity". Approximately 63% of machine-learning developers and data scientists report using Python, whereas less than 15% use R, another programming language often associated with data science.
Both the Kotlin and Rust communities doubled in size in the past two years, the article points out. But according to the survey, only 9% of developers were involved in blockchain technologies.

Yet 27% of respondents reported they were learning about (if not currently working on) cryptocurrency-based projects. ZDNet summarizes the findings: Of the three blockchain technologies covered in the report, non-fungible tokens (NFTs) were found to be of least interest to developers: 58% showed "no interest" in NFTs, which SlashData said was "likely due to its perception as a novelty".

The report found that one-quarter (25%) of developers currently work on, or are learning about, blockchain applications other than cryptocurrencies.

It's been one week since Python 3.11 was released — and it's "faster than ever!" So says Jay Miller, a Microsoft developer writing about Microsoft's six-person "Faster CPython" team (which includes Python creator Guido van Rossum, and offers assistance to other core developers). Miller cites the team's report that Python 3.11 has already seen speedups of 10-60% in some areas of the language -- and offers this inside look at their work.

First, how the team came together: In 2020, Core Developer Mark Shannon drafted an Implementation plan for speeding up CPython (the most common implementation) by five times. This plan proposed a 4-stage process that, as Python's creator Guido van Rossum says, "was an effort that was too much for one volunteer to accomplish".

"Right from the start, my thought was well, we should try to see if Microsoft can hire Mark and a small team of people to support him." In the previous year Van Rossum came out of retirement and joined Microsoft as a Distinguished Engineer. "It was an important effort and it was too much for one person." Microsoft was open to the idea and a team of 6 engineers, including Van Rossum were established. That team has assisted other core developers in acting on this plan.
But the blog post also looks at how the team functions: Every contributor that made the switch from part-time to full-time contribution mentioned being able to get deeper into their work on the language.... The team meets regularly to discuss these things. "All six of us meet every Monday," says Van Rossum. "There's always more than enough to talk about. That is very different than as a core dev community getting together for a Sprint twice a year, like one day after the conference. That is a very special event, of course, but it doesn't feed me throughout the year." Van Rossum believes that knowledge of one another and their collaborative work gave the team a "leg up" because everyone "knows what communication styles people have and what everybody's weaknesses and strengths are...."

Shannon's original 4 stage plan has continued to evolve to have continuous optimizations for the next several years. "To make that as smooth as possible, you have to think in terms of smaller steps, right?" says [team member] Michael Droettboom. Droettboom has worked on long-term projects in the scientific community including the Hubble Space Telescope and more recently the James Web Space Telescope.... "We hope we can bring some knowledge from really large proprietary systems into what we develop for the Community." says Droettboom. "I think that's really valuable because then you're not just doing it in the abstract. Not just imagining what's going to make Python faster for real use cases, but actually measuring it." [Team member] Brandt Bucher adds in that developers working with these teams can test the impact of changes, "getting useful insights and contributions from people who maintain large, diverse codebases...." Many of the team's meetings feature core developers from other teams and companies.
The blog post highlights specific activities of team members:

• L Pereira is working on a change to how integers are represented inside Python, and "intends to change smaller integers to use native computation instead of the slower algorithms for arbitrarily large numbers."

• Irit Katriel implemented the new Exception groups and except* features in Python 3.11, and reports that "By simplifying the interpreter's internal representation of raised exceptions, I reduced the time it takes to raise and catch an exception by about 10%."

• Brandt Bucher (who helped create structural pattern matching for Python 3.10) is working on a Specialized Adaptive Interpreter (and tools like Specialist to help users move to Python).

• Long-time contributor Eric Snow is working on a per-interpreter Global Interpreter Lock.

And they've already begun working on features for future versions of Python. "You can also find out more about what the Faster CPython Team has in mind for 3.12 in their ideas repo on Github."

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.