I think it's the different feeling you get from using a completely streaming service (compute, not videos) versus the one that does a lot of intermittent buffering. It's quite subtle actually. Using a vanilla language model can feel like that if it's also sufficiently small but they are going towards the opposite direction very rapidly now because cloud.
When it comes to navigating (except public transit), hiking, and route building, Organic Maps[1] is very good. OSM data and offline-first is the way forward for detailed and _fast_ map experience.
For cycling route building I have to mention BRouter[2], which allows you to write a custom cost function that is used to tweak your route preferences.
I run headless Alpine Linux (a minimal distro) in my homelab and it’s fast AF. The lag in Windows Explorer is sad when something like cd folder/folder is instant in Linux.
To be fair, cd folder/folder is also instant in a command line in Windows, it's just the GUI aspects that are slow. Comparing Windows Explorer to a terminal is comparing apples to oranges.
I don’t think I’ve ever noticed a difference in speed on the terminal between distros. Shells (or more accurately, plugins / frameworks - I recently gave up oh-my-zsh in favor of zimfw for that reason), yes, but not the terminal itself.
I fully agree. I loathe slow software. I hate bloat. I love fast software. As a developer, I'm completely, even irrationally, obsessed with speed, performance optimization, and profiling. I wish more developers felt the same way.
Fast and efficient software varies depending on the local context, but for me, I think I'd be fine with something slower as long as it's convenient enough. After all, once it passes a certain threshold, I can barely even notice the speed difference anyway.
I wonder what OP's thinks of IDEs like VSCode. Would they see it as heavy and not great because it's Electron-based? But I find IDEs convenient.
Simple tasks being barely fast enough alone is not fast enough, as they could unexpectedly slow down to a halt if you run a moderately heavy load alongside them.
Speed enables more features and also simpler architectures and algorithms, since you can rely more on brute force in higher-level code.
> Fastness in software is like great margins in a book — makes you smile without necessarily knowing why.
EDIT: I didn't say _AI_ slop; it's just not well-written. In addition to the word salad quoted above, there's unsubstantiated jumps in logic and opinions that undercut the premise (e.g. "Speed and reliability are often intuited hand-in-hand" being followed later by an example of a "faster, simpler" application having "reliability issues"; or typewriters being "slow in a relative sense" while then praising simplicity of operation, task-focused design, and observability of state over speed); it feels like the author wanted to list out some random complaints but failed to tie them together in a way that felt worth reading.
EDIT 2: having now skimmed the article a few times, I think what the author actually wanted to say is not that software shouldn't be slow, but that it shouldn't be _frustrating_; "slow" is a very common way to frustrate, but not the only one.
When it comes to navigating (except public transit), hiking, and route building, Organic Maps[1] is very good. OSM data and offline-first is the way forward for detailed and _fast_ map experience.
For cycling route building I have to mention BRouter[2], which allows you to write a custom cost function that is used to tweak your route preferences.
[1]: https://organicmaps.app/
[2]: https://brouter.de/brouter/index.html
BTW, the title should say "(2019)".
I wonder what OP's thinks of IDEs like VSCode. Would they see it as heavy and not great because it's Electron-based? But I find IDEs convenient.
Speed enables more features and also simpler architectures and algorithms, since you can rely more on brute force in higher-level code.
A good WYSIWYG editor will run circles around the fastest text editor. Even if WYSIWYG is a bit slower to open.
It would be preferable for software to be more focused and faster over time, but that doesn't attract people to it.
> Fastness in software is like great margins in a book — makes you smile without necessarily knowing why.
EDIT: I didn't say _AI_ slop; it's just not well-written. In addition to the word salad quoted above, there's unsubstantiated jumps in logic and opinions that undercut the premise (e.g. "Speed and reliability are often intuited hand-in-hand" being followed later by an example of a "faster, simpler" application having "reliability issues"; or typewriters being "slow in a relative sense" while then praising simplicity of operation, task-focused design, and observability of state over speed); it feels like the author wanted to list out some random complaints but failed to tie them together in a way that felt worth reading.
EDIT 2: having now skimmed the article a few times, I think what the author actually wanted to say is not that software shouldn't be slow, but that it shouldn't be _frustrating_; "slow" is a very common way to frustrate, but not the only one.
Ahahaha holy cope