The "protective waiting period" of 24h is what kills it. For people like me, who rely more and more every day on OSS apps not necessarily in the Play Store, installing a new phone will mean waiting a full day for almighty Google to allow me to do so. It reminds me of the same annoyance of carrier phone unlocks.
I wonder how this will play out in the phones coming out of the Motorola+GrapheneOS partnership.
I've been experimenting with their controller for k8s runners https://github.com/actions/actions-runner-controller. The awful thing about it is that you cannot run one set for all projects unless they're all under an organisation, so for normal accounts you need to provision one runner set per project.
We used to run Gitlab Premium for around 300 users running hundreds of jobs over some monorepos. Gitlab suggested a small architecture using Omnibus, and while it helped a bit, it didn't perform as well under load as we expected it to.
Eventually, there was no virtual scaling that could help. This, for me, is the biggest problem with Gitlab hosting: as soon as you hit a scale where a single machine with Omnibus doesn't cut it, the jump in complexity, cost, and engineering hours is significant.
Maybe yes but also maybe not. Intra-european travel can be cheap but it can also be expensive. You can take a Ryanair flight and a local train to stay somewhere cheap for a couple days. But you can also take a expensive Lufthansa flight to stay in a big city where costs can be similar or higher to where where you are. It will always depend of where you are and where you'd like to go to.
My impression is that nowadays the UK has more cheap flight options than the rest of Europe and that trains aren't as cheap as they used to be a decade ago.
We’re reaching out to let you know that your organization is currently on the legacy HCP Terraform Free plan. This plan will reach end-of-life (EOL) on March 31, 2026. After this date, the plan will no longer be supported.
To keep using your organization without interruption, please sign up for a current HCP Terraform plan and migrate your existing organization before March 31, 2026
Hey, that's good to hear. Was it a recent experience for you? Maybe they heard some of the feedback and acted on it.
This encourages me to revisit them, not because I'm unhappy with my current provider, but rather because Twilio offers what I need (a number that can receive and send SMS) in regions where my current provider doesn't.
One sidenote is that the Twilio part is harder than it looks. Not because of technical factors, but because of the paid requirement. Twilio refused to take my money and upgrade me to a paid account, even though they forced me to go to their confusing KYC procedure, where they asked me many times to provide the same set of documents. Support was useless, it looked like an AI bot repeating the same thing, but this was before the widespread usage of AI bots.
Eventually I gave up and went to Telnyx, which had a better KYC process and actual humans behind support that could resolve any quirks with KYC. Apparently not being born where you live breaks a lot of the automation behind some of these processes, go figure.
I also use this guide, but I switched it to PostgreSQL instead. The recent upgrade to Trixie brought a new Dovecot with breaking changes to its configuration. That was a bit of a pain to resolve, but everything is working fine now.
That's curious. I moved from KeePassXC to pass precisely because the synchronization story for the database file wasn't working so well. For too many times I ended up with an outdated database in the backend server because the sync process failed to work properly.
After I moved to pass, every credential became its own file and I rarely edited the same credential in way too many devices. For the rare conflicts I had, having it being Git made it possible to resolve them without massive hassle.
Then again, that was also some many years ago. Maybe the synchronization story is better these days.
I'm in a similar situation and considering doing the same thing as you, for the same reasons, but I'm curious about how the offline experience is.
I'm often facing periods of bad to no connectivity, and I find the ability to lookup or even update a credential offline very useful. Not sure how much of it is possible with Vaulwarden and I couldn't find the time to try it yet.
I wonder if they're successful in converting free users to paid users after they gate all useful product features behind a paywall.
I was always a light user of most products they bought and their changes just pushed me away. But as a light user, I wasn't planning to pay a subscription anyway, so going away might just release them the resources used to keep a user that generates no revenue.
However, it looks to me that the communities they buy thrive on free users. If the free users go away, will the community and usage remain? For how long will they be able to make money out of those communities until there aren't any users left?
> Booting from ZFS seemed like a hassle, without clear benefits.
It used to be a major hassle around 2 years ago but since then things have evolved significantly, up to the point where as long as you follow the install instructions correctly the first time, you can trust it to just keep on working.
One benefit (for me) is the ability of having full system snapshots taken periodically with minimum storage cost. I've used a setup on my personal workstation for years where a zfSnap job takes snapshots every hour. This has proven itself to be super convenient when accidents occur. Of course that the important data is backed up externally or committed to Git, but having the possibility to quickly revert mistakes is a big nice to have.
Such a system could also be easily improved to ship these snapshots to an offsite location as incremental backups. Of course the same process can be done in many other ways, but it is also other thing nice to have.
Another benefit I've had with this is portability between machines. My current Debian Stable system with ZFS on root began its life running out of an external HDD plugged onto an old Macbook Air. After I was able to get an external SSD and a Thunderbolt adapter, all I needed to do was to add the new device to the existing pool as a mirror and wait for resilvering, then remove the old device after all data was mirrored and the migration was done. When I finally got a new laptop, all I needed to do was to boot from the SSD and add the new NVMe device to the pool as a mirror, then remove the old SSD afterwards.
There is also the transparent compression feature that can potentially save a lot of HDD space depending on the usage pattern of the particular system.
And of course since ZFS is there present in your system (as it's the rootfs anyway!) you can use all other features you want, such as slicing volumes to use as root volumes for virtual machines or to use it as the backend for a local Docker host, where Docker can use an specific ZFS driver and leverage filesystem capabilities when storing images.
Of course you don't need to run it as the rootfs for many of these things, but you if do like ZFS then the benefits, possibilities, and the fact that you can do it outweigh the (nowadays reduced) hassle. :)
I wonder how this will play out in the phones coming out of the Motorola+GrapheneOS partnership.