"Coding is solved" is a very high bar, and current-gen AI/LLM is very far from that.
Where AI did make alot of impact is triage. I can throw a messy bug report of an intermittent issue at claude, and tell I need issue reproduced and fix developed, and there is a well above 50% chance it'll deliver. Never commit that fix to the codebase as-is, of course.
Are you saying they're blocking the `User-Agent`? Because that's trivial to bypass. I'm not exactly sure what you mean by "Chromium" because that's a whole class of browsers (Edge, Brave, Chrome, etc. are all forked "Chromium" browsers).
Aliexpress specifically uses a javascript blob to do detection, and quite a sophisticated one. There was a recent story about that blob messing with bluetooth headphones.
Here's my agentic Chromium browser browsing Aliexpress[1]. Usually I'd run it in headless mode, but wanted to test and make sure I'm getting the website proper.
It searched for "Aliexpress" on Google and clicked the link, hence the Google UTM params.
And the worst part is humans just getting more cognitively demanding captchas.
Some days I'm literally fatigued enough I can't clear the overly complex hCaptchas these days I keep getting forced upon me and bots sail right through this crap.
Agreed on inevitable collateral blockage of real people using real "headed" browser. I'm getting a ton of that already, personally.
Throttling is poor help though. Mass scrapers are using "residential proxy" loophole + rotating UA and other attributes. You can't throttle somebody without identifying them. Unless you're talking about a global rate-limit.
throttling based on sessions kind of works; we're headed in the direction that sites like Reddit will probably prevent logged-out users from viewing threads (as they already do with mobile devices)
Once the LLMs create sockpuppets to get around that, the web services will need to resort to profiling users more aggressively so that they know which actual human an account corresponds to.
If someone has a malicious browser extension that uses their session to scrape Reddit then, they're probably going to see significant usage obstacles.
That stuff is choke-full of carbon and silica, and is brittle as hell. To get it malleable (which is actually desirable in a weapon, so it wouldn't just snap in use), there is a separate process to decrease carbon content:
>Isn't that backwards? Surely "primitive iron" was closer to what we call pig iron nowadays.
You're under the illusion that the west used kilns to melt iron into a liquid that they poured into a crucible during the Bronze Age. That's actually an ancient Chinese technique that was adopted long after the western Bronze Age ended and it does indeed create pig iron. But the west only adopted pig iron as an intermediate process for making steel starting in the middle ages.
Back then you just put the crushed (via hammer) iron ore and coal into a clay kiln (a bloomery). Because these furnaces couldn't reach the melting point of pure iron, the metal never liquefied. Then at the end you basically had mostly slag with some small iron pearls inside (a bloom). You had to hammer the slag off the iron under heat. Hence primitive wrought iron came first and because it had low carbon it was highly malleable.
The technique that was used to make primitive steel was very simple. In fact, it is basically the same process as was used to get the iron out of the ore. You make a steel tool with malleable wrought iron, pack it with powdered charcoal and seal them both inside of clay. You then heat up a kiln and the carbon diffuses into the outer surface of the iron. This process is known as case hardening.
Also you just linked an article that just told you everything I just wrote from memory:
>While the bloomery process produced wrought iron directly from ore, cast iron or pig iron were the starting materials used in the finery forge and puddling furnace. Pig iron and cast iron have higher carbon content than wrought iron, but have a lower melting point than iron or steel. Cast and especially pig iron have excess slag which must be at least partially removed to produce quality wrought iron. At foundries it was common to blend scrap wrought iron with cast iron to improve the physical properties of castings.
Yeah, so bloomeries produce wrought iron directly hence wrought iron came first.
No, it's not backwards. The modern steelmaking process starts with iron that has too much carbon content that has to be removed; the premodern process was the other way round. See A Collection of Unmitigated Pedantry's excellent series explaining premodern iron and steel production: https://acoup.blog/2020/09/18/collections-iron-how-did-they-...
Historically speaking, between average Android device and average Chromebook, latter is far easier to get mainline kernel + "normal" Linux distro running, e.g: 8 Chromebooks vs. only 1 Android device (and even that is a dev. board) in official Arch supported hardware list:
ALARM isn't official Arch, so this also isn't an "official Arch supported hardware list". Arch is currently still only x86_64 and everything else is at best unofficial if not just straight up unaffiliated.
(do note that this might change soon-ish™ considering [0], but I think they want to first get their automated build infrastructure ready)
So Arch on ARM is basically limited to an SoC with at most 8GB of RAM? It looks like we are still very far from a mainstream ARM motherboard with a socketed CPU, upgradable RAM and support for discrete GPUs. Until then, I see no reason to move away from x86.
"Need" might be a bit too strong, but I do want overly obnoxious guardrails not to stand in the way.
Case in point, last week I was poking Opus 5 into writing me some RPi-pico firmware for driving a small e-paper screen. Font was built in right into C code as hex constants. Space being tight, I asked if there is some clever compression that could be applied. Claude thought for good 10 minutes, then guardrail kicked in telling me that was "cyber", and refused to continue.
Just apply to the cyber program? I got in in around 2 hours, and I'm just some hobby hacker, not some paid security consultant. It is a valid point though, I'm doing tons of systems and embedded stuff and was hitting the safe guards with Claude and Codex before getting into their cyber programs (hex REALLY triggered Claude in particular, which was amusing).
Fair point but you get that only for 252GB of ram so it’s not even “totally better” than a Mac Studio ultra with 512GB RAM. It still the old “smaller but faster than a Mac” stuff nvidia sells.Maybe in 1-2 years they will match the Mac 512 but then Apple will release an even bigger Mac
> model to add new vulnerabilities to your code so it can present you with more exciting findings.
Not so sure about this level of 4D chess capability just yet. The other day I asked Opus to come up with some cleverly vulnerable crypto code "as a good, hard challenge for an IT security student", and results were quite mediocre.
And by mediocre results I mean that 3 "cheap" models out of 3: qwen3.8-27b, glimmer, and luna - all were able to find every problem planted there, with fairly little steering, and no spoilers.
Let it iterate, give it access to the cheap models, and tell it part of the requirements is that the cheap models shouldn't be able to solve it with such and such a prompt. I expect it will be able to zoom in on something.
One shot generating a problem of exactly the difficulty the user has in mind is a very difficult problem for anyone. "IT security students" span a wide range of capabilities, but I would expect most of them are worse than qwen3.8-2.7b at this kind of work.
Yes, you asked it for a good, hard challenge for an IT security student. I'd suggest checking if it succeeded by asking an IT security student, and not an LLM.
Students are still learning, and have not been trained on vulerabilities. Qwen, glimmer, and luna have been. LLMs are largely better than IT security students at finding vulnerabilities. In many aspects, they're better than IT security experts at finding vulnerabilities.
Train it on human content, get human emulating behaviour, including all the perverse incentives and bad acting we see from people, fictional or otherwise.
> all were able to find every problem planted there, with fairly little steering, and no spoilers.
Given that LLMs prefer output of LLMs (of the same LLM and of others) [1], can it be the case that they generate "hard challenges" from the manifold of challenges solvable by (other) LLMs?
I would worry more about 5D chess or 6D and even 7D chess. This article talks about teaching models to be good and methods that could train goodness, but it sounds like there are some unsolved problems to graduate to 8D+ chess.
Zram also supports a block device for pages that do not compress. So the primary advantage of zswap is that one can use its swap for hibernation while it does not work with zram.
Zram support for a block device is quite misleading, since there are no automatic mechanisms for enabling this. You have to build your own daemon to scan pages and take action on them. Zswap doesn't have that problem.
Not "a" bank. You (somewhat) trust your bank, I would imagine. Since you know, they have your money.
GP's hypothetical here is that Anthropic or other service provider who wants to do "age verification" could partner with (among others) your bank [1], where bank can answer yes/no to "is this user >= 18?", without revealing any other personal info to the SP. Allegedly.
[1] via an intermediary, no doubt. Trying to do a "full-mesh" of partnering of every SP with every bank directly would not scale.
You may trust them with your money, but does not equate to trusting them with anything else. Principle of least privilege, if you will. Anthropic has your chat data, which in many ways is more valuable than money, so if the only bar for free lying giving out your personal details is trusting a business with something of yours then why bother with this complex scheme and give Anthropic all of your personal information directly?
> Banks by law require substantial PII in order to even do business with you.
That is technically true, but keep in mind that in the early days of banking banks expected you to provide that information without the hand of the law requiring it. The laws you speak of came into effect after the fact to normalize across the industry what the banks were already doing. History is repeating itself in tech, and we already know lawmakers are waiting with bated breath to do their thing all over again just as they did in banking once critical adoption is there.
I expect what you are trying to get at is that you are willing to trust a bank because giving them your life story was already normalized before you were born, so you have never thought to question it. Whereas tech doing the same now feels new and scary. However, that's a funny way to look at it as the kids born in the future, who never knew the world where you could use the internet anonymously, will see giving tech their ID as being no different than how you see giving your bank your ID.
Although I can understand why you would now question why any business that does little more than store numbers on a computer needs a comprehensive profile on you by law or otherwise. Normalized does not equal sensible. That is a fair point.
> Banks by law require substantial PII in order to even do business with you.
And those laws are extremely invasive and should be repealed. It's offensive to have a law that de facto requires you to identify yourself in order to pay for a newspaper subscription or buy contraceptives over the internet.
But that's not the issue in this case. It's that the bank knows your name and what you buy -- already very bad -- but now you want to create a path to tying that information to everything you do on the internet.
Gift cards don't allow reloading which consequently makes them a significant inconvenience to use for subscriptions. It's sort of like saying you can pay for something by going to their offices and paying in cash. Okay, but then why does the way that 99.9% of people are actually going to do it have to be the one that invades their privacy and puts everything they do in a database?
> You may trust them with your money, but does not equate to trusting them with any other personal information.
How do you expect that they will give you your money when you walk in to a branch and ask for a withdrawal? Or that they'll replace a lost card? Surely you'd expect them to verify your identity.
Well, how do you expect a website to know that you are 18+?
The technical solution offered earlier was to have a trusted third-party only be willing to answer the "is this person 18+?" question. Of course, the same works for banks. The trusted third-party can answer "does this person own this account?" without needing to reveal to the bank any other information about you.
Now, that still leaves open the question of who you can trust. If you can trust a business run by people then that allows you to trust a bank, sure, but it also allows you to trust a tech company, so why not just give the tech company your ID and skip all that technical complexity? Understandably the broader idea presented earlier was that you cannot trust businesses operated by people, but then that includes banks, so...
For the sake of discussion, if we accept that technical solution and the need for a trusted third-party that is a business run by people, surely it should at least be a business that does nothing but offer profile trust to minimize the blast radius? For what reason would we want that business to have their hand in other activities like chat or banking?
> Now, that still leaves open the question of who you can trust. If you can trust a business run by people then that allows you to trust a bank, sure, but it also allows you to trust a tech company
Banks are subject to much stricter regulation than any tech company is or ever will be (IMO, I could end up surprised).
I trust my bank to know who I am and keep track of my money. I trust big tech to lose or misinterpret my data, to close my account for no reason, etc, and to face zero consequences for those failures -- not even fines.
> Banks are subject to much stricter regulation than any tech company is
That's true, but remember what we're talking about: Using banks (or another trusted third-party) to assert your age instead of having big tech collecting your personal information themselves. There is context here. Writing comments in a vacuum makes no sense.
In that context it is understood that only incentive for big tech to follow the proposed is regulation, but if you are going to push regulation on them then you can regulate them just as much as banks.
Your broader point that, in the real world, there isn't much political will to push any of that regulation is also no doubt true, but, again, writing comments in a vacuum makes no sense. The hypothetical of big tech adopting a third-party attestation system was already understood to be just that: hypothetical.
They could verify your identity if you've given it to them.
But it would also be completely reasonable to authenticate the customer exclusively using mechanisms other than government ID. You can already make a withdrawal using your bank card and PIN. If you lose your card you could sign into their website using your password and request a new one etc.
Consider what happens if you lose your government ID. Your bank has much better ways to authenticate you at that point than the government does. Government ID has a major bootstrap problem, whereas patronizing a service doesn't because a new account with no money in it belongs to whoever is signing up for it regardless of who they are, and you can at that point give them a bank card and have them provide a password and email address etc. that allows you to identify them in subsequent transactions without ever needing their name.
Where AI did make a lot of impact is triage. I can throw a messy bug report of an intermittent issue at claude, and tell I need issue reproduced and fix developed, and there is a well above 50% chance it'll deliver. Never commit that fix to the codebase as-is, of course.