Hacker Newsnew | past | comments | ask | show | jobs | submit | axelfontaine's commentslogin


> We’ve read your posts and heard your feedback. We’re postponing the announced billing change for self-hosted GitHub Actions to take time to re-evaluate our approach.

So the price change is not cancelled, as the post title says, but just postponed. A big difference.

When they say "we read your posts", I wonder if they're running a language model to digest HN comments for sentiment analysis. It was overwhelmingly negative, so they're backtracking on it. If it weren't for the public reaction, they would have happily went through with the plan.

Feels similar to the recent announcement by the new Mozilla CEO to make Firefox into an "AI browser". The majority of users expressed disfavor, and now they're de-emphasizing it, while scheming behind the scenes to implement it anyway. Like how the new GitHub CEO said, basically, that programmers who don't embrace AI will become irrelevant. That was unpopular so they had to reframe the messaging for marketing purpose.


The $0.002 per-minute for self-hosted runners will definitely change the unit economics for a lot of 3rd party runner providers.

I'm sure we'll feel it too at https://sprinters.sh, but probably a bit less than others as our flat $0.01 per job fee for runners on your own AWS account will still work out to about 80% average savings in practice, compared to ~90% now when using spot instances.


And yet somehow, bad planning like this can be seen every day in cycling paths. It's almost as if the planners think it would be acceptable there. To which I clearly say: no, it's not! In fact even less so than for cars are losing your momentum and regaining costs significantly more energy than a press on the accelerator!


This is a great article, with many important points.

One nitpick:

> Self-hosted runners should never be used with public repositories.

Public repositories themselves aren't the issue, pull requests are. Any infrastructure or data mutable by a workflow involving pull requests should be burned to the ground after that workflow completes. You can achieve this with ephemeral runners with JIT tokens, where the complete VM is disposed of after the job completes.

As always the principle of least-privilege is your friend.

If you stick to that, ephemeral self-hosted runners on disposable infrastructure are a solid, high-performance, cost-effective choice.

We built exactly this at Sprinters [0] for your own AWS account, but there are many other good solutions out there too if you keep this in mind.

[0] https://sprinters.sh


Iframes, while not perfect, are pretty close though...


Making iframes be the right size is super awkward. I might actually use them more if they were easy to get responsive.

This post does link to a technique (new to me) to extract iframe contents:

    <iframe src="/example.html" onload="this.before((this.contentDocument.body||this.contentDocument).children[0]);this.remove()"></iframe>


I've come across this technique here [0] to try it on <object> elements, but sizing is even more difficult there.

[0]: https://www.filamentgroup.com/lab/html-includes/


Are we solving the information-centric transclusion problem, or the design-centric asset reuse problem? An iframe is fine for the former but is not geared towards design and layout solutions.


It kinda sucks for both! Dropping in a box of text that flatly does not resize to fit its contents does not fit the definition of "fine" for me, here.

You can do some really silly maneuvers with `window.postMessage` to communicate an expected size between the parent and frame on resize, but that's expensive and fiddly.


Iframes fundamentally encapsulate html documents, not fragments.


Interaction between elements in different iframes is very restricted.


IIRC, you can communicate entire JSON objects between an iframe and it's host frame with PostMessage.

The host can then act as a server for the iframe client, even updating it's state or DOM in response to a message from the iframe.


While I haven't canoed it, I cycled the whole Danube from the sources of the Brigach and Breg in the Black Forest in Germany to the delta in Romania. AMA.


What percentage of the route was directly next to, or very close to, the river? Did you have to veer inland to get past any parts?


A very large part. Certainly up to the Romanian border, then it's all over the place. The Danube cycle path has been integrated in EuroVelo 6. You can see the detailed path here for yourself (just click through the different sections): https://en.eurovelo.com/ev6/from-ulm-to-passau


I did most of this too! It was great.

Do you have recommendations for folks who can only do a shorter trip (say, a long weekend, or a week)?


The classic recommendation would be Passau - Vienna as the infrastructure is very well built out and Vienna is a great destination. This can easily be combined with a start in Munich and taking the bike back on the train to Munich for a round- trip that takes around 5-7 days (+-500 km).

That being said a few other sections come to mind:

- the very start from Donaueschingen to Regensburg is on beautifully wild cycling paths in the middle of nature with a number of interesting cities along the way

- Vienna - Budapest + train back is another fun loop including 3 capitals!

- For the more adventurous, the Serbian part is very scenic too. Belgrade is great. Leaving it on the busy road not so much. After that you quickly find yourself on a meandering road along the shore with spectacular cliffs and tunnels. No cycling path anymore. But well worth it.

- Romania is still challenging for cyclists, but the delta is very spectacular if you get a chance to visit it (by boat, no bike , as there are no roads).


At https://sprinters.sh we offer AWS-hosted runners at a price point that will be much more suitable for a company like yours.


... so far


Luxembourg has free public transit.


That may be true for the "what", but certainly not for the "why".


Why is best inferred from context imo, otherwise it's a smell for a system with too much scope.


You can't context-out business requirements, IMO. Also code can have bugs. You need more formal requirements definition so you can compare behavior to requirements so you can find out bugs. Otherwise, how do you find the bugs?


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: