6 ms·

There are lots of people in the comments here who appear to not get it. This isn't about replacing a contemporary computer with something old. It's about the us

There are lots of people in the comments here who appear to not get it. This isn't about replacing a contemporary computer with something old. It's about the usability of a decent OS on very modest hardware. One of the systems on which I run NetBSD is a 33 MHz m68030 Mac LC III+ (http://elsie.zia.io http://elsie.zia.io - it's hosting a site about an LC II, which I'm still working on). It's quite useful to see how assumptions people make about "acceptable" performance regressions bear out in the real world. Sure, not much can be done about taking six or seven minutes to ssh, but when bad coding causes a shell script to take twice as long, it's much more obvious on hardware like this than on a modern Ryzen system. Nobody is telling others to forego your modern computer and your Windows needs. It's just interesting to some of us that we can still run modern things on very modest and, in some cases, very non-mainstream hardware in 2023.

BizarreByte 4y ago
Thank you for getting it, this was my entire point and I’m glad it came across to someone. Obviously I would never suggest someone replace their modern daily driver computer with one of this age.
deleted 4y ago
[deleted]
mro_name 4y ago
indeed, developing fast software requires slow hardware.
- flenserboy 4y ago
  Excellent point. Software testing (not for stability but instead for usability, and certainly not for compiling, lol) ought to be done on minimal-spec systems (the specs of which might possibly be dialed-down further once optimization is done, which would be a bonus). Assuming that a faster system (or one with more RAM or storage) will cure the real problem has allowed all sorts of sloppiness to creep into software.
  - LoganDark 4y ago
    We once heard a story about how someone optimized their game engine for a crappy old netbook and ended up with some tens of thousands of frames per second on any vaguely modern system. This works. -Emily
    - mro_name 4y ago
      as you mention gaming – do you know the doom-in-lego-brick? https://kilograham.github.io/rp2040-doom/ https://kilograham.github.io/rp2040-doom/ and brick assembly https://youtube.com/watch?v=6wBrOV2FJM8 https://youtube.com/watch?v=6wBrOV2FJM8 There are some video links in the (german) article https://heise.de/-7448263 https://heise.de/-7448263. Mind-blowing.
  - rahen 4y ago
    NetBSD is still routinely tested on 486s and old Vaxen, and developed on ARM SBCs or Pinebooks. It helps keep the code base light and efficient. The latest minimal kernel will still boot on 4MB of memory on 32 bits machines, although it will take more than that to be usable. Unfortunately NetBSD can only do so much considering the sad state of the Linux ecosystem. GCC has become so big it won't self host on most platform, making cross compilation mandatory for them. Switching to PCC would be a solution, but a lot of software won't compile with PCC and obviously their maintainers couldn't care less. Then you have the newer behemoths like Rust and Go. Once they start creeping in some majors projects like GCC or OpenSSL, a lot of machines will turn into e-waste, and the resource requirements will climb even further.
- Sesse__ 4y ago
  It does not. Slow hardware _can_ give you a certain amount of _motivation_ for speeding up your software, but this is by no means a given (if software running slowly on your own computer automatically made you optimize it, there would not be software that is really slow even on fast hardware, and there clearly is). If you care about making software fast, you invest time in the measurements-ideas-measurements loop, where having fast hardware helps a lot (it allows you get measurements faster, and try out more ideas in a given time frame). Since any sane measurement is based on benchmarking and not eyeballing, slower CPUs don't help you. And you certainly can care about fast software without having a slow computer personally.
  - andai 4y ago
    >if software running slowly on your own computer automatically made you optimize it I recently changed 1 byte in Chrome.dll and decreased the lag for copying large images by a factor of 2-3. (The UI freezes for 5-10 seconds. Turns out it's re-encoding a 2MB JPG into a 20MB PNG for the clipboard, at compression level 6 no less!) I put up with it for years thinking there was nothing I could do, but one day I decided to ask some people smarter than me, and they gave me enough info to track down the code in IDA (I had never used it before). My point is, motivation is a powerful thing! (Offtopic but turns out Firefox copies the original file, so you can paste it right into Windows explorer—blew my mind!)
    - alexchantavy 4y ago
      This sounds cool, you should write a blog on it
    - charcircuit 4y ago
      For those curious. https://source.chromium.org/chromium/chromium/src/+/main:ui/base/clipboard/clipboard_win.cc;l=736;drc=0c4306fc554c80506eb0f9b833a5d2a5fdd452d5 https://source.chromium.org/chromium/chromium/src/+/main:ui/... An improvement would be to replace EncodeBGRASkBitmap with FastEncodeBGRASkBitmap so that it uses the fastest zlib level instead of the default (6). This is what the Linux X11 (ozone) implementation uses. This would be an easy fix to upstream if someone wants to do it.
drewcoo 4y ago
I think any article on HN is really just a jumping off point for people to talk about themselves. Everyone's had old computers, so that's easier to talk about.
harel 4y ago
Absolutely this. I'll add that there is a certain kind of joy (to me at least) to see an old machine spring back to life and become useful again.
- jkepler 4y ago
  I heartily agree. I have an old Asus netbook (castoff from a family member who switched to computing nearly exclusively on her smartphone; the machine originally ran MeeGo Linux on a 8GB internal disk) that runs Debian stable, slowly, but I've been wondering if one of the BSDs might be slightly faster. I'm thinking of making it a kitchen computer primarily to serve as a recipe database.
desuforever 4y ago
[flagged]
JoshMcguigan 4y ago
What part of SSH takes 6 minutes?
- Topgamer7 4y ago
  Maybe the encryption on older hardware?
- johnklos 4y ago
  Running sshd on a 33 MHz m68030 (OpenSSH_9.1), and connecting to it from a modern(ish) machine (OpenSSH_8.1p1) takes about six minutes to complete when the system is otherwise idle. Right now it's busy with lots of http requests due to putting the link here, so it's taking about 9 minutes or so ;)
  - snvzz 4y ago
    Is that Linux? It takes too long, but much less than that, on Netbsd @ A1200 with 030, albeit 50MHz.
    - johnklos 4y ago
      NetBSD 10.0_BETA. I'd expect a 50 MHz '030 to be faster than a 33 MHz one ;) But running newer ssh and sshd means more expensive default ciphers. I can speed it up a bit by being more deliberate about the choice of cipher, but I want to run things by default, generally speaking.
