yetanotherjosh

I'm not sure what kind of point you're trying to make. There are projects to train competent modern LLMs in which the entire pipeline (data, training process, final weights) is all completely transparent, shared, and reproducible by anyone with the compute to try it out.

Or is your definition of "open source" mean that a small indie dev should be able to reproduce the entire pipeline? Because that would disqualify more than just LLMs, but also hardware platforms like Arduino where you need to pay for manufacturing to get the underlying stuff built... is Arduino "open source?"

Olmo 3? K2 V2? There are definitely LLMs with very compelling capabilities where the dataset, training process, and final weights are all open. There are also initiatives in the EU and various national government levels (e.g. Switzerland) to develop LLMs in an open and transparent way, not just "open weights."

I experience this too, but the danger is is making assumptions based on "tells" which might just be how the user wrote the post. It's a situation now where if someone authentically writes something, but happens to rub up against some arbitrary "tell," they flip a bit in the reader and get their work rejected. For example, I used em dashes fairly regularly in my writing before AI started convincing everyone that the mere presence of an em dash is the AI tell, so I actually stopped using them, just to avoid this backlash.

The real problem is not terms like "load-bearing," which communicate clearly enough. It's the constant invention of cryptic shorthand terms and phrases that have no referent, and end up acting like a puzzle to be decoded. This is often paired with hyphenation, but not always:

"The current behavior paper" -> The behavior in the running system that was previously described as papered over.

"Marker transport over-claim" -> The inaccurate review finding on the object's sentinel flag in the API response.

I suppose the cryptic/invented language problem is about token efficiency? But this sort of token efficiency is extremely difficult to deal with when it comes to conversation with a human about complex system. It might be efficient inside reasoning blocks, but when the model generates the final turn text, it should avoid this, as it's brutally inefficient due to the time spent wondering what each uniquely coined phrase means and having to ask for constant clarifications, which then you have to wait for another turn, eating up time and context while it burns more xhigh reasoning just thinking about how to explain its own awful language.

There is nothing called "GPT5.5 Codex" unless I've completely misunderstood OpenAI's product line?

