I see asserts used in production code as part of flow control way too frequently, so I assume the majority of python users aren't aware of the -O flag, much less this behavior- which I too haven't ever heard of.
Of recently, I've noticed claude is a big fan of asserts too.
Observationally, for people that /aren't/ using models to code but to just do their white-collar job, claude.ai /is/ AI, now. The entire perspective for how to use AI is through claude skills, claude projects, claude cowork, etc. They've massively won the corp buy-in at the moment I believe.
Fully agree, that’s how I see most of my less technical coworkers reason about using AI. “Is there a Claude skill for that?” is a question I hear multiple times a week.
I see a lot of comments (incl 2 sibling comments) are always discussing whether there is a moat on AI. We agree there is no technical moat, there is nothing that Anthropic or any other AI lab could do that wouldn’t be quickly offered by other competitors too. However, _market penetration is the moat_. The deeper Anthropic is in relationships with orgs, the higher the cost of switching. Sure, for an individual it’s a 2-second job, but for a business it’s actual work of changing permissions, provisions, updating vendors etc. Nothing catastrophic but still real work, implying that Anthropic would need to drop the ball significantly to be swapped out, and wouldn’t be just because there’s a competitor who does everything kinda the same for kinda the same price (or slightly less).
Moat can be in execution and not just in technology. McDonalds has no specific burger-making technology that no other restaurant can acquire, what they do have is a well-scaled execution. Sure, there are competitors, and sure there are new comers to the burger space with different recipes (e.g. smash) but that doesn’t mean McDonalds is going under. Market penetration is the moat.
People always underestimate the moat that is institutional agility/ossification. There may be no theoretical moat in software, but every time you switch HR or financial systems you find out the hard way just how many integrations have been built (directly or indirectly) around a specific way of thinking about organizational data imposed by the software containing it, all of which require significant rewrites for the new system's conceptualization. The costs of switching add up fast and the risks of delayed payments/paychecks significant, which is how you end up with companies paying $$$ for extended support on discontinued HR and financial software.
It's the same reason companies will pay for GSuite and O365 subscriptions concurrently because a handful of departments refuse to give up their desktop applications and others have Excel-based workflows that do not work in Google Sheets and do not care enough to learn Python or find someone in the company who can write a better system.
> You have to review the source of every PKGBUILD from the AUR you install, full stop
I don't really think this is a solution- the usual workflow for these attacks has been to hide your payload in some dependency. This one is somewhat unusual in that it's just a very lazy `npm install` in the pkgbuild. Pretty much every package repository even outside of AUR has this issue now, and it's not really viable to audit the entire dep chain by hand.
Mind you, I don't have a solution either.
> I don't really think this is a solution- the usual workflow for these attacks has been to hide your payload in some dependency. This one is somewhat unusual in that it's just a very lazy `npm install` in the pkgbuild. Pretty much every package repository even outside of AUR has this issue now, and it's not really viable to audit the entire dep chain by hand. Mind you, I don't have a solution either.
This is different though. The attackers of the AUR don't have access to do anything to upstream and any malicious dependency they add would have to be either 1) already built as an official package or 2) also taken from the AUR... in which case the person building it would need to audit the dependency as well.
So you have two "AUR hygiene" principals at play: One, know what software you're even installing, and Two, know that the PKGBUILD does what it says on the tin. If you neglect either of these and YOLO then it's kind of on you.
Arch users should really know that the AUR is something to approach with a massive amount of caution. It's better than "curl bash" from some rando web site, but that's only due to the fact that you can easily audit and diff the payload of the install recipe yourself.
This is an "in addition to" problem though, not an "instead of" problem.
Having code reviewed the PKGBUILD doesn't mean the upstream software is safe to use, having reviewed the upstream software and it's dependency tree doesn't mean the PKGBUILD is safe to use.
Also have realized at some point that reviewing the PKGBUILD and code in github repo still doesn't check whether the github release files are compromised.
> it's not really viable to audit the entire dep chain by hand
When you `makepkg -s`, makepkg will get the dependencies it can from the vetted and maintained pacman repos. Only the dependencies that are not present there would have to be obtained from the AUR the same way as the package you're currently reviewing: git clone, manually review, makepkg, etc.
Having dependencies in the AUR is not that common in my experience. I think I've had rarely 1 or 2 deps in the AUR; maybe once or twice I had like 6 deps. It can happen, and it's a bit of a chore, but it can be done.
Another reason published CVEs isn't a great metric is that one of the largest contributors to the number of CVEs significantly increasing in the past couple years has been that the Linux kernel now submits almost all bugs as CVEs which wasn't the case before.
Good consideration but I still think there’s an uptick. This is all AI generated as I’m not in a spot to do anything more at the moment but this is a chart of ‘linux kernel’ CVEs rated as high/critical correlated with NVD.
It's worth reading this one to the end- the point of this paper isn't about the math involved, it's that this math was the result of the federal funding of maths research.
> The cost-benefit ratio of Mathematical research has been off-scale. The Federal government spends about $250 Million/year on mathematics research. Yet in the US there are 40 Million MRI scans per year, incurring tens of billions in Medicaid, Medicare and other Federal costs. The financial benefits of the roughly 10-to-1 productivity improvements now being seen in MRI could soon far exceed the annual NSF budget for mathematics research
It's the thing people don't get when they see odd studies being funded and try to judge if they're worthy of being funded. Either it's just they don't understand where the study fits into a larger problem or simply that esoteric studies sometimes leads to surprising findings that are far more useful than anyone could reasonable predict.
But have the scans got cheaper?
It’s possibly that acceleration techniques have prevented the cost being greater, but key parts of the cost are not getting cheaper. Staffing costs are just so high.
Pricing a scan based on scanner time doesn’t really work.
Some time ago I wanted the original MS solitaire playing card files. Wasn't too hard to find a copy of the binary, but the interesting thing to me is it appeared the files were handwritten- a couple possible typos in color and not a single byte longer than they needed to be.
You don't.
The normal procedure here is to have multiple unique keys with multiple unique secrets. If one breaks that's it it's broken. This also allows you to revoke a key without removing all keys.
It's not even just that- with component selection you have a handful of datasheets that give you (ideally) fairly truthful information about the device. You can rather deterministically look at these and compare them.
Regular consumer products? Good fucking luck. Anywhere an LLM pulls from is probably going to be mostly SEO'd listicles.
Better than ever! Getting some awareness raised. This whole post should be flagged, and people need to quit crapping on the people of Iran by trying to make this a Trump thing.