aidenn0 4y ago
Not nearly as low-end, but I ran a server off of a P3 450MHz for over a decade, then sold it to someone who was going to continue using it for a similar purpose. 4 of those years were in a college dorm room with no A/C. The CPU fan died at some point, and I didn't notice until I opened it up to change a hard-drive. If it's not still running it's probably due to an exploded capacitor, because that thing was indestructible.

BizarreByte 4y ago

Thank you for getting it, this was my entire point and I’m glad it came across to someone. Obviously I would never suggest someone replace their modern daily driver computer with one of this age.

deleted 4y ago

[deleted]

mro_name 4y ago

indeed, developing fast software requires slow hardware.

flenserboy 4y ago
Excellent point. Software testing (not for stability but instead for usability, and certainly not for compiling, lol) ought to be done on minimal-spec systems (the specs of which might possibly be dialed-down further once optimization is done, which would be a bonus). Assuming that a faster system (or one with more RAM or storage) will cure the real problem has allowed all sorts of sloppiness to creep into software.
- LoganDark 4y ago
  We once heard a story about how someone optimized their game engine for a crappy old netbook and ended up with some tens of thousands of frames per second on any vaguely modern system. This works. -Emily
  - mro_name 4y ago
    as you mention gaming – do you know the doom-in-lego-brick? https://kilograham.github.io/rp2040-doom/ https://kilograham.github.io/rp2040-doom/ and brick assembly https://youtube.com/watch?v=6wBrOV2FJM8 https://youtube.com/watch?v=6wBrOV2FJM8 There are some video links in the (german) article https://heise.de/-7448263 https://heise.de/-7448263. Mind-blowing.
- rahen 4y ago
  NetBSD is still routinely tested on 486s and old Vaxen, and developed on ARM SBCs or Pinebooks. It helps keep the code base light and efficient. The latest minimal kernel will still boot on 4MB of memory on 32 bits machines, although it will take more than that to be usable. Unfortunately NetBSD can only do so much considering the sad state of the Linux ecosystem. GCC has become so big it won't self host on most platform, making cross compilation mandatory for them. Switching to PCC would be a solution, but a lot of software won't compile with PCC and obviously their maintainers couldn't care less. Then you have the newer behemoths like Rust and Go. Once they start creeping in some majors projects like GCC or OpenSSL, a lot of machines will turn into e-waste, and the resource requirements will climb even further.
