> you can run out of space at one partition, but have lot of free space at another

that's exactly the point — you can run out of space in your /home but that does not affect, for example, /var. or vice versa, log explosion in /var is contained within its own partition and does not clog the entire filesystem.

Logs should had a limit, and dealing with partitions is inconvenient for home user. How do you easily change allocation of space between partition?

Also, there are quotas for this purpose.

very important for /var/log, pretty easy to have log spamming app fill the drive, and you don't want logs filling get your database into out of disk space state

There are a lot of reasons. Just three from the top of my head:

1. The way Unix works, a directory is a file, so if you can write in a directory you'll also be able to move directories around (and thus break the structure you mentioned completely).

2. Doesn't make sense for multi-user. Yes, I understand most people have their own computers, but (1) why design it in a way that breaks multi-user unnecessarily? (2) there are a lot of utility users, and having them get access to user files because of the way this is structured is silly.

3. `grep -r` is going to be a pain in the ass when searching your own files, because it'll also search all the other system subdirectories too.

> The way Unix works, a directory is a file, so if you can write in a directory you'll also be able to move directories around

Well, maybe this should be changed, or we could just use the sticky bit.

Other users, except for primary user, can use /ubuntu24/home/. Primary user uses the root of hard drive however they want.

> because it'll also search all the other system subdirectories too.

It's already a pain because /home contains lots of system files, caches etc. And it would not be difficult to add a flag "skip system files".

It’s just historical. Believe the large number of top level directories was a result of ken not having enough space on a single disk on his PDP, when that was precious.

For years I’ve been putting all user data into a separate /data partition and have kept the OS partition small (~30gb). But you have to fix the system when first installed. When I still used Windows I had the same c:/d: split.

More recently started putting kernels into a bigger ESP (EFI) partition with sdboot or uki.

With terabyte system disks, running out of space mostly doesn’t happen anymore unless you made the system partition(s) small. Don’t do that, give them plenty of GB, each of which are now thousandths of the disk.

No. This makes configuration complex, pain to restore if something breaks, and some partitions will have lot of unused space.

Not at all. Having your data on a separate partition makes system upgrades and backups a breeze, the opposite of what you said. Only one percent of my disk is currently "wasted," and I can live with that.

If one user kept their files in the root directory, where would a second user keep theirs?

In /ubuntu24/home. Or a subdirectory could be created in the root directory.

This is a very recent aspect time wise in the very long history of Unix (and Linux) systems.

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

Partitioning a drive lets you use different file systems on different parts.

It also lets you somewhat-better enforce things like:

* Setting some data aside as read-only-never-touch-it.

* Excluding some files and directories from searching and indexing.

although admittedly you don't _have_ to partition for that purpose.