5 ms·

Hopefully these efforts from the big players result in more reliable hardware for everyone.

by rho4 5y ago

hulitu 5y ago
How about reliable software ?
- dijit 5y ago
  I think it goes without saying that you can't build a castle on a beach. So too goes for reliability, you need foundations on which to build.
  - DylanSp 5y ago
    Counterexample: the Internet. Reliable communication over unreliable networks. Any highly-available system with better reliability than any individual component also shows that it's not _impossible_ to build from unreliable components, though it might be difficult.
    - dijit 5y ago
      If you think the internet is reliable then your monitoring is lying to you. Keeping a persistent connection open to a machine 1 ISP hop away for more than a couple of days is basically impossible, or at the very least improbable. I ran an always-online game which required a non-breaking TCP session, this was the single largest cause of user frustration. I also run an IRC network which requires the same thing, and you need only look at the number of people ungracefully disconnecting in a day. Stateless requests help of course, but I'm pretty sure you and I brush failures away because we've internalised the idea that the internet is not really reliable; whether it by wifi, a faulty cable, DNS, the router, "the site" or so on.
      - athenot 5y ago
        A single TCP socket may not be reliable, but I understood the parent comment at the application layer. With enough redundancy, checks, retries and caches, it's possible to conduct business reliably[1] over the internet, tolerating failures from nearly any component involved along the way. [1] By "reliable" I mean with an uptime satisfactory for the application involved. Nothing is ever 100% but we can get pretty darn close in terms of probabilities.
        DylanSp 5y ago
        Yes, that's what I had in mind. I can make an HTTP request and (usually) get a response, even with intermediate routing failures, repeated packets, dropped packets, out-of-order packets, etc.

Hopefully these efforts from the big players result in more reliable hardware for everyone.

by rho4 5y ago

Hopefully these efforts from the big players result in more reliable hardware for everyone.

hulitu 5y ago

How about reliable software ?

dijit 5y ago
I think it goes without saying that you can't build a castle on a beach. So too goes for reliability, you need foundations on which to build.
- DylanSp 5y ago
  Counterexample: the Internet. Reliable communication over unreliable networks. Any highly-available system with better reliability than any individual component also shows that it's not _impossible_ to build from unreliable components, though it might be difficult.
  - dijit 5y ago
    If you think the internet is reliable then your monitoring is lying to you. Keeping a persistent connection open to a machine 1 ISP hop away for more than a couple of days is basically impossible, or at the very least improbable. I ran an always-online game which required a non-breaking TCP session, this was the single largest cause of user frustration. I also run an IRC network which requires the same thing, and you need only look at the number of people ungracefully disconnecting in a day. Stateless requests help of course, but I'm pretty sure you and I brush failures away because we've internalised the idea that the internet is not really reliable; whether it by wifi, a faulty cable, DNS, the router, "the site" or so on.
    - athenot 5y ago
      A single TCP socket may not be reliable, but I understood the parent comment at the application layer. With enough redundancy, checks, retries and caches, it's possible to conduct business reliably[1] over the internet, tolerating failures from nearly any component involved along the way. [1] By "reliable" I mean with an uptime satisfactory for the application involved. Nothing is ever 100% but we can get pretty darn close in terms of probabilities.
      - DylanSp 5y ago
        Yes, that's what I had in mind. I can make an HTTP request and (usually) get a response, even with intermediate routing failures, repeated packets, dropped packets, out-of-order packets, etc.