An anonymous reader quotes a report from The Register: Two years after the Log4Shell vulnerability in the open source Java-based Log4j logging utility was disclosed, circa one in four applications are dependent on outdated libraries, leaving them open to exploitation. Research from security shop Veracode revealed that the vast majority of vulnerable apps may never have updated the Log4j library after it was implemented by developers as 32 percent were running pre-2015 EOL versions. Prior investigations from Veracode also showed that 79 percent of all developers never update third-party libraries after first introducing them into projects, and given that Log4j2 -- the specific version of Log4j affected by the vulnerability -- dates back to 2014, this could explain the large proportion of unpatched apps.

A far smaller minority are running versions that were vulnerable at the time of the Log4j vulnerability's disclosure in December 2021. Only 2.8 percent are still using versions 2.0-beta9 through 2.15.0 -- post-EOL versions that remain exposed to Log4Shell, the industry-coined moniker of the vulnerability's exploit. Some 3.8 percent are still running version 2.17, a post-patch version of the Java logger that's not exposed to Log4Shell attacks, but is vulnerable to a separate remote code execution (RCE) bug (CVE-2021-44832).

The researchers believe this illustrates a minority of developers that acted quickly when the vulnerability was first disclosed, as was the advice at the time, had returned to older habits of leaving libraries untouched. Altogether, just shy of 35 percent remain vulnerable to Log4Shell, and nearly 40 percent are vulnerable to RCE flaws. The EOL versions of Log4j are also vulnerable to three additional critical bugs announced by Apache, bringing the total to seven high and critical-rated issues. "At a surface level, the numbers above show that the massive effort to remediate the Log4Shell vulnerability was effective in mitigating risk of exploitation of the zero-day vulnerability. That should not be surprising," said Chris Eng, chief research officer at Veracode.

"The bigger story at the two-year anniversary, however, is that there is still room for improvement when it comes to open source software security. If Log4Shell was another example in a long series of wake-up calls to adopt more stringent open source security practices, the fact that more than one in three applications currently run vulnerable versions of Log4j shows there is more work to do.

"The major takeaway here is that organizations may not be aware of how much open source security risk they are exposed to and how to mitigate it."

"Every day, 3 trillion dollars worth of transactions are handled by a 64-year-old programming language that hardly anybody knows anymore," writes PC Magazine. But most school's don't teach the mainframe programming language COBOL any more, and "COBOL cowboys" are aging out of the workforce, with replacements in short supply.

"This is precisely the kind of problem that IBM thinks it can fix with AI." IBM's approach is fairly straightforward: Rather than relying exclusively on a limited pool of human programmers to solve the problem, it built a generative AI-powered code assistant (watsonx) that helps convert all that dusty old COBOL code to a more modern language, thereby saving coders countless hours of reprogramming. In extremely simplified terms, the process is similar to feeding an essay written in English into ChatGPT and asking it to translate certain paragraphs into Esperanto. It allows programmers to take a chunk of COBOL and enlist watsonx to transform it into Java.

But of course, it's not quite that simple in practice... After IBM and the customer have a thorough understanding of the application landscape, the data flow, and the existing dependencies, "we help them refactor their applications," says IBM's Vice President of Product Management, IT Automation, Keri Olson. "That is, breaking it down into smaller pieces, which the customer can selectively choose, at that point, to do the modernization from COBOL to Java." Skyla Loomis, IBM's Vice President of IBM Z Software adds, "But you have to remember that this is a developer assistant tool. It's AI assisted, but it still requires the developer. So yes, the developer is involved with the tooling and helping the customers select the services."

Once the partnership between man and machine is established, the AI steps in and says, 'Okay, I want to transform this portion of code. The developer may still need to perform some minor editing of the code that the AI provides, Loomis explains. "It might be 80 or 90 percent of what they need, but it still requires a couple of changes. It's a productivity enhancement — not a developer replacement type of activity."
The article quotes a skeptical Gartner Distinguished Vice President and Analyst, who notes that IBM "has no case studies, at this time, to validate its claims."