Sesse__ 4y ago
It does not. Slow hardware _can_ give you a certain amount of _motivation_ for speeding up your software, but this is by no means a given (if software running slowly on your own computer automatically made you optimize it, there would not be software that is really slow even on fast hardware, and there clearly is). If you care about making software fast, you invest time in the measurements-ideas-measurements loop, where having fast hardware helps a lot (it allows you get measurements faster, and try out more ideas in a given time frame). Since any sane measurement is based on benchmarking and not eyeballing, slower CPUs don't help you. And you certainly can care about fast software without having a slow computer personally.
- andai 4y ago
  >if software running slowly on your own computer automatically made you optimize it I recently changed 1 byte in Chrome.dll and decreased the lag for copying large images by a factor of 2-3. (The UI freezes for 5-10 seconds. Turns out it's re-encoding a 2MB JPG into a 20MB PNG for the clipboard, at compression level 6 no less!) I put up with it for years thinking there was nothing I could do, but one day I decided to ask some people smarter than me, and they gave me enough info to track down the code in IDA (I had never used it before). My point is, motivation is a powerful thing! (Offtopic but turns out Firefox copies the original file, so you can paste it right into Windows explorer—blew my mind!)
  - alexchantavy 4y ago
    This sounds cool, you should write a blog on it
  - charcircuit 4y ago
    For those curious. https://source.chromium.org/chromium/chromium/src/+/main:ui/base/clipboard/clipboard_win.cc;l=736;drc=0c4306fc554c80506eb0f9b833a5d2a5fdd452d5 https://source.chromium.org/chromium/chromium/src/+/main:ui/... An improvement would be to replace EncodeBGRASkBitmap with FastEncodeBGRASkBitmap so that it uses the fastest zlib level instead of the default (6). This is what the Linux X11 (ozone) implementation uses. This would be an easy fix to upstream if someone wants to do it.

drewcoo 4y ago

I think any article on HN is really just a jumping off point for people to talk about themselves. Everyone's had old computers, so that's easier to talk about.

harel 4y ago

Absolutely this. I'll add that there is a certain kind of joy (to me at least) to see an old machine spring back to life and become useful again.

jkepler 4y ago
I heartily agree. I have an old Asus netbook (castoff from a family member who switched to computing nearly exclusively on her smartphone; the machine originally ran MeeGo Linux on a 8GB internal disk) that runs Debian stable, slowly, but I've been wondering if one of the BSDs might be slightly faster. I'm thinking of making it a kitchen computer primarily to serve as a recipe database.

desuforever 4y ago

[flagged]

JoshMcguigan 4y ago

What part of SSH takes 6 minutes?

Topgamer7 4y ago
Maybe the encryption on older hardware?
johnklos 4y ago
Running sshd on a 33 MHz m68030 (OpenSSH_9.1), and connecting to it from a modern(ish) machine (OpenSSH_8.1p1) takes about six minutes to complete when the system is otherwise idle. Right now it's busy with lots of http requests due to putting the link here, so it's taking about 9 minutes or so ;)
- snvzz 4y ago
  Is that Linux? It takes too long, but much less than that, on Netbsd @ A1200 with 030, albeit 50MHz.
  - johnklos 4y ago
    NetBSD 10.0_BETA. I'd expect a 50 MHz '030 to be faster than a 33 MHz one ;) But running newer ssh and sshd means more expensive default ciphers. I can speed it up a bit by being more deliberate about the choice of cipher, but I want to run things by default, generally speaking.

aidenn0 4y ago

Not nearly as low-end, but I ran a server off of a P3 450MHz for over a decade, then sold it to someone who was going to continue using it for a similar purpose. 4 of those years were in a college dorm room with no A/C. The CPU fan died at some point, and I didn't notice until I opened it up to change a hard-drive. If it's not still running it's probably due to an exploded capacitor, because that thing was indestructible.