3 ms·

Porting and hacking on low level stuff is probably the most interesting thing I can think of for it. That is probably why I keep the machines around. In practic

Porting and hacking on low level stuff is probably the most interesting thing I can think of for it. That is probably why I keep the machines around. In practice though I hardly have the time to use them.

rbanffy 6y ago
But then they'll be nothing more than awkward PCs running software in slow motion.
- asveikau 6y ago
  Porting software to unexpected environments sometimes exposes legit bugs and validates your design. I always like to get software I write working in unusual configurations. It tests my assumptions and often results in something sturdier.
  - rbanffy 6y ago
    Indeed. Also, if it runs well on a 25 year old machine, it'll probably run well on a modern computer a thousand times faster ;-) I always recommend developers to get the cheapest possible laptop for testing.
    - nix23 6y ago
      It has nothing todo with speed, but finding bug's. >I always recommend developers to get the cheapest possible laptop for testing. Yeah that is stupid, until you are the developer of that Laptop, or your dev's have too much time, take trusty Hardware and Down-clock it if you need to (you don't want to debug cheap hardware).
      - rbanffy 6y ago
        If you want to find bugs in your code that arise from assumptions about machine architecture, you can use emulators. You don't need an ancient MIPS machine for that, unless you want to find bugs on code that supports long obsolete hardware. And you can emulate architectures far weirder than MIPS with that. And you should test on slow and unreliable hardware. You'd be surprised, for instance, how frequently servers fail to boot because the BMC ignored your instructions.
        nix23 6y ago
        >from assumptions about machine architecture, you can use emulators That is exactly NOT true, since there is no 100% correct emulation around, think of x64 emulation with integrated Meltdown, if you don't know about meltdown your emulation has no implementation for it. Look you made a perfect counterargument, using unreliable hardware...with your words you could just test it with unreliable emulation ;) >unreliable hardware... how frequently servers Wait...server's and unreliable do not match together...and then the BMC argument..sound's bit crazy to me.
        rbanffy 6y ago
        It did sound crazy to me too, before I saw it happen a couple times. Or "not happen" would be a better description.

rbanffy 6y ago

But then they'll be nothing more than awkward PCs running software in slow motion.

asveikau 6y ago
Porting software to unexpected environments sometimes exposes legit bugs and validates your design. I always like to get software I write working in unusual configurations. It tests my assumptions and often results in something sturdier.
- rbanffy 6y ago
  Indeed. Also, if it runs well on a 25 year old machine, it'll probably run well on a modern computer a thousand times faster ;-) I always recommend developers to get the cheapest possible laptop for testing.
  - nix23 6y ago
    It has nothing todo with speed, but finding bug's. >I always recommend developers to get the cheapest possible laptop for testing. Yeah that is stupid, until you are the developer of that Laptop, or your dev's have too much time, take trusty Hardware and Down-clock it if you need to (you don't want to debug cheap hardware).
    - rbanffy 6y ago
      If you want to find bugs in your code that arise from assumptions about machine architecture, you can use emulators. You don't need an ancient MIPS machine for that, unless you want to find bugs on code that supports long obsolete hardware. And you can emulate architectures far weirder than MIPS with that. And you should test on slow and unreliable hardware. You'd be surprised, for instance, how frequently servers fail to boot because the BMC ignored your instructions.
      - nix23 6y ago
        >from assumptions about machine architecture, you can use emulators That is exactly NOT true, since there is no 100% correct emulation around, think of x64 emulation with integrated Meltdown, if you don't know about meltdown your emulation has no implementation for it. Look you made a perfect counterargument, using unreliable hardware...with your words you could just test it with unreliable emulation ;) >unreliable hardware... how frequently servers Wait...server's and unreliable do not match together...and then the BMC argument..sound's bit crazy to me.
        rbanffy 6y ago
        It did sound crazy to me too, before I saw it happen a couple times. Or "not happen" would be a better description.