Veteran open source report Steven J. Vaughan-Nichols, writing at The Register: We can all agree that securing our software is a good thing. Thanks to one security fiasco after another -- the SolarWinds software supply chain attack, the perpetual Log4j vulnerability, and the npm maintainer protest code gone wrong -- we know we must secure our code. But the European Union's proposed Cyber Resilience Act (CRA) goes way, way too far in trying to regulate software security. At the top level, it looks good. Brussels states that before "products with digital elements" are allowed on the EU market, manufacturers must follow best practices in four areas. Secure the product over its whole life; follow a coherent cybersecurity framework; show cybersecurity transparency; and ensure customers can use products securely. Sounds great, doesn't it? But the road to hell is paved with good intentions. The devil, as always, is in the details. Some of this has nothing to do with open source software. Good luck creating any program in any way that a clueless user can't screw up.

But the EU commissioners don't have a clue about how open source software works. Or, frankly, what it is. They think that open source is the same as proprietary software with a single company behind it that's responsible for the work and then monetizes it. Nope. Open source, as I've said over and over again, is not a business model. Sure, you can build businesses around it. Who doesn't these days? But just as the AWSes, Googles, and Facebooks of the world depend on open source software, they also use programs written by Tom, Denise, and Harry from around the world. The CRA's underlying assumption is that you can just add security to software, like adding a new color option to your car's paint job. We wish!