Codex is a harness, while GPT-5.5 is a model. The last codex-branded model was 5.3. Codex as a harness ships as a CLI, a desktop app, and a web product (and I'm not at all sure how similar the underlying harness is between them.)

Is the bug here supposed to be with the CLI harness, or the model? Does it also happen in pi, opencode, etc while running GPT-5.5?

Kinda reads to me like: "I'm not worried about prompt injection anymore because I setup a test where my agent could just ignore the input channel as noise, and a bunch of comically simple attacks thrown at it didn't succeed."

To be fair I appreciate the effort of running and sharing the test. It will hopefully lead to better ones. But this is not a great test. Super interesting to think about what would constitute a better test.

For one, I think the agent would have to be expected to have productive interaction through the email channel, in a way the user depends on it generally working for some real world use case / value prop. In other words, needing emails to actually have the agent really do work, respond with results, etc. Also, most requests should be legit and the real attacks should be intelligently disguised, not pitiful/joke-level spam (although those would be arguably realistic to have in the stream, but, perhaps only as deflection so that the real attack is mischaracterized.)

Well said. This experiment is extremely unrealistic and gave the model the opportunity to simply refuse to deal with the channel outright. If he had built it to be a functional agent that depends on real interaction via email and occasional mixed attacks (and attacks that were better designed than the pitiful examples given), this would have gone differently.

From the article:

LongMemEval rewards recovering literal witnesses: exact dates, counts, preferences, and spans that often remain stable under tokenization.

Is this saying they chose a benchmark that is biased towards doing well against literal string matching, thus works well with grep, and then (gasp) showed that grep did well, finally declaring "grep is all you need"?

The examples in the benchmark's demo image(1) are all examples you could see grep doing well on. A conversation about bikes, then a query about bike(s) where "bike" is a common token hit. But not stuff like a conversation about a Beethoven sonata, then a question about classical music, where embedding based approach would shine.

(1) https://github.com/xiaowu0162/LongMemEval/blob/main/assets/l...

How is this not a Github P0? Can anyone explain?

When I read that, I thought they must be using 'fork' wrong, and actually mean branch on the official repo, as that can't be right!?" Good lord.

I practiced the Buteyko method for many years when I was in states of high anxiety and frequent panic attacks, and it was incredibly helpful. I had a syndrome called new daily persistent headache, which means a sudden-onset headache that becomes constant from that instant forward, as in 24/7, for years. It's hard for people who haven't experienced that to understand I mean that literally. Buteyko breathing was the only thing that ever cut down on that headache, and a couple times I was able to suspend it for an hour or two, which when you have a literally constant headache for years, is a big deal.

My big takeaway from it was that breathing and neurological state are deeply connected and actually relaxed, natural, healthy breathing (and the corresponding state of the brain and nervous system) is something that most people have probably never even experienced unfortunately. We all think our state is normal, but I assure you, it is very far from the state where your control pause is 40s-60s or more, it's a radically different experience.

Also the nuance of what the control pause and how to measure it correctly is lost on I would say, even most people who attempt to learn Buteyko. The control pause is how long you can, under normal breathing, suspend breath with zero discomfort, and then prefectly resume normal breathing without any change from before. If you took a bigger breath to start, or when you start breathing again it's even slightly heavier, it's not a control pause measurement, it becomes an ego metric juiced to make you feel better about a number while avoiding the disappointing facts.

Buteyko claimed that healthy breathing had a 40+ second control pause. Which if you think about the real meaning and how to measure it, is a super long time. And I got there sometimes, it's a major learning experience about what deep alignment and relaxation of the brain/nerves can really feel like.

Buteyko practioners build up the ability to work very hard while only nasal breathing over the long term. The point is to learn to modulate breathing in a way that keeps a certain kind of blood chemistry (CO2 levels) and cellular oxygenation.

If you commit to nasal breathing for exercise as a constraint, it does force you to modulate your exertion while also increasing your CO2 and developing, according to the Buteyko folks, a new baseline for respiratory health and capability.

If you're running for your life from a tsunami, by all means mouth breathe. If your purpose is maximum exertion, of course mouth breathe. But that's not the only possible purpose of exercise. It can also be about respiratory training. Nasal breathing becomes a natural guideline/modulator for long term improvement in that regard.

I struggle to understand what this specifically has to do with rails or global IDs. In ANY framework or query system, if you are asking an LLM to produce IDs which you are then passing to a database for lookup, you need to understand those identifiers could be hallucinated or incorrect in surprising or malicious ways, and can lead to data leaks or exfiltration.

It's like writing an article about "the dangers of PostgreSQL" ... when generating SQL from an LLM. It has nothing to do with Postgres specifically, it's that you're generating queries to run in a trusted context from an untrustable origin.

I don't understand how code review would catch this. The extension advertises itself as an AI protection tool, that monitors your AI interactions. The code is basically consistent with the stated purpose. That it doesn't stop collecting data when you turn of the UI alerting is perhaps an inconsistency, but I think that's debatable (is there a rule in google's terms that says data collection is contingent on UI alerts being enabled?). I'm curious what workflow or decision tree you'd expect a code review process to follow here that results in this being rejected? The problem here doesn't seem like code related, it's policy related, as in, what are they doing with the information, not that the extension has code to collect it.

So you can get native behaviors when it’s critical. Like share sheets, push and many other critical features that only apps get even if the bulk of the experience can be done in a webview. This is because mobile OS platforms choose not to make these available to web apps, because app store profits are better for them than an open ecosystem where sites can do the same things as apps.

.95 is quite generous here

Yes "good" caching - a consistent storage interface - is an abstraction over "bad" caching - multiple different storage interfaces with different speeds. But caching overall is not an abstraction over not having caching.

Why?

Astroturfing alert. This comment author is also the author of cursor-agent-tools.

ollama is stating there's a difference: https://ollama.com/library/deepseek-r1

"including six dense models distilled from DeepSeek-R1 based on Llama and Qwen. "

people just don't read? not sure there's reason to criticize ollama here.

don't confuse the actual R1 (671b params) with the distilled models (the ones that are plausible to run locally.) Just as you shouldn't conclude about how o1 behaves when you are using o1-mini. maybe you're running the 671b model via ollama, but most folks here are not

"Looking cool" IS a component of UX. UX includes the user's emotional experience of using the product. It is 100% acceptable to do something for UX that is otherwise bad "UI". While you talk about UX here, you really mean UI, because the UX is arguably improved at least for some audiences, who are more positively affected by the dimensionality and light-conscious design the effect brings than negatively affected by the readability downside.

In the bigger picture, people use products to perform a function that often includes how they feel in and about themselves while using it. People buy cars to tell a story about who they are. People buy coffee and sit at a cafe in order to get a moment of peace or some internet access. People wear shoes that are a little less comfortable in order to get compliments on them. This is not bad UX. This is literally the meaning of good UX - paying attention to what people actually want versus the minutia of objective functionality.

