In the interest of reducing possible confusion, I would prefer to see a unique extension name without a familiar one like gz (whether tar or anything else). Why not just .opt?An idea (just brainstorming): - Merge '.tar.gz', '.unc', '.uci' into a single extension name that installs into '/opt'??
My suggestion for the name: Retain '.dsl'??
Possibly, FUSE with a <insert-VFS-driver>?? Then, all extensions could be gzipped tarballs. (But won't tarballs be more memory-intensive than compressed images??)
p.s. I am quite sure roberts has thought of all this.
Quote
Merge '.tar.gz', '.unc', '.uci' into a single extension name that installs into '/opt'??
I'm not sure I follow why you would want to do that. Separate identities for each extension format distinguish the intended use. How is a user to decide which version to download if he's not using unionfs (mitigating against UNC)? What then becomes the distinction between UNC and UCI? Wouldn't UNC to /opt be somewhat redundant to using cloop for UCI (or vice versa) except that it uses unionfs? And then why give up the "stackability" of unionfs by confining it to /opt instead of across the system as intended?lucky13: You're right, the idea is rather, um, eccentric. Being able to mount tarballs seemed like a pretty cool idea. But then I realized that this idea has a fatal weakness. You can't "merge" files and directories like you can with UnionFS/AuFS.
Crazy idea: 1. What if '.uci' extensions were writable? 2. What if '.unc' extensions were changed to write only to '/opt'. This would be a complement to '.uci' extensions. The '.unc' can write into a '.uci' directory. But it can't write into itself (self-referencing is impossible). 3. Lastly, we could retain the '.tar.gz' extensions - for extensions that only write to '/opt/bin'.
I like this idea alot, although it seems somewhat insane.
p.s. Okay, here's an even crazier idea: We could call the 3 types of extension '.dsl1', '.dsl2', & '.dsl3'. Seriously!
Quote
We could call the 3 types of extension '.dsl1', '.dsl2', & '.dsl3'.
Too confusing. I think the more distinct they are the better.
I'm curious why you like the first crazy idea better than using UNCs over the standard file system. First thought, I think it might be problematic overwriting UCI mount points and then unmounting the UCI with a UNC overlay in place (crash/lock?).
I don't know. I admit I'm more familiar with its implementation in FreeBSD than in Linux and that I've refrained from using it in FreeBSD because of the seriousness of the bugs. Maybe the Linux implementation has fixed some of the issues that prevailed in FreeBSD.Next Page...
original here.
