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?
The Basic Attention Tokens from Brave were intended to work in a similar way: you could pre-purchase them and a fraction would be sent to an website when you accessed their page, in theory removing the need for paywalls.
I thought it to be an interesting idea, but it'd only work as a replacement for subscriptions with a lot of people onboard, which depended not only on adoption for Brave.
Matters of regulation and off-ramp of these tokens into the usual financial system were complicated, since they built the infrastructure on Ethereum and had to partner with an existing crypto exchange to get it running and vetted. Eventually they stopped supporting my country and I never looked into them again.
> To me Hamburg seemed exceptionally road/car heavy. Munich in comparison seems much more sane and European
That's an interesting perspective. I've been living in Hamburg for more than 10 years and visited Munich many times in the past 5 years or so for work, and my observation was always the opposite (and similar to the article's author).
I never felt the need to get a driver's license while living in Hamburg, given the broad coverage of the U-/S-Bahn network. It goes _really_ far. And most of the people I know who have cars usually prefer to commute by train and save the drive for weekends or evening events.
I've entertained the idea of moving to Munich for many, many times, and one of the deterrents for me always was that I found Munich to be too much of a car-oriented city; U-Bahn/Tram coverage seemed limited to a more central area where rents were quite high. Farther away, where most of my friends live, is covered by buses or S-Bahn with long, long journeys. And that's it, it's either a long commute on trains that look a bit old, or having a nice drive.
It does look like rent prices are not as high in that central area as they're used to be, which sounds nice, because living in the nice area with good public transit coverage looks lovely.
6 years ago when I used Hetzner, it was widely known as unreliable, a provider where you could get hosting that delivered good performance for a cheap price. The tradeoff always was that you needed to treat each machine almost as EC2 Spot: it could go down at any time.
You also needed to consider that when this happened, the data inside the machine was mostly lost. Finally, you also needed to plan to graduate out of it as soon as you had enough money to go either to a colocated data center or the "real cloud".
I kept Hetzner as a backup provider in more than one company, mainly to have real machines for take home tests, back when hiring was plentiful. Even so, we often faced problems with the machines going down due to hardware or networking issues, and the need to rebuild them from the ground up. Those mirrored all tales of woe everyone in the department had from years of working with Hetzner, sometimes losing production data because the rules of the game were not followed.
So it seems that 6 years later their scale has increased but the experience remains the same. On the bright side, kudos to Hetzner for teaching waves of engineers about reliability and disaster recovery during all these years.
Thanks for sharing this! I had to do exactly the same thing some 10 years ago to get an Oracle instance up and running again. Oracle insisted on using the /tmp location, despite being installed on a different drive, and the disk was full. As I had access to the Oracle system user, but not to the DBA user to change any configuration, I built a similar shared lib and preloaded it to the script. Worked like a charm! Happy to know that there is something _slightly more streamlined_ to do that now.
I wonder how this will play out in the phones coming out of the Motorola+GrapheneOS partnership.