"Structured concurrency is a new way to use multithreading in Java," reports InfoWorld.

"It allows developers to think about work in logical groups while taking advantage of both traditional and virtual threads." Available in preview in Java 21, structured concurrency is a key aspect of Java's future, so now is a good time to start working with it... Java's thread model makes it a strong contender among concurrent languages, but multithreading has always been inherently tricky. Structured concurrency allows you to use multiple threads with structured programming syntax. In essence, it provides a way to write concurrent software using familiar program flows and constructs. This lets developers focus on the business at hand, instead of the orchestration of threading.

As the JEP for structured concurrency says, "If a task splits into concurrent subtasks then they all return to the same place, namely the task's code block." Virtual threads, now an official feature of Java, create the possibility of cheaply spawning threads to gain concurrent performance. Structured concurrency provides the simple syntax to do so. As a result, Java now has a unique and highly-optimized threading system that is also easy to understand...

Between virtual threads and structured concurrency, Java developers have a compelling new mechanism for breaking up almost any code into concurrent tasks without much overhead... Any time you encounter a bottleneck where many tasks are occurring, you can easily hand them all off to the virtual thread engine, which will find the best way to orchestrate them. The new thread model with structured concurrency also makes it easy to customize and fine-tune this behavior. It will be very interesting to see how developers use these new concurrency capabilities in our applications, frameworks, and servers going forward.
It involves a new class StructuredTaskScope located in the java.util.concurrent library. (InfoWorld points out that "you'll need to use --enable-preview and --source 21 or --source 22 to enable structured concurrency.")

Their reporter shared an example on GitHub, and there's more examples in the Java 21 documentation. "The structured concurrency documentation includes an example of collecting subtask results as they succeed or fail and then returning the results."

An anonymous reader shared this report from InfoWorld: JetBrains' Kotlin language, a Java rival endorsed by Google for Android mobile development, continues to scale up Tiobe's index of language popularity, reaching the 15th spot in the November 2023 rankings...

Software quality services company Tiobe cites Kotlin advantages including interoperability with Java and unrivaled Android accommodations as reasons for the language's rise. Kotlin, Tiobe CEO Paul Jansen said, also fits in with a modern programming culture of expressive languages that have a strong type system and avoid null pointer exceptions by design. "Based on my experience, I am pretty sure Kotlin can reach a top 10 position," Jansen said. It remains to be seen if it can ever scale as high as a top four slot, he added...

In the rival Pypl Popularity of Programming languages index this month, Kotlin was ranked 13th with a 1.76% share, having slipped slightly year-over-year.
Kotlin's rank on the TIOBE index rose three positions in the last month — after rising two positions the month before. TIOBE's CEO says the language has now achieved its highest ranking ever on the index, surpassing 2017's "first wave of Kotlin popularity...when Google announced first class support for Kotlin on Android."

Rust now ranks #20 on the index, behind Delphi/Object Pascal, Swift, Ruby, and R.

Here's TIOBE November rankings for top-20 most popular programming languages:

1. Python
2. C
3. C++
4. Java
5. C#
6. JavaScript
7. PHP
8. Visual Basic
9. SQL
10. Assembly Language
11. Scratch
12. Fortran
13. Go
14. MATLAB
15. Kotlin
16. Delphi/Object Pascal
17. Swift
18. Ruby
19. R
20. Rust

In Chrome, JavaScript (and WebAssembly) code are both executed by Google's open source V8 engine — which already has garbage-collecting capabilities. "This means developers making use of, for example, PHP compiled to Wasm, end up shipping a garbage collector implementation of the ported language (PHP) to the browser that already has a garbage collector," writes Google developer advocate Thomas Steiner, "which is as wasteful as it sounds."

