I finally got around to burning a disk with 3.2 to try out the UNC extensions. I'm running a dell latitude laptop with 250 megs of ram. Although the UNC's loaded and everything initially worked, the desktop would freeze up, or apps like Emelfm would stop loading.
I next booted from an older version CD just to compare, and tried to abuse the system by repeadly clicking UCI's (load, unload, .....). Everything snapped and appeared unbreakable. Even apps like OO instantly load and unload, with no damage to the desktop. Maybe someone can write a dsl2uci.sh script??I've been seeing something similar since I started to use unc's rather than dsl's from DSL 3.1 onwards - I was thinking the problem was probably due to some kind of error I was making:
1. Using unc's with blank directory entries 2. Using unc's that overwrote something important 3. Using unc's containing files that were owned by root rather than dsl or vice versa 4. Using unc's built from Debian stable packages because they were not available in Debian oldstable 5. etc, etc
I also noticed (perhaps I am imagining this) that my system works for longer if I load the unc's from a terminal window (mydsl-load) rather than the right-click menu.
A while ago I had made a simple script to set up a 2.4.26 kernel sources environment (once gnu-utils.dsl and gcc1-with-libs.dsl were loaded) to re-build the kernel. I tried this the other day with the unc equivalents and got several weird errors.
All this being said, I'm pretty sure the mistake is mine somewhere or other...
Quote
Maybe someone can write a dsl2uci.sh script??
I think that would be pretty much impossible to fully debug. There is no way to tell whether an application which was originally compiled to run from /usr would succeed when moved to /opt.
I noticed my system randomly freezing with unionfs enabled without even installing an unc package (never a problem when booting legacy), so i don't think the problem is necessarily with the unc packages themselves.
Quote
Using unc's that overwrote something important
As far as I know, uncs do not literally overwrite anything in the base system, since their file structure is pretty much the same as ucis. However, I could see possible file conflicts if the unc package contains a file with the same filename as one already in DSL. In this case, I suppose one or the other has to take priority, but I have no idea which one. In either case there is a possibility of failure, either by the unc application or by an app in the DSL base.
Overall, my belief is that the unionfs system is very useful for some (most?) users, but I have a feeling that it is not stable or flexible enough to be depended upon in every environment. I'm sure others would disagree and say it's the best thing to happen to DSL, but after several months with it I'm still not impressed.DSL has always been about choices. Even with it small size, I still support both unionfs and legacy.
If you prefer no unionfs boot with legacy boot code, or add it to your append section. This support will not be abandoned
Unionfs is used in a very limited way, i.e., mount points. You can use the command listu to see the priority of the overlays. I don't experience these locks up but then again, I mostly program and not a big users of contributed extensions. I run the default unionfs with alsa, opera, xfree, and gnu-utils on a 112MB transmeta system without issues. Without unionfs it would not be possible.
Running DSL with user contributed extensions, either .dsl or .unc can sometimes cause issues. The uci being self contained are by far the safest to use however, they are by far the most difficult to create.
Speaking for myself, I choose DSL because it's fast and because it's extremely stable. I can buy 250 megs of ram for about $50 or buy a laptop with 250 megs of ram and no operating system for $200 on eb ay. People trying out DSL for the first time will never know the stability of the older version of DSL. Just my thoughts.......Next Page...
original here.