Securing software is a long, painful process. Many open source developers have neither the revenue nor resources to secure their programs to a government standard. The notional open source developer in Nebraska, thanklessly maintaining a vital small program, may not even know where Brussels is (it's in Belgium). They can't afford to secure their software to meet EU specifications. They often have no revenue. They certainly have no control over who uses their software. It's open source, for pity's sake! As open source developer Thomas Depierre recently blogged: "We are not suppliers. All the people writing and maintaining these projects, we are not suppliers. We do not have a business relationship with all these organizations. We are volunteers, writing code and putting it online under these Licenses." Exactly.

According to Azure CTO Mark Russinovich, the most recent Windows 11 Insider Preview build is the first to include the memory-safe programming language Rust. Thurrott reports: "If you're on the Win11 Insider ring, you're getting the first taste of Rust in the Windows kernel," Russinovich tweeted last night. It's not clear which Insider channel he is referring to, however.

Regardless, that that was quick: Microsoft only went public with its plans to replace parts of the Windows kernel with Rust code in mid-April at its BlueHat IL 2023 security conference in Israel. At that event, Microsoft vice president David Weston said that "we're using Rust on the operating system along with other constructs" as part of an "aggressive and meaningful pursuit of memory safety," a key source of exploits. And it's not just the Windows kernel. Microsoft is bringing Rust to its Pluton security processor as well.

SimilarWeb: Developers increasingly get advice from AI chatbots and GitHub CoPilot rather than Stack Overflow message boards. While traffic to OpenAI's ChatGPT has been growing exponentially, Stack Overflow has been experiencing a steady decline -- losing some of its standings as the go-to source developers turn to for answers to coding challenges. Actually, traffic to Stack Overflow's community website has been dropping since the beginning of 2022. That may be in part because of a related development, the introduction of the CoPilot coding assistant from Microsoft's GitHub business. CoPilot is built on top of the same OpenAI large language model as ChatGPT, capable of processing both human language and programming language. A plugin to the widely used Microsoft Visual Studio Code allows developers to have CoPilot write entire functions on their behalf, rather than going to Stack Overflow in search of something to copy and paste. CoPilot now incorporates the latest GPT-4 version of OpenAI's platform.

On a year-over-year basis, traffic to Stack Overflow (stackoverflow.com) has been down by an average of 6% every month since January 2022 and was down 13.9% in March. ChatGPT doesn't have a year-over-year track record, having only launched at the end of November, but its website (chat.openai.com) has become one of the world's hottest digital properties in that short time, bigger than Microsoft's Bing search engine for worldwide traffic. It attracted 1.6 billion visits in March and another 920.7 million in the first half of April. The GitHub website has also been seeing strong growth, with traffic to github.com up 26.4% year-over-year in March to 524 million visits. That doesn't reflect all the usage of CoPilot, which normally takes place within an editor like Visual Studio Code, but it would include people coming to the website to get a subscription to the service. Visits to the GitHub CoPilot free trial signup page more than tripled from February to March, topping 800,000.

An anonymous reader quotes a report from TechCrunch: Google is launching a new AI-powered coding bot for Android developers. During its I/O event on Wednesday, Google announced that the tool, called Studio Bot, will help developers build apps by generating code, fixing errors, and answering questions about Android. According to Google, the bot is built on Codey, the company's new foundational coding model that stems from its updated PaLM 2 large language model (LLM). Studio Bot supports both the Kotlin and Java programming languages and will live directly in the toolbar on Android Studio. There, developers can get quick answers to their questions or even have the bot debug a portion of their code.

While Google notes that developers don't need to share their source code with Google in order to use Studio Bot, the company will receive data on the conversations they have with the tool. Google says the bot is still in "very early days" but that it will continue training it to improve its answers. It's also currently only available to developers in the US for now via the Canary channel, and there's no word on when it will see a global launch.

For 16 years, Rik Farrow has been an editor for the long-running nonprofit Usenix. He's also been a consultant for 43 years (according to his biography at Usenix.org) — and even wrote the 1988 book Unix System Security: How to Protect Your Data and Prevent Intruders.

Today Farrow stopped by Slashdot to share his thoughts on Codon. rikfarrow writes: Researchers at MIT decided to build a compiler focused on speeding up genomics processing... Recently, they have posted their code on GitHub, and I gave it a test drive.
"Managed" languages produce code for a specific runtime (like JavaScript). Now Farrow's article at Usenix.org argues that Codon produces code "much faster than other managed languages, and in some cases faster than C/C++."

Codon-compiled code is faster because "it's compiled, variables are typed at compile time, and it supports parallel execution." But there's some important caveats: The "version of Python" part is actually an important point: the builders of Codon have built a compiler that accepts a large portion of Python, including all of the most commonly used parts — but not all... Duck typing means that the Codon compiler uses hints found in the source or attempts to deduce them to determine the correct type, and assigns that as a static type. If you wanted to process data where the type is unknown before execution, this may not work for you, although Codon does support a union type that is a possible workaround. In most cases of processing large data sets, the types are known in advance so this is not an issue...

Codon is not the same as Python, in that the developers have not yet implemented all the features you would find in Python 3.10, and this, along with duck typing, will likely cause problems if you just try and compile existing scripts. I quickly ran into problems, as I uncovered unsupported bits of Python, and, by looking at the Issues section of their Github pages, so have other people.

Codon supports a JIT feature, so that instead of attempting to compile complete scripts, you can just add a @codon.jit decorator to functions that you think would benefit from being compiled or executed in parallel, becoming much faster to execute...

Whether your projects will benefit from experimenting with Codon will mean taking the time to read the documentation. Codon is not exactly like Python. For example, there's support for Nvidia GPUs included as well and I ran into a limitation when using a dictionary. I suspect that some potential users will appreciate that Codon takes Python as input and produces executables, making the distribution of code simpler while avoiding disclosure of the source. Codon, with its LLVM backend, also seems like a great solution for people wanting to use Python for embedded projects.

My uses of Python are much simpler: I can process millions of lines of nginx logs in seconds, so a reduction in execution time means little to me. I do think there will be others who can take full advantage of Codon.
Farrow's article also points out that Codon "must be licensed for commercial use, but versions older than three years convert to an Apache license. Non-commercial users are welcome to experiment with Codon."

"I write all novel client-side code as JavaScript instead of TypeScript, and it's a delight," says the creator of Ruby on Rails. Posting on Twitter, David Heinemeier Hansson opined that TypeScript "sucked out much of the joy I had writing JavaScript. I'm forever grateful that Yukihiro 'Matz' Matsumoto didn't succumb to the pressure of adding similar type hints to Ruby."

When it comes to static vs dynamic typing, "I've heard a million arguments from both sides throughout my entire career," Hansson wrote on his blog today, "but seen very few of them ever convinced anyone of anything."

But wait — he thinks we can all get along: Personally, I'm unashamedly a dynamic typing kind of guy. That's why I love Ruby so very much. It takes full advantage of dynamic typing to allow the poetic syntax that results in such beautiful code. To me, Ruby with explicit, static typing would be like a salad with a scoop of ice cream. They just don't go together.

I'll also confess to having embraced the evangelical position for dynamic typing in the past. To the point of suffering from a One True Proposition affliction. Seeing the lack of enthusiasm for dynamic typing as a reflection of missing education, experience, or perhaps even competence.

Oh what folly. Like trying to convince an introvert that they'd really like parties if they'd just loosen up a bit...

These days, I've come to appreciate the magnificence of multiplicity. Programming would be an awful endeavor if we were all confined to the same paradigm. Human nature is much too varied to accept such constraint on its creativity...But it took a while for me to come to these conclusions. I'm a recovering solutionist. So when I see folks cross their heart in disbelief that anyone, anywhere might fancy JavaScript over TypeScript, I smile, and I remember the days when I'd recognize their zeal in the mirror.
Hansson also sees the "magnificence of multiplicity" in positions about functional vs object-oriented programming. "Poles on both these axes have shown to deliver excellent software over the decades (and awful stuff too!)."

While working at Apple, Chris Lattner designed Swift to "fully leverage the power of LLVM," and "led a team for a while at Google to try to move Swift out of its Apple comfort zone, to become a replacement for Python in AI model development." That's according to a blog post by Jeremy Howard, an advisor to Lattner's Modular AI (which he co-founded in 2022 to build a next-generation AI platform for developers).

"But sadly," Howard writes, Swift "did not receive the support it needed from either Apple or from Google, and it was not ultimately successful." And yet... [W]hilst at Google Chris did develop another project which became hugely successful: MLIR. MLIR is a replacement for LLVM's intermediate representation [or IR] for the modern age of many-core computing and AI workloads. It's critical for fully leveraging the power of hardware like GPUs, TPUs, and the vector units increasingly being added to server-class CPUs.

So, if Swift was "syntax sugar for LLVM", what's "syntax sugar for MLIR"? The answer is: Mojo! Mojo is a brand new language that's designed to take full advantage of MLIR. And also Mojo is Python.

Wait what?

OK let me explain. Maybe it's better to say Mojo is Python++. It will be (when complete) a strict superset of the Python language. But it also has additional functionality so we can write high performance code that takes advantage of modern accelerators...

Whereas Swift was a brand new language packing all kinds of cool features based on latest research in programming language design, Mojo is, at its heart, just Python. This seems wise, not just because Python is already well understood by millions of coders, but also because after decades of use its capabilities and limitations are now well understood. Relying on the latest programming language research is pretty cool, but its potentially-dangerous speculation because you never really know how things will turn out...

A key trick in Mojo is that you can opt in at any time to a faster "mode" as a developer, by using "fn" instead of "def" to create your function. In this mode, you have to declare exactly what the type of every variable is, and as a result Mojo can create optimised machine code to implement your function. Furthermore, if you use "struct" instead of "class", your attributes will be tightly packed into memory, such that they can even be used in data structures without chasing pointers around. These are the kinds of features that allow languages like C to be so fast, and now they're accessible to Python programmers too — just by learning a tiny bit of new syntax...

I can't begin to describe all the little (and big!) ideas throughout Mojo's design and implementation — it's the result of Chris and his team's decades of work on compiler and language design and includes all the tricks and hard-won experience from that time — but what I can describe is an amazing result that I saw with my own eyes.
Mojo hasn't been released to the public yet, (other than an online "playground" with a waitlist where they're "rolling out access slowly.") But the blog post notes that creating a programming language's syntax is usually complex, error-prone, and controversial — a problem Mojo neatly avoids by "outsourcing" its syntax to an existing language, "which also happens to be the most widely used language today."