"This is where WasmGC comes in." WebAssembly Garbage Collection (or WasmGC) is a proposal of the WebAssembly Community Group [which] adds struct and array heap types, which means support for non-linear memory allocation... In simplified terms, this means that with WasmGC, porting a programming language to WebAssembly means the programming language's garbage collector no longer needs to be part of the port, but instead the existing garbage collector can be used.
Sometime on Halloween, Steiner wrote that in Chrome, WebAssembly garbage collection is now enabled by default. But then he explored what this means for high-level programming languages (with their own built-in garbage collection) being compiled into WebAssembly: To verify the real-world impact of this improvement, Chrome's Wasm team has compiled versions of the Fannkuch benchmark (which allocates data structures as it works) from C, Rust, and Java. The C and Rust binaries could be anywhere from 6.1 K to 9.6 K depending on the various compiler flags, while the Java version is much smaller at only 2.3 K! C and Rust do not include a garbage collector, but they do still bundle malloc/free to manage memory, and the reason Java is smaller here is because it doesn't need to bundle any memory management code at all. This is just one specific example, but it shows that WasmGC binaries have the potential of being very small, and this is even before any significant work on optimizing for size.
The blog post includes two examples of WasmGC-ported programming languages in action:

• "One of the first programming languages that has been ported to Wasm thanks to WasmGC is Kotlin in the form of Kotlin/Wasm."

• "The Dart and Flutter teams at Google are also preparing support for WasmGC. The Dart-to-Wasm compilation work is almost complete, and the team is working on tooling support for delivering Flutter web applications compiled to WebAssembly."

An anonymous reader quotes a report from Ars Technica: Android is slowly entering the RISC-V era. So far we've seen Google say it wants to give the up-and-coming CPU architecture "tier-1" support in Android, putting RISC-V on equal footing with Arm. Qualcomm has announced the first mass-market RISC-V Android chip, a still-untitled Snapdragon Wear chip for smartwatches. Now Google has announced a timeline for developer tools via the Google Open Source Blog. The last post is titled "Android and RISC-V: What you need to know to be ready."

Getting the Android OS and app ecosystem to support a new architecture is going to take an incredible amount of work from Google and developers, and these tools are laying the foundation for that work. First up, Google already has the "Cuttlefish" virtual device emulator running, including a gif of it booting up. This isn't the official "Android Emulator" -- which is targeted at app developers doing app development -- Cuttlefish is a hardware emulator for Android OS development. It's the same idea as the Android Emulator but for the bottom half of the tech stack -- the kernel, framework, and hardware bits. Cuttlefish lets Google and other Android OS contributors work on a RISC-V Android build without messing with an individual RISC-V device. Google says it's working well enough now that you can download and emulate a RISC-V device today, though the company warns that nothing is optimized yet.

The next step is getting the Android Emulator (for app developers) up and running, and Google says: "By 2024, the plan is to have emulators available publicly, with a full feature set to test applications for various device form factors!" The nice thing about Android is that most app code is written with no architecture in mind -- it's all just Java/Kotlin. So once the Android RunTime starts spitting out RISC-V code, a lot of app code should Just Work. That means most of the porting work will need to go into things written in the NDK, the native developer kit, like libraries and games. The emulator will still be great for testing, though.

"A recent analysis accounting for nearly 1.2 million open source software projects primarily across four major ecosystems found that only about 11% of projects were actively maintained," reports InfoWorld: In its 9th Annual State of the Software Supply Chain report, published October 3, software supply chain management company Sonatype assessed 1,176,407 projects and reported an 18% decline this year in actively maintained projects. Just 11% of projects — 118,028 — were receiving active maintenance.

The report also found some new projects, unmaintained in 2022, now being maintained.

The four ecosystems included JavaScript, via NPM; Java, via the Maven project management tool; Python, via the PyPI package index; and .NET, through the NuGet gallery. Some Go projects also were included. According to the report, 18.6% of Java and JavaScript projects that were being maintained in 2022 are no longer being maintained today.
Other interesting findings:

• Nearly 10% reported security breaches due to open source vulnerabilities in the past 12 months.

• Use of AI and machine learning software components within corporate environments surged 135% over the last year.

"The gap between C# and Java never has been so small," according to October's update for TIOBE's "Programming Community Index".

