On the flip side, I'm not sure I ever saw a revenue plan or exit strategy for Astral other than acquihire. And most plausible bidders are unfortunate in one way or another.
Astral was building a private package hosting system for enterprise customers. That was their stated approach to becoming profitable, while continuing to fund their open source work.
It's also a crowded and super mature space space between JFrog (Artifactory) and Sonatype (Nexus). They already support private PyPI repositories and are super locked in at pretty much every enterprise-level company out there.
A commodity yes, but could be wrapped in to work very nicely with the latest and greatest in python tooling. Remember, the only 2 ways to make money are by bundling and unbundling. This seems like a pretty easy bundling story.
Yeah you'd think so but somehow JFrog (makers of Artifactory) made half a billion dollars last year. I don't really understand that. Conda also makes an implausible amount of money.
Most of the companies that spend $$$$ with them can't use public registries for production/production-adjacent workloads due to regulations and, secondarily a desire to mitigate supply chain risk.
Artifactory is a drop-in replacement for every kind of repository they'll need to work with, and it has a nice UI. They also support "pass-through" repositories that mirror the public repositories with the customization options these customers like to have. It also has image/artifact scanning, which cybersecurity teams love to use in their remediation reporting.
It's also relatively easy to spin up and scale. I don't work there, but I had to use Artifactory for a demo I built, and getting it up and running took very little time, even without AI assistance.
Yeah I mean I understand the demand. My previous company used Artifactory. I just don't understand why nobody has made a free option. It's so simple it seems like it would be a no brainer open source project.
Like, nobody really pays for web servers - there are too many good free options. They're far more complex than Artifactory.
I guess it's just that it's a product that only really appeals to private companies?
JFrog has a free version. It's called the JFrog Container Registry. Lots of features are missing and you can't use the Artifactory API that it ships with, but it's there.
There are also several free registries out there: Quay, Harbor, and Docker's own distribution. They all have paid versions, of course.
Both Artifactory and Sonatype have somewhat restricted open-source options, which is part of their "get a foot in the door" product-driven sales strategy.
There are no competing open-source projects because such projects would need to provide more value than Artifactory/Sonatype OSS, which are both already huge projects, just to be considered.
From my understanding there are a lot of companies that need their own package repositories, for a variety of reasons. I listened to a couple podcasts where Charlie Marsh outlined their plans for pyx, and why they felt their entry into that market would be profitable. My guess is that OpenAI just dangled way more money in their faces than what they were likely to get from pyx.
Having a private package index gives you a central place where all employees can install from, without having to screen what each person is installing. Also, if I remember right, there are some large AI and ML focused packages that benefit from an index that's tuned to your specific hardware and workflows.
Private artifact repositories also help to mitigate supply chain risk since you can host all of your screened packages and don't have to worry about something getting removed from mvn-central, PyPI, NPM, etc.
Plus the obvious need for a place to host proprietary internal libraries.
> a lot of companies that need their own package repositories
Every company needs its own package repository. You need to be able to control what is running on your environment. Supply-chain risk is very, very real and affects anybody selling software for a living.
This is besides the point that in the real world, not every risk is addressed, at least in part because available resources are diverted to address larger risks.
How many people use that simple pip repo daily? If the number is not in the high hundreds, or a few thousands; maybe nothing. But once you get up there, any kind of better coordination layer is useful enough to pay money to a third party for, unless maintaining a layer over pip is your core competency.
i mean ofc but like you can self-host pypi and the "Docker Hub" model isn't like VC-expected level returns especially as ECR and GHCR and the other repos exist
They could have joined projects like the Linux Foundation which try to not depend on any single donor, even though complete independence from big tech is not possible. I don't know the motivation behind Astral's approach, but this acquisition does leave a weird taste behind about how serious they were about truly open source software. Time will tell, I guess. (Edit: typo)
> I don't know the motivation behind Astral's approach, but this acquisition does leave a weird taste behind about how serious they were about truly open source software.
Well-known vulns are all over this code. For example, mkdir had a TOCTTOU which persisted into v7 (and I believe 2BSD); it was implemented as a setuid binary which did a mknod followed by a chown to create the directory. Code which invoked mkdir could set up a race replacing the root-owned directory, before the chown, with a link to something else -- which would then get chowned to the user running mkdir. The target had to be on the same filesystem as some writable directory, but on many installations of the day, a mkdir in /tmp followed by this race was good enough to get you ownership of /etc/passwd.
This was finally cleaned up in 4.2bsd, when mkdir was made a single syscall which was guaranteed to alter only the particular inode it allocated.
They were already mailing distribution tapes -- the software being run here was extracted off one of them (which had literally been lost in a store room for decades).
Anthropic's ahead of you -- the LLM that the reporters were interacting with here had an AI supervisor, "Seymour Cash", which uh... turned out to have some of the same vulnerabilities, though to a lesser extent. Anthropic's own writeup here describes the setup: https://www.anthropic.com/research/project-vend-2
Ummmm... yes. The problem with versioning file systems is that they only kept the last few versions; for files under active development, it was usually difficult to recover state older than a week or two.
(SCCS handled collaborative development and merges a lot worse than anything current, but... versioning file systems were worse there, too; one war story I heard involved an overenthusiastic developer "revising" someone else's file with enough new versions that by the time the original author came back to it, their last version of the code was unrecoverable.)
According to Wikipedia,there are apps that provide an emulated Android environment ("Easy Abroad", "Droitong"), they're incomplete and glitchy, and a lot of important apps won't run at all (including banking apps and streaming services).
If the libraries were missing entirely, I'm not sure 32-bit Firefox would even start. But if they were present and nothing was keeping them updated (pretty likely on an otherwise 64-bit system), they'd pretty likely become out of date -- which could certainly explain spurious crashes.
Fair point, although Firefox also launches subprocesses, and I don't know if those use same libraries as the main process. And I also don't know if it dynamically loads supporting libs after launch.
People go through all sorts of weird mental gymnastics about this. The FSF at one point took the position that binary blobs were cool so long as they could not be upgraded, because then you could pretend they weren't software at all, but just part of the wiring. I've seen this odd line of thought attributed to RMS himself, but here's an FSF statement, from when he was running it: https://www.fsf.org/blogs/community/task2-openmoko
WASM has a better security sandbox. (Designed in from the beginning, not the thousand-fingers-in-the-dike retrofit that was the Java SecurityManager -- which was eventually deprecated and abandoned along with the Applet tech it was intended to support.)
reply