Comment by gavinhoward
3 years ago
I am right there with the author, all the way.
I run a machine with lots of RAM and a hefty CPU and a monster GPU and an SSD for my Linux install and...a pair of HDD's with ZFS managing them as a mirror.
Wat. [1]
I also have Windows on a separate drive...that is also an HDD.
Double wat.
My Linux is snappy, but I also run the most minimal of things: I run the Awesome Window Manager with no animations. I run OpenRC with minimal services. I run most of my stuff in the terminal, and I'm getting upset at how slow Neovim is getting.
But my own stuff, I run off of ZFS on hard drives, and I'll do it in VM's with constrained resources.
Why?
While my own desktop has been optimized, I want my software to be snappy everywhere, even on lesser machines, even on phones. Even on Windows with an HDD.
This is my promise: my software will be far faster than what companies produce.
Because speed will be my killer feature. [2]
[1]: https://www.destroyallsoftware.com/talks/wat
[2]: https://bdickason.com/posts/speed-is-the-killer-feature/
There is a Raymond Chen post (I'll come back to add the link if I find it) that explains how the developers working on Windows 95 were only allowed to use machines with the minimum specs required by the OS. This was to ensure that the OS ran well on those specs.
And, IMHO, that's the way it should be: I think it's insane(?) to give developers top-of-the-line hardware, because such hardware is not representative of the user population... and that's part of why I stick to older hardware for longer than others would say is reasonable.
> I think it's insane(?) to give developers top-of-the-line hardware, because such hardware is not representative of the user population
But a developer's needs are radically different from the user's needs. In typical web dev, the developer's machine is playing the role of the client machine, web server, and database server, all in one. On top of that you'll probably be running multiple editors/IDEs and other dev tools, which are pretty much always processor and memory hungry. Even for desktop development the dev needs to be able to run compilers and debuggers that the user doesn't care a thing about. If you truly care about the low end user experience then you need to do acceptance testing against your minimum supported specs. It's pretty crazy to intentionally hamstring the productivity of some of your most expensive employees.
Fair observation about web apps vs. desktop apps / systems. So maybe the browser should intentionally slow things down when using the device-specific previews to mimic real-world behavior, instead of just changing the window size? :)
In any case... the fact that you need so powerful machines to develop the app is also an indicator of waste at all layers. It hadn't cross my mind to showcase how even CLI tools have gotten sluggish, for example, but they have... Running 'aws', or 'az', or things like that show visible pauses at startup too. Furthermore, the tendency to depend on tons of services "for scalability" is also questionable in the majority of web apps.
It takes a lot of work to keep the development environment lean because it's easier than ever to pull in library and tool dependencies into them. It's doable, but usually also not a priority.
Edit: By the way, I do develop a few web apps on the side where I can be careful about dependencies and the like, and the resource needs are minimal. Running a database and web server on the local machine take almost zero resources. The heaviest thing of all is the JavaScript toolchain, which is... quite telling. And I can run the hundreds of integration/unit tests for the apps in milliseconds. It has taken care to get to this point though, and I have never experienced this kind of "lightweightness" in a corporate project. Here is a post that provides some background on just one aspect (https://jmmv.dev/2023/06/iii-iv-task-queue.html), and I'm working on another one to describe the testing process in detail.
1 reply →
Merad's sibling post is exactly why my machine is beefy instead of weak: I still need that power.
Of course, I run Gentoo, so...
And I run my Gentoo updates off of a ramdisk to save my SSD and for that much more does.
But if I intentionally run my code in hamstrung VM's, it achieves the effect you are advocating, which is a good thing, by the way. I do agree with you.
Oh what ritualistic nonsense. Those developer machines will also have to compile the code and run the application in debug mode, which will make the app slower than on a regular user’s machine if we assume the same hardware.
Fast software that nobody uses helps nobody. Slow software that everyone uses is, well, slow. So I'm curious: how many people use your software? I get that this topic is like nerd rage catnip but if people actually want to help users, then they need to meet users where they're at. And if "marketing" is what's needed, then maybe it is. Software is generally built for humans after all.
Don't get me wrong, All of my servers at home run Void Linux and use runit. Pretty much anything that runs on them is snappy and they run on 10 year old hardware but still sing because I use software written in Go or native languages. But remembering the particulars about runit services and symlinks is something I forget every 3 months between deploying new services. Trying to troubleshoot the logger is also a fun one where I remember then forget a few months later. Using systemd, this all just comes for free. Maybe I should write all of this down but I'm doing this for fun aren't I?
The reason users don't care that much about slow software is because they use software primarily to get things done.
You are absolutely correct.
So my new projects are not out yet, but I will market them heavily once they are.
One of them is an init system specifically designed to be easier to use than runit and $6, while still being sane, unlike systemd. Yes, I'm going to focus on ease of use because as you said, that matters a lot.
However, I do have a project out in the public now. It ships with the base system in FreeBSD and also ships with Mac OSX. It is a command-line tool that lots of people may use in bash scripts.
Is that widespread enough?
Also, one reason people adopted mine over the GNU alternative is speed.
> However, I do have a project out in the public now. It ships with the base system in FreeBSD and also ships with Mac OSX. It is a command-line tool that lots of people may use in bash scripts. Is that widespread enough? Also, one reason people adopted mine over the GNU alternative is speed.
Which one is that?
1 reply →
> One of them is an init system specifically designed to be easier to use than runit and $6, while still being sane, unlike systemd. Yes, I'm going to focus on ease of use because as you said, that matters a lot.
Ooh can you link directly to this? I'd love to take a look at. Runit is sharp and annoying.
1 reply →
They could get things done faster, they probably just don't know
> My Linux is snappy, but I also run the most minimal of things: I run the Awesome Window Manager with no animations.
Same: a very lean Linux install with the Awesome WM, now running on a 7700X (NVMe PCIe 4.0 x4 SSD in my case). I also use one of the keyboard that comes stock with the lowest latency (and I bumped its polling rate because why not).
This feels not just a bit but very snappy.
Speed is not a feature IMHO. Speed is the feature, even in non-software areas of your life, see the recent thread: https://news.ycombinator.com/item?id=36312295
At https://bdickason.com/posts/speed-is-the-killer-feature/
"A vibrant screen that responded instantly when you tapped replaced cramped keyboards."
I tentatively assume this results from a partial edit. Something to do with "replaced your dumbphone and tapped on cramped keyboards" or just maybe the slightly non sequitur "replaced erroneous characters on cramped keyboards"?
Parse errors aside,
"Design Tools - Users are consistently frustrated when Sketch or Figma are slow. Designers have high APM (actions per minute) and a small slowdown can occur 5-10 times per minute. "
Haven't used those, but with some design tools, it felt like 5-10 times per second, especially when trying to get an idea on screen quickly!
Regarding when it's okay to be slow:
"When a human has to keep up with a machine (e.g. we slow down video game framerates, otherwise the game would run at 60x speed and overwhelm you). "
I…wouldn't slow the framerate, unless you mean the game's speed is locked to refreshrate (as some ancient graphical games are), so allowing frames to be generated faster causes the gameworld to change faster. Or unless unrestrained framerate results in too much heat or power consumption.