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.

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