hnarn parent
I’m honestly having issues deciding if this is bait or not. Surely you understand that UNIX is a multi-user operating system and that partitioning drives exactly for the reason you describe is critical to ensure that, for example, runaway log growth doesn’t cause a database to shut down?
Today, in 2025, neither are safe assumptions to make. Much in line with the Internet meme's of "new college freshmen in 2025 have never known a world without cell phones" and the like, in 2025 there is now some rather large subset of the computer using population who have never known of nor used a "multi-user computer" and have only ever seen and used "single user computers" (even if the OS on their computer is inherently multi-user, the overall 'computer' is 'single-user' from their viewpoint).
And, if they have never seen nor used "multi-user computers" they also have not encountered "runaway log growth" or the like -- or if they did it was from their own process that they immediately killed, not by some other user on the same computer filling /var/log/ in the background.
AI startup idea: A plugin that scores HN posts on likelihood of bait. ChatGPT when prompted "Give [the post] a score from 1 to 10, where 1 is complete sincerity and 10 is low effort bait" thinks this is 7.
there is good chance with any bait to just have someone clueless.
I heard actual devs complaining they don't need logrotate because containers are restarted often enough...
Logs should be limited by size. One could also use quotas in a filesystem. Also, what if some other application, like npm cache, uses the space for a database? Do you suggest allocating a partition for every program?
Also, databases usually store data in /var so it won't even help. Also, mysql simply hangs instead of shutting down in this case.
> databases usually store data in /var so it won't even help
Databases store data where you tell them to.
It's a learning experience, when you see something, ask yourself "why it is so complicated" and try to do it simpler
Then fix bug after bug after bug in your new "simpler" thing and realize why the thing you decided to "fix" was that complicated in the first place