frontpage.
newsnewestaskshowjobs

Made with ♥ by @iamnishanth

Open Source @Github

fp.

Frontier AI agents violate ethical constraints 30–50% of time, pressured by KPIs

https://arxiv.org/abs/2512.20798
276•tiny-automates•7h ago•177 comments

Qwen-Image-2.0: Professional infographics, exquisite photorealism

https://qwen.ai/blog?id=qwen-image-2.0
36•meetpateltech•1h ago•12 comments

Discord will require a face scan or ID for full access next month

https://www.theverge.com/tech/875309/discord-age-verification-global-roll-out
1671•x01•19h ago•1606 comments

Rust implementation of Mistral's Voxtral Mini 4B Realtime runs in your browser

https://github.com/TrevorS/voxtral-mini-realtime-rs
228•Curiositry•8h ago•25 comments

Pure C, CPU-only inference with Mistral Voxtral Realtime 4B speech to text model

https://github.com/antirez/voxtral.c
151•Curiositry•9h ago•13 comments

Why is the sky blue?

https://explainers.blog/posts/why-is-the-sky-blue/
598•udit99•18h ago•203 comments

Discord Alternatives, Ranked

https://taggart-tech.com/discord-alternatives/
242•pseudalopex•15h ago•115 comments

Converting a $3.88 analog clock from Walmart into a ESP8266-based Wi-Fi clock

https://github.com/jim11662418/ESP8266_WiFi_Analog_Clock
509•tokyobreakfast•17h ago•162 comments

Hard-braking events as indicators of road segment crash risk

https://research.google/blog/hard-braking-events-as-indicators-of-road-segment-crash-risk/
288•aleyan•17h ago•415 comments

Is particle physics dead, dying, or just hard?

https://www.quantamagazine.org/is-particle-physics-dead-dying-or-just-hard-20260126/
121•mellosouls•10h ago•187 comments

AI doesn’t reduce work, it intensifies it

https://simonwillison.net/2026/Feb/9/ai-intensifies-work/
24•walterbell•5h ago•3 comments

Luce: First Electric Ferrari

https://www.ferrari.com/en-US/auto/ferrari-luce
187•kaizenb•14h ago•187 comments

LiftKit – UI where "everything derives from the golden ratio"

https://www.chainlift.io/liftkit
177•peter_d_sherman•12h ago•102 comments

Sandboxels

https://neal.fun/sandboxels/
291•2sf5•18h ago•36 comments

MIT Technology Review has confirmed that posts on Moltbook were fake

https://www.technologyreview.com/2026/02/06/1132448/moltbook-was-peak-ai-theater/
90•helloplanets•2d ago•37 comments

Zulip.com Values

https://zulip.com/values/
63•nothrowaways•9h ago•11 comments

Eight more months of agents

https://crawshaw.io/blog/eight-more-months-of-agents
139•arrowsmith•1d ago•145 comments

.Beat Swatch Internet Time

https://beats.wiki/
3•Deprogrammer9•5d ago•1 comments

Upcoming changes to Let's Encrypt and how they affect XMPP server operators

https://blog.prosody.im/2026-letsencrypt-changes/
120•zaik•13h ago•130 comments

America has a tungsten problem

https://www.noleary.com/blog/posts/1
172•noleary•13h ago•162 comments

UEFI Bindings for JavaScript

https://codeberg.org/smnx/promethee
225•ananas-dev•20h ago•109 comments

Game Theory Patterns at Work (2016)

https://daeus.blog/2026/01/18/game-theory-patterns-at-work/
87•kurinikku•13h ago•6 comments

Grindr trials premium $500 per month plan to become 'AI-first' app

https://www.thepinknews.com/2026/02/09/grindr-trials-premium-500-per-month-plan-to-become-ai-firs...
8•mraniki•40m ago•10 comments

Generative Pen-Trained Transformer

https://theodore.net/projects/Polargraph/
45•Twarner•4d ago•0 comments

Thoughts on Generating C

https://wingolog.org/archives/2026/02/09/six-thoughts-on-generating-c
226•ingve•20h ago•78 comments

The Abstraction Rises

https://cyber-omelette.com/posts/the-abstraction-rises.html
53•birdculture•2d ago•12 comments