"Currently, the difference is only 1.2%, and if the trends remain this way, C# will surpass Java in about 2 month's time." Java shows the largest decline of -3.92% and C# the largest gain of +3.29% of all programming languages (annually).

The two languages have always been used in similar domains and thus have been competitors for more than 2 decades now. Java's decline in popularity is mainly caused by Oracle's decision to introduce a paid license model after Java 8. Microsoft took the opposite approach with C#. In the past, C# could only be used as part of commercial tool Visual Studio. Nowadays, C# is free and open source and it's embraced by many developers.

There are also other reasons for Java's decline. First of all, the Java language definition has not changed much the past few years and Kotlin, its fully compatible direct competitor, is easier to use and free of charge.
"Java remains a critical language in enterprise computing," argues InfoWorld, "with Java 21 just released last month and Java 22 due next March. And free open source binaries of Java still are available via OpenJDK." InfoWorld also notes TIOBE's ranking is different than other indexes. TIOBE's top 10:

1. Python (14.82%)
2. C (12.08%)
3. C++ (10.67%)
4. Java (8.92%)
5. C# (7.71%)
6. JavaScript (2.91%)
7. Visual Basic (2.13%)
8. PHP (1.9%)
9. SQL (1.78%)
10. Assembly (1.64%)

And here's the Pypl Popularity of Programming Language (based on searches for language tutorials on Google):

1. Python, with a 28.05% share
2. Java (15.88%)
3. JavaScript (9.27%)
4. C# (6.79%)
5. C/C++ (6.59%)
6. PHP (4.86%)
7. R (4.45%)
8. TypeScript (2.93%)
9. Swift (2.69%)
10. Objective-C (2.29%)

Tom Ivan, reporting for VGC: Ransomware group Ransomed[dot]vc claims to have successfully breached Sony Group and is threatening to sell a cache of data stolen from the Japanese company. While its claims remain unverified, Cyber Security Connect reports that the relative ransomware newcomer "has racked up an impressive amount of victims" since bursting onto the scene last month. "We have successfully compromissed [sic] all of sony systems," the group claimed on both the clear and dark nets. "We won't ransom them! We will sell the data. Due to Sony not wanting to pay. DATA IS FOR SALE."

According to Cyber Security Connect, the group has posted some proof-of-hack data, although it says this is "not particularly compelling information on the face of things." It includes what appear to be screenshots of an internal log-in page, an internal PowerPoint presentation, several Java files, and a file tree of the leak which seemingly includes fewer than 6,000 files. Most of the Ransomed[dot]vc's members reportedly operate out of Ukraine and Russia.

Last week IEEE Spectrum released its 10th annual rankings of the Top Programming Languages. It choose a top language for each of three categories: actively used among typical IEEE members and working software engineers, in demand by employers, or "in the zeitgeist".

The results? This year, Python doesn't just remain No. 1 in our general "Spectrum" ranking — which is weighted to reflect the interests of the typical IEEE member — but it widens its lead.

Python's increased dominance appears to be largely at the expense of smaller, more specialized, languages. It has become the jack-of-all-trades language — and the master of some, such as AI, where powerful and extensive libraries make it ubiquitous. And although Moore's Law is winding down for high-end computing, low-end microcontrollers are still benefiting from performance gains, which means there's now enough computing power available on a US $0.70 CPU to make Python a contender in embedded development, despite the overhead of an interpreter. Python also looks to be solidifying its position for the long term: Many children and teens now program their first game or blink their first LED using Python. They can then move seamlessly into more advanced domains, and even get a job, with the same language.

But Python alone does not make a career. In our "Jobs" ranking, it is SQL that shines at No. 1. Ironically though, you're very unlikely to get a job as a pure SQL programmer. Instead, employers love, love, love, seeing SQL skills in tandem with some other language such as Java or C++. With today's distributed architectures, a lot of business-critical data live in SQL databases...

