wilkystyle

Whereas previously, creating this amount of code by hand would simply result in RSI.

Good point. The power and compute time would be put to much better use in one of Sam Altman's datacenters.

I definitely agree with this. Literally the only time I use lisp is when working on my Emacs configuration, but after almost 20 years of using it to write all sorts of functionality from big to small things, just having the exposure to lisp has really helped expand my thinking about programming in ways that working with e.g. C, Python, Rust may not have.

One last thing on the Vim emulation front: While I'm not a big fan of VSCode, the VSCode-Neovim extension[0] connects to an actual Neovim instance via Neovim's MessagePack-RPC API, allowing you to use real Neovim but native in VS Code. Pretty cool!

0: https://github.com/vscode-neovim/vscode-neovim

(not the person you are replying to)

I am primarily an Emacs user, using the standard key bindings (and a whole bunch of custom bindings and functions I've built on top of it over the decades, ctrl remaped to caps lock and no Emacs pinky so far).

But I am also 80% a NeoVim and Vim user for about 15 years now, and I consider myself quite proficient with Vim keybindings. The Emacs emulation is truly incredible, but the fact that Vim implementation quality varies wildly from environment to environment is extremely frustrating to me. For example, the jupyterlab-vim plugin is so jarringly broken in a handful of ways that it completely knocks me out of the flow of whatever I was doing when I encounter those emulation failures. IntelliJ's idea Vim plugin is a pretty decent one, but even there I have encountered the occasional issue [1][2][3]. Otherwise, I strongly agree with your point about learning one way to work with text and being able to leverage it most places.

Sort of a tangent, but I think this is why Emacs users tend to end up trying to do as much in Emacs as possible: It's not really the keybindings but the fact that everything in Emacs is a text buffer. Emacs owns the input and the output, and because everything in Emacs operates on text, you can do most everything in most every mode, to most any buffer content. One example of how powerful this can be is the ability to press a key and use dabbrev-expand to autocomplete shell input I'm typing based off the shell output of a prior command.

1: https://youtrack.jetbrains.com/issue/VIM-569

2: https://youtrack.jetbrains.com/issue/VIM-636

3: https://github.com/JetBrains/ideavim/pull/33

Unrelated to the content of the article, but what a wonderful site text.npr.org is. It looks like a slightly enhanced version of my iPhone's reader mode and it displays instantly, scrolling with no lag, stuttering, or dynamic loading of page elements.

I wish more of the web were like this.

It's a great point! The 2015 has been a linux machine for ~5 years, and the 2012 is my wife's laptop, used once every couple of weeks. Trying to get her to upgrade to a MacBook Neo for this exact reason.

Agreed with all of this! To date, agent-shell.el is my favorite AI coding experience.

Similar experience. In active use in my house:

    2012 MacBook Pro
    2015 MacBook Pro
    2019 MacBook Air
    2020 M1 MacBook Pro

The longevity is incredible.

> On the other hand, the "wheeled platform powered by a box of controlled explosions" doesn't get close to capturing the impact of the car on individual freedom, the environment, the economy, and more. So if someone was saying "there's nothing to talk about here, it's just a box of controlled explosions", we can safely ignore that person too.

This is also a good point, and I agree with you 100% here. I don't think one could responsibly argue that the impact and consequences are not significant, regardless of if they believe it's near AGI or it's just fancy next token prediction.

I think the point, with a more charitable reading of the parent comment, is that people forget the fundamental underlying technology and its inherent limitations.

"It's just a four wheeled platform powered by a box of controlled explosions" isn't a terribly useful description of a car until you get into a conversation with someone who thinks their car is depressed because it spends most of its time locked up in a garage.

> are you actively pointing your LLM at the kernel to identify security bugs?

I am not actively pointing my LLM at the kernel in the specific way that would uncover these bugs, and just because it's possible to do so doesn't mean that it has happened already.

> the policy wasn't made on a whim. to quote the linux security team [...]

Great, so let the ones that arise simultaneously do so. What does that have to do with immediately publicizing a vulnerability, regardless of severity, just because an LLM was involved in its discovery?

> the term responsible disclosure is a silly thing made up by vendors

That's certainly an opinion you're welcome to have, but unless you are proposing that responsibility and disclosure are two orthogonal concepts I don't see what that opinion has to do with anything I've said.

No. I have an LLM and didn't discover it. Folks in HR have LLMs but can't produce the same software you can. Just because an LLM could discover it does not mean that it has been discovered yet. Responsible disclosure is still a valuable thing.

Yes, and I did qualify my comment with "if you can use uv"

I took the parent's comment to mean "brutal" as in an absolute burn/roast.

If you can use uv, try the --exclude flag, e.g.:

    uv pip install -r requirements.txt --exclude excludes.txt

excludes.txt is basically like an inverse requirements.txt. Your requirements.txt could have this...

    pandas
    scikit-learn
    matplotlib

...while excludes.txt has this...

    numpy

... and uv would resolve the dependencies in requirements.txt, excluding numpy from the dependency graph entirely and ignoring any dependencies that would have been introduced by numpy itself.

EDIT: You can also configure this for uv directly in a pyproject.toml file:

    [tool.uv]
    exclude-dependencies = ["numpy"]

> in practice the MOE models with few active parameters are just faster and easier to run without too much loss of intelligence

Is this true for coding tasks? Genuinely asking because I don't yet have the hardware to be able to run/compare. I thought I remembered the sentiment that the 27B dense was better than the 35B MoE

In an attention layer, the query, key, and value are all computed at inference time using weight matrices that are determined as a result of the training. If X is the token representations entering the attention layer, then each of Q, K, and V would be determined by multiplying X by the corresponding learned weight matrix for queries, keys, and values:

Q = XW_q

K = XW_k

V = XW_v

From there, you can think of K and V like keys and values in a Python dictionary, and Q as the key you pass (e.g. d[Q] in Python to return some value V). The difference in an attention layer is that the query is matched to each key using a dot product, and rather than getting a single value back you get a weighted sum of values.

go on...

Siri IS bad at many things, but the Reddit post is not a particularly compelling example. I am continually astounded by the fact that Apple has had an on-device voice assistant for 15 years, on a vertical hardware/software stack that they own completely, and yet which cannot reliably perform even the most basic tasks.

Inconsistent capabilities: it can toggle do not disturb, but not "silence unknown callers". It can disable auto-brightness but not automatic screen lock.

Completely brain-dead responses even within things it is capable of affecting: "delete all alarms except for my 7:30 AM alarm" → "I deleted your 7:30 AM alarm"

And even with features that actually do work, subtle details of that feature inexplicably change over time, and they happen to be details I was relying on: asking Siri to set an alarm for a given time used to respect whatever ringtone I had last chosen (and which IS respected when I physically tap the + button to add a new alarm), but sometime over the past five or so years it switched to creating alarms with the default sound.

And so many more things that I can't recall the top of my head right now. Siri is an inexcusable failure by a company that supposedly prides itself on user experience and which has had every opportunity for a decade and a half to do better.

edit: One more I just remembered. For a decade, me saying "call [WIFE'S NAME]" would 100% of the time result in my wife being called. Back in the spring, Siri inexplicably decided to call the number of a woman I hadn't seen in the past decade, and whose name is pronounced the same but spelled differently. I had to delete that contact from my phone to be able to call my wife again using Siri.

Why? What does this comment have to do with the post?

Why is this downvoted? I also started seeing this a couple months back.

Appreciate the response. I would only really be interested in the multiplexer aspect, as well. The SSH support does sound pretty cool. I am a long time tmux user, and I have a pretty refined/customized set up that works really well for me. Was mostly just curious if there was anything major that I might be missing out on in these new platforms.

Gotcha. I'm a long time tmux user, and I do have all of this working really well for me. I also realize that is due to years of refining my setup, and that better defaults/easier setup could be very valuable to a newcomer.

Any particular reason to try herdr?

So simple, I love this.

As a long-time Emacs user, I also prefer Markdown (and by a wide margin). I have tried so many times over the years, even going all in for a time with Beorg on iOS. But I always come back to Markdown.

Part of it is that I just prefer the Markdown syntax to everything else, but the other part is that I just don't care to use much of the (admittedly super cool) machinery around org, such as task capture, calendars, etc.

And furthermore there is a huge difference between "works for me" software and a proper software product.

HN users: "I'm not going to read the article if you can't be bothered to write the words yourself."

Also HN users: "I'm not going to read the article because you told me up front you wrote the words yourself."

What a picky bunch we are.

about to be put to the test

Same problem with Brave. Really frustrating.