Ask HN: What are you working on? (February 2026)

282•david927•1d ago•956 comments

Another GitHub outage in the same day

https://www.githubstatus.com/incidents/lcw3tg2f6zsd
333•Nezteb•15h ago•254 comments

Game Boy Advance Audio Interpolation

https://jsgroth.dev/blog/posts/gba-audio-interpolation/
93•ibobev•16h ago•41 comments

Expansion Microscopy Has Transformed How We See the Cellular World

https://www.quantamagazine.org/expansion-microscopy-has-transformed-how-we-see-the-cellular-world...
87•sohkamyung•4d ago•4 comments
Open in hackernews

The original vi is a product of its time (and its time has passed)

https://utcc.utoronto.ca/~cks/space/blog/unix/ViIsAProductOfItsTime
31•ingve•2d ago

Comments

tim-tday•1d ago
OK cool, should I switch to nano? I need to be able to ssh into an arbitrary machine of whatever distro started by someone else, on another continent and edit a config file before restarting a service that is currently shedding millions of connections a minute.

What else should I use?

bpye•2h ago
This article is arguing against vi, most systems install vim by default.
awesome_dude•1h ago
vim is so ubiquitous that most people don't realise vi is symlinked to vim pretty much across the board
raverbashing•44m ago
Yeah

The exception is when you go do some work at server using a commercial unix and that is not how it's set up (in fact they don't even know about vim)

sigh but ok that story is dated and that behavior was already dated at that time

iso1631•17m ago
> but ok that story is dated

I'm struggling to think of the last time I saw a commercial unix -- we still had solaris on some new machines until about 2006 - the last I remember was the x4500 with ZFS.

Our sun sysadmin contractor (whose full time job it was to look after about 10 solaris machines) was a big fan of ksh at the time.

gustavorg•17m ago
I was honestly embarrassed to admit that I have no idea what I've been using on my Ubuntu server for the last 10 years. The way to find out if I'm using vi or vim is to enter command mode (by pressing “:”) and run “version” I'm using vim ;)
wahern•1h ago
Most systems meaning Linux and macOS. FreeBSD, NetBSD, and OpenBSD use nvi, and BusyBox (Alpine Linux core userland) uses tiny vi.c.
bpye•1h ago
Very true! I spent a few months using OpenBSD and nvi as my primary environment, and actually ended up pretty productive with it.
OJFord•1h ago
Or further, I don't know about other distros, but Arch doesn't even package vi (in the main repos) - it's a package group (or some implementation I'm not sure off the top of my head) consisting of vim and vi-compat.
gethly•1h ago
i've been using nano for server stuff since ever. i could never understand why anyone would us vi/m with its bs shortcuts, making BASIC text editing into a complete **.
MrGilbert•1h ago
I can see both having a place: vi/vim for more elaborate features and editing capabilities, and nano for the quick "I need to change that one little thing in my config file" fix. I prefer nano over vi every time, but I barely work over ssh more than once a month. There is simply no need for me to know more about vi/vim.

It doesn't hurt to know some basic vi/vim commands though, as you will mostly encounter them pre-installed on even the most exotic distribution.

cbdevidal•1h ago
Speed (both in the CPU/memory usage and in speed of editing using advanced commands), backwards compatibility with older servers, ubiquity (guaranteed it is on every server you touch), insane feature count vs Nano, and my fingers mostly stay on the home row.

Its major downfall is the commands are hardly intuitive, but I forced myself to learn it by doing everything in Vim (including shopping lists) and it now feels comfortable.

Then you have situations where you have no choice. I work for a company with over 100,000 servers and they only install Vim and disallow us installing anything else.

Not that we would have time; we’re in and out of each server in five minutes then on to the next ticket.

tpoacher•1h ago
I won't deny that vim has an "insane" feature count (particularly with plugins), but people who claim this kind of comparison typically vastly underestimate nano's own feature count and flexibility / extensibility.

And I'm surprised this usually comes as a surprise to people, given nano provides the ability for both internal (i.e. macros) and external scripts to manipulate its buffer. In principle you could even run non-interactive vim commands through nano if you really wanted to.