But don't let Python and SQL's rankings fool you: Programming is still far from becoming a monoculture. Java and the various C-like languages outweigh Python in their combined popularity, especially for high-performance or resource-sensitive tasks where that interpreter overhead of Python's is still too costly (although there are a number of attempts to make Python more competitive on that front). And there are software ecologies that are resistant to being absorbed into Python for other reasons.
The article cites the statistical analysis/visualization language R, as well as Fortran and Cobol, as languages that are hard to port code from or that have accumulated large already-validated codebases. But Python also remains at #1 in their third "Trending" category — with Java in second there and on the general "IEEE Spectrum" list.

JavaScript appears below Python and Java on all three lists. Java is immediately below them on the Trending and "Jobs" list, but two positions further down on the general "Spectrum" list (below C++ and C).

The metrics used for the calculation include the number of hits on Google, recent questions on Stack Overflow, tags on Discord, mentions in IEEE's library of journal articles and its CareerBuilder job site, and language use in starred GitHub repositories and number of new programming books.

The creators of four programming languages will appear together onstage for a historic conversation on September 19th.

- Adele Goldberg — Smalltalk
- Guido Van Rossum — Python
- Anders Hejlsberg — Turbo Pascal, C#, TypeScript
- James Gosling — Java

The announcement describes it as "a conversation about programming language design." The charity event brings together this unique group of computer science pioneers, unlike any event held before. These great minds come together for what will surely be a fantastic night of discussion as the panel delves into the past and future of programming language creation.
It's a fundraiser for two groups. NumFOCUS is a nonprofit charity sponsoring nearly all the major tools in the Python data science stack (including jupyter, numpy, pandas, and matplotlib), and it's also the group behind PyData conferences on open source data tools. And the Last Mile Education Fund offers financial support for low-income underrepresented students. It's being billed as the "inaugural charity event" of PyData Seattle.

