• abhibeckert@lemmy.world
    link
    fedilink
    English
    arrow-up
    28
    ·
    edit-2
    2 months ago

    The S30 OS, before Nokia collapses, was much better.

    Yeah no - you’re miss-remembering it. For example you had to delete SMS messages otherwise your mailbox would fill up.

    It could only fit 10 messages before it’d run out of space, and once full no messages would be received at all.

    Also, the battery life was ten days in standby if you didn’t use the phone which was nice but as soon as you started using it… then it only lasted 3 hours. I used to carry two spare batteries in my bag… don’t miss those days at all.

    • Guy_Fieris_Hair@lemmy.world
      link
      fedilink
      English
      arrow-up
      7
      arrow-down
      1
      ·
      edit-2
      2 months ago

      Yeah, this would be a novelty and it was SOLID for it’s time. But we have come a long way, pretty sure my light switches have more processing power than these phones did. This isn’t like your favorite band rebooting, it is a peice of technology that is no longer relevant or even capable of operating on modern networks. The entire hardware will be completely different or it will be a paperweight immediately.

    • barsoap@lemm.ee
      link
      fedilink
      English
      arrow-up
      2
      ·
      2 months ago

      It could only fit 10 messages before it’d run out of space, and once full no messages would be received at all.

      You often hear programmers cite zero, one, infinity but fact of the matter is… while most if not all of your code should be capable of that, be blissfully ignorant about any imposed limit because it’s going to work whatever you set it to, the application often still should have a limit:

      Even if you’re not as ludicrously storage-constrained as those old Nokia bricks the data structure you’re storing it in is going to have some kind of assumptions about up to what number of elements it’s going to be efficient, so in e.g. game programming you write your code, document your assumption in the form of an error or warning thrown if that limit is exceeded, and when the level designers break it you have a look together at the thing and decide whether the limit needs increasing, or the level designers should reign in their use of whatever thingummy is breaking the limit.

      Not to mention that just storing an index for an arbitrarily large data structure can take up arbitrary amounts of RAM. Do you really expect me to use variable-sized numbers just so that you can have more than 264 (~1.84×1019) messages. Or columns in your spreadsheet, or whatnot.