codebje

I am fortunate enough to have both a butterfly keyboard MBP and a touch bar MBP. Obviously the butterfly keyboard has the known issues, but the touch bar MBP also has the very common issues with that hardware.

I can replace the butterfly keycaps myself. It's something like $10 from aliexpress for a full set of keycaps and clips and a minute's work to pop the busted one and replace it. Annoying, but not fatal.

The touch bar needs a full battery, keyboard, track pad, and upper case replacement to fix. I just have to live that that thing flickering brightly at me every day, or spend AU$500+ to get it fixed.

IMO the touch bar is the bigger mistake.

Because LLMs aren't sentient, they don't draw on facts, and they don't have nuance. The answer given is similar to answers you might expect to see for similar questions.

It's really amazing we can make machines do that, and it's really depressing that we think a stochastic bullshit machine is going to give us something we can rely on.

If you have an interpreted language, you don't have a C function corresponding to each language function. You have a C interpreter loop with a "current instruction" pointer. When the current interpreted instruction is a call, you check all the things you need to check, push the current IP to a stack, and set the IP to the first instruction of the function.

C's type checker never sees the interpreted language's functions.

Thanks for the response. I really like the measured, evidence-based approach you're taking to this work.

I have the wrong CPU architectures for pre-built jank packages (x86 mac, aarch64 linux, the exact opposite of 'normal') so I haven't actually looked at what it produces, so my last paragraph was pure speculation. I appreciate the detail you gave!

The article talks about inlining a two-arity call to clojure.core/max to instead be an explicit call to cpp/jank.runtime.max, eliminating the unnecessary argument count matching and recursion portions of the Clojure function.

It also mentions that in Clang the runtime max function will itself be inlined, so that's something LLVM ("the LLVM project", anyway) is still doing - and beyond that, as written this IR is likely to leave behind plenty of opportunities for LLVM to do the things it's good at: DCE, load/store optimisation, constant propagation, etc. And register allocation.

The jank::runtime::max call is itself complex: it's got to type check its arguments and work out what to actually do based on the two types; if parts of these tests are done before the inlined call to max there's a fair chance that LLVM will be able to eliminate their repetition and slim it all down a long way. In the fibonnaci example the fact that a previous test will have likely identified whether the argument is an int or something else should hopefully carry over for ::lte, ::sub, and ::add and simplify those down to just the single operator call - but sadly I suspect it won't at least for the addition, because the recursive call will lose the information that the return value when called with a tagged integer is always a tagged integer.

A future optimisation might be to specialise for unboxed types: far more potential speed improvement over pointer tagging, and IMO quite amenable to analysis with the Jank IR (:metadata tag functions as specialised for <type> with the new entry point, if a function only calls specalised functions (and itself) it too can be specialised, and a heuristic to determine if specialisation gains enough to sacrifice space for it).

There isn't a more expensive Mac option to buy if what you're after is a gaming GPU. It's more likely that the VM team sees this as a very low benefit ticket to pursue given the tiny segment of Mac gamers hoping to improve their options with a Linux VM for gaming.

(Meanwhile, I'm recompiling Wine to see if I can patch it to address an issue that was hotfixed in Proton two weeks ago but isn't in a CrossOver build yet, so yeah, there's maybe some arguments to be made here that I'd be a potential beneficiary. If I weren't too cheap to spring for an eGPU in today's market, anyway.)

DPI can refer to inspecting beyond just the headers, but since it's more of a marketing term than a technical one, you could also say you're "deeply inspecting" the IP headers of a packet and no-one would show up to arrest you for bad terminology.

Anyway, one way to detect NAT is to observe different TTLs originating from one device. Is that deep inspection? Probably depends on who you ask. The fact that you have to track information across multiple packets counts for something, though.

Off the top of my head I wouldn't really expect there to be much value in a MITM inspection of the contents of HTTP traffic for the purposes of NAT detection. You could probably come up with some scenarios in which it might be possible, but I'd content those scenarios aren't very practical. Easier to compare TTLs between packets, say, or track connections to known OS "phone home" destinations. While these just use information from the IP layer, they're stateful observations requiring comparisons across multiple packets, and that might count for something.

One way to detect a shitty carrier service, though, is that they're inspecting your traffic for "good" or "bad" uses of their service, because that is a good indicator that they're not just a carrier. I call it Dickish Practices Identification, or DPI.

Does Qwen3.5 know it needs to do this because the API in question has had loads of churn and much of its training data is on obsolete versions, or do you need to prompt it? How well does it handle having an API reference with sample code in its context window?

Having an LLM use a web search tool isn't the same thing as researching a topic, IMO, because it's so ephemeral and needs constant reinforcement. LLMs aren't learning machines, they're static ones.

Anything that requires server-side storage is a good reason to ask for an account, IMO. Theoretically you could assign a pseudo-account and store the id in client storage to have a shareable profile, but then you'll have to figure out how long you'll retain idle pseudo-accounts. (Assuming that completion detail is in client storage, at least for anonymous players).

A consequence of me being a freeloader too is that you don't have to change your plans to please me :-)

Both of those are cool projects!