cbdevidal•52m ago
That’s a fair point, but the rest are still relevant. I simply cannot use Nano at my job but once you learn the basics Vi is not bad.
matrss•1h ago
> i could never understand why anyone would us vi/m with its bs shortcuts, making BASIC text editing into a complete *.

I could never understand why anyone would use nano with its bs shortcuts, making basic text editing (in contrast to basic linear text writing, which even a non-modal editor like nano can do decently) into a complete *.

This is dumb. Sure, some people don't get modal editing. Others don't get how you could live without. It is almost as if people work differently and have different preferences.

iso1631•21m ago
I get why OSes come with nano as the default editor, but it's so confining and slow to use when you're used to vim (or I'm sure emacs)
BoredPositron•20m ago
Vim is the exception, not the rule. Most people don't want a mental model just to type a sentence. Instead of the snark, you could just admit that your preference doesn't align with the median user.
wiseowise•1h ago
> Hot take: basic vim (without plugins) is mostly what vi should have been in the first place, and much of the differences between vi and vim are improvements.

Literally second paragraph.

tpoacher•1h ago
Unironically yes, switch to nano. It is an excellent and vastly underestimated editor.

(though admittedly, with a somewhat unfortunate default config, at least for modern environments)

It has been my editor of choice over vim for many years now, and I'm super productive on it (though at this point, partly this stems from me having developed my own set of custom macros and helper utilities over the years).

jjav•57m ago
In a world where emacs exists, why use something else?
jibal•39m ago
Because it's not installed by default.
iso1631•23m ago
Because emacs requires 8 meg of ram, and even then it's continuously swapping?
charcircuit•53m ago
Have you tried Claude Code for this use case? I have found it effective for editing remote configs.
byzantinegene•50m ago
seems like a security risk
ThePowerOfFuet•48m ago
>Have you tried Claude Code for this use case?

Surely you're being sarcastic... aren't you?

Aren't you?!

charcircuit•31m ago
Don't knock it until you try it. For example:

"ssh username@ip and configure logs to be persisted for only 1 week."

usefulposter•34m ago
Then: Do one thing well. Every megabyte matters. Personal webspace and shell accounts. Unix herding. Vi vs vim. Vim vs Emacs.

Now: Which React Yoga Bun TypeScript Tailwind Node vomit is better for shipping 250k unchecked LOC? Florp Code or Blorp Codex?

We mourn our craft.

https://news.ycombinator.com/item?id=46926245

awesome_dude•1h ago
Sacrilege:wq!
y1n0•1h ago
ZQ
burnt-resistor•1h ago
ZZ because I like my changes!
aa-jv•55m ago
:exit

Because its nice to sound it out .. "colon .. exit" ..

ivankelly•51m ago
He's right man ^X^S

WTF, why isn't my terminal responding

comrade1234•1h ago
I'm a lot faster on it than anything else... I especially dislike those editors that show all of the commands on the screen. I'm not using it as an ide (although I worked with someone that did and his code sucked). I'm just logging in by ssh, editing a configuration file, and logging out.
jey•1h ago
have you tried vim or neovim?
iso1631•24m ago
I've used vim instead of vi for decades and haven't seen an speed.

I went into the article expecting some nonsense about how I should be using vscode or whatever, but this was just about how having vim as the default editor is far better than having vi.

As my beard greys, I find that a reasonable take.

BrouteMinou•23m ago
What's the link between your ex-coworkers bad code and VI again?
willtemperley•50m ago
Do people really still program in vi when most IDEs have excellent Vim support?
carb•39m ago
Yes, I only open an IDE to run a debugger when needed. The vim support isn't exhaustive and it's jarring whenever a command doesn't work.

This is about Vi though and that's certainly more rare. For me that's only used over a rare ssh with vim not available but vi present

sevensor•8m ago
IDE vim support suffers from three problems. First, performance. I have yet to try an IDE that can match the responsiveness of vim. You can obviously tank vim’s performance with plugins, but you don’t have to. Second: clutter. Modern displays are gigantic, and yet most IDE users don’t have more than 40 lines of code on the screen at a time. The rest is occupied by a file picker, command palette, integrated terminal, LLM chat interface, and so forth. You have to go to some effort to reclaim those pixels; big context is not yours by default. Third: uncanny valley effect. Vim implementation is usually incomplete, especially when it comes to ex-style colon-prefixed commands. It’s jarring to run into a spot where your muscle memory doesn’t work.

In short, IDE vim support does not measure up to the experience of using the real thing.

dboreham•46m ago
I think it would be helpful if the article had outlined the cases when users do get classic vi. I mean, for me vi is a pretty new thing (I began with ed), but I don't use systems that have code written by Bill Joy. They're all running vim which is what the OS gives me. Is this a BSD thing?
lproven•22m ago
Vi is primitive and clunky not because it's a bad design, but because it's from 1976 and computers have changed a lot since then. It dates from a pivotal point: when glass terminals had replaced teletypes.

Glass terminal means with a screen, so any point on the screen could be changed at any time. Screen means a CRT, and that means specifically text-only and single-colour.

But before microcomputers, before a mass market in software that individual people could get and use on their own computers. Vi was from the end of the era of computers that cost as much as a house and so which you had to share.

So, terminals with screens were becoming common enough that an editor designed for them caught on.

But it was before microcomputers, where the computer was so closely coupled with the screen and keyboard that soon they were built into the same casing.

Screen + keyboard + computer in one unit == Commodore PET.

Keyboard + computer in 1 = Apple II

Keyboard, screen, and computer all sold together: TSR-80

All 1977, the year after vi appeared.

Computers with their own keyboards, or in their own keyboards, led to keyboards designed alongside the computer's OS.

Before then terminals were printers with typewriters: instead of just printing, the keyboard sent codes to the computer, and the computer sent them to the printer. Replace printer with screen, this still happened.

A mass market in software for individuals led to UI conventions and keyboard improvements.

Typewriters only have Shift and Tab. But as glass terminals went mainstream, then microcomputers which came with their own dedicated keyboards, they sprouted lots more keys.

Vi is from the early stage: it expects "Esc" and there's a combo for that.

What came right after it was Ctrl and Alt... and at first they went a bit crazy and there was Meta and Hyper and so on too.

To this day, the meaning of "meta" has not been agreed. Emacs and relatives mean one thing, KDE and relatives mean a different key.

Along with these keys, and a way to represent them as bits in a byte, nicknamed after a very young Niklaus Wirth -- "Bucky bits".

(I am guessing this is from him having European teeth not as even and straight as American kids who if they were from families rich enough to send them to university, all had braces.)

Along with all those keys came arrow keys and forwards and backwards delete keys, and rows of F-keys.

And it shows because vi doesn't use all this. It uses letters and Ctrl and nothing much else.

Once all the keys were they, software started to use them. Result, a Cambrian explosion in UI diversity. That's the era Emacs is from.

Then, next, came a great extinction event, as most of the dozens of weird 1980s computer makers went broke, and the industry standardised on CP/M replaced by MS-DOS, and PC clones, plus off to one side a few makers of GUI computers: Apple, Atari with the ST, Commodore with the Amiga, Acorn with the Archimedes.

And a matching great extinction event in UI design, as IBM-lauout keyboard became the standard and GUIs standardised software UI. DOS standardised UIs on CUA as it fought to stop Windows taking over.

It failed. Windows uses CUA. GUIs and CUA killed modal editors and weird UIs.

The Unix world stayed on minicomputers and their single-user descendants, workstations. It avoided all this standardisation. Keyboards stayed weird, UIs remained chaotic.

That's why vi is still weird, and so is Emacs in totally different ways.

The sad thing is this:

Those standardised UI are good ones backed by millions in R&D spend. They are better UIs than vi -- any vi.

Vi users like the rich keyboard controls, and won't move. But CUA editors have equally rich keyboard UI and if you know it you can drive all GUI apps with the same UI. This is massively useful. You can drive the whole OS and all its apps at the speed and control and power of a Vim user who's been practising for a decade.

And it hasn't gone away because this is also the UI that all blind and visually-impaired users use, and those with serious motor coordination problems.

But the Linux shell came straight out of minicomputers and workstations and never got standardised like this.

phoronixrly•13m ago
Thanks for the advice, but I predominantly use vi on remote systems for rudimentary config editing. It is perfect for this, as is tiny, present out of the box on many distros, and I do not need to switch between nano and vim navigation.