And "As a compiled language, Mojo's deployment story is basically the same as C," the post argues. [That is, "you can literally just make the compiled program available for direct download. It can be just 100k or so in size, and will launch and run quickly."]

"This means that Mojo is far more than a language for AI/ML applications. It's actually a version of Python that allows us to write fast, small, easily-deployed applications that take advantage of all available cores and accelerators!"

Python 3.12 was released today, with improvements to speed and efficiency, reports InfoWorld. Core developers explained the improvements at this year's PyCon convention in Salt Lake City, Utah, including efforts to reduce Python's memory use, make the interpreter faster, and optimize compilation for more efficient code: Subinterpreters is a mechanism where the Python runtime can have multiple interpreters running together inside a single process, as opposed to each interpreter being isolated in its own process (the current multiprocessing mechanism)... While subinterpreters have been available in the Python runtime for some time now, they haven't had an interface for the end user. Also, the messy state of Python's internals hasn't allowed subinterperters to be used effectively. With Python 3.12, core python developer Eric Snow and his cohort cleaned up Python's internals enough to make subinterpreters useful, and they are adding a minimal module to the Python standard library called interpreters. This gives programmers a rudimentary way to launch subinterpreters and execute code on them.

Snow's own initial experiments with subinterpreters significantly outperformed threading and multiprocessing. One example, a simple web service that performed some CPU-bound work, maxed out at 100 requests per second with threads, and 600 with multiprocessing. But with subinterpreters, it yielded 11,500 requests, and with little to no drop-off when scaled up from one client. The interpreters module has very limited functionality right now, and it lacks robust mechanisms for sharing state between subinterpreters. But Snow believes by Python 3.13 a good deal more functionality will appear, and in the interim developers are encouraged to experiment...

