jeduardo

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 he meant a usable one, which meetup.com progressively ceases to be.

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.

For now, but soon running these things in Github Actions might pose an extra cost. https://news.ycombinator.com/item?id=46291156

Thanks for clarifying it! I left bitbucket many years ago when they changed their UI to a new style that was awful to use...

That's a surprise, do you have a link to their announcement?

Got an email today:

Hi there,

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.

How has it been working for you so far?

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?

Ah, that explains it. Fingers crossed that they can bring it back up soon.

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.

archive.is ftw I guess

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.

Got it, thanks. Well, if you ever decide to open it up I'd be keen to having a look at it. I have yet to see a good automated scheduler and none of the places I've been so far had an automated solution that worked fine when it comes to holidays, scheduled time off, etc. A lot of manual work was put into scheduling shifts, which I always found very disappointing.

Yup, I faced the very same recently crossing back into Germany from Denmark. Suddenly, nothing worked anymore. I dread the time I have to take the train to a different city, as Internet mostly only works when close to the actual stations. It's even worse now that many routes got longer as the trains get diverted due to maintenance work.

Second that. The state of internet in Germany is what always gets me thinking about how things will work when speed is slow, connections are spotty or you get offline. So many problems with Spotify in particular, as even when it detects that it is offline, it still insists to try fetching assets related to content that was already downloaded.

Are you using an in-house scheduler or is this a feature of a particular tool?

I remember a significant redesign and a lot of features moved to Swarm, which had a different kind of social push. I remember the app losing its usefulness to me and Swarm not being something I wanted to use. Details are hazy, though, it's been a long while.

Not a lot in the news about this one it seems.

Not really as far as I know. Providers in Germany have more or less standardized on Fritz!Box from AVM and the router comes with the admin password available. Updates are then fetched from upstream AVM.

But the key point here is device independence - by law, providers need to give you all information required to establish a connection to them. This allows you to run a Linux or BSD box as a router should you wish to. It somehow makes up for the slow broadband speeds you can get.

*Edit: complaints about slow broadband speeds

pass (passwordstore.org) backed by a remote git repo works well across Linux, Windows, macOS, iOS, and Android, as all of them have decent clients available and there is working browser integration for all popular browsers using browserpass (https://github.com/browserpass/browserpass-extension).

The learning curve to understand all the moving pieces and the initial setup can be more hassle than many are willing to put up with, but after the initial legwork is done, adding new devices is not that much more complicated than what it is on paid services, and using it is as simple as any of the popular services, IMHO.

GrapheneOS looks interesting but DivestOS's focus seem to be aftermarket devices that Graphene is not targeting.

I recently got an unofficial build of LineageOS running on a Nexus 4 (mako) device and I was positively surprised with the speed it can run modern software. But this is an unofficial build that is also broken on some essential points, such as WiFi.

For these old devices, Graphene is not an option and if there are others targeting the same devices as DivestOS (which I will surely be checking out soon) I have yet to see them.

There is some info about archiving here: https://www.gwern.net/Archiving-URLs

Lots of jobs and scripts, plus usage of archive.org as well. It's an interesting read.