Ah, yes, well...
Posted Jan 27, 2012 18:58 UTC (Fri) by jd
Parent article: The case for the /usr merge
Most of the good points have been made, so here are some bad points that can be added on:
- Since you're not continually writing to the recovery partition, you want a format that can always be accessed and possesses a high read speed even if that sacrifices write speed and write robustness. You want a reasonably wide range of recovery tools, statically linked so that they're independent of any other change in the system, so you don't want filesystems with overheads. This is a highly specialized set of requirements that applies to no other part of the system. It should be isolated as far as is humanly possible. Files containing filesystems are only a replacement if all the criteria above and mentioned by others as necessary can be met.
- Optimal performance will always mean having a large set of specialized systems, not a single compromise-driven one-size-fits-all system.
- We need a broader and maybe deeper directory tree, not a shallow, simplified one. Packing too many files into one directory risks name collisions and invites security problems (it's easier to remember to lock down one directory than it is to remember to lock down every file that needs it). It also complicates the case where you need multiple versions of things.
- If any directory should go, I'd eliminate /usr as a physical tree and make it a virtual one. Each user and each process would then see /usr/* according to what they have rights to see. This solves the need of commercial software, avoids the collision issue, maintains LSB as far as the users are concerned, unclutters what is visible and allows even finer granularity on your choice of filesystems as you can have "/usr" be on several according to the needs of the software.
Yes, there will be complaints about this approach, but I did tell you these were bad points so don't blame me. However, I'm twisted so I like it.
to post comments)