Python 3.11 introduced new bytecodes to the interpreter, called adaptive instructions. These instructions can be replaced automatically at runtime with versions specialized for a given Python type, a process called quickening. This saves the interpreter the step of having to look up what types the objects are, speeding up the whole process enormously. For instance, if a given addition operation regularly takes in two integers, that instruction can be replaced with one that assumes the operands are both integers... Python 3.12 has more adaptive specialization opcodes...
And starting with Python 3.12, object headers now use 96 bytes, which InfoWorld reports is "slightly less than half of what it was before."

AI startup Hugging Face and ServiceNow Research, ServiceNow's R&D division, have released StarCoder, a free alternative to code-generating AI systems along the lines of GitHub's Copilot. From a report: Code-generating systems like DeepMind's AlphaCode; Amazon's CodeWhisperer; and OpenAI's Codex, which powers Copilot, provide a tantalizing glimpse at what's possible with AI within the realm of computer programming. Assuming the ethical, technical and legal issues are someday ironed out (and AI-powered coding tools don't cause more bugs and security exploits than they solve), they could cut development costs substantially while allowing coders to focus on more creative tasks.

According to a study from the University of Cambridge, at least half of developers' efforts are spent debugging and not actively programming, which costs the software industry an estimated $312 billion per year. But so far, only a handful of code-generating AI systems have been made freely available to the public -- reflecting the commercial incentives of the organizations building them (see: Replit). StarCoder, which by contrast is licensed to allow for royalty-free use by anyone, including corporations, was trained on over 80 programming languages as well as text from GitHub repositories, including documentation and programming notebooks. StarCoder integrates with Microsoft's Visual Studio Code code editor and, like OpenAI's ChatGPT, can follow basic instructions (e.g., "create an app UI") and answer questions about code.

Phoronix reports: With the financial backing of Amazon Web Services, sudo and su are being rewritten in the Rust programming language in order to increase the memory safety for the widely relied upon software... to further enhance Linux/open-source security.
"[B]ecause it's written in C, sudo has experienced many vulnerabilities related to memory safety issues," according to a blog post announcing the project: It's important that we secure our most critical software, particularly from memory safety vulnerabilities. It's hard to imagine software that's much more critical than sudo and su.

This work is being done by a joint team from Ferrous Systems and Tweede Golf with generous support from Amazon Web Services. The work plan is viewable here. The GitHub repository is here.

HackerNoon tested five AI bots on coding problems from Leetcode.com — GPT-4, GitHub Co-Pilot, Bard, Bing, and Claude+.

There's some interesting commentary on the strengths and weaknesses of each one -- and of course, the code that they ultimately output. The final results? [GPT-4's submission] passes all tests. It beat 47% of submissions on runtime and 8% on memory. GPT-4 is highly versatile in generating code for various programming languages and applications. Some of the caveats are that it takes much longer to get a response. API usage is also a lot more expensive and costs could ramp up quickly. Overall it got the answer right and passed the test.

