podman-compose definitely got better over the past year…

But you can also use docker-compose itself with podman instead!

https://www.redhat.com/en/blog/podman-docker-compose

Basically, for system level containers, you can do:

sudo systemctl start podman.socket

(or enable --now instead of start if you want it to stick around after rebooting)

Then use docker-compose and it’ll communicate with podman instead of docker.

For user session “rootless” containers, it’s mainly the same thing, except you’ll need to remove sudo and then add --user after start or enable in that systemctl command. And you’d need to set an environment variable (either prefixing it on the command or using export to set it in your session), like this:

DOCKER_HOST=unix:///run/user/$UID/podman/podman

(Put that in front of the docker-compose command and it’ll connect to podman as your user instead, provided the service is available. Or toss it into your .bashrc with "export " before it and new bash sessions would have it.)

https://brandonrozek.com/blog/rootless-docker-compose-podman/

The one big gotcha I’ve hit is that if you have SELinux on your system, you’ll want to add :z to your volume(s) mount to have it automatically deal with SELinux stuff. (Lowercase z for volumes that can be mounted for multiplayer containers and uppercase Z for volumes that are tied to a specific container.)

But, I’ve found that using “quadlet” service files is much, much better than using podman-compose or docker-compose. There’s a program called “podlet” that can even convert compose files to service files (quadlet)… It can convert command line flags and kubes and other formats too.

Quadlets are basically systems service files that integrate with podman, letting you easily set up a container as a system (or even user level) service, making managing a container just like managing any other service.

Here’s the podlet command that’ll convert things to quadlets: https://github.com/containers/podlet

It certainly is a differentiator: uBlock Origin already works best on Firefox. https://github.com/gorhill/uBlock/wiki/uBlock-Origin-works-best-on-Firefox

And when Manifest v3 is fully enforced in Chromium (current date is slated to be July 2024), then the more restricted uBlock Origin Lite would need to be used instead.

(I’m not sure if Arc will fully adopt v3, but they might not have a choice at some point in time.)

The Lite version still works well considering all the restrictions, but has a lot of limitations: https://github.com/uBlockOrigin/uBlock-issues/issues/338#issuecomment-1507539114

• Filter lists update only when the extension updates (no fetching up to date lists from servers)

• Many filters are dropped at conversion time due to MV3’s limited filter syntax
• No crafting your own filters (thus no element picker)
• No strict-blocked pages
• No per-site switches
• No dynamic filtering
• No importing external lists

TL;DR: The way uBlock Origin works on Firefox right now is already better, but if Arc has to go along with Manifest v3 in Chromium in a few months, then it’ll be even more of a differentiator.

It also looks like they’re even thinking about rolling out their own tracker blocker (instead of using uBlock Origin) as a result of the Manifest v3 changes:

https://www.reddit.com/r/ArcBrowser/wiki/index/#wiki_how_will_arc_handle_the_transition_from_manifest_v2_to_manifest_v3.3F

https://twitter.com/joshm/status/1728926780600508716

We’re rolling our own native @arcinternet Ad & Tracker Blocker in 2024 (since Chrome is restricting them)…

Any creative ideas for how we can go above and beyond, and reimagine the category?

Remove GDPR/Cookie Consents? What else?