A limitation with this setup is you can't let your agent/Linux user run containers with docker. Adding a user to the `docker` group effectively grants the user full root privileges [1], so the secure way is to setup docker in rootless mode. It's doable, but in my experience it's hard to setup (I find it complex with podman as well).
> Until I'm shown otherwise it seems like a good compromise
Agreed. In my case I went a long way running the Pi harness in a (simple, rootfull) docker container. As the project I worked on relied on a standardized docker compose stack for local dev and testing, I realized I could automate more if only my agent could use docker. Ultimately, the need for docker for my agent grew when testcontainer [2] was introduced in the project. That's when I finally took the time to setup a VM with incus [3], and now I can let the agent go wild with docker inside the VM.
This is at least one example where more isolation is required. Otherwise, the dedicated Linux user, if it works for you, is by far the easiest and most pragmatic solution IMO.
You just made me realize why I've always considered 'chore' the most ambiguous type. In addition to being loosely defined ("transparent change with zero functionnal impact"?), this one is indeed a word related to emotion. No wonder it has a more subjective meaning than 'fix' or 'feat'.
This is why I never use it and almost always pick 'feat' to please the linter. Because I can't help considering that any change worth committing is improving the quality of the code in one way or the other, and thus a feature.
Some alternative forge are built with decentralization in mind:
- forgejo [1] is working on ForgeFed [2], an extension of ActivityPub (the protocol made popular by Mastodon)
- tangled is built on top of ATproto (the protocol behind Bluesky) [3]
- radicle is rolling their own protocol, more peer-to-peer than federated [4]
- fossil is a broader all-in-one solution: not only a new Version Control System (a replacement for git), but also a forge (has the features of a forge: issues (bug-tracking), PRs, comments, wikis, ...) [5]
The other self-hosted forges such as gitlab, sourcehut, gitea don't have such a high level of decentralization and resilience. It does not make them less good, they are solving different problems, mainly being a easy-to-use self-hosted alternative to proprietary forges. For instance Gitea has Gitea Actions, which is designed to be compatible with GitHub Actions [6], while I don't think running CI/CD workflow in a decentralized way will the priority of projects like tangled or radicle.
And to go one step further, for achieving a profile-per-firefox-window workflow, I suggest to have a look at the underrated extension Sticky Window Containers [0]
While far from being perfect, I find it good enough for keeping things separated, especially when using a desktop/workspace workflow. For example, in workspace/desktop 2 I have a Firefox window opened with the first tab set to "container A", so hitting ctrl-t there opens new tabs with the same container "A", so I'm logged-in for all projects A. In another Firefox window in workspace 3 I work with "business project B" tabs (where I'm logged into different atlassian, github, cloud, gmail, ...)
Then with a Window Manager like i3wm or Sway I set keybinds to jump directly to the window (and workspace), using the mark feature [1]
It's also possible to open websites directly in specific containers so it's flexible. For example on my desktop 8 I have all my AI webchats in "wherever my company pay for it" tabs: `firefox --new-window 'ext+container:name=loggedInPersonnal&url=https://chat.mistral.ai' 'ext+container:name=loggedInBusinessA&url=https://chatgpt.com' 'ext+container:name=loggedInBusinessB&url=https://gemini.google.com' 'ext+container:name=loggedInBusinessB&url=https://claude.ai'`
It's also the only way I found to keep opened multiple chat apps (Teams, Slack, Discord, ...). The alternative electron apps are as resource-hungry, and in my experience never handled multiple accounts well (especially Teams).
The part about permissions with settings.json [0] is laughable. Are we really supposed to list all potential variations of harmful commands? In addition to the `Bash(cat ./.env)`, we would also need to add `Bash(cat .env)`, Bash(tail ./.env)`, Bash(tail .env)`, `Bash(head ./.env)`, `Bash(sed '' ./.env)`, and countless others... while at the same time we allow something like `npm` to run?
I know the deny list is only for automatically denying, and that non-explicitly allowed command will pause, waiting for user input confirmation. But still it reminds me of the rationale the author of the Pi harness [1] gave to explain why there will be no permission feature built-in in Pi (emphasis mine):
> If you look at the security measures in other coding agents, *they're mostly security theater*. As soon as your agent can write code and run code, it's pretty much game over. [...] If you're uncomfortable with full access, run pi inside a container or use a different tool if you need (faux) guardrails.
As you mentioned, this is a big feature of Claude Code Web (or Codex/Antigravity or whatever equivalent of other companies): they handle the sand-boxing.
The webcomics is awful. It feels off, the characters look very fake, unsettling in the way they communicate. The prompt is shown bellow the image, but for me the result looks closer to a prompt "Create lifeless characters reciting marketing slop. They must fake an over exaggerated excitement but it should be clear they don't believe in what they're saying and have no souls".
Also, the prompt specifically ask "Panel 4 should show the cat and dog high-fiving" but the cat is high-fiving ... the cat. Personally I find this hallucinated plot twist good, it makes the ending a bit better. Although technically this is demonstrating a failure of the tool to follow the instructions from the prompt. Interesting choice of example for an official announcement.
Because the strategy of changing brand after a scandal works so well, it's good to add some precision here, for those who may not know: Facebook changed its name to Meta after a huge public backlash, the Cambridge Analytica scandal [0]
What was once a scandal in 2018 became common place. In 2018, targeting citizens with tailored messages to influence them was considered wrong. We had a different conception of "How we should make up our minds to choose our leaders" (it's still the case in some parts of Western Europe, where there are more regulations regarding elections, such as a ceiling for how much candidates can spend in marketing campaigns). Nowadays, we have Elon Musk directly involved in politics, who incidentally happen to possess all the data he bought with Twitter, and now tons of sensitive data he rushed to harness from government agencies during his short time in DOGE. Since he didn't shy away from directly paying people to vote for his candidates, it's hard to believe he would have the ethical restraint to not use this data and his social network to organize extremely precise and effective targeted manipulation campaigns to further his personal agenda.
Unfortunately, the unchecked (unregulated) use of personal data for massive manipulation is considered "inevitable" (i has been for decades). So much that we now comment about the word "inevitability" itself, and whether LLMs are "inevitably good at coding", completely brushing aside the most important, the main social issues LLMs can cause, such as: their biases (reinforcing fake news, or stereotypes), who train the model, what ads they will show in the near future, how they will be used for influencing people, how they will be used in drones, which humans in the loop, what guardrails, for whose interest, how will it be used in troll farm, how is it compatible with democracy, how (or if) the economics gains of this technology will be redistributed, ...
> This is why I avoid using non-official actions where possible and always set a version for the action.
Those are good practices. I would add that pinning the version (tag) is not enough, as we learnt with the tj-actions/changed-files event. We should pin the commit sha.[0]. Github states this in their official documentation [1] as well:
> Pin actions to a full length commit SHA
> Pin actions to a tag only if you trust the creator
> which GitHub goes to extents to document GitHub Actions policies as applying to `uses:` clauses
If it were phrased like this then you would be right. The docs would give a false sense of security, would be misleading. So I went to check, but I didn't find such assertion in the linked docs (please let me know if I missed it) [0]
So I agree with the commenter above (and Github) that "editing the github action to add steps to download a script and running" is not a fundamental flaw of this system designed to do exactly that, to run commands as instructed by the user.
Overall we should always ask ourselves: what's the threat model here? If anyone can edit the Github Action, then we can make it do a lot of things, and this "Github Action Policy" filter toggle is the last of our worry. The only way to make the CI/CD pipeline secure (especially since the CD part usually have access to the outside world) is to prevent people from editing and running anything they want in it. It means preventing the access of users to the repository itself in the case off Github Actions.
That's what I understood as well. Also, the author mentions:
> The installation succeeded, but the system would panic during boot. *Bhyve is more of a niche thing and not among the hypervisors supported by NetBSD*, [...]
I am guessing what he meant was rather "the support of NetBSD (as a guest OS) by the hypervisor Bhyve", because Bhyve is an hypervisor running on FreeBSD. Given the other posts on the blog, it would not be surprising if the author was daily driving FreeBSD while doing this experiment, and Bhyve is well maintained and probably the best fit in the BSD world for this. I don't even know if OpenBSD's vmm can virtualize something else than OpenBSD.
> Q: What VM operating systems does bhyve support?
> A: bhyve supports any version of FreeBSD i386/amd64. OpenBSD, NetBSD, illumos and GNU/Linux are supported using the UEFI and the sysutils/grub2-bhyve port.
The author wrote another blog post "Geoblocking the UK with Debian & Nginx"[0]. It's a short tutorial to do exactly as the title says, so it looks like the author did apply this configuration and intentionally want to geoblock the UK for compliance reasons, or maybe as a statement. The blog post has a link to https://geoblockthe.uk
With aider and Gemini Pro 2.5 at least I constantly have to fight against it to keep it focused on a small task. It keeps editing other parts of the file, doing small "improvements" and "optimizations" and commenting here and there. To the point where I'm considering switching to a graphical IDE where the interface would make it easier to accept or dismiss parts of changes (per lines/blocks, as opposed to a per file and per commit approach with aider).
Would you mind sharing more about your workflow with aider? Have you tried the `--watch-files` option? [0] What makes the architect mode [1] way better in your experience?
As for C, the "suitable" subset really depends what we expect from a browser. In my experience, I was forced to use a Chrome based browser only for work, because mostly for google web apps (Google Cloud and Google Meet come to mind). For browsing the small web, I'm sure smaller browsers can work well. I tried some, but was usually put off because of the lack of adblockers, and I also quickly miss the element picker zapper feature of the ublock origin extension.
I've been using eza (and exa before it) for a long time, but only for the pretty and colored output. I didn't even know about the git support! I now added the --git flag to my alias and will try it out. Thank you!
In the desktop-centric organization, many people also have 1 app per workspace most of the time (I think). In a tiling WM, the app will take the full screen estate if it's alone there, so it's also maximized.
The difference with alt+tab is that switching to another workspace (which represents a window if the workspace has only one app) is deterministic, given the right keybindings setup and if we have some habits regarding the placing of windows.
So 99% of the time I have the same placement of windows in workspaces. At the very least my main Firefox on destkop 1, Code Editor on desktop 2, a terminal (related to my coding task) on desktop 3, and then things get more "dynamic", maybe some extra term or other stuff I may need for my task on desktop 4, 5, ... With the bindings Super+<number> (number row on top of the keyboard), I jump directly to my workspaces(windows). With my left hand I hit Super+1 and it will always show Firefox, Super+2 vim, etc...
I prefer it to cycling through alt+tab, hitting Tab multiple times until I find my window. Here's an example of a flow I was doing just earlier today:
win+2 (editor) : I edit code
win+3 (term1) : run command to build or run tests or deploy...
win+1 (firefox) : refresh the app I just built, click somewhere, test...
win+3 (term1) : see that the build actually failed
win+4 (term2) : check a quick solution in another term, use a CLI tool, do some tests in a repl...
win+2 (editor) : fix code
win+3 (term1) : build
win+1 (firefox) : refresh, prepare the page (input some text or something, ready to click a button)
win+3 (term1) : check if build finished
win+1 (firefox) : click the page button to test my change
The idea is that each time I switch to a different desktop/window, I just go there directly, without thinking, as I know where they are. The example I gave is the natural way I use my computer (with i3 or dwm, but can be configured with KDE, Cinamon...), so it's not a far fetched example at all (in my case). Switching back and forth is extremely fast that way. A long time ago, a colleague even told me I was a bit hard to follow when in pair programming sessions so now I try to slow down a bit. With Alt+Tab it's not as smooth, as we'd have to cycle through 4 windows. With the default implementation of most alt+tab out there, it's the opposite of deterministic, there's some logic (that I never fully understood) to go back to the windows in the order of last used/focused windows. But I know that in KDE at least it's possible to configure the behavior of alt+tab to make it loop in a "dumb" predictive way (1->2->3->4->1->2...), so in the end, it's again just a matter of personal preference.
If the bindings were less optimized (shift+alt+<number> or something) it would get uncomfortable to use. I use the Super modifier ("Windows logo" key) as the basis for all shortcuts related to my WM, so it doesn't conflict with the shortcuts reserved by the apps themselves (apps may interpret the modifiers Alt, Option, Shift, but not Super). It's a bit of finger-stretching to reach desktops higher than 5 on the number row, and at some point I need my right hand, but it works fine for me.
You're also correct that workspaces allow for more windows (very useful the 1% of the time I need it), and in that regard a workspaces organization is not comparable to a alt+tab based flow.
I also think the taskbar showing only icons is confusing when we have the same app opened multiple time. I have a similar organization as you for work: a Firefox window on desktop 10 for Calendar, Mail, another on desktop 9 for company Chat, another (main) window on desktop 1, another on desktop 2 for a different project, ... By default on Gnome they would be all grouped into 1 Firefox icon. We can change the settings to not group apps, but a bunch of Firefox icons next to each others doesn't help either.
I recently discovered in the Fluxbox edition of MX Linux the taskbar Tint2. It was configured in a way that split the taskbar into dedicated and fixed workspace areas. It's an efficient way to see quickly what app is on which desktop, and clicking on one app will bring me to the desktop where the app is. I can also move apps to different desktop with the mouse by dragging them in the bar (for instance drag terminal of desktop 2 in desktop 3 next to the file browser opened there).
I currently use this taskbar with Openbox, but it should work with other DE/WMs. It has some bugs in some edge-cases so it's not perfect, but I like the concept.
I went on a quest to configure the same behavior on different DEs. I couldn't reproduce it with the default bars of Budgie, Cinamon, Gnome, Mate. KDE was the only one where I was close to achieve this. In the default KDE bar, it's possible to sort the apps by their workspaces. But it only sorts them, it doesn't split clearly by static desktops like you can do in Tint2. Still, KDE showed once again it was one of the most customizable :)
I'm aware. I think I tried. At the time (silverblue 26) they recommended to use a firefox installed as rpm (actually, the GUI was offering both flatpak and RPM for some packages, and "RPM" meant it used rpm-ostree under the hood to overlay the package). At least they warned about some issues when using firefox as flatpak (mostly related to integration with the rest of the desktop environment). And so, in order to get some things to work I had to install a few packages with rpm-ostree. Digging in my docs, it was:
> # nvidia and codecs necessary for firefox and youtube:
> # You'll need rpmfusion repo (see dedicated section for how to install them. Ugly.))
> rpm-ostree install akmod-nvidia ffmpeg xorg-x11-drv-nvidia xorg-x11-drv-nvidia-cuda
Maybe I used it wrong, idk, but here is how my .zshrc looked like:
> alias "hx"="toolbox run -c devops hx" # I installed there all the mess for LSP server
> alias "aws"="toolbox run -c devops aws"
> alias "mpv"="flatpak run io.mpv.Mpv"
> alias "yt-dlp"="toolbox run yt-dlp" # default distrobox is fedora
I could go inside containers ("activate" containers), but then, if I want all my tools... they need to reside in the same container, right?
I didn't feel like installing all the utils in all containers, or running exa and ripgrep in some fedora "basic-utils" containers and adding more aliases for very basic tools. So I ended up overlaying the utils I cannot live without, thinking they are not really unstable software, it can't possibly break the upgrade (and indeed it never did for the time I used silverblue) :
> rpm-ostree install bat exa git-delta ripgrep vim zsh zsh-syntax-highlighting zsh-autosuggestions fzf jq
I also needed some stuff to fix the thumbnails of the default gnome (I don't remember, but I'm pretty sure that if I did it with rpm-ostree it's because I didn't find another way):
I also couldn't install some ibus packages (with too much integration with the desktop/keyboard) in a container so I resorted to rpm-ostree there as well.
So while I really tried to keep everything out of rpm-ostree as much as I could, I felt like it was a constant trade-off: going against the spirit of the distribution VS managing every single util and running little cli tool in containers (that need to be maintained).
I'd be happy to read about some workflows, the "correct way to do it", or if silverblue changed since the last time I used it. But for me it's in the design itself: "use containers" mean "do the plumbing between or your tools yourself" (even if distrobox makes it easier by exposing/sharing pretty much the whole home, network, env vars etc...)
I like that they went from Ubuntu to Debian as the base OS. I assume they target Debian Sid (the unstable flavor of Debian) because they can compensate for the instability with the immutability provided by ABroot. Or is it simply because the distro is pretty much in a rapid development stage?
The distribution looks very fun. Something quite new to play with for distro-hoppers and to learn more about some techs.
Last time I tried fedora-silverblue I didn't like it. My packages were scattered in 2 or 3 distrobox containers. It's not that much, but they can be different distributions, and then we add flatpak to the mix, and apps installed in the base OS with rpm-ostree... It felt like a frankenstein distro. Upgrades were time consuming, and not smooth at all. Not only did I have to learn how to manage a fedora-silverblue, but I also had to maintain a debian container, upgrade another fedora (a regular one, not silverblue), learn the quirks of flatpak, and... that was too much work. It doesn't really matter that I can confidently upgrade the empty base OS, if I still need to manually upgrade my fedora container and it can break the package I need from that container.
The approach here with Apx is worth a closer look. It abstracts away the different package managers of the main distro (`apx search` PACKAGE will translate to `apt-cache search` in debian container, `pacman -Ss` in arch container, `zypper search` in opensuse...). The concept of "exporting" the packages, and the UI around it, makes me think they aim at making the management of these distrobox containers easier.
It looks like you can do it that way according to the docs [0] :
> abroot pkg add PACKAGE_NAME
Not sure what it does exactly under the hood. I'm not sure it persists after an upgrade.
In the release announcement blog post they also mention a way to build your own (base OS?) image with something called VIB [1]
Regarding space efficiency, the distribution relies on a "LVM Thin provisioning" feature. [2]
I don't know enough about it (nor about ostree) to compare the two.
This is all very refreshing! Many new techs and concepts to look into :)
> Until I'm shown otherwise it seems like a good compromise
Agreed. In my case I went a long way running the Pi harness in a (simple, rootfull) docker container. As the project I worked on relied on a standardized docker compose stack for local dev and testing, I realized I could automate more if only my agent could use docker. Ultimately, the need for docker for my agent grew when testcontainer [2] was introduced in the project. That's when I finally took the time to setup a VM with incus [3], and now I can let the agent go wild with docker inside the VM.
This is at least one example where more isolation is required. Otherwise, the dedicated Linux user, if it works for you, is by far the easiest and most pragmatic solution IMO.
[1] https://docs.docker.com/engine/install/linux-postinstall/#ma... ; https://wiki.debian.org/Docker
[2] https://testcontainers.com/getting-started/
[3] https://linuxcontainers.org/incus/docs/main/