This happened once before in 2019, when Puget Sound Programming Python arranged a four-way discussion with Python creator Guido van Rossum, Java creator James Gosling, Perl creator Larry Wall, and Anders Hejlsberg (Turbo Pascal, C#, TypeScript). They held a 90-minute discussion about "language design, the universe, and everything" as a benefit for CSforALL (a group promoting computer science classes at every grade level). During that discussion Gosling shared how Java "started out as kind of 'Do a better C', and it got out of control. The rest of the project really ended up just providing the context." And Anders Hejlsberg told the audience that TypeScript was inspired by massive "write-only" JavaScript code bases.

In their discussion on variable typing and its use in IDEs, Gosling mocked what he called the "real men use vi" mentality, leading to a lively back and forth. Perl's Larry Wall later acknowledged the importance of types and the careful consideration that went into implementing them for Perl 6, but also shared his unique perspective as a long-time designer of programming languages. "I think IDEs make language developers lazy."

At the end of the event, they all agreed that the most rewarding part of language design was the people — the excitement, the gratitude, and to see that community helping others in its community.

According to a team of researchers from RMIT University in Australia, coffee grounds can be used as a silica substitute in the concrete production process to yield a significantly stronger chemical bond than sand alone. Engadget reports: "The disposal of organic waste poses an environmental challenge as it emits large amounts of greenhouse gases including methane and carbon dioxide, which contribute to climate change," lead author of the study, Dr Rajeev Roychand of RMIT's School of Engineering, said in a recent release. He notes that Australia alone produces 75 million kilograms of used coffee grounds each year, most of which ends up in landfills. Coffee grounds can't simply be mixed in raw with standard concrete as they won't bind with the other materials due to their organic content, Dr. Roychand explained. In order to make the grounds more compatible, the team experimented with pyrolyzing the materials at 350 and 500 degrees C, then substituting them in for sand in 5, 10, 15 and 20 percentages (by volume) for standard concrete mixtures.

The team found that at 350 degrees is perfect temperature, producing a "29.3 percent enhancement in the compressive strength of the composite concrete blended with coffee biochar," per the team's study, published in the September issue of Journal of Cleaner Production. "In addition to reducing emissions and making a stronger concrete, we're reducing the impact of continuous mining of natural resources like sand," Dr. Roychand said.

Meta, intent on making a splash in a generative AI space rife with competition, is on something of an open source tear. From a report: Following the release of AI models for generating text, translating languages and creating audio, the company today open sourced Code Llama, a machine learning system that can generate and explain code in natural language -- specifically English. Akin to GitHub Copilot and Amazon CodeWhisperer, as well as open source AI-powered code generators like StarCoder, StableCode and PolyCoder, Code Llama can complete code and debug existing code across a range of programming languages, including Python, C++, Java, PHP, Typescript, C# and Bash.

"At Meta, we believe that AI models, but large language models for coding in particular, benefit most from an open approach, both in terms of innovation and safety," Meta wrote in a blog post shared with TechCrunch. "Publicly available, code-specific models can facilitate the development of new technologies that improve peoples' lives. By releasing code models like Code Llama, the entire community can evaluate their capabilities, identify issues and fix vulnerabilities." Code Llama, which is available in several flavors, including a version optimized for Python and a version fine-tuned to understand instructions (e.g. "Write me a function that outputs the fibonacci sequence"), is based on the Llama 2 text-generating model that Meta open sourced earlier this month. While Llama 2 could generate code, it wasn't necessarily good code -- certainly not up to the quality a purpose-built model like Copilot could produce.

IBM is introducing the watsonx Code Assistant for Z, a tool that uses generative AI to translate COBOL code to Java. This tool is set to be available in Q4 2023 and aims to speed up the translation of COBOL to Java on IBM's Z mainframes. The Register reports: According to IBM, there are billions of lines of COBOL code out there as potential candidates for modernization (a report last year estimated the total figure at 775-850 billion lines). For this reason, the generative AI features in watsonx Code Assistant for Z are intended to help developers to assess and determine the code most in need of modernization, allowing them to more speedily update large applications and focus on critical tasks.

IBM wants to provide tooling for each step of the modernization process, starting with its Application Discovery and Delivery Intelligence (ADDI) inventory and analysis tool. Other steps include refactoring business services in COBOL, transforming the code to Java code, and then validating the resulting outcome with the aid of automated testing. The resulting Java code emitted by watsonx Code Assistant for Z will be object-oriented, but will still interoperate with the rest of the COBOL application IBM claimed, as well as with key services such as CICS, IMS, DB2, and other z/OS runtimes.

The latest update to the Android Runtime (ART) -- the "engine behind the Android operating system (OS)" -- has resulted in app startup time "improvements of up to 30% on some devices," says Google. 9to5Google reports: Behind the scenes, "ART is the same for all devices" and: "The ART APEX module is a complex piece of software with an order of magnitude more APIs than any other APEX module. It also backs a quarter of the developer APIs available in the Android SDK. In addition, ART has a compiler that aims to make the most of the underlying hardware by generating chipset-specific instructions, such as Arm SVE." The testing process for Android Runtime updates involves "compiling over 18 million APKs and running app compatibility tests, and startup, performance, and memory benchmarks on a variety of Android devices that replicate the diversity of our ecosystem as closely as possible." There's then a very gradual rollout process.

Google also notes developer improvements with every update "like OpenJDK improvements and compiler optimizations that benefit both Java and Kotlin," with ART 13 resulting in the "fastest-ever adoption of a new OpenJDK [11] release on Android devices." ART 14 is rolling out "in the coming months" with "new compiler and runtime optimizations that improve performance while reducing code size," as well as OpenJDK 17.

Researchers at Georgia Tech have developed a prototype pipeline for the Defense Advanced Research Projects Agency (DARPA) that can "distill" binary executables into human-intelligible code so that it can be updated and deployed in "weeks, days, or hours, in some cases." The work is part of a five-year, $10 million project with the agency. The Register reports: After running an executable through the university's "distillation" process, software engineers should be able to examine the generated HAR, figure out what the code does, and make changes to add new features, patch bugs, or improve security, and turn the HAR back into executable code, says GT associate professor and project participant Brendan Saltaformaggio. This would be useful for, say, updating complex software that was written by a contractor or internal team, the source code is no longer or never was to hand and neither are its creators, and stuff needs to be fixed up. Reverse engineering the binary and patching in an update by hand can be a little hairy, hence DARPA's desire for something a bit more solid and automatic. The idea is to use this pipeline to freshen up legacy or outdated software that may have taken years and millions of dollars to develop some time ago.

Saltaformaggio told El Reg his team has the entire process working from start to finish, and with some level of stability, too. "DARPA sets challenges they like to use to test the capabilities of a project," he told us over the phone. "So far we've handled every challenge problem DARPA's thrown at us, so I'd say it's working pretty well." Saltaformaggio said his team's pipeline disassembles binaries into a graph structure with pseudo-code, and presented in a way that developers can navigate, and replace or add parts in C and C++. Sorry, Java devs and Pythonistas: Saltaformaggio tells us that there's no reason the system couldn't work with other programming languages, "but we're focused on C and C++. Other folks would need to build out support for that." Along with being able to deconstruct, edit, and reconstruct binaries, the team said its processing pipeline is also able to comb through HARs and remove extraneous routines. The team has also, we're told, baked in verification steps to ensure changes made to code within hardware ranging from jets and drones to plain-old desktop computers work exactly as expected with no side effects.

Michael Larabel writes via Phoronix: Mozilla developers are celebrating that they are now faster than Google Chrome with the SunSpider JavaScript benchmark, although that test has been superseded by the JetStream benchmark. Last week a new Firefox Nightly News was published that outlines that "We're now apparently beating Chrome on the SunSpider JavaScript benchmark!" The provided numbers now show Firefox easily beating Chrome in this decade-old JavaScript benchmark. The benchmarks come from AreWeFastYet.com. Meanwhile for the newer and more demanding JetStream 2.0 benchmark, Google Chrome continues to win easily over Firefox. You can learn more about the latest Firefox Nightly build advancements via Firefox Nightly News.

Canonical engineering manager Ben Hoyt believes that a variable's name is more important than its type, so "the name should be more prominent and come first in declarations." In many popular programming languages, including C, C++, Java, and C#, when you define a field or variable, you write the type before the name. For example (in C++):

// Struct definition
struct person {
std::string name;
std::string email;
int age;
};

In other languages, including Go, Rust, TypeScript, and Python (with type hints), you write the name before the type. For example (in Go):

// Struct definition
type Person struct {
Name string
Email string
Age int
}

There's a nice answer in the Go FAQ about why Go chose this order: "Why are declarations backwards?". It starts with "they're only backwards if you're used to C", which is a good point — name-before-type has a long history in languages like Pascal. In fact, Go's type declaration syntax (and packages) were directly inspired by Pascal.

The FAQ goes on to point out that parsing is simpler with name-before-type, and declaring multiple variables is less error-prone than in C. In C, the following declares x to be a pointer, but (surprisingly at first!) y to be a normal integer:

int* x, y;

Whereas the equivalent in Go does what you'd expect, declaring both to be pointers:

var x, y *int

The Go blog even has an in-depth article by Rob Pike on Go's Declaration Syntax, which describes more of the advantages of Go's syntax over C's, particularly with arrays and function pointers.

Oddly, the article only hints at what I think is the more important reason to prefer name-before-type for everyday programming: it's clearer.
Hoyt argues a variable's name has more meaning (semantically) — pointing out dynamically-typed languages like Python and Ruby don't even need types, and that languages like Java, Go, C++ and C# now include type inference.

"I think the takeaway is this: we can't change the past, but if you're creating a new language, please put names before types!"

For storing passwords, Slashdot reader eggegick has a simple, easy solution: "I use Vim to keep my passwords in an encrypted file."

But what's the easiest solution for people who don't use Vim? My wife is not a Linux geek like I am, so she's using [free and open-source] KeePass. It's relatively simple to install and use, but I seem to recall it used to be even much simpler... Does anybody know of a really simple password manager or encrypting notepad?

I've looked at a number of them, and they use Java or Javascript, or they involve an external web site, or they have way too many features, or they use an installation program. Or Windows Defender objects to them.
Share your own suggestions and thoughts in the comments.

What's the best (encrypted) password manager?

Last weekend in Portland, Oregon, the Software Freedom Conservancy hosted a new conference called the Free and Open Source Software Yearly.

And long-time free software activist Bradley M. Kuhn (currently a policy fellow/hacker-in-residence for the Software Freedom Conservancy) hosted a lively panel discussion on "the recent change" to public source code releases for Red Hat Enterprise Linux which shed light on what may happen next. The panel also included:

• benny Vasquez, the Chair of the AlmaLinux OS Foundation
• Jeremy Alison, Samba co-founder and software engineer at CIQ (focused on Rocky Linux). Allison is also Jeremy Allison - Sam Slashdot reader #8,157.
• James (Jim) Wright, Oracle's chief architect for Open Source policy/strategy/compliance/alliances

"Red Hat themselves did not reply to our repeated requests to join us on this panel... SUSE was also invited but let us know they were unable to send someone on short notice to Portland for the panel."

One interesting audience question for the panel came from Karsten Wade, a one-time Red Hat senior community architect who left Red Hat in April after 21 years, but said he was "responsible for bringing the CentOS team onboard to Red Hat." Wade argued that CentOS "was always doing a clean rebuild from source RPMS of their own..." So "isn't all of this thunder doing Red Hat's job for them, of trying to get everyone to say, 'This thing is not the equivalent to RHEL.'"

In response Jeremy Alison made a good point. "None of us here are the arbiters of whether it's good enough of a rebuild of Red Hat Linux. The customers are the arbiters." But this led to an audience member asking a very forward-looking question: what are the chances the community could adopt a new (and open) enterprise Linux standard that distributions could follow. AlmaLinux's Vasquez replied, "Chances are real high... I think everyone sees that as the obvious answer. I think that's the obvious next step. I'll leave it at that." And Oracle's Wright added "to the extent that the market asks us to standardize? We're all responsive."

When asked if they'd consider adding features not found in RHEL ("such as high-security gates through reproducible builds") AlmaLinux's Vasquez said "100% -- yeah. One of the things that we're kind of excited about is the opportunities that this opens for us. We had decided we were just going to focus on this north star of 1:1 Red Hat no matter what -- and with that limitation being removed, we have all kinds of options." And CIQ's Alison said "We're working on FIPS certification for an earlier version of Rocky, that Red Hat, I don't believe, FIPS certified. And we're planning to release that."

AlmaLinux's Vasquez emphasized later that "We're just going to build Enterprise Linux. Red Hat has done a great job of establishing a fantastic target for all of us, but they don't own the rights to enterprise Linux. We can make this happen, without forcing an uncomfortable conversation with Red Hat. We can get around this."

And Alison later applied a "Star Wars" quote to Red Hat's predicament. "The more things you try and grab, the more things slip through your fingers." That is, "The more somebody tries to exert control over a codebase, the more the pushback will occur from people who collaborate in that codebase." AlmaLinux's Vasquez also said they're already "in conversations" with independent software vendors about the "flow of support" into non-Red Hat distributions -- though that's always been the case. "Finding ways to reduce the barrier for those independent software vendors to add official support for us is, like, maybe more cumbersome now, but it's the same problem that we've had..."

Early in the discussion Oracle's Jim Wright pointed out that even Red Hat's own web site defines open source code as "designed to be publicly accessible — anyone can see, modify, and distribute the code as they see fit." ("Until now," Wright added pointedly...) There was some mild teasing of Oracle during the 50-minute discussion -- someone asked at one point if they'd re-license their proprietary implementation of ZFS under the GPL. But at the end of the panel, Oracle's Jim Wright still reminded the audience that "If you want to work on open source Linux, we are hiring."

Read Slashdot's transcript of highlights from the discussion.