> Operations like filter and map allocate memory, but that allocation is only necessary if the value escapes. The Swift standard library provides .lazy.map and .lazy.filter, but they don’t work in every case. For logic that only iterates over the filter or map, it’s much more efficient to loop with continue (or use for … in … where) and transform elements into local variables as necessary.
It does feel like a compiler/optimiser failure to have to rewrite those cases.
It isn't. You'd need full lifetime analysis as part of the compiler to even decide whether you _could_ skip the allocation, and even then it's 100% up to the circumstance and actual lifetime of the data to say whether it can be, e.g. stack-allocated to avoid placing it somewhere less localized.
As if supply chain attacks could have been prevented by 2fa or passkeys always.
You want delays by x days because supply chain attacks get caught very often within 1-2 days. And if you really really want to make an exception for a zero day then that's no problem and you can still quick patch by exclusion of that rule. They don't contradict in a unsolvable problem. You want both, you get both.
While I think this may be true, what validation do you have on this point?
Have you rolled the numbers, vs all of the high-pri security updates that will be missed on day one, and exploited?
What is really needed is simply more nuance. I agree the delay can help, but honestly the entire ecosystem is broken. There shouldn't be a single thing installed, without someone having an eyes-on. That's how this is fixed.
Distros aren't perfect, but they handle this a load better. And this really runs to the problem, people want "new new new", yet often have very little real reason to want it. 99% of npm packages could be 5 years old, and no one would care.
But outside of that, npm could operate like a distro, but with more of a Debian unstable -> testing method, where it typically takes a few days for this migration to happen.
My point is, the fix isn't publishing by default, then hoping to catch. The fix is that nothing gets published, without a QA/validation step. Of course, that takes money. There is naturally, a super easy fix for that.
The code stays open source. The licensing stays <insert whatever by author>. However?
The ToS for using any or all of the npm architecture is if you're a company, you pay. If you neglect to pay, eg you don't register as a corporate entity, set up and account, and pay per use, then as per ToS the licensing is invalid, and you're fined via a copyright infringement. And yes, this would mean all npm packages would have an altered licensing model, basically with this tacked on.
Is what I'm saying perfect? Nope. Yet it's the general path which should be taken. And frankly, with the way things are going, this level of audit would allow for staff also categorize licenses, ensure accurate template files, and so on.
And some of this is the perfect use of an LLM. Not to do the work, but to flag with human review.
--
This ecosystem is done. Its model is broken. The concept of downloading random stuff without auditing in any way, is broken. The industry will be moving away, is starting to move away, and is having to move away.
So... how can this survive with that concept?
If one doesn't like my proposal above, then they should provide an alterative which allows:
* companies to have validate of licensing
* audits which validate change is not untoward
> Have you rolled the numbers, vs all of the high-pri security updates that will be missed on day one, and exploited?
(Different person here) I don't have data and I don't think I need it. You either have a process to push security-critical updates out very rapidly or you don't.
If you have that process then nothing changes for you because that cooldown won't be used in that context.
If you don't have that process then nothing changes for you because you weren't pushing out those time-sensitive patches to begin with. But now you won't get hit by drive-by supply chain attacks.
The vast majority of "high severity vulnerabilities" in your dependencies are just noise by the virtue of not being exploitable in the manner that they're used in your project.
Why anyone would still use mypy besides legacy infrastructure is beyond me. It is dog slow as well as being the laziest of all, not catching many mistakes.
Unfortunately for Django apps switching to any alternative leads to the dreaded “wall of errors” issue. If anyone got to work this out in the past, I’d gladly take advices.
We switched our very large Django monolith codebase over to ty — the trick for us was generating stubs for Django models and having tooling keep those stubs in sync with the actual models.
Went from type checking taking ~10 minutes in CI to now taking ~15 seconds and runs on pre-commit.
Absolute game changer, I think we spent $10k in claude credits and did the entire mypy -> ty refactor in about 3 weeks.
It does feel like a compiler/optimiser failure to have to rewrite those cases.
reply