myDSL Extensions (deprecated) :: complex dsl vs uci



cloop has a 2G limit to uncompressed size, I think, and you are limited to 8 cloop devices
You can get up to 255 normal loop devices, too. (to unlock the extra loops requires:
-A change to the boot parameters (add max_loop(s?)=n)
-An on-boot script that will create the devices necessary to handle the extra loops (makedev is not available on the core DSL distro, so it would require a script in /etc/init.d, a link to that script in /etc/rcS.d, and a copy of makedevs from the dsl-utils.dsl package, all stored within a customized .dsl pack)

I did a little research on this a short while back and had someone unveil the key to this trick in the "Talk" page.

And, yes, this will be in my own microlinux distro (so far, I've got a pre-beta running to X from eight or so megs, and is compatible with .debs, .dsls, .ucis, .rpms, dsl-type .tar.gzs (must be renamed to dtz for getting-there's sake), my own sqsh (kept cos it's simpler to just use the loops as sqshfs than to translate the loops to cloops - it has the same directory limitation as uci) and sqx (same as sqsh, but links into the filesystem proper) formats.

Running to X, but with little else but the WM (which is post-boot mounted and configurable from outside the main FS file.  I currently have Fluxbox, KDE, xpde and icewm).

Yes.  KDE.  As an sqx, and eating about 10% of the filehandles (1k blocks in a quick ramdisk kernel hack greatly reduces the amount of space utilized by symlinks.  To be honest, I don't know why one has to have blocks from RAM.  Sure, 1 Byte blocks would reduce performance - too many system calls - but 1k works fine on my 500 MHz machine.)  I also had to do a dirty little hack to the uClibc that I've been using.  If a symlink is opened for write, it checks if the target is read-only, and if so, replaces the symlink with a copy of the file and reopens it, returning the file handle.  Recursive function, nice and elegant.  Even detects looped links and complains about them.  The upshot is that the user can run an app like KDE mostly from a read-only source, but in the even the WM has to write to its own FS links, it can, and does, nice and transparent-like.

So yeah.  Nice stuff.  Too bad it's still buggy (mostly getting apps to work is similar to pulling teeth.  Things are supposed to work all transparently, but the second you install a decompression-type package - like a dsl, tar.gz, rpm or deb - over a big linked app, things get all funny.  S'probably from RAM use, so I think I just have to have a target machine calculator. (Idiot light-type + details.  you know.  OK! This disc will run fine on the target machine, WAIT! This disc will boot fine, but initializing too many of the optional apps will crash your machine,  STOP! This disc will not boot on your target machine)

Sorry I been so quiet lately.  While I've been doing that, on my Windows machine, I've been toying around with GBA development using HAM.  Fun stuff, really.  Nearly have a port of the old DOS game, Brix, completed.
resurrection of article & slight off topic
Here I have, bringing links from the dead:
BTW I'm not a programmer of any sort so anything I'm saying will be in layman terms.

1) RelinkCompiles everything into the same directory, effectively making a self contained app. Works like .uci uncompressed I guess. CLI interface and stable, works hand in hand with make.

2)
AutopackageAutopackage is something like the way .exe's work in Windows, only that it's also self contained in the same directory. Version 0.7 with CLI, GTK+ or Qt frontend, stable API with 10+ working samples.

3)Klik (1) is something of a Click'N'Run, only that it's free in both senses of the word. Incredibly akin to .uci but has a far larger repository, already tested with Knoppix, MEPIS and Kanotix. Stock Debian is rumoured to work also; KDE may or may not be required.

So why am I talking about this? First things first Damnsmall is an incredibly useful distro and has a not-so-small following, with a very neato .dsl and .uci system, complementing an already powerful apt system. But myDSL will never, ever reach the scale of that of such repositories mentioned above; nothing short of a miracle or sudden upsurge of myDSL contributions of massive proportions will ever achieve that.
That's why I'm suggesting here to ya'll that we include another package management system! It WON'T replace the current system if I'm reading things correctly, its purpose will only be to benefit the DSL community more by providing huge treasure troves of software that is easily reachable.
I have been an advocate for our ci and uci. In fact if you look at the timeline of these features, DSL has had ci and uci before there was even a Klik and run.
I believe the vast majority of the Kilk repository will be KDE based. So how much would we actually gain?

With the added capability of completely "unloading" the uci in RC1. I would think that is should become "the" most desired form of an extension. I believe all .tar.gz could be easily turned into a uci which would benefit all users.

But also, another thing to think about. We are a community driven distro. It is easy to Monday Morning Quarterback and say it should be this way. We have grown in many directions. And mostly to be easily embraced by the user community. It is indeed quite simple to make a tar.gz, then graduate to a .dsl. But look at the few uci s that have been contributed. So being community driven then those types that are easy to make become the most popular and not necessarily the best for package management. We are still evolving and will continue to embrace technology that our user community is comfortable with.

You can look for many more uci's in the near future as they provide an easy pacakge management as described in your above quoted articles. One last thing, our uci's do not require special software to download, nor do they even require any window manager to use.
Interesting stuff.

I looked at some of your links. I'm not sure what the actual system requirements are for things like klik. DSL may be too stripped down. I also noticed it appears to only be stable for Knoppix 3.3 right now while DSL is based on 3.4. May be a really cool option for the future.

Since Frugal now supports a persistent /home and /opt directory I have begun converting .dsl's to tar.gz's. So far I have been fortunate that apps have only required export LD_LIBRARY_PATH or a symlink or two. I've been able to convert tuxpaint, wmdrawer and gcompris. Ke4nt pitched in and converted gcompris to a uci! I know also that lgames will convert I just haven't packaged it up yet.

EDIT: I just saw roberts posted at the same time I did and agree with him.
Quote (roberts @ Mar. 21 2005,08:06)
I have been an advocate for our ci and uci. In fact if you look at the timeline of these features, DSL has had ci and uci before there was even a Klik and run.
I believe the vast majority of the Kilk repository will be KDE based. So how much would we actually gain?

I agree that we should go ahead with our repositories and extensions. dsl is not like the others as it is a little distro which thinks big!

I have been experimenting with the creation of postgresql and zope  for some time with debs and failed. now I have downloaded the source distro and am trying to make them into ucis!
./configure --prefix -/opt/oio/pgsql

but it needs other dependencies like zlib and python-dev and also creates a /var/lib/pgsql directory during make and make install. Does this mean this cannot be made into a uci?
Next Page...
original here.