And what's your security model? Each user that needs to run services has to run them under their user account? Or are you going to also allocate some number of service accounts to each user and pay the cost to manage these accounts and the combined quotas they entail?
Now how do your users' service accounts share resources? Someone will need a web server running under one account and a job processor running under a different account (different accounts in order to allow for limited privileges). Are they restricted to communicating through named pipes (hope no one else binds the pipe)? What if they want to share some disk-based resources? Shove them all in a group and set someone's home directory to 770?
How do you handle it when one of your users needs a SQL server? Do they need to install this in their home directory, too? And lock down their install so that hopefully other users on the box can't call it?
What about port binding? Just luck of the draw, and everyone binds on what they want? Then they file a request for you to forward to the port they happened to grab? And they hope that they never lose the port due to a server reboot, or a service crash?
People could work in the environment you describe, but it would be miserable. And you (the server owner) would have to sink a massive amount of resources into maintenance. This isn't a shortcoming of the OS. It's a fundamental mismatch between the goal of sharing a server among many users and giving those users sufficient control to build what they need.
How do you handle it when one of your users needs a SQL server? Do they need to install this in their home directory, too? And lock down their install so that hopefully other users on the box can't call it?
NixOS can handle situations like this. It enables per-user package management with deterministic, immutable installs. If multiple users install the same package, it only puts one copy on the system. Each user gets their own environment where they can customize the package without affecting the other users.
How does that work when you factor in quotas? What if a malicious user installs every possible package? Do they kill the system? How are versions handled? Can N users install N versions of a package? (Looks like the answer is yes.)
This sounds like a nice system. I'm just wondering how much of the core issue is really addressed.
For quotas, you probably want something like ZFS. It allows you to set both quotas and reservations. Reservations are nice in that they guarantee the specified amount of space to the given filesystem. ZFS allows the creation of many nested filesystems with different properties (including block-level compression and encryption) and uses inheritance and overrides to give you a very flexible, fine-grained level of control.
ZFS also has real-time, block-level deduplication. This will dramatically cut down on the space usage when users install multiple different versions of the same package.
By combining all this, you can give every user their own nix store with its own set of packages and a quota as well as a minimum reservation of space. Deduplication will take care of all the wasted space from multiple users having the same/similar packages installed.
Now how do your users' service accounts share resources? Someone will need a web server running under one account and a job processor running under a different account (different accounts in order to allow for limited privileges). Are they restricted to communicating through named pipes (hope no one else binds the pipe)? What if they want to share some disk-based resources? Shove them all in a group and set someone's home directory to 770?
How do you handle it when one of your users needs a SQL server? Do they need to install this in their home directory, too? And lock down their install so that hopefully other users on the box can't call it?
What about port binding? Just luck of the draw, and everyone binds on what they want? Then they file a request for you to forward to the port they happened to grab? And they hope that they never lose the port due to a server reboot, or a service crash?
People could work in the environment you describe, but it would be miserable. And you (the server owner) would have to sink a massive amount of resources into maintenance. This isn't a shortcoming of the OS. It's a fundamental mismatch between the goal of sharing a server among many users and giving those users sufficient control to build what they need.