bramblerose

In my experience the issue is one of torque, not of power. Most cheaper electric bicycles (including most Decathlon models) have a hub-mounted motor which cannot deliver power effectively at low speeds -> it stops assisting when you most need it. For hilly terrain you need a motor that's mounted on the crankshaft so that it can take advantage of the gears.

To compare: a tour de france runner outputs 400-500W on mountain climbs while keeping up to 20-25km/h. So a 500W motor (plus 100W power output from yourself) should be enough for smaller climbs!

While that is true, "Drivers consistently ignoring rules" is also a systems issue, which can be mitigated through e.g. better road design (narrower roads reduce speeding, for example).

Unless the design of the object is copyrightable (which it often is!) in which case the photo is a derivative work.

- Using the commit SHA of a released action version is the safest for stability and security.

This is not true for stability in practice: the action often depends on a specific Node version (which may not be supported by the runner at some point) and/or a versioned API that becomes unsupported. I've had better luck with @main.

   uses: actions/checkout@v4

That uses the Node that is provided by GitHub, and that will break in the future.

I find the repeated deprecations on GitHub Actions frustrating to work with. One of the key goals of a build system is to be able to come back to a project after several years and just having the build work out of the box.

Yet with GHA I need to update actions/checkout@v2 to actions/checkout@vwhatever (or, what I'm doing now, actions/checkout@main because the actual API haven't actually changed) because... some Node version is "out of maintenance"?!

GHA is literally code execution as a service. Why would I care whether the Node runner has a security vulnerability?

In the end, this is the age old "I built by thing on top of a 3rd party platform, it doesn't quite match my use case (anymore) and now I'm stuck".

Would GitLab have been better? Maybe. But chances are that there is another edge case that is not handled well there. You're in a PaaS world, don't expect the platform to adjust to your workflow; adjust your workflow to the platform.

You could of course choose to "step down" (PaaS to IaaS) by just having a "ci" script in your repo that is called by GA/other CI tooling. That gives you immense flexibility but also you lose specific features (e.g. pipeline display).

I would argue that the second rule is even optional here. There is enough literature (McConnell's Software Estimation, Boehm's Software Engineering Economics) that suggests that, given a well-scoped problem and other projects to base the estimation on, a good (+/-50% or so) estimate is possible. But if you don't know what you're building it's all wasted effort because you're estimating the wrong thing!

The subsidy could be independent from the carbon emissions (e.g. by subsidies on the produced goods) while the carbon tax isn't, effectively creating an incentive to produce in a less carbon intensive manner.

Which risk would TLS mitigate in this specific use case?

The alternative would be "two applications talking to the same microservice" where you run into the same issues with backwards compatibility, except the API is now "application to microservice" instead of "application to database schema". Either way, when someone changes the interface they either need to do this in a backwards compatible fashion or all dependent applications need to be updates.

I have the same (and ran into this trying to wrap my head around why Maven didn't work... I don't want a tutorial explaining how to get started, I need to understand the fundamentals to understand what's happening!).

I think, however, that starting from the examples might help with good API design: if you design your API to be "core concept first", this will likely lead to an API that _can only be used after you understand the core concepts_, which is not great when people are only occasional users.

You also have to allow the end user to make changes to the LGPL software running on the device.

Judging by the graph on the linked page, the UK's rail network is mostly safer due to a lower number of workplace accidents. A cynic might suggest that that's correlated with a lack of maintenance :-).However I do also believe that the UK takes workplace accidents more serious than some other European countries.