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.

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.

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.

"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.

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.

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?

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.

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

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 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.