bramblerose

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.

The solution to the "interface/tooling to translate" problem, at least for open source applications, is https://translatewiki.net/ , with the additional benefit that it comes with a team of experts that can help you understand how to deal with stuff you might be unfamiliar with, such as RTL languages and plural forms.

   uses: actions/checkout@v4

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.

It's the power output that is relevant for the failure mode described in the article, not the yearly production. And in terms of power output, 20GW is an incredibly common number for peak solar production (see e.g. https://energieopwek.nl/ at the end of Jul this year) in summer. Borssele (the medium-sized power plant named in the article) has a 485MWe net output. So yes, we _are_ talking about >25 mid-sized nuclear power plants!

The failure mode is much simpler: you don't need to physically break anything, you just need to drop 10GW of production from the grid (send a "turn off" command to all solar inverters) leading to a cascade of failures. Getting the grid back online is a laboreous manual process which will take (a lot of) time. Think https://en.wikipedia.org/wiki/Northeast_blackout_of_2003 or https://en.wikipedia.org/wiki/2021_Texas_power_crisis .

You can, but you need to enable it (as it fundamentally changes how the game plays); https://wiki.openttd.org/en/Manual/Passenger%20and%20cargo%2...

You can do this with `np.newaxis` - in the NumPy course I wrote as TA we required students to always be explicit about the axes (also in e.g. sums). It would be nice if you could disable the implicit broadcasting, but as you mention that would break so much code

I appreciate your response. I feel the same as the other commenter: the asymmetry between "a steep fine" and "losing your home" is enormous. But "what happens if the fine is enormous" (say, the landlord also stands to lose their home) is an interesting thought experiment - how big does the punishment need to be to "fix" the power imbalance?

So what happens when the law requires a contract yet the landlord doesn't offer a contract and simply collects the rent?

You can be refunded without receiving additional compensation.

They are not entitled to compensation over their previous work, but you/me/AWS are also not entitled to their _future_ work.

That only works for copyleft licenses. Even with Antirez' original work fully available under BSD, there is nothing stopping Redis Labs from adding new code under a proprietary license.

A Vector Network Analyzer - https://en.wikipedia.org/wiki/Network_analyzer_(electrical)

The MIT license just gives you permission to use the work as published. Normally that work would be in source form, but there is nothing in the MIT license requiring that. In this case, it seems that the authors chose to release the binaries under the MIT license.

You can, in fact, with the right equipment, talk to NFC chips from a distance. Easier with 125kHz than with 13.56MHz but still possible. See, e.g., https://www.youtube.com/watch?v=gP9f_TiKHIY

Security of NFC applications is complex, and generally a layered approach. Yes, physical distance is a mitigating factor. Using smart cards (rather than keyfobs) and encrypted communication mitigates the risk of skimming. Using sensible financial limits and good monitoring limits the impact of any issue that does occur.

In the end, security is not a black and white 'you need to be at a distance thus things are secure' story. It's about reducing the risk, which is a combination of reducing probability _and_ reducing impact.

There's a blog post by the author explaining the context at https://sonnet.io/posts/sit/ . But really, just sit :-)

I suspect this may have to do with who owns what: the trailer is not always owned by the same entity as the truck which means that some sort of agreement needs to be made. This could be part of the transport fee, but would need to solve questions like what happens if the trailer battery is empty.

In my experience it's often the _developer of the PoC_ that goes "oh, this will just need a little bit of cleanup" rather than clearly communicating "this PoC has validated risks X and Y, but we still need to mitigate risks A and B and the current implementation has taken shortcuts which introduces risks D and E".

Contact/support only provided through Reddit and a contact form, no information on the company providing the hosting (other than "Mango Mail is an American company based in the state of Florida."). Domain name with privacy protection.

All in all, this makes everything seem like a hobby project rather than a serious supplier. What's your postal address? Company registration number?

The pricing model is nice, but the basic 'serious supplier' components would really need to be addressed before I'd consider switching.