Hint: :q!
Sister communities:
Community rules (click to expand)
1. Follow the site-wide rules
sudo in Windows.Please report posts and comments that break these rules!
Important: never execute code or follow advice that you don't understand or can't verify, especially here. The word of the day is credibility. This is a meme community -- even the most helpful comments might just be shitposts that can damage your system. Be aware, be smart, don't remove France.
I like having a consistent update and reboot schedule. Uptime feels overrated over stability and clearing the RAM occasionally.
I definitely have some Docker containers that randomly stop working, and they are more often consistently fixed by a reboot of the machine rather than a reboot of the container or the Docker service.
Not to mention the security implications of not rebooting after certain updates.
Clearing the ram? For what purpose?
At some point when I am less busy again I think I am gonna swap back to a debian based system because my experience on arch and red hat systems just hasnt been as good (this may be because I started on Debian based systems and keep trying to use commands that dont work on the other ones out of muscle memory)
I get bored every so often and move all the important stuff to an external drive or a separate internal one and completely change my os
I am on manjaro but I have also run arch, red hat, void, mint, Debian, Ubuntu and a bunch of others that I either put on laptops or something similar as messing around with devices
Tails and slitaz have to be my favorite to run from a USB but peppermint isn't the worst
I just did the contrary. Moved from debian to arch. After the update to trixie my network stack completely died somehow, so I'm going back to arch.
Huh. Only 11 days on the Raspberry Pi I'm using as a "desktop system" right now. (Arch Linux Arm, btw... though Arch Linux Arm sucks now-a-days.)
Let's check my RPi-based NAS:
[tootsweet@mynasserver ~]$ uptime
19:56:07 up 212 days, 18:43, 4 users, load average: 0.16, 0.04, 0.01
Also not as long as I'd have guessed.
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.
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...
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.
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.
"If it works, it ain't stupid." ;)
I've got an OpenBSD based router with ~4 hours of battery backup. If I ever stopped futzing around with it, the uptime would be fairly close to when the last version update was. (They've got a release cadence of about 6 months).