• partial_accumen@lemmy.world
    link
    fedilink
    arrow-up
    6
    ·
    3 days ago

    My RPi uptime on one project will never exceed 4 hours.

    I’ve got a cron job set to reboot my Raspberry Pi every 4 hours because I wrote a crappy Python app that continuously creates objects during operation that I would have to recreate, but I can’t delete the originals, or rather, I can delete the original parent but the child survives and keeps its memory allocation. So a full reboot with autolaunch of the application on boot is my ugly janky workaround. Its a cosmetic application, nothing critical. Its just a colorful display of data metrics.

    I can hear the horror and gnashing of teeth of real developers as they read this.

    • ozymandias117@lemmy.world
      link
      fedilink
      English
      arrow-up
      7
      ·
      edit-2
      2 days ago

      As a real developer…

      I just remember that airplanes have “reboot the plane every 51 days” to prevent an overflow from crashing the plane in their maintenance manuals

      So, like, yours can be improved, but it’s not safety critical like other reboot requirements…

    • fayoh@sopuli.xyz
      link
      fedilink
      arrow-up
      8
      ·
      3 days ago

      You just lack imagination. Some hikvision security cameras (the large, very expensive enterprisey ones) restart every couple of days due to “buildup of cosmic radiation”.

      No matter how competent you are as a developer, there is no escaping cosmic radiation! 😉

    • shalafi@lemmy.world
      link
      fedilink
      English
      arrow-up
      6
      ·
      2 days ago

      I’m a sysadmin and I’m weeping, gnashing my teeth and rending my garments. 😆 And I’ve never done anything janky like that. Ever.

      • partial_accumen@lemmy.world
        link
        fedilink
        arrow-up
        2
        ·
        2 days ago

        Oh, there’s even more jank in this thing than the reboot workaround described above!

        I have 3 windows displaying different metrics on this display powered by the RPi. Because of the animation of each metric rendered on the display, higher value metrics will consume more CPU. Since each is a separate process, the animation in the displays would be different for each window by without any modifications. So to make each of the 3 display’s animations operate at the same relative speed, I do a calculation of how the number of objects being displayed for the metric, then add an amount of invisible (well, black on black) objects to each window so to equal a fixed amount of the animation speed I want resulting in each window having the exact same number of objects and the animations move at the same speed.

        This works surprisingly well. The only time I have to monkey with the fixed value is if I’m using it on faster or slower Raspberry Pis. For example, I’ll have a lower number of final fixed objects for an RPi 3 rather than a higher number of fixed final objects for a faster RPi 4.