[Bing's submission] passed all the tests. It beat 47% of submissions on runtime and 37% on memory. This code looks a lot simpler than what GPT-4 generated. It beat GPT-4 on memory and it used less code! Bing seems to have the most efficient code so far, however, it gave a very short explanation of how it solved it. Nonetheless, best so far.
But both Bard and Claude+ failed the submission test (badly), while GitHub Copilot "passes all the tests. It scored better than 30% of submissions on runtime and 37% on memory."

Long-time software engineer Blake1024 (Slashdot reader #846,727) writes: We are thrilled to announce the release of Kiss v2.0, a comprehensive, Java-based, open-source, full-stack web development framework... Kiss v2.0 provides an even more seamless, out-of-the-box experience, including pre-configured front-end and back-end components... Key Features:

* Custom HTML controls
* RESTful web services
* Microservices architecture
* Built-in authentication
* SQL API integration
* Robust reporting capabilities

Kiss utilizes microservices, allowing developers to work on a running system without the need for rebuilds, redeploys, or server reboots... Production systems can be updated without any downtime.

With proven success in commercial applications, Kiss v2.0 is ready for prime time. It's not a beta, but a reliable solution for your web development needs.

Jules Wang from Android Police reports on the cases of two icon pack artists who had their products taken down from the Play Store for supposedly violating the platform's Repetitive Content policy. Despite both creators' products being reinstated, they revealed that Google's opaque application of its rules has caused frustration and hopelessness among developers. From the report: All this heartache stems from Google Play's Repetitive Content policy. While on its face a well-meaning effort to reduce spammy apps and keep quality up, there's a core problem with compliance when creators find themselves forced to use apps to distribute content: "If these apps are each small in content volume, developers should consider creating a single app that aggregates all the content."

If you've browsed on the Play Store, you'll immediately know this guidance isn't universally followed: many artists like JustNewDesigns will have multiple designs in their portfolio and each of those designs will come in multiple colorways or shapeways -- whether they're changing out an accent in a line design or are implementing some sort of adaptive element.

Not only are there so many apps, but they also look so much alike -- artists, many of whom might not consider coding their strong suit, tend to use open-source templates to create the actual app. You'll likely see them credited to Sarsa Murmu, who runs a GitHub project called CandyBar, or Jahir Fiquitiva, the maintainer of the Blueprint repository. These resources take care of the "packaging" for the assets. They include integration compatibility with various popular launchers, a license scheme to prevent those who sideloaded the app for free from having the icons applied, and all sorts of other functionality. In addition to the icon assets, the apps may also house wallpapers and links to other apps. [...] What is Google's role and what should it be? Wang writes: Artists would have much to gain from a new or revised API. Adding and adapting new icon designs to existing products would be much easier. New designs may be able to take advantage of changes to the Adaptive Icons API as Google lays them out. There would be unease as to how the business model could shift -- should publishers charge by the app, through in-app purchases, or both? But as it stands, the biggest benefit with such a change is that it would presumably get Play's "RoboCops" off their back. Of course, we can't be sure of that with how Google's enforcement apparatus operates, but the notion of unfairness lends credibility to those supporting the status quo unless the company is willing to come to the bargaining table.

At the end of the day, Google is certainly within its right to build regulations around apps to respond to emergent scammers and distressing content. Automation is meant to render manageable the sheer volume of content the Play platform sees published on a daily basis. But so long as icon artists sit under threat from a rulebook that can be arbitrarily thrown at them at any time, if nothing changes, we may be on a road leading to the degradation of a core Android tenet that even the most casual tech consumer associates with the platform -- user customizability.

Last year Python's massive PyPI repository of pre-written software packages had 235.7 billion downloads — a 57% annual growth in its download counts and bandwidth. So now Python's nonprofit Python Software Foundation has an announcement.

Their director of infrastructure said today that they're rolling out "the first step in our plan to build financial support and long-term sustainability of PyPI, while simultaneously giving our users one of our most requested features: organization accounts." Organizations on PyPI are self-managed teams, with their own exclusive branded web addresses. Our goal is to make PyPI easier to use for large community projects, organizations, or companies who manage multiple sub-teams and multiple packages.

We're making organizations available to community projects for free, forever, and to corporate projects for a small fee. Additional priority support agreements will be available to all paid subscribers, and all revenue will go right back into PyPI to continue building better support and infrastructure for all our users... Having more people using and contributing to Python every year is an fantastic problem to have, but it is one we must increase organizational capacity to accommodate. Increased revenue for PyPI allows it to become a staffed platform that can respond to support requests and attend to issues in a timeframe that is significantly faster than what our excellent (but thinly spread) largely volunteer team could reasonably handle.

We want to be very clear — these new features are completely optional. If features for larger projects don't sound like something that would be useful to you as a PyPI maintainer, then there is no obligation to create an organization and absolutely nothing about your PyPI experience will change for you.

We look forward to discussing what other features PyPI users would like to see tackled next...

Long-time Slashdot reader theodp writes: According to Google Trends, peak "Lean to Code" occurred in early 2019 when laid-off Buzzfeed and Huffpost journalists were taunted with the phrase on Twitter... As Meta founder and CEO Mark Zuckerberg recently put it, "We're in a different world." Indeed. Encouraging kids to pursue CS careers in Code.org's viral 2013 launch video, Zuckerberg explained, "Our policy at Facebook is literally to hire as many talented engineers as we can find."

In Learning to Code Isn't Enough, a new MIT Technology Review article, Joy Lisi Rankin reports on the long history of learn-to-code efforts, which date back to the 1960s. "Then as now," Lisi Rankin writes, "just learning to code is neither a pathway to a stable financial future for people from economically precarious backgrounds nor a panacea for the inadequacies of the educational system."
But is that really true? Vox does note that the latest round of layoffs at Meta "is impacting workers in core technical roles like data scientists and software engineers — positions once thought to be beyond reproach." Yet while that's also true at other companies, those laid-off tech workers also seem to be finding similar positions by working in other industries: Software engineers were the most overrepresented position in layoffs in 2023, relative to their employment, according to data requested by Vox from workforce data company Revelio Labs. Last year, when major tech layoffs first began, recruiters and customer success specialists experienced the most outsize impact. So far this year, nearly 20 percent of the 170,000 tech company layoffs were software engineers, even though they made up roughly 14 percent of employees at these companies. "Early layoffs were dominated by recruiters, which is forgoing future hiring," Revelio senior economist Reyhan Ayas told Vox. "Whereas in 2023 we see a shift toward more core engineering and software engineering, which signals a change in focus of current business priorities."

In other words, tech companies aren't just trimming the fat by firing people who fill out their extensive ecosystem, which ranges from marketers to massage therapists. They're also, many for the first time, making cuts to the people who build the very products they're known for, and who enjoyed a sort of revered status since they, like the founders of the companies, were coders. Software engineers are still important, but they don't have the power they used to...

The latest monthly jobs report by tech industry association CompTIA found that even though employment at tech companies (which includes all roles at those companies) declined slightly in March, employment in technical occupations across industry sectors increased by nearly 200,000 positions. So even if tech companies are laying off tech workers, other industries are snatching them up. Unfortunately for software engineers and the like, that means they might also have to follow those industries' pay schemes. The average software engineer base pay in the US is $90,000, according to PayScale, but can be substantially higher at tech firms like Facebook, where such workers also get bonuses and stock options.

The Rust team released a new version Thursday — Rust 1.69.0 — boasting over over 3,000 new commits from over 500 contributors.

Phoronix highlights two new improvements: In order to speed-up compilation speeds, Rust 1.69 and moving forward debug information is no longer included in build scripts by default. Cargo will avoid emitting debug information in build scripts by default — leading to less informative backtraces in build scripts when problems arise, but faster build speeds by default. Those wanting the debug information emitted can now set the debug flag in their Cargo.toml configuration.

The Cargo build shipped by Rust 1.69 is also now capable of suggesting fixes automatically for some of the generated warnings. Cargo will also suggest using "cargo fix" / "cargo clippy --fix" when it knows the errors can be automatically fixed.

"The Rust Foundation on Monday apologized for confusion caused by the organization's proposed trademark policy changes," reports the Register.

The Foundation now says their proposed policy "clearly needs improvement" and "there are many valid critiques of the initial draft," promising to address them and adopt a more transparent process (with a report summarizing the feedback soon). From the Register's report: The foundation, which provides financial and legal support for the memory-safe programming language, had proposed fresh rules on the use of the word Rust and its logo, which included the recommendation that people not use 'Rust' in their Rust crate names, eg: vulture-rs would be preferred over vulture-rust. These draft changes triggered a backlash... Over the weekend, Rust creator Graydon Hoare voiced support for the community's objections in a Reddit discussion thread, in response to a post by programmer Andrew Gallant, a former member of the Rust moderation team, who argued the new policy was not all that different from the old one.

"Open them up side by side — old and new — and look at what they each say about, specifically, package names, project names, repos or websites using the word 'rust', or modified versions of the logo used for small groups or projects," wrote Hoare. "These are specifically the things people are upset about, because they all changed from 'acceptable' to 'prohibited' when 'clarifying' the policy. And those are specifically things that everyone in the community does, and has done, for years. There are zillions of packages, projects, repos, websites and groups using the names and logo this way, as the old policy said they could. The new policy tells them all to stop."
Long-time open source advocate Bruce Perens told the Register that Rust's trademark policy "goes far awry of fair use which is legally permitted. Books on Rust will always have its name in their title, commercial products will be advertised as being written in Rust, being compatible with Rust, or compiling Rust. But the policy attempts to deny permission for these things. A proper trademark policy prevents others from representing that their product is Rust or is endorsed by the trademark holder of Rust. That's really as much as you can ever enforce, so there's no sense in a policy that asks for more."

The Register also spoke to Ashley Williams, a former member of the Rust core team and the original executive director and founder of the Rust Foundation, who argued upheaval in Rust's governance over the past year led to a team with less experience dealing with the Rust community. "I think a couple of very passionate people participated in the trademark working group and they didn't involve a lot of people who have even basic experience interacting with the community. So really classic community behaviors ended up getting prohibited in that [draft] policy. And that's really why everybody got upset. The policy ultimately said, 'a thing that you do all the time as a way of contributing to the Rust community is now against our policy.'"

ChatGPT, OpenAI's large language model for chatbots, not only produces mostly insecure code but also fails to alert users to its inadequacies despite being capable of pointing out its shortcomings. The Register reports: Amid the frenzy of academic interest in the possibilities and limitations of large language models, four researchers affiliated with Universite du Quebec, in Canada, have delved into the security of code generated by ChatGPT, the non-intelligent, text-regurgitating bot from OpenAI. In a pre-press paper titled, "How Secure is Code Generated by ChatGPT?" computer scientists Raphael Khoury, Anderson Avila, Jacob Brunelle, and Baba Mamadou Camara answer the question with research that can be summarized as "not very."

"The results were worrisome," the authors state in their paper. "We found that, in several cases, the code generated by ChatGPT fell well below minimal security standards applicable in most contexts. In fact, when prodded to whether or not the produced code was secure, ChatGPT was able to recognize that it was not." [...] In all, ChatGPT managed to generate just five secure programs out of 21 on its first attempt. After further prompting to correct its missteps, the large language model managed to produce seven more secure apps -- though that's "secure" only as it pertains to the specific vulnerability being evaluated. It's not an assertion that the final code is free of any other exploitable condition. [...]

The academics observe in their paper that part of the problem appears to arise from ChatGPT not assuming an adversarial model of code execution. The model, they say, "repeatedly informed us that security problems can be circumvented simply by 'not feeding an invalid input' to the vulnerable program it has created." Yet, they say, "ChatGPT seems aware of -- and indeed readily admits -- the presence of critical vulnerabilities in the code it suggests." It just doesn't say anything unless asked to evaluate the security of its own code suggestions.

Initially, ChatGPT's response to security concerns was to recommend only using valid inputs -- something of a non-starter in the real world. It was only afterward, when prompted to remediate problems, that the AI model provided useful guidance. That's not ideal, the authors suggest, because knowing which questions to ask presupposes familiarity with specific vulnerabilities and coding techniques. The authors also point out that there's ethical inconsistency in the fact that ChatGPT will refuse to create attack code but will create vulnerable code.

The Linux Foundation, the nonprofit tech consortium that manages various open source efforts, today announced the launch of the TLA+ Foundation to promote the adoption and development of the TLA+ programming language. AWS, Oracle and Microsoft are among the inaugural members. From a report: What is the TLA+ programming language, you ask? It's a formal "spec" language developed by computer scientist and mathematician Leslie Lamport. Best known for his seminal work in distributed systems, Lamport -- now a scientist at Microsoft Research -- created TLA+ to design, model, document and verify software programs -- particularly those of the concurrent and distributed variety.

To give a few examples, ElasticSearch, the organization behind the search engine of the same name, used TLA+ to verify the correctness of their distributed systems algorithms. Elsewhere, Thales, the electrical systems manufacturing firm, used TLA+ to model and develop fault-tolerant modules for its industrial control platform. "TLA+ is unique in that it's intended for specifying a system, rather than for implementing software," a Linux Foundation spokesperson told TechCrunch via email. "Based on mathematical concepts, notably set theory and temporal logic, TLA+ allows for the expression of a system's desired correctness properties in a formal and rigorous manner."

Apple in iOS 17 will for the first time allow iPhone users to download apps hosted outside of its official App Store, according to Bloomberg's Mark Gurman. From a report: Otherwise known as sideloading, the change would allow customers to download apps without needing to use the App Store, which would mean developers wouldn't need to pay Apple's 15 to 30 percent fees. The European Union's Digital Markets Act (DMA), which went into effect on November 1, 2022, requires "gatekeeper" companies to open up their services and platforms to other companies and developers. The DMA will have a big impact on Apple's platforms, and it could result in Apple making major changes to the App Store, Messages, FaceTime, Siri, and more. Apple is planning to implement sideloading support to comply with the new European regulations by next year, according to Gurman.