

Oh dang. That’s pretty cool!
Hello! I am originally @[email protected] but moved to lemmy.blahaj due to the June 2025 shutdown of lemm.ee (o7)


Oh dang. That’s pretty cool!


While these points are valid, I feel for a homelab, one would want a headless system running *nix vs OS X.
Also, it doesn’t help that there is no bootcamp for ARM, least not that I’m aware. Because if that was the case, then yes running ARM64-based distros/software would be great. I’d actually love to see how the M1 runs ARM server software :)


I had one 2 netgear WiFi AC routers that failed back to back, tho the first one ran for 10 years without trouble. When it died, the replacement was just… Awful. A direct downgrade in every aspect. Performance, wifi coverage was gARBAGE , it would reboot constantly, and the management ui was Fisher Priced to death. I got the Dream Machine BC it was on sale and they were about to roll out the new Dream Router. Never looked back.


Everyone in this thread is complaining about their short-lived UniFi devices, meanwhile I have two dream machines (the original WiFi 5 sol’n, not the rack mounted variant) that have had zero issues and are still running 24/7. I guess I should count my stars. (They replaced multiple failed netgear routers).


I wanted to provide feedback for THIS part only. :) not for OPs issue. I would have responded to OPs post if that were the case…


This but put the entries in /etc/fstab instead.


This looks pretty interesting. I have been passively looking for such a service. I will give this a whirl and try it out.


Based off what you wrote - and the fact that I’m massively sleep-deprived - it all makes sense. The issue you describe and the fix applied are akin to what we see in the database world, where users complain about queries being slow or unresponsive after trying to force-kill. Only for us to find out, that they submitted queries with a COMMIT after the whole 10mil record transaction, which clearly the DB can handle, but it will take a significant amount of time to rollback vs if the COMMITs are broken up and submitted more frequent. Basically chunking up the data into more manageable pieces as to not saturate the db threads, not to mention the underlying REDO and transaction log files too. So hope this was truly a long-term fix vs just a short-term one. Either way, great write up.( Also, you may want to invest in some 2.5gb networking for later, not that 1GbE isn’t enough, but just more pipeline is great, although I don’t know how much upgradeability your Synology will have in that department, so YMMV)


Libreoffice calc/MS Excel. Old school tracking and extremly flexible for documentation. I have been doing this for the last decade, both at home and at my workplace. My team loves it, tho YMMV.
Pardon my stupidity BUT why include stdout to Devnull? Why not omit and simply ‘du -sh /home’