How is garage for a simple local dev env ?
I recently used seaweedfs since they have a super simple minimal setup compared to garage which seemed to require a config file just to get started.
Building a framework on a non-async foundation (flask) in 2025 is bizarre.
The only way to scale a flask API is to use gevent, which is just problems waiting to happen. Asyncio is just better, safer and has been adopted by the industry.
I've been thinking about Flask and Quart pretty much interchangeably for awhile now and use Quart for Python backends. For those who aren't aware Quart is the async Flask and they share system internals, it is usually easy to use something created for Flask for Quart.
You're not wrong, but building a new web framework is bizarre to start with, so they might as well do whatever makes them happy so it at least has had some use
I ran into:
- too high memory usage
- no warning when a task doesn't yield
- monkey patching:
* general confusion like threading.local behaving differently
* pain to integrate sentry in gunicorn with gevent since you need to import sentry after monkey patching. The OTel libs work better but you need to be careful
* all compiled libs need to be replaced (eg psycogreen)
...
> Building a framework on a non-async foundation (flask) in 2025 is bizarre.
Assuming that non-blocking sockets require a special language syntax that breaks seamless compositionality of functions is a lack of fundamental knowledge. No wonder you refer to the industry adoption (crowd opinion) in your next sentence, instead of applying the first-principles analysis. In 2025, the expectation is that you should've at least tried learning how Project Loom is implemented, before venturing bold opinions on the async keyword in Python: https://openjdk.org/projects/loom/
> The only way to scale a flask API is to use gevent, which is just problems waiting to happen.
This announcement contains so many fake marketing words I can't help but read it in DJT's voice...
Add Tim Apple's present and yeah, cool tech, not interested.
The main issue is podman support on Ubuntu.
Ubuntu ships outdated podman versions that don't work out of the box.
So I use podman v5, GitHub actions uses podman v3, and my coworkers on Ubuntu use docker.
So now my script must work with old podman, recent podman and docker
Additionally, there aren't even any trusted repos out there building/publishing a .deb for it. The ones that I could find when I searched last were all outdated or indicated they were not going to keep moving forward.
I could get over this. But, IMO, it lends itself to asking the "why" question. Why wouldn't Podman make installing it easier? And the only thing that makes sense to me is that RedHat doesn't want their dev effort supporting their competitor's products.
That's a perfectly reasonable stance, they owe me nothing. But, it does make me feel that anything not in the RH ecosystem is going to be treated as a second-class citizen. That concerns me more than having to build my own debs.
They publish statically-linked binaries on GitHub [0], so to install it, you just need to download and unpack a single file. But you don't get any automatic updates like you would if they provided an apt repository.
Well all the downstream distros have their own installers (apt, dnf, pacman, etc.). If you're compiling from source, then "make install" [0] should work as expected, and if you're downloading the pre-built binaries from GitHub [1], you just need to copy a single statically-linked binary into "/usr/local/bin".
I don't know about this specific case but Debian and or Ubuntu having outdated software is a common Debian/Ubuntu problem which nearly always is cause by Debian/Ubuntu itself (funnily if it's outdated in Ubuntu doesn't mean it's outdated in Debian and the other way around ;=) ).
They can do what Docker and many other software providers do that are committed to cross OS functionality. They could build packages for those OSes. Example:
The install instructions you link to are relying on the OS providers to build/package Podman as part of their OS release process. But that is notoriously out-of-date.
You could argue, "Not Podman's Problem", and, in one sense, you'd be right. But, again, it leads to the question "Why wouldn't they make it their problem like so many other popular projects have?" and I believe I answered that previously.
> cost additional developer time, which for most OSS is fairly limited
Mostly agree. But something like Podman w/ RedHat behind it is unlikely to be limited in the same way a lot of community OSS projects are.
Unfortunately, I disagree with just about every other point you made but don't think it's worth responding point-by-point. In short, I think a project having dedicated builds for popular OSes is a win-win for just about everyone, excepting that it does take, sometimes a considerable amount of, effort to support those cross OS builds. Additionally, there are now options like Snap/Flatpack/AppImage that can be targets instead of the OS itself, although there is admittedly a tradeoff there as well.
For some projects, say something like ripgrep, just using what is in the OS repo is fine because having the latest and greatest features/bug-fixes is unlikely to matter to most people using the tool.
But, on something like Podman, where there is so many pieces, it's a relatively new technology, and the interaction between Kernel, OS, and user space is so high, being stuck with a non-current OS provided release for a couple years is a non-starter.
> why not use a Linux distribution which works with modern software development cycles?
Because I like my OS to be stable, widely supported, and I also like some of my applications to be evergreen. I find Ubuntu is usually a really good mix that way and I'm going on 15+ years of use. There are other solutions for that that I could use, but I'm mostly happy where I am and don't want to spend the kind of time it would take to adopt a different OS and everything that would follow from that.
That leads _me_ to avoid Podman currently. I can appreciate that you have a different opinion, I just think you are a overplaying your perspective a bit in the comment above.
> like Snap/Flatpack/AppImage that can be targets instead of the OS itself [..] ripgrep
sure I agree that where it's easily doable (like e.g. ripgrep) having non distro specific builds is a must have
But sadly this doesn't fully work for podman AFIK as it involves a lot of subtle interactions with things which aren't consistently setup across Linux distros with probably the worst offender being the Linux security modules system (e.g. SELinux, AppArmor etc.). But thinking about probably sooner or later you probably could have a mostly OS independent postman setup (limited to newer OS versions). Or to be more specific 3 one with SELinux one with AppArmor and neither with neither, so I guess maybe not :/
>something like Podman w/ RedHat behind it is unlikely to be limited in the same way a lot of community OSS projects are
exactly. I've built podman for debian. It's not an esoteric target. It gets a little hairy with all of the capabilities stuff and selinux, but it's feasible. Give me, I don't know, $10k a quarter and I'd probably do it.
After many years of "I want stability and evergreen", I finally realized that this is Fedora. Each release is very stable, and they arrive more often than once an eon.
Also on Ubuntu 25.04, which I updated a homeserver too despite it not being LTS just for the easy access to Podman 5. Once Ubuntu 26.04 comes out the pain described by some sibling comments should end. Podman 4 is a workable version but 5.0 is where I'd say it really became a complete replacement for Docker and quadlets fully matured.
Yeah, the lack of an official upstream .deb that is kept up to date (like the official Docker .deb repos) for Ubuntu really kills using podman for most of my internal use cases.
This is my biggest problem too, and it's not just my problem but Podman's problem. Lack of name recognition is big for sure compared to Docker, but to me this version mismatch problem is higher on the list and more sure to keep Podman niche. Distros like Ubuntu always ship with older versions of software, it's sadly up to the maintainer to release newer versions, and Podman just doesn't seem interested in doing that. I don't know if it was their goal but it got me to use some RedHat derivative on my home server just to get a later version.
LTS in general being slow to uptake new versions of software is a feature not a bug. It gives predictability at the cost of having to deal with older versions of software.
With Ubuntu at least, some upstreams publish official PPAs so that you aren't stuck on the rapidly aging versions that Canonical picks when they cut an LTS release.
Debian I found out recently has something similar now via "extrepo".
Since Podman is open source, Ubuntu (and others) are able to package it and and update it themselves if they choose. But I think it's understandable that Red Hat would not want to pay their development teams to package their software for a direct competitor.
Yes! I really like the idea of podman, but after 4 hours trying to make it work on 24.04, I reverted to Docker and compose.
There is some dissonance in presenting Podman as a plug-in replacement for Docker, and making it so damn hard to install on (some category's) most popular contemporary LTS Linux distro.
I had this problem on the latest Pop OS LTS (I know, I know). Took about 4 hours to find the magic incantation that would let me install podman >= 4 without breaking anything else.
That's an Ubuntu issue though, they ship lots of outdated software. Nginx, PHP, PostgreSQL, Podman, etc, the critical software that must be updated asap, even with stable versions they all require a PPA to be properly updated.
You also can't turn off Play Protect if you've enabled Advanced Protection on your account (which also enforces a range of other security measures) but that's fully opt-in and hasn't even been availble to the wide public for all that long.
Wait till you see the cPython stdlib email parser..
Any programming language these days should ship a decent rfc5234 API in the standard library, so you do not get these kinds of problems in slightly different fashion for each and every library/program.
reply