Apps :: Two new applications



Quote
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 meant to add in my previous response I wanted to think more about these before passing judgment. I've given them more thought.

I'm neutral on the first point although I see limited usefulness to it. If one wants writable extension directories in /opt, one can already use tar.gz now (or even UNC, though I don't know why one would do that since it seems it goes against what unionfs is all about). What I wrote previously about issues of overlays on mount points (i.e., UCI directories) still concerns me.

I don't care for the second point at all. The whole idea behind using filesystem overlays like unionfs is to write across the operating system. Application extensions aren't the only thing for which UNCs are useful. They can overwrite /home and /etc, making things like configuration files portable or even easier to try out (I've been using overlays similarly for "portable" settings between different distros, remasters, etc., so I can carry over WPA and other settings and keep them in the directory structure I normally use).

As I wrote above, you can already compile a UNC to install to /opt. It seems that it would be redundant to what's already in UCI. It also begs the question why you would need to have unionfs at all for it in the first place and give up the leverage it affords of laying files and directories over a traditional directory structure. I don't want it to be limited to /opt.

The third option makes some sense but I don't think it's practical. If you require compiling executables to /opt/bin, what about all the share and lib files in self-contained apps? Those don't belong in a bin directory. If you'll end up with things installing in /opt/share, etc., I'll pass. I'd rather continue to use links between executables and /opt/bin.

Personally, I'd prefer to see tar.gz deprecated altogether in favor of UCI and, likewise, deprecate DSL in favor of UNC. I know that's not likely to happen -- especially the DSL-UNC thing because some users will choose to not use unionfs. But to make things more nomadic, I think it makes more sense to use overlays and compressed/(un)mountable applications.

Quote (lucky13 @ Mar. 02 2008,14:46)

Personally, I'd prefer to see tar.gz deprecated altogether in favor of UCI and, likewise, deprecate DSL in favor of UNC. I know that's not likely to happen -- especially the DSL-UNC thing because some users will choose to not use unionfs. But to make things more nomadic, I think it makes more sense to use overlays and compressed/(un)mountable applications.

That is exactly how I wanted to simplify extensions.
When I proposed doing such, I got much grief, as some, perhaps many, refuse to use unionfs. They boot using legacy option.
I still think it is a better solution.

The biggest reason to not use unionfs is that it's too buggy. I thought that's why unc extensions aren't unmounted?

.tar.gz could be replaced by .uci IMO, but it would make looking in on non-DSL systems harder.

i only suggested renaming the .tar.gz  because in the rest of the
linux world a .tar.gz is just, an innocent tarball.

and although i don't use an hd-install, it can get confusing when someone who does, plans to make an app for hd-install and wants
to call it that.

The .tar.gz ias used in MyDSL extension is simply a tarball.
It does nothing more than lay down files as in any tarball.
Since both menu and icon are optional there is nothing unique about a tar.gz.

I have never seen any standard convention specifying relative or absolute pathing within a tarball. I always preview (ztf) to see which pathing was used in any tarball that I am going to install. And that is why I wrote xtar.lua the way I did, automatic preview.

Next Page...
original here.