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.
> Vim implementation quality varies wildly from environment to environment is extremely frustrating to me.
I know exactly what you're talking about. I am a die-hard vimmer and used vim plugins in every editor/IDE/browser/shell/multiplexer/WM/etc. I use vim bindings system-wide. I control my music, switch between apps, swap and resize windows - all without lifting a finger from the home-row.
I spent almost a decade living in IntelliJ. I had many direct conversations with Andy Vlasovskikh (he's the maintainer of IdeaVim then). Gary Bernhard (Destroy All Software, wat guy) once said: "there's no vim-mode, there's only Vim" in the sense that no single editor or IDE, not a single vim emulation layer properly works, they all have glaring deficiencies - to the point that it can drive any experienced vimmer truly mad.
With one notable exception. Evil-mode in Emacs is just wonderful. It's the best vim-emulation layer, to a certain degree it works even better than in Vim/Nvim. Weirdest thing - it makes you forget it's not a built-in feature of Emacs. I'm honestly very happy with it, because I don't know, otherwise, I might have never convinced myself to ever give Emacs a try.
These two ideas - vim modality and the grand idea of Lisp - are possibly the two best things that I am forever grateful to my younger self for forcing me to learn. I can't even comprehend being a professional software developer and not grokking them.
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!
afaik, even with the extension it only affects the editor pane - any other windows still require tons of mouse use. I'm not mouse-nazi, but years of one-handed use of it have created tons of problems for me - in the neck, wrists and my back. All kinds of mice I tried didn't help - magic trackpad, vertical, ergonomic, etc. I'm sure this is pretty common.
I keep thinking of maybe I should learn to become ambidexter mouse user, and if I ever have to become a VSCoder (I pray not), I still may have to. For now, Emacs and vim and reduced mouse use are working.
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.
In a similar vein, I've been using https://brutalist.report/ for a while just to browse headlines.
All the links lead to the full regular pages, so the articles themselves aren't "lightweight" like the CNN Lite version is. I still like how it lets me quickly peruse many headlines from lots of different categories and only click through onto something I'm genuinely interested in.
I wasn't aware of CNN Lite, I will add this to my news bookmarks.
No who remembers WAP has any desire to see anything like it return. A 'lite' subdomain is far easier and more effective by not trying to reinvent the entire stack.
As for WML, I'd say transport-level compression made that pretty much academic.
The Compuserve and Netscape ISP website husks also feature no-nonsense text-only news pages with 2000s-style renderings that are near-instant on any device.
68k.news also exists but has been broken for a long time. It's maintained by a retro computing youtuber who seems to have abandoned it or isn't paying attention to its brokenness.
I came across this years ago. It is pretty much the only news I will look at. They only update like 3 times a day too, so no incentive to keep coming back.
It was created in protest to GDPR - "see how terrible the web would be if we followed GDPR" - and backfired a bit, but apparently not enough to delete it.
The biggest value of gptel is its API. I can send a request anytime, anywhere, from pretty much any buffer. I sometimes ask things in the middle of typing a message, or I can ask a model to reword the prompt I'm about to send to another model.
Doesn't work with my github enterprise with entra sso integration. I left a question on github gptel but no progress as of yet. That drove me to agent-shell which requires a cli but works.
Don't tell anyone: https://github.com/agzam/.emacs.d/blob/main/modules/ai/gptel...
There's a fear among third-party Claude tool-builders that Ant will close the shop very soon, making it hard for them to use it. Like they did with OpenClaw. I'm sure some inventive hackers still doing it anyway.
At least two of these are now on completely unsupported OSes that are no longer receiving security updates (and lots of latest versions of apps won't work). Especially given the uptick in major CVEs of late I'm very nervous about reconnecting any of these machines to the internet :/
That's what Linux is for I've got a 2011 MacBook Pro running Debian and its still perfectly usable(after maxing it out to 16 GB RAM, installing an SSD, tossing the CD drive, repasting the CPU, and replacing the battery). I'm curious to see how long it can keep on trucking, at some point the charger may be the difficult part to procure; it’s not very robust.
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.
no one is going to hack your laptop that sits behind your router at home checking emails and browsing the web
I get that this is hn and we're paranoid about everything, but come on, what CVE is a threat to joe sixpack here where he should drop $2K on a new machine to protect against it?
In 2024 I sold a 2010 MBP that still worked. I beat the hell out of it in college dual booting and cooking the cpu playing Trackmania for 12 hours at a time or running Solidworks, then after I graduated it sat closed behind my stove sharing its wifi connection (my neighbors unprotected wifi) out the ethernet port and into my own managed router for about 4 years. Up until the last days it was running Windows as a host for controlling my old not-network-connected 3d printer. I definitely got my money out of that machine, someone paid $150 for it.
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.
I like the analogy. And yes, I'm not interested in conversing with a person who thinks that about a car.
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.
And I want to stress that I say all this tentatively. We still don't understand what LLMs are actually capable of or what the best way to understand them is. They may indeed be as limited as their "probabilistic database" critics suggest. Alternatively, by building a deep and incredibly complex probabilistic database of one of our primary cognitive tools, it may turn out that they are capable of much, much more, and that understanding them in "purely" mechanistic ways is not useful.
> 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.
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.
are you actively pointing your LLM at the kernel to identify security bugs?
the policy wasn't made on a whim. to quote the linux security team: "bugs discovered this way [via ai] systematically surface simultaneously across multiple researchers, often on the same day."
>Responsible disclosure
the term responsible disclosure is a silly thing made up by vendors.
> 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.
reply