The PyPI blog: In March and April 2023, the Python Software Foundation (PSF) received three (3) subpoenas for PyPI user data. All three subpoenas were issued by the United States Department of Justice. The PSF was not provided with context on the legal circumstances surrounding these subpoenas. In total, user data related to five (5) PyPI usernames were requested. The data request was:

"Names (including subscriber names, user names, and screen names);"
"Addresses (including mailing, residential addresses, business addresses, and email addresses);"
"Connection records;"
"Records of session times and durations, and the temporarily assigned network address (such as Internet Protocol addresses) associated with those sessions;"
"Length of service (including start date) and type of services utilized;"
"Telephone or instrument numbers (including the registration Internet Protocol address);"
"Means and source of payment of any such services (including any credit card or bank account number) and billing records;"
"Records of all Python Package Index (PyPI) packages uploaded by..." given usernames
"IP download logs of any Python Package Index (PyPI) packages uploaded by..." given usernames

The privacy of PyPI users is of utmost concern to PSF and the PyPI Administrators, and we are committed to protecting user data from disclosure whenever possible. In this case, however, PSF determined with the advice of counsel that our only course of action was to provide the requested data. I, as Director of Infrastructure of the Python Software Foundation, fulfilled the requests in consultation with PSF's counsel.

We have waited for the string of subpoenas to subside, though we were committed from the beginning to write and publish this post as a matter of transparency, and as allowed by the lack of a non-disclosure order associated with the subpoenas received in March and April 2023.

On Saturday PyPI, the official third-party registry of open source Python packages, "temporarily suspended new users from signing up, and new projects from being uploaded to the platform" reports BleepingComputer.

"The volume of malicious users and malicious projects being created on the index in the past week has outpaced our ability to respond to it in a timely fashion, especially with multiple PyPI administrators on leave," stated an incident notice posted by PyPI admins Saturday.

Hours ago they posted a four-word update: "Suspension has been lifted." No details were provided, but The Hacker News writes the incident "comes as software registries such as PyPI have proven time and time again to be a popular target for attackers looking to poison the software supply chain and compromise developer environments." Earlier this week, Israeli cybersecurity startup Phylum uncovered an active malware campaign that leverages OpenAI ChatGPT-themed lures to bait developers into downloading a malicious Python module capable of stealing clipboard content in order to hijack cryptocurrency transactions. ReversingLabs, in a similar discovery, identified multiple npm packages named nodejs-encrypt-agent and nodejs-cookie-proxy-agent in the npm repository that drops a trojan called TurkoRat.

Google Colab hosts free cloud-based "executable documents" that, among other things, let you write and run code in your browser (in dozens of languages, including Python).

Over 7 million people, including students, already use Colab, according to a recent post on Google's blog, "and now it's getting even better with advances in AI [with] features like code completions, natural language to code generation and even a code-assisting chatbot."

Google says it will "dramatically increase programming speed, quality, and comprehension." Our first features will focus on code generation. Natural language to code generation helps you generate larger blocks of code, writing whole functions from comments or prompts. [For example: "import data.csv as a dataframe."] The goal here is to reduce the need for writing repetitive code, so you can focus on the more interesting parts of programming and data science. Eligible users in Colab will see a new "Generate" button in their notebooks, allowing them to enter any text prompt to generate code.

For eligible paid users, as you type, you'll see autocomplete suggestions.

We're also bringing the helpfulness of a chatbot directly into Colab. Soon, you'll be able to ask questions directly in Colab like, "How do I import data from Google Sheets?" or "How do I filter a Pandas DataFrame?"

Anyone with an internet connection can access Colab, and use it free of charge... Access to these features will roll out gradually in the coming months, starting with our paid subscribers in the U.S. and then expanding into the free-of-charge tier.
It's powered by Google's "next generation" machine-learning language model PaLM 2 (announced earlier this month), which "excels at popular programming languages like Python and JavaScript, but can also generate specialized code in languages like Prolog, Fortran and Verilog." Colab will use Codey, a family of code models built on PaLM 2... fine-tuned on a large dataset of high quality, permissively licensed code from external sources to improve performance on coding tasks. Plus, the versions of Codey being used to power Colab have been customized especially for Python and for Colab-specific uses.

An anonymous reader quotes a report from Bloomberg: A trash can overflowing with disposable drink cups is an all-too-familiar sight outside any high-traffic cafe or fast-food joint. It was during a lunch-time walk in Melbourne that colleagues Aniyo Rahebi and Catherine Hutchins passed by several such eyesores and decided to combat the piles of waste. A few months later they arrived at an idea: a to-go cup that can be eaten. After hundreds of hours in the kitchen refining their concept, the duo took it to market. Their startup Good-Edi now offers an edible, biodegradable, plastic-free alternative to the standard polyethylene-lined paper cups used for coffee that largely end up in landfills or gets incinerated.