I've been playing this since it was first mentioned on HN a few puzzles in. It's a nice idea and pretty well executed.

I have, however, rejected making a user login. I recognise you're putting in time and energy to make something I'm just taking without payment, and it's your right to try to leverage it into something more - I wish you all the best in doing so - but asking for a user login as a gate to a feature you clearly don't need a user login for is enshittification.

To me a "stop watch" is a type of watch, that's straight forward. But there are other clues that rely on cultural references I'm not familiar with - and that is, I think, inevitable in this type of game. We all have different backgrounds and there's no universal shared understanding that would make every clue the same difficulty for everyone.

I saw someone on here recently say they like to do the puzzle without looking at the clues, and I've started doing that on and off too, it changes the game in an interesting way.

It depends on the purpose for the model. AFAIK LLMs aren't particularly capable at researching answers, relying more on having 'truth' baked in to their weights, so if it takes 12 months to train up a crowd-trained LLM it'll be 12 months behind the times.

How serious a risk is poisoned weights?

Can we leverage the cryptobros into using LLM training as a proof of work?

Baidu have a lot of services I've never heard of, that are highly successful in China. The lack of interest in expanding into Western audiences doesn't seem to matter there - what's different about inference?

I'd expect unified memory architectures (Apple M-series, AMD Ryzen AI series, etc) to be the future of local inference, not GPU cards.

Brain drain.

If you fire all your SWEs they won't sit around twiddling their thumbs waiting for an AI collapse, they'll career shift. Maybe to an unemployment line and/or homelessness, maybe to something else productive, but either way they'll lose SWE skills.

If you close down all the SWE junior positions you'll strongly discourage young people training in the field. They'll do something else.

Then if you want to go back, who will you hire for it?

Hah, I like that: the main benefit of monads is turning your functional language back into an imperative one...

IMO it's because option is a monad, list is a monad, io is a monad, async is a monad, try-except is a monad, why invent different magic syntax and semantics for all of them when there's a perfectly good abstraction that covers the lot, and that lets you write functions that are agnostic to which particular monad they're in to boot.

Not the parent, but the only thing I really hate about 1Password is that I can't tell it to never offer to save a specific site's password. I can turn off all offers to save passwords, or I can have the stupid pop-up ask me multiple times a day if I want to save that password. The pop-up chases me across the site until I get rid of it. Aarrgh. Blood boiling. Rage overflowing.

Other than that it's fine, I guess.

That is exactly where I am.

We're putting other providers through the gauntlet. An M4 Studio or two running the latest Qwen3 or whatever counts for state of the art in open models is also looking a little more viable all the time.

Using a proof language with an SMT solver is basically that: an inexplicable tick that it’s fine, until a small change is needed, the tick is gone, and nothing can say why.

I love freeform wire circuits.

I could believe a ~66% success rate on asking an agent to run a linter and make PRs addressing issues found, that sounds about right: very tightly bounded problem, a sensible solution is often offered by the tool, and verification of success is binary.

Structural changes, in which attention to the small details of a task is directly at odds with the need to consider less overt factors like cohesion and coherence, are where an agent will turn your code base into a dog's breakfast.

The vibe coded software I have for my own use only is like that. Giant hundred-line functions, poor separation of concerns, easy for a change to have unintended behaviour somewhere else. It's probably a step up from the spreadsheet I was using before it, but not by enough to justify current RAM prices.

Those chips need to be scanned from about 3cm away. If you want a locator tag, it needs to carry enough power to broadcast a signal a useful distance. Still, a microchip is handy if you're not sure if it's your tiger you found.

Both of those products are out of stock.

ZeroID looks like a good idea to me. Lots there I'll be digging into over time, and related to the use of token exchange for authorising back-end M2M transactions on behalf of a user at the front-end.

As far as I can tell the parent post is talking about discovery for agent-to-agent communications, which is not something I have much interest in myself: it feels very "OpenClaw" to replace stable, deterministic APIs with LLMs.

This isn't the only thing you'd want to do.

I use containers to isolate agents to just the data I intend for them to read and modify. If I have a data exfiltration event, it'll be limited to what I put into the container plus whatever code run inside the container can reach.

I have limited data in reach of the agent, limited network access for it, and was missing exactly this Vault. I'm relieved not to need to invent (vibe code) it.

That'll stay true for consumer software, because the cost for extra resource usage is not borne by the development house.

That's only true if you consider the process the LLM is undergoing to be a faithful replica of the processes in the brain, right?

Why would that be curious? The network is trained on the linguistic structure, not the "intelligence."

It's a difficult thing to produce a body of text that conveys a particular meaning, even for simple concepts, especially if you're seeking brevity. The editing process is not in the training set, so we're hoping to replicate it simply by looking at the final output.

How effectively do you suppose model training differentiates between low quality verbiage and high quality prose? I think that itself would be a fascinatingly hard problem that, if we could train a machine to do, would deliver plenty of value simply as a classifier.

Regular expressions are definitely enough for turning characters into tokens, after which a simple recursive descent parser is vastly more straightforward to write. Lexing is optional, but generally advised.