#Tag
I’m self hosting things, and if I don’t write things down I don’t remember how to do them. So far I’ve been relying on Obsidian for my docs, but I’m really tempted to go with @atuin desktop.
No BS playbooks you can run (so playbooks you keep updated), and that you can store on git? Open source and free? No AI?! It’s almost too good to be true!
I'm writing the post-mortem of the 24h outage of matrix.org, and I'm learning so much from our SRE team.
I think I'm going to make "reading public post-mortems" a new hobby of mine. What are good sources to find interesting ones?
One of the points of agile development is to seek input from customers throughout the development process, including early stages. But if a development team isn’t allowed, without authorization from some outside body, to change requirements or specifications in response to what they discover, their ability to innovate is sharply inhibited. —Nicole Forsgren et al.,
Accelerate: The Science of Lean Software and DevOps
Good design is not a one-and-done activity—it is an iterative process of shaping, testing, and refining ideas in response to how real users engage with them. The best designs emerge not from isolated studios or static documentation, but from rapid cycles of delivery, feedback, and improvement.
Unfortunately, this is where many government digital services fall short. The issue is not simply a lack of design talent or access to modern design methods. Rather, it is the friction in delivering design outputs to real users, and the difficulty of iterating quickly once those outputs are in production.
When users cannot interact with design artifacts, or when changes take weeks or months to deploy, the quality of the resulting services inevitably suffers. Designers are left guessing about user needs, and by the time changes are implemented, the context may have shifted entirely.
The lifeblood of good user experience is frequent deployments. Continuous deployment (the CD in CI/CD) is not just an industry trend, it is literally how improvements and enhancements get into the hands of users. If the time between software deployments is measured in months (or even years for some government organizations) no amount of user research or data analytics can save you. You can’t meaningfully help users unless you can get them enhancements quickly, reliably, and securely.
As service design scholar Lara Penin puts it in her book An Introduction to Service Design: Designing the Invisible:
Designers of interactions not only need to spend a lot of time trying to anticipate people’s reactions but also – and foremost – they need to get their interaction ideas out there and test them with users in context throughout the development process.
This is the heart of good design: short, frequent feedback loops that allow teams to adapt based on what they learn. Understanding the connection between deployment frequency and user experience is critical to successful digital solutions.
Government agencies face unique challenges in achieving this kind of rapid iteration. Compliance requirements like Authority to Operate (ATO) add delays before new features can go live. Legacy systems make deployments risky and expensive. And many teams lack mature DevOps practices that make delivery seamless and low-risk.
Poor DevOps practices are often the unseen culprit in poor digital service designAs a result, even well-researched, well-crafted designs often stall before they can make a meaningful impact.
Improving government services isn’t just about bringing in skilled designers or training staff in human-centered design, though that’s important as well. Those investments will only go so far if agencies cannot act quickly on what they learn from users. The key is reducing the cost, in time, money, and risk, of delivering and iterating on design ideas.
Mature DevOps practices make iteration cheap, secure, and fast. Automated testing, continuous delivery pipelines, and modular architectures mean teams can experiment safely, deploy quickly, and revert easily when needed. Frequent deployments aren’t just a nice-to-have—they are how user experience improves in practice.
If we want better digital services for the public, we need to focus not just on designing the right things, but on making it easier for governments to deliver and refine them—over and over again.
One of the points of agile development is to seek input from customers throughout the development process, including early stages. But if a development team isn’t allowed, without authorization from some outside body, to change requirements or specifications in response to what they discover, their ability to innovate is sharply inhibited. —Nicole Forsgren et al.,
Accelerate: The Science of Lean Software and DevOps
Good design is not a one-and-done activity—it is an iterative process of shaping, testing, and refining ideas in response to how real users engage with them. The best designs emerge not from isolated studios or static documentation, but from rapid cycles of delivery, feedback, and improvement.
Unfortunately, this is where many government digital services fall short. The issue is not simply a lack of design talent or access to modern design methods. Rather, it is the friction in delivering design outputs to real users, and the difficulty of iterating quickly once those outputs are in production.
When users cannot interact with design artifacts, or when changes take weeks or months to deploy, the quality of the resulting services inevitably suffers. Designers are left guessing about user needs, and by the time changes are implemented, the context may have shifted entirely.
The lifeblood of good user experience is frequent deployments. Continuous deployment (the CD in CI/CD) is not just an industry trend, it is literally how improvements and enhancements get into the hands of users. If the time between software deployments is measured in months (or even years for some government organizations) no amount of user research or data analytics can save you. You can’t meaningfully help users unless you can get them enhancements quickly, reliably, and securely.
As service design scholar Lara Penin puts it in her book An Introduction to Service Design: Designing the Invisible:
Designers of interactions not only need to spend a lot of time trying to anticipate people’s reactions but also – and foremost – they need to get their interaction ideas out there and test them with users in context throughout the development process.
This is the heart of good design: short, frequent feedback loops that allow teams to adapt based on what they learn. Understanding the connection between deployment frequency and user experience is critical to successful digital solutions.
Government agencies face unique challenges in achieving this kind of rapid iteration. Compliance requirements like Authority to Operate (ATO) add delays before new features can go live. Legacy systems make deployments risky and expensive. And many teams lack mature DevOps practices that make delivery seamless and low-risk.
Poor DevOps practices are often the unseen culprit in poor digital service designAs a result, even well-researched, well-crafted designs often stall before they can make a meaningful impact.
Improving government services isn’t just about bringing in skilled designers or training staff in human-centered design, though that’s important as well. Those investments will only go so far if agencies cannot act quickly on what they learn from users. The key is reducing the cost, in time, money, and risk, of delivering and iterating on design ideas.
Mature DevOps practices make iteration cheap, secure, and fast. Automated testing, continuous delivery pipelines, and modular architectures mean teams can experiment safely, deploy quickly, and revert easily when needed. Frequent deployments aren’t just a nice-to-have—they are how user experience improves in practice.
If we want better digital services for the public, we need to focus not just on designing the right things, but on making it easier for governments to deliver and refine them—over and over again.
What’s up with mosh? It didn’t receive an update in years, and it seems to be a rather sensitive piece of software. Is it no longer maintained?
I turned a tiny #Mac mini into my own #Mastodon server—secure, low‑maintenance, and running like a dream. Here’s the full build, from #Docker to #Cloudflare Tunnel, and why #SelfHosting doesn’t have to be a headache.
@bobmagicii @daspotato Just looked it up. There are a couple of problems with Jellyfin, unfortunately:
1. I have to have digital copies of all the media I want to watch.
2. I need to store those digital copies on my own server.
I don’t want to do these things.
@ramsey @bobmagicii hi Ben, I think u are educated user, considering u've done research on what Jellyfin is.
as for ur concerns:
yes. the way how Jellyfin or other personal / community hosted service is an UX obstacle.
u can:
- connect with ur local #foss or #devops communities & ask if ppl willing to share their service (jellyfin / whatever u feel comfortable) with u.
many #selfhosting hobbyists enjoy sharing, just like sharing a book from their library. it's time to make some new friends.
I turned a tiny #Mac mini into my own #Mastodon server—secure, low‑maintenance, and running like a dream. Here’s the full build, from #Docker to #Cloudflare Tunnel, and why #SelfHosting doesn’t have to be a headache.
modern #devops means downloading hundreds of megs, spinning up a brand new full system and destroying a perfectly fine running one just to flip a single bit of configuration and I think it's not beautiful at all.
Hey #Proxmox community! I would like to hear your thoughts on how you usually update your Proxmox nodes and clusters. How do you handle minor Proxmox and #Debian package upgrades with #APT?
What would you think about a new API endpoint that lets you run unattended upgrades with a simple call like:
/nodes/{node_name}/apt/upgrade
At the moment you need to use the node’s HTML5 console to perform upgrades. Other methods exist such as running unattended Debian upgrade scripts, using patch management tools like #Spacewalk or #QualvoSec, or automating the process with #Ansible over SSH. My idea is to have an API based solution that relies on Proxmox authentication and authorization. This would also allow third party tools such as #ProxLB to provide automated patch management and even handle guest rebalancing in a way that is similar to DRS without requiring direct SSH access.Hey #Proxmox community! I would like to hear your thoughts on how you usually update your Proxmox nodes and clusters. How do you handle minor Proxmox and #Debian package upgrades with #APT?
What would you think about a new API endpoint that lets you run unattended upgrades with a simple call like:
/nodes/{node_name}/apt/upgrade
At the moment you need to use the node’s HTML5 console to perform upgrades. Other methods exist such as running unattended Debian upgrade scripts, using patch management tools like #Spacewalk or #QualvoSec, or automating the process with #Ansible over SSH. My idea is to have an API based solution that relies on Proxmox authentication and authorization. This would also allow third party tools such as #ProxLB to provide automated patch management and even handle guest rebalancing in a way that is similar to DRS without requiring direct SSH access.modern #devops means downloading hundreds of megs, spinning up a brand new full system and destroying a perfectly fine running one just to flip a single bit of configuration and I think it's not beautiful at all.
In our quest to move away from GitHub, we have a working self-hosted cgit instance as well as a runner for CI.
The last missing piece is to find a way to safely expose it to the world.
Are there any good Cloudflare alternatives to protect the origin?
Tor works fine, but I would like to also be reachable from the clearnet.
In our quest to move away from GitHub, we have a working self-hosted cgit instance as well as a runner for CI.
The last missing piece is to find a way to safely expose it to the world.
Are there any good Cloudflare alternatives to protect the origin?
Tor works fine, but I would like to also be reachable from the clearnet.
En formation, j'ai un peu mieux découvert le monde merveilleux créé par Microsoft pour le #devops etc.
Par exemple, cette extension VS Code officielle qui permet de faire un ssh + une sorte de sshfs sur toutes les machines déclarées dans notre ~/.ssh/config… et qui y dépose le code d'un serveur VS Code de 230 Mo (508 répertoires, 1585 fichiers) sans doute pour assurer cette fonctionnalité !
Je suis retourné aussi sec sous #emacs et sshfs.
Now that OpenBSD-current is 7.8-beta, it is time to reprise "You Have Installed OpenBSD. Now For The Daily Tasks." https://nxdomain.no/~peter/openbsd_installed_now_for_the_daily_tasks.html (tracked version https://bsdly.blogspot.com/2024/09/you-have-installed-openbsd-now-for.html) to prepare :)
#openbsd #newrelease #78beta #upgrading #sysadmin #unixlike #devops #development
Now that OpenBSD-current is 7.8-beta, it is time to reprise "You Have Installed OpenBSD. Now For The Daily Tasks." https://nxdomain.no/~peter/openbsd_installed_now_for_the_daily_tasks.html (tracked version https://bsdly.blogspot.com/2024/09/you-have-installed-openbsd-now-for.html) to prepare :)
#openbsd #newrelease #78beta #upgrading #sysadmin #unixlike #devops #development
Just published a comprehensive FreeBSD Cheat Sheet for Linux Admins!
Covers all the essentials:
- Hardware info (pciconf → lspci)
- Network commands (sockstat is amazing!)
- Disk management & ZFS operations
- Service management differences
- Package management across systems
Perfect for Linux admins diving into FreeBSD or anyone working across both systems. Includes 100+ command comparisons and real-world examples.
https://codeberg.org/Larvitz/gists/src/branch/main/2025/20250829-FreeBSD_CheatSheet_Linux.md
DRS alike VM balancing in #Proxmox clusters? #ProxLB 1.1.6.1 has been released. ProxLB is free and #opensource.
#devops #virtualization #python #python3 #coding #tools #pve #prox #proxlb #drs #clustering #loadbalancing #features
GitHub: https://github.com/gyptazy/ProxLB
DRS alike VM balancing in #Proxmox clusters? #ProxLB 1.1.6.1 has been released. ProxLB is free and #opensource.
#devops #virtualization #python #python3 #coding #tools #pve #prox #proxlb #drs #clustering #loadbalancing #features
GitHub: https://github.com/gyptazy/ProxLB
A space for Bonfire maintainers and contributors to communicate
