As another commentator said "do nothing" is a decision. There's a distinction between "don't make a decision and hope someone else makes a decision" and "we acknowledge we're deciding to do nothing about X until/unless Y"
The people in leadership positions should be active participants, and not all decisions will be ones they are are able to make locally - but they should feel comfortable to present a POV and recommendation/tradeoffs upwards when that's the case. If the buck stops with them then they should be aware that "do nothing" is a decision that they are making.
In terms of the expert observation, I've seen this happen a number of times in conjunction with "not invented here" (and probably been guilty of it myself at times) - "the commodity solution doesn't do X that we want", "yeah our in house solution doesn't do x,y,z that the commodity solution does but just a little more effort and it'll be perfect"
Spoiler: neither the commodity solution or the in-house solution will ever be perfect, and you should be really self critical of whether you're building something in-house to scratch your own itch.
If you can find a commodity solution with the right extension points that's often the best solution, failing that many times it's worth accepting the limitations, rarely it's worth investing in the totally bespoke thing (outside of your core domain/proposition).
Yeah you could run a single instance with multiple frontends - but the way I'm currently running things the public haproxy instance doesn't have network connectivity to the private services, meaning there is no way I can misconfigure things and expose an internal service to the internet.
Personally I think wildcard certs are more secure in many instances - if you're just running one load balancer/reverse proxy then all the private keys are going to the same place anyway. You get the upside of not leaking your subdomains to transparency logs, and having fewer certs to renew.
It also forces you to use DNS challenges, which means you don't require the publicly route able address.
Personally what I do is:
- Predominantly use wildcards
- Run a tiny coredns instance with my A records for a internal subdomain of my normal domain
- Configure tailscale to use the coredns resolver
- Run two haproxy instances, one for internal services, one for public facing. The public facing one can't route directly to the internal services.
When even the obscure DNS provider I'm using is supported for DNS challenges, I really don't see much upside to using HTTP challenges anymore
I'm aware, and I'm choosing GOG when I can now, though even then I see phoning home (or attempts to) happening (opensnitch is useful for that https://github.com/evilsocket/opensnitch) - I've paid for some titles 2-3x over which is frustrating, admittedly I don't have the physical media from the first time which is on me, but it's frustrating seeing single player games wanting to phone home
When I brought half life 2 there was a lag of about 2-4 years before I could play it for the first time - I didn't read the fine print, and on a dial up connection I couldn't get past the steam client updating in a reasonable amount of time, mind you I was able to download much larger Linux ISOs over time frames of a month+ through resumable downloads.
Not really an issue these days but it certainly was back in the day
The UK tax system also has a bunch of unfortunate cliffs, and tapers that create >60% marginal tax rates and worse. There's a calculator here that illustrates it well https://tax-cliffs.britishprogress.org/calculator
The childcare cliff edge is probably the worst, but the personal allowance taper isn't ideal either as it's compressed over a relatively short income range
And of course all the thresholds remain frozen, creating plenty of fiscal drag on top.
I think the litmus test is roughly "is this obviously AI created" - if it's a well crafted PR that doesn't do the things you mention, and solves a genuine issue in a sensible way then you'd not be able to tell.
The other part of the litmus test is "does the person submitting actually understand what they're submitting and why" - which is arguably not required for PRs that you'd otherwise accept, but since you have to put time and effort into determining whether a given contribution is ok to merge, it's common decency for the submitter to have done a self review first (AI or no AI)
I don't have so much knowledge about EV repairs, but I got burnt by this on ICE cars already - had a car fail a regular fitness test on suspension bushes, they weren't replaceable without replacing the whole arm(s). What should've been a $40 part was being quoted as more than the cars value.
(I'm not sure if there was a way around this, there may well have been but I had other things going on and sold for scrap)
In every of these threads there's a bunch of snarky comments, either acting like this class of attack is exclusive to npm, or that nothing has been done about it. I don't think that's fair.
There's plenty of comments mentioning delay lines, and the other good stuff pnpm (and others) have implemented in response to protect package consumers.
That bit that's getting less conversation is the tools on the package maintainer side:
In my experience with a relatively modest number of concurrent workflows (think hundreds) you'll be pushing several thousand transactions per second through that postgres instance.
As best I can tell it doesn't do any batching of it's writes/reads, and it's update heavy in places rather than append (I suspect their cloud version might do some of these things)
It's pretty close to "let's make every function call serialise it's parameters/return value, go through a postgres table and several network hops"
That said it can be very useful, but it's a heavy tool that's best suited for high value/risk workflows where you're earning enough from the execution that you can afford the overhead (for example an Uber trip with several dollars of service fees is probably a good fit, unsurprisingly since it's roots are from Uber)
I've used their (same family of company) email hosting services lightly in the past and found that to work well also. For the DNS I'm paying like $1 a month which is probably more than it needs to be, but sufficiently low that I'm happy to support small/local business. I'm also reasonably confident I could get a response if anything ever goes wrong, untested as nothing has so far.
It's not European, rather a New Zealand company but I find https://zonomi.com/ pretty good. There's a Lego resolver that works fine https://github.com/go-acme/lego - although my only complaint is the DNS propagation takes a while though I suspect that's a my config problem (dig will show the txt record long before Lego sees it)
One issue I've seen with LLM's is adding superfluous code in the name of "safety" and confidently generating a bunch of stuff that was useful in years gone by, but now handled correctly by the standard lib. I'm of the opinion that less is more when it comes to code, and find the trend this is introducing quite frustrating.
In the UK tax on interest earned on plain savings accounts isn't deducted at source - so if you have a rainy day pot chances are you're required to register for self assessment and pay tax on it (particularly now that interest rates are higher and it's relatively easy to go above the tax free threshold, which has been frozen for a long time).
If you have investments outside of an ISA (tax free investment wrapper) then same story - you need to report disposals and dividends for tax purposes.
That's before we get into side hustles/self employment and investment properties, etc.
Yeah that seems like a massive reach. Does banking count as a "supporting service"? After all a prediction market isn't very useful if you can't get money in/out.
Eg: JDK + maven + junit + tomcat
Making these components pluggable is arguably how we get innovation (eg: yarn/pnpm, jest/vitest, etc)