So this identifies keys from source and target objects that are fuzzy synonyms and copies the values over. What is a real world use case for this? Add the fact that it's fuzzy and won't always work, so would require a great deal of extra effort in QA/testing (harder than just mapping the keys programmatically), and I'm puzzled.

It seems to me that the "knowledge graph" generated in this article is incredibly naive and not comparable to the process in the MS paper, which requires multiple rounds of preprocessing the source content using LLMs to extract, summarize, find relationships at multiple levels and model them in the graph store. This just splats chunks and words into a vector graph and is barely defensible as a "knowledge graph".

Please tell me I'm missing something because this is egregious. How can you expect a graph approach to improve over naive rag if you don't actually build a knowledge graph that captures high quality, higher level entity relationships?

A key part of avoiding MITM is to get the values from an authoritative origin, not comments on HN, so the link is here:

https://docs.github.com/en/authentication/keeping-your-accou...

Yes, this assumes the github-hosted docs and your SSL connection to them are not also compromised, but it's far better than not checking at all.

That key didn't change and is listed here https://docs.github.com/en/authentication/keeping-your-accou...

Please before replacing your local fingerprint with the new one, double check it is the expected value. This is an opportune time for man-in-the-middle attackers to strike, knowing everyone has to replace their stored signatures, and that some will be lazy about it with a blind "ssh-keygen -R github.com" command.

Even outside private browsing, Firefox has a feature called "total cookie protection"(1) which in a nutshell creates a separate cookie jar for every domain, so that third party cookies "work" but are not actually the same cookies if you change to a different site that uses the same third party. This would be entirely self-defeating for Chrome to do that, as it would substantially hinder the ad system's ability to build a comprehensive behavior profile and to know that while you're on site A that you also shop and buy on site B. Again this is now the default behavior in Firefox, not even a special mode. Mozilla as an org really is a good guy doing good things in the fight for online privacy, safety, transparency, etc. Not that I think Google is evil, it's just a different business with different customers with different concerns.

1) https://blog.mozilla.org/en/products/firefox/firefox-rolls-o...

Are you interested in learning a potentially new and more efficient way of doing things? Then you have to stop being annoyed that your habitual way of doing things is unavailable to you, and stop assuming your habits are the obvious and correct way.

The modal nature of Vim is one of it's key features and makes a lot of sense. If you consider the keyboard the primary, if not singular, means of interaction, then there will be times you want to use the keyboard to type text and times you want to use the keyboard to control the editor behavior. In a "normal" editor, you have to use modifier keys to enter commands. In Vim, you do it by changing modes. It's actually quite powerful but you can't get past your own assumptions about efficiency.

a harder way of doing things initially in exchange for incredibly small productivity gains that when applied millions of times over the course of a programming career, make a monumental difference

A key ethos of Vim is that once you climb the initial learning curve, you're on a path of increased efficiency for the long haul. Moving the hand to the mouse, dragging the cursor to the spot you want, then moving the hand back to the keyboard, is objectively slower than key-based movement commands for someone who has climbed the learning curve and I'm confident that could be proven empirically though I'm not aware of any such proof. There may be certain exceptional cases where the mouse is faster, but for most editor usage it would not be. I'm not sure if you agree w/ that and are just criticizing how tutorials introduce people to Vim, that they should start w/ the mouse to lower the learning curve, which might be an okay argument.

k8s is just one component of the whole architecture, yet people talk about it like it's the singular defining characteristic. It reminds of people talking about building "react apps" when react is one of probably hundreds of essential library dependencies and says nothing about 80% of the tooling. In my rig that I manage in a startup of 2 people, k8s (managed EKS on AWS) is the part that generally just works with very little effort. I provision and deploy to it with terraform and helm. The cluster itself is cattle. I can spin up a second identical cluster with a config file, cut dns over, then spin the old one down. It took around 3 weeks to get everything setup, but k8s was not the hard part, it was making all the OTHER decisions and integrations for things like container building, monitoring/logging/apm, secrets management, setting up a VPC correctly, writing some custom config scripts to generate the right setup for the 2 separate apps we run in both staging and production, etc. The work was undoubtedly far greater outside the k8s domain. In fact when it came to the k8s parts, e.g. defining services, ingress, etc, I was generally relieved and pleased. And now that I've done all this, I feel comfortable repeating it. Things run quite well and I have zero pressure to migrate.