Apps :: Two new applications



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

It's one of the things with a roadblock as far as 2.4 development goes. How much better is its implementation in 2.6? I don't know for certain. Andrew Morton includes unionfs in his tree, fwiw.

Quote
it would make looking in on non-DSL systems harder.

Please explain.

-----------------
humpty:
Quote
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.

I think it's worth revisiting whether DSL should even include a traditional hard drive install option when it moves to 2.6. While I generally like as many options as possible, I think there are better options if users want that kind of set up (and I'm saying that as someone who has a couple hard drives with DSL traditional installs). It was okay when DSL's cart was tied somewhat to Debian Woody. But as Debian dropped support for Woody, I think all of that gets in the way and we have too many people asking questions trying to use DSL in ways it's not intended (e.g., someone asking why apt-get dist-upgrade breaks!) and complaining about it. Maybe it makes sense if DSL 2.6 will be tied to another distro, but if it's not 100% compatible and, maybe more importantly, doesn't stay up with changes in that distro, why bother?

I think it's adequate to offer frugal and encourage use as DSL is intended to be used, including with UCI and UNC extensions. Get people away from dsl and tar.gz extensions. If you want a "Debian-like" system, just use Debian.

I know there will be people who will object to being forced to use DSL as it's intended. How long will they get to decide the future of DSL?
I meant by that that as the cloop module is a PITA to get to compile, and the cloop tools are flawed by design (the ram constraint), it is harder to look inside an extension from a non-DSL/Debian/Knoppix system.
Quote (lucky13 @ Mar. 03 2008,12:25)
Quote
it would make looking in on non-DSL systems harder.

Please explain.

I think he means for easy viewing on any system, since tar.gz's are typically supported oob or some archiving program (whereas cloops are less likely).

That's an interesting idea to have that restriction on those hd-installs, but, as of the moment, I'm leaning towards having that placed into an extension instead.

I agree that the .tar.gz extension name can be confusing (such as someone trying to load a non-mydsl .tar.gz that could potentially be harmful, since afaik no checking is done for loading, or submission of bad extensions, etc).  It's fine once one knows that there is a specific extensions requiring a certain structure for it, but iirc the naming was also kept the same for backwards compatibility.
Although I have not had problems compiling cloop for 64 or even 128 devices, perhaps as we move away from 2.4 kernel and Woody, I should also consider to switch to squashfs instead of cloop. It would mean less backward compatibilty. DSL is one of very few distros that have tried to maintain backward compatibity from nearly its first release!
I didn't succeed compiling a newer version of cloop for my 2.6 kernel when I tried. It might behave better now, but the tools' flaw still exists.

I'm against taking HD install away. Debian would not run as nicely on old hardware as DSL. It's bloated compared to DSL. It has different goals. If DSL dropped the whole option, which distro should the ones on old HW looking for the HD install features turn to?
Next Page...
original here.