On 2021-03-10 at 19:31, Cmdte Alpha Tigre Z wrote: > Written by The Wanderer > >> Well, if all you want is to be able to have more "newbie-friendly" >> descriptive names of the directories, it might be possible to >> achieve something like that by the simple addition of a collection >> of symlinks; just symlink e.g. "/Configuration" to '/etc', >> '/Programs' to '/bin', "/System Programs" to '/sbin', '/User Files' >> to '/home', et cetera. >> >> That wouldn't get rid of the existing names, but it would be simple >> to implement as a single nearly-empty package. >> >> I imagine one could also set up a custom configuration of some >> file browser such that it would hide displaying the "real" names, >> and then ship a sort of micro-distro (installer task, maybe?) which >> installs the symlinking package and that file browser as part of >> its standard UI setup. It wouldn't be perfect, but it might meet >> the described want. > > I was thinking about that, but something could go wrong with that: > > Written by me. > >>> I was wondering what would happen if some program used filesystem >>> paths as its input data for some processing task. He he, yes, >>> changing status quo is not easy I don't see why that would come up in this case. In the model I described, the original paths which you found confusing are all still there, and anything which wants to find things under them can continue to use them. All this model does is give those paths an additional name each, and maybe go out of its way to hide the original names from you. Just because there are new names, and you can't see the old ones when you use one specific way of looking, doesn't mean that they aren't there or that other things can't see them. That would mean that you'd probably still see the original names in e.g. program error messages - but you could continue to use the new ones when navigating through the filesystem, and the circumstances in which it could lead to something breaking would be relatively rare (and maybe even nonexistent). That said, I repeat, I don't think the benefit from this would be remotely worth the effort that implementing it would require. If you happen to think it would, then you are entirely free to implement it. Doing the first part (creating the new names) locally on a per-machine basis is a trivial matter of setting up a handful of symlinks. Anyone with much *nix experience could do this casually, if given root access on the relevant computer. Doing the second part is a complex and nontrivial matter of A: finding a file-browser program which can be configured to hide files without having to rename them and creating a suitable configuration for the names you don't want to see, B: finding a file-browser program which can't be configured to do that and modifying it so that either it can or it just automatically hides them without configuration, or C: writing a file-browser program with those capabilities, entirely from scratch. If the type of file-browser program required for option A already exists, option A could probably be done in a week or less by someone with enough *nix experience to know how to search out programs and learn to configure them. Option B would probably take weeks at least, for someone who already has skill with programming. Option C would probably take months at least, for a reasonably expert programmer. Doing the third part (the "micro-distro") is probably not as hard as the second part, but presents an entirely distinct kind of challenge, and I don't even know how to estimate how long it might take. -- The Wanderer The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man. -- George Bernard Shaw
Attachment:
signature.asc
Description: OpenPGP digital signature