The company raised about $98,000 through a crowd-funding site in 2021, and its baking team currently produces about 500 cups a day for clients across Australia, including coffee shops, roasteries and concert venues, from a facility in a suburb of Melbourne. Good-Edi aims to boost output and expand sales internationally this year. The world goes through more than 250 billion plastic-lined paper drink cups every year, according to the United Nations Environment Programme. Only about 1% of those cups are recycled. Good-Edi says about 2.7 million disposable cups find their way to landfills each day in Australia.

Good-Edi's product works for both for hot drinks like coffee and tea as well as cold drinks. After about 250 recipe adjustments, the founders settled on a blend of rye flour, wheat bran, oat bran, sugar, salt, coconut oil and water. They say their container stays crispy holding a hot cup of joe for about 40 minutes and won't leak a cold beverage for about eight hours. For Hutchins and Rahebi, who have a combined 20 years experience in the food-processing and packaging sectors, Good-Edi is still a side hustle. They are banking on shifting consumer sentiment and a beverage industry under pressure to offer more sustainable to-go options to drive sales and compensate for the fact that their containers can increase the cost of a cup of takeaway coffee by A$1. "Will coffee drinkers be keen to gobble up the company's innovation, if it doesn't feel like a treat?" asks a Bloomberg Businessweek reporter that says the cup tasted like an unsweetened wheat biscuit.

Mojo is a new programming language developed by Modular1 that aims to address the performance and deployment limitations of Python in areas like AI model development. After demoing Mojo prior to its launch, Jeremy Howard from the non-profit research group fast.ai said it feels like coding will never be the same again. Here's an excerpt from Howard's article: Modular is a fairly small startup that's only a year old, and only one part of the company is working on the Mojo language. Mojo development was only started recently. It's a small team, working for a short time, so how have they done so much? The key is that Mojo builds on some really powerful foundations. Very few software projects I've seen spend enough time building the right foundations, and tend to accrue as a result mounds of technical debt. Over time, it becomes harder and harder to add features and fix bugs. In a well designed system, however, every feature is easier to add than the last one, is faster, and has fewer bugs, because the foundations each feature builds upon are getting better and better. Mojo is a well designed system.

At its core is MLIR (Multi-Level Intermediate Representation), which has already been developed for many years, initially kicked off by Chris Lattner at Google. He had recognized what the core foundations for an "AI era programming language" would need, and focused on building them. MLIR was a key piece. Just as LLVM made it dramatically easier for powerful new programming languages to be developed over the last decade (such as Rust, Julia, and Swift, which are all based on LLVM), MLIR provides an even more powerful core to languages that are built on it. Another key enabler of Mojo's rapid development is the decision to use Python as the syntax. Developing and iterating on syntax is one of the most error-prone, complex, and controversial parts of the development of a language. By simply outsourcing that to an existing language (which also happens to be the most widely used language today) that whole piece disappears! The relatively small number of new bits of syntax needed on top of Python then largely fit quite naturally, since the base is already in place.

The next step was to create a minimal Pythonic way to call MLIR directly. That wasn't a big job at all, but it was all that was needed to then create all of Mojo on top of that -- and work directly in Mojo for everything else. That meant that the Mojo devs were able to "dog-food" Mojo when writing Mojo, nearly from the very start. Any time they found something didn't quite work great as they developed Mojo, they could add a needed feature to Mojo itself to make it easier for them to develop the next bit of Mojo! You can give Mojo a try here.

Serverless JavaScript is hosted in an edge network or by an HTTP caching service (and only runs when requested), explains Cloudflare. "Developers can write and deploy JavaScript functions that process HTTP requests before they travel all the way to the origin server."

Their platform for serverless JavaScript will soon have built-in AI features, Cloudflare's CTO announced today, "so that developers have a rich toolset at their disposal. A developer platform without AI isn't going to be much use. It'll be a bit like a developer platform that can't do floating point arithmetic, or handle a list of data. We're going to see every developer platform have AI capability built in because these capabilities will allow developers to make richer experiences for users...

As I look back at 40 years of my programming life, I haven't been this excited about a new technology... ever. That's because AI is going to be a pervasive change to how programs get written, who writes programs and how all of us interact with software... I think it'll make us more productive and make more people programmers.
But in addition, developers on the platform will also be able to train and upload their own models to run on Cloudflare's global network: Unlike a database where data might largely be stored and accessed infrequently, AI systems are alive with moving data. To accommodate that, platforms need to stop treating data as something to lock in developers with. Data needs to be free to move from system to system, from platform to platform, without transfer fees, egress or other nonsense. If we want a world of AI, we need a world of data fluidity.

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