Any devs that find the visuals, keyboard driven workflow, or cult of DHH appealing enough to try Omarchy are likely already Linux users.
Linux has been a great platform for devs for a long time. This is exactly why WSL exists, and why MacOS has a native Linux container[1] tool.. because Linux was eating their lunch in this user segment.
I've been using MacOS as my daily driver for 20 years exactly because it had the best mix of (what I used to say a while back), "Linux that works, and ain't ugly"
OrbStack has solved all the issues I had with running containers on macOS. It's just a wonderful piece of software that just works. (Not arguing vs container, just specifying another option)
It's really not Linux though. You don't get a modern GNU userland, or even a modern bash without having to brew install a bunch of stuff. You don't get the networking capabilities. You don't get a well tested and stable ZFS implementation. And Orbstack may be great but it still has to run a VM and a Linux kernel under the hood to run all your containers.
For some, the Mac hardware or familiarity with the MacOS UI justifies these downsides. Personally, I'll take my Framework 13 with real actual Linux (Fedora workstation) every time :)
> but for ordinary work you're better off using gunicorn
I'd like to see some evidence for this. Other than simplicity, IMO there's very little reason to use synchronous Python for a web server these days. Streaming files, websockets, etc. are all areas where asyncio is almost a necessity (in the past you might have used twisted), to say nothing of the performance advantage for typical CRUD workloads. The developer ergonomics are also much better if you have to talk to multiple downstream services or perform actions outside of the request context. Needing to manage a thread pool for this or defer to a system like Celery is a ton more code (and infrastructure, typically).
> async i/o solutions are all single threaded
And your typical gunicorn web server is single threaded as well. Yes you can spin up more workers (processes), but you can also do that with an asgi server and get significantly higher performance per process / for the same memory footprint. You can even use uvicorn as a gunicorn worker type and continue to use it as your process supervisor, though if you're using something like Kubernetes that's not really necessary.
Agree to disagree. Monkey patching the stdlib is a terrible hack and having to debug non-trivial gevent apps is a nightmare (not that asyncio apps are perfect either).
Can't agree more. We were using pyenv+poetry before and regularly had to pin our poetry version to a specific one, because new poetry releases would stall trying to resolve dependencies.
pyenv was problematic because you needed the right concoction of system packages to ensure it compiled python with the right features, and we have a mix of MacOS and Linux devs so this was often non-trivial.
uv is much faster than both of these tools, has a more ergonomic CLI, and solves both of the issues I just mentioned.
I'm hoping astral's type checker is suitably good once released, because we're on mypy right now and it's a constant source of frustration (slow and buggy).
> because new poetry releases would stall trying to resolve dependencies.
> uv is much faster than both of these tools
conda is also (in)famous for being slow at this, although the new mamba solver is much faster. What does uv do in order to resolve dependencies much faster?
> What does uv do in order to resolve dependencies much faster?
- Representing version numbers as single integer for fast comparison.
- Being implemented in rust rather than Python (compared to Poetry)
- Parallel downloads
- Caching individual files rather than zipped wheel, so installation is just hard-linking files, zero copy (on unix at least). Also makes it very storage efficient.
I'm pretty ignorant about this stuff but I think asyncio is for exactly that, asynchronus I/O. Whereas GIL-less Python would be beneficial for CPU bound programs. My day job is boring so I'm never CPU bound, always IO bound on the database or network. If there is CPU heavy code, it's in Numpy. So I'm not sure if Gil-less actually helps there.
+1 for Syncthing. I've been running it for years, after my student discount for Dropbox expired (Google drive and OneDrive were just getting traction at the time).
The mobile experience last I tried was pretty rough though. I don't really need my files on my phone and I have a web interface on my home server I can use to grab them in a pinch, but it's something to keep in mind.
You are most likely in France: your government does not allow publishing an app containing cryptography (in this case, Golang's crypto implementations and a package used by Syncthing - only using iOS libs should be fine) without authorization (which can only be obtained through French forms, at which point I'd want a French lawyer to be involved, so no).
You could of course build the app yourself from source.
I'm not sure if you're joking, but if not this is a fundamental misunderstanding of how Rust (and C) are used in the kernel.
Much like how you don't have the C stdlib when writing kernel code, Rust is used with the no_std option. You do not use cargo and do not have access to crates.
You'd likely have to rewrite half of tokio to use kernel level abstractions for things like sockets and everything else that interacts with the OS.
reply