Two new applications
Forum: Apps
Topic: Two new applications
started by: newby
Posted by newby on Feb. 04 2008,19:14
---Deleted due to errors---
Posted by roberts on Feb. 04 2008,20:07
.bz2 is not a supported MyDSL extension type.Please use the supported standards. I will adjust the format this time.
Posted by curaga on Feb. 05 2008,06:59
I don't think it's good to send apps needing stuff not in MyDSL (qt 4!), since the whole idea of mydsl is click-n-play, or atleast read info, load a dependency extension, then play..
Posted by stupid_idiot on Feb. 05 2008,07:29
Curaga:Hope to finish 'qt3.uci' and 'qt4.uci' by next month.
(Yay.)
Posted by lucky13 on Feb. 05 2008,13:54
Re: what curaga wrote, did you build against those libraries?Re: what s-i wrote, those UCIs may be of use if newby's qt libs were in the same /opt path when the scidavis extension was compiled. I bet it wasn't, though.
One way to see. I went ahead and opened it. This is not set to untar in /opt. See:
< http://lucky13linux.wordpress.com/files/2008/02/scidavis.png >
(edit: for comparison purposes, see also the following:
< http://lucky13linux.wordpress.com/files/2008/02/scidavis2.png > )
So, will this install in pwd or / ?
Notice there's an 18kb file of gpl.txt. Is this needed in a "damn small" extension since anyone can find a copy of it online?
In addition to what curaga wrote...
| Quote |
| Description: Program I made into a MyDSL extension |
Not helpful.
Posted by ^thehatsrule^ on Feb. 05 2008,14:55
These are not MyDSL extensions - they should be pulled.
Posted by lucky13 on Feb. 05 2008,15:56
From the info file for asymptote:| Quote |
| Copying-policy: No policy posted on website. Wikipedia lists the GNU General Public License |
This makes me very uneasy because this is the kind of thing you need to be 100% sure of BEFORE posting. Even though the extensions are community effort and not strictly DSL, this kind of thing ultimately reflects on DSL when users want apps or when lawyers get involved (fwiw, the FSF lawyers don't play any nicer than Microsoft's -- in some respects, I think they're more overbearing). We don't need anyone accusing DSL of being in non-compliance with their licenses!
Wikipedia may be fine for learning general information about things, but not when it comes to legal matters regarding distribution and redistribution of source and/or binaries. *Please* check with developers before submitting if you can't find specific information on their sites.
I went ahead and downloaded asymptote and looked at it. It has the same problem as the other one -- it's not prefixed for /opt. It also contains man and info pages, etc.
I agree with hats that these should be pulled. Thanks for the effort, newby, but please read the wiki for information on the different extensions and how to put them together.
Posted by roberts on Feb. 05 2008,16:16
MyDSL extensions are a community process. As such each extension is subject to peer review.
Therefore the subject two applications have been removed.
Thanks to the community for their review, comments and recommendations.
Posted by newby on Feb. 08 2008,12:24
| Quote (lucky13 @ Feb. 05 2008,08:54) |
| One way to see. I went ahead and opened it. This is not set to untar in /opt. See: < http://lucky13linux.wordpress.com/files/2008/02/scidavis.png > (edit: for comparison purposes, see also the following: < http://lucky13linux.wordpress.com/files/2008/02/scidavis2.png > ) |
Still learning here.
What app did you use to get that listing? I'll use it to check in the future.
newby
-- Learning curve? Hell, it's a mountain!
Posted by ^thehatsrule^ on Feb. 08 2008,16:11
It looks like you just archived some files, and didn't look up on how to create extensions... the wiki has some resources that you can start with.And to list an archive's files you can use the "-t" switch on tar.
Posted by lucky13 on Feb. 23 2008,18:50
I know this is a couple weeks old, but I'm playing catch up...| Quote |
| What app did you use to get that listing? I'll use it to check in the future. |
That's konqueror (I was using KDE that morning). It uses basically the same thing DSL has to get archive listings, it just does it differently. There's nothing all that special about it.
Those images were only to show the differences in archive structures. When extracted, your extension would install to /; this makes it an unacceptable DSL extension. In contrast, the mplayer.tar.gz extension extracts to /opt -- which is where tar.gz and UCI extensions belong (though, now that I see it again, I would be happier if the mplayer extension were more self-contained and extracted to /opt/mplayer instead of spreading out in /opt like that; I only downloaded a small one to compare).
As hats said, you can use "tar -t" to get the list of an archive in a console. DSL also has other tools to inspect archives. I think both emelfm and dfm will open an archive without extracting it.
Posted by stupid_idiot on Feb. 24 2008,02:54
Hi lucky13:The next update of MPlayer will be self-contained in '/opt/mplayer/'.
(Will probably include MEncoder together with MPlayer in 'mplayer.tar.gz', instead of in a separate 'mencoder.tar.gz', since the 2 programs are pretty small.
Less confusing/troublesome for the user.)
VLC will be in '/opt/vlc/' as well.
Scattering files all over '/opt/' was a real mistake.
Posted by lucky13 on Feb. 24 2008,05:25
| Quote |
| The next update of MPlayer will be self-contained in '/opt/mplayer/'. |
Excellent.
Posted by humpty on Feb. 24 2008,21:19
.tar.gz might be confusing for 'newbie's. perhaps anothername for it instead for future DSL ?
Posted by curaga on Feb. 27 2008,13:50
.opt.gz? I like it ;)
Posted by lucky13 on Feb. 27 2008,15:10
| Quote |
| .opt.gz? I like it ;) |
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?
Posted by stupid_idiot on Feb. 28 2008,10:14
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.
Posted by lucky13 on Feb. 28 2008,18:46
| 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?
Posted by stupid_idiot on Feb. 29 2008,01:36
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!
Posted by lucky13 on Feb. 29 2008,03:34
| 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.
Posted by lucky13 on Mar. 02 2008,22:46
| 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.
Posted by roberts on Mar. 02 2008,23:47
| 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.
Posted by curaga on Mar. 03 2008,15:03
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.
Posted by humpty on Mar. 03 2008,15:03
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.
Posted by roberts on Mar. 03 2008,16:06
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.
Posted by lucky13 on Mar. 03 2008,17:25
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?
Posted by curaga on Mar. 03 2008,18:43
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.
Posted by ^thehatsrule^ on Mar. 03 2008,18:51
| Quote (lucky13 @ Mar. 03 2008,12:25) | ||
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.
Posted by roberts on Mar. 03 2008,18:58
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!
Posted by curaga on Mar. 03 2008,19:07
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?
Posted by lucky13 on Mar. 03 2008,22:52
| Quote |
| Debian would not run as nicely on old hardware as DSL. It's bloated compared to DSL. |
Uhhhh, no. YMMV. I disagree that it's bloated. If you do a full install it certainly could be bloated. But that's not the only installation option.
I can do a Debian net install of only the things I want and need and be at a similar size as a DSL hard drive install, just as I've done with the BSDs. The same is true of Slackware, which allows the option of not installing X or of installing only select window managers.
| Quote |
| It has different goals. |
Exactly! You're making my point for me.
Why should DSL cater to those who want a Debian-like system? Debian already does that.
DSL and Debian are completely different animals. If you want a small Debian (or Slackware or whatever) system, they have tools appropriate for you. Their installation scripts and binary pools allow users to add or remove bits and pieces as desired with apt-get or slapt-get or yum or pkg_add/pkg_remove or whatever.
| Quote |
| If DSL dropped the whole option, which distro should the ones on old HW looking for the HD install features turn to? |
Slackware. Debian. Any of the BSDs. All are suitable for older hardware. Most (if not all) Slackware binary packaging is still optimized for 486 and comes with kernels suitable for use on 486 architecture. Debian likewise has kernels optimized for 486. You can make Debian and Slackware fit older hardware quite easily and without any X if you lack RAM.
When DSL moves to kernel 2.6, what will be the difference aside from intended use? DSL is intended to be more nomadic and Debian/Slackware/etc. are designed to install in a more traditional manner across one or more partitions. What if the next iteration of DSL isn't based on (or close enough to) another distro with its own repositories? Users who want Debian-based systems have other live CD options already like Knoppix, Sidux, Finnix, etc.
How many of those vintage hardware users are going to want to upgrade to a 2.6 version? How many are going to stick with older 2.4 versions? Why should 2.6 users with newer hardware and intentions more in line with DSL's nomadic philosophy be held back by legacy users whose demands are quite different and more in tune with Debian, Slackware, the BSDs, etc.?
Posted by curaga on Mar. 04 2008,13:03
Well, compare any two binaries from current Debian (lenny I guess) with the DSL counterpart. DSL has older versions, that function well but are smaller. Here you might say install an old debian then. While that might be done, you may be in need of package A that isn't in that debian, but a newer one. When you add the keyword to sources.list you will find it, but also that it will want to upgrade tons of libs to the newest level.I'm pro-2.6 and also against having a close package relationship with another distro. I prefer to compile from source, much cleaner that way.
In your last paragraph you however relate 2.6 kernel and the DSL philosophy together. I don't think it's like that, and that a HD install is easily doable with a 2.6 based DSL too. It can be as unsupported as now, but the possibilities shouldn't be limited.
Posted by lucky13 on Mar. 04 2008,16:07
| Quote |
| Well, compare any two binaries from current Debian (lenny I guess) with the DSL counterpart. DSL has older versions, that function well but are smaller. Here you might say install an old debian then. |
Or set up the system in such a way that it uses versions and/or configs you want; users aren't locked into any one repository if they even choose to use apt-get or whichever binary distribution method. One of the reasons I'm a big fan of ports and pkgsrc over binaries is because they make it easier to do exactly what the users wants -- e.g., compile against GTK1 instead of GTK2 (if possible). Where that's not possible, you can download the source you want and compile it separately. Both Slackware and Debian work very well with pkgsrc, both are suitable as bases for compiling preferred versions or esoteric collections of apps.
I also left out DeLi in the list of possibilities for people with older hardware. I'm not as gung ho about ulibc as you've been, but DeLi uses it and is oriented for older hardware. It also allows users to choose a ports system from Crux.
I want an idea of how many users with older hardware are going to move to a 2.6 version of DSL. I think between that and a better implementation of unionfs in 2.6, it's possible to transition things to the more nomadic way Robert has wanted to in the past and streamline MyDSL to UNC and UCI.
He's commented about backwards compatibility. Sometimes, though, that becomes more a hindrance than a benefit. How long should DSL continue to support hard drive installs, dsl and tar.gz extensions, use cloop instead of cramfs or squashfs, etc.? With the changes coming to update DSL, it's time to look at the big picture and decide what's in the best interest going forward. The longer DSL looks backward (hard drive install, dsl and tar.gz), the less reason current and future users will have to use it the way it's intended.
Posted by ^thehatsrule^ on Mar. 04 2008,17:23
I have a feeling most users would not want to compile programs, and do like the option of at least trying apt repos (not based on any stats in any way though). The current state of MyDSL is growing larger, but it does not cover as an extensive field. Not tying it to another distro's could avoid problems and confusion (like apt-get), but would lose that part (again, this is really not based on any numbers).I think dsl and .tar.gz are not really 'backwards'. Here's an example. For my own uses on modern machines, I only use those extensions. If you look at the current trends and the future, permanent storage devices are much slower than having a ramdisk, and with RAM getting cheaper and in higher capacities, etc. but it is probably quite trivial to make a wrapper to load uci/unc's to act as dsl/targz's, or even just copy the extension to the ramdisk first... Another example would be users who avoid the use of unionfs (although it has been hinted that another similar technology may be used instead).
Saying all of that, I can see if this 'branch' of DSL does have its own restrictions since the target audience would be different. The users who would try this one would probably be smaller in terms of numbers, but would grow in time. So if there is any time to set the base 'rules' or standards straight, now would be best time (imo).
heh - this thread had become a full blown discussion now.
Posted by curaga on Mar. 04 2008,17:57
I don't see how keeping hd install around would be a hindrance; unless you mean only the extensions. Uci's can be used in hd installs already, and unc's can be converted.Since a big update is coming, which would in itself break some of the backwards compatibility, it would be fine by me to flush old standards and shed the skin. As the new version grows better, more users will turn to it. It's just natural to go forwards.
Also, having a 2.6 kernel might decrease the hate mail to Robert.
Posted by roberts on Mar. 04 2008,18:40
I have to admit that I really wonder about a tiny core when I cannot get consensus on making current DSL smaller. Many currently included programs could easily become or are already offered as extensions. Removing then would drastically reduce the memory needed to run DSL. With all this talk about supporting older hardware you would think that the two would go hand-in-hand. In v4x I am talking about fluxbox and emelfm to start with. Drop the larger duplicates in favor of the smaller.
Posted by lucky13 on Mar. 04 2008,19:12
curaga:| Quote |
| having a 2.6 kernel might decrease the hate mail to Robert. |
You underestimate how others can and will react to whatever decisions he makes!
"Don't remove emelfm!" -- So we get two file managers in 4.x and those of us who prefer mc use it by extension.
"Don't remove fluxbox!" -- A newer version is available in MyDSL and it will work just as well as or better than what's in the base!
"Upgrade this!" -- Okay, but it can break something else or it may necessitate removing other things to make room.
"Include that." -- Even if it's in MyDSL already?!
A lot of these requests are duplication, redundancy, bloat, etc. Not "damn small."
How can it be win-win for him? That's why I think he should just follow his own vision for DSL and let the chips fall. I think users will eventually come around.
-----
roberts:
| Quote |
| I have to admit that I really wonder about a tiny core when I cannot get consensus on making current DSL smaller. Many currently included programs could easily become or are already offered as extensions. Removing then would drastically reduce the memory needed to run DSL. With all this talk about supporting older hardware you would think that the two would go hand-in-hand. In v4x I am talking about fluxbox and emelfm to start with. Drop the larger duplicates in favor of the smaller. |
I don't get it, either. I would understand it more if this were a static environment without extensions or if you were behind the eight-ball on having extensions to make up for what's moved out of the base. Instead, a lot of this is duplicated effort with stuff already in MyDSL and you still have people trying to get other stuff (e.g., virtual keyboard) from MyDSL moved into the base!
Posted by Nigadoo on Mar. 05 2008,18:23
Thanks for bringing up the virtual keyboard ... I resemble that remark. It is pretty cool to have a distro like DSL with pretty well everything thrown in but the kitchen sink fitting 50MB.
Personally, I would prefer DSL as a LEGO-like kit, with minimal base to easily let users build the kind of 50MB, or whatever MB, distro they would like/need.
Yank out all apps, and leave only the bare minimum to allow the complete newbie to create their own MYDSL distro. Take out the following, and make them available via MYDSL:
* fluxbox
* all editors (except one, maybe Beaver for newbs?)
* all graphics apps
* all office apps
* all sound apps
* firefox, netrik
* non-crucial net apps, like remotedesktop etc.
* all games
Would that make much difference in ISO size?
The nomadic DSL user would have the super-slim base DSL CD (I wish two kernels would fit on that!) and a CD or USB key with all the apps they need. Personally, I'd like a 2.4 kernel version of DSL and a 2.6 kernel on each their own mini-CD.
OR, if a user really just wants to have the one CD, then make MYDSL with the can't-do-without apps needed.
Sounds extreme, but that should make just about everybody happy ... anybody who can burn the DSL ISO should be able just fine to build their perfect MYDSL ISO.
Posted by mikshaw on Mar. 05 2008,20:02
| Quote |
| 1. What if '.uci' extensions were writable? |
| Quote |
| I think he should just follow his own vision for DSL and let the chips fall. I think users will eventually come around. |
I would suggest, though, that the current path seems to be working in a sense. That path, with some exceptions, seems to include gradually pulling out unnecessary applications and sometimes replacing them with smaller alternatives. The removal of mc was entirely unnoticed by most users. If firefox is left in its current version in DSL, eventually most users will opt for myDSL versions, and it can then be pulled from DSL base without people getting snippy.
Posted by jaygeedsl on Mar. 05 2008,23:07
| Quote (Nigadoo @ Mar. 05 2008,18:23) |
It is pretty cool to have a distro like DSL with pretty well everything thrown in but the kitchen sink fitting 50MB. Personally, I would prefer DSL as a LEGO-like kit, with minimal base to easily let users build the kind of 50MB, or whatever MB, distro they would like/need. ...... |
I'd like to comment on your "LEGO-like kit" suggestion from a newbie's perspective.
IMO it's a difficult enough task for a newbie to get DSL up and running using only the apps he needs with a standard "everything bar the kitchen sink" DSL version.
To be faced with the prospect of adding apps piecemeal from a barebones distribution would require a regularly updated single-stop documentation source allied to an all-GUI approach else it would be inviting a flood of additional help queries on this board.
Having achieved a working familiarity with DSL, the ability to produce a custom distro - again preferably GUI-based - would be a definite asset.
stupid_idiot's proposed "Howto for building a DSL environment using the LFS method" might be interesting in this context.
Posted by curaga on Mar. 06 2008,13:39
For an example of a newbie's select your components around the tiny core-distro, check out the Nimblex creator. First it asks what areas are you interested in, then goes through each category with descriptions of programs and very easy UI. As the last step it builds the iso for you.Since we do not want to stress the DSL server, I would replace the iso generating by just outputting a list of all the extensions selected, as well as a link to each one. All the user would need skill at is generating the iso, or just burning the tiny core iso and having all the extensions in mydsl-named directory on HD or usb.
How does this sound?
Posted by roberts on Mar. 06 2008,16:17
If one can deploy frugal, then mkmydsl automatically makes an iso.This easy custom iso creation tool has been a part of DSL for years. Actually since the beginning of mydsl extensions.
The concept is to learn to walk before you run. By that I mean, start slow. Try out different collections of mydsl extensions. When you have a collection that you like and they are setup correctly, i.e. survive a reboot, using a mydsl directory, then use mkmydsl to create your custom cdrom image.
This same concept would easily work with a tiny core.
Posted by curaga on Mar. 06 2008,17:06
Yes, I agree. What I meant was customization before trying them all, which in some cases might not be as good as selecting with experience, but in some cases might be very nice.
Posted by jaygeedsl on Mar. 06 2008,17:49
curagaThe Custom NimbleX creator seems very much what I had in mind. I'll try it out on a spare 4GB pendrive when I've got time between fishing trips.
roberts
I didn't realise that there is effectively the same custom distro making facility in DSL in the shape of mkmydsl. When the latest xine is available - the only app I need to complete my desktop collection - I'll give mkmydsl a try.
Many thanks gents.
Posted by roberts on Mar. 06 2008,21:02
| Quote (mikshaw @ Mar. 05 2008,12:02) | ||||
I would suggest, though, that the current path seems to be working in a sense. That path, with some exceptions, seems to include gradually pulling out unnecessary applications and sometimes replacing them with smaller alternatives. The removal of mc was entirely unnoticed by most users. If firefox is left in its current version in DSL, eventually most users will opt for myDSL versions, and it can then be pulled from DSL base without people getting snippy. |
Firefox will not be removed from DSL.
Look for an update to Firefox in the next version of DSL v4.3.
John has finished his size reduction work so that a newer version will be possible. I had to make some other cuts in order make it all fit in 50MB. I am still working on some changes to better search MyDSL extensions.
Posted by mikshaw on Mar. 07 2008,01:49
Another idea would be to post applications targeted for future removal from DSL. If those apps are not already available in mydsl, they could be created before the next DSL release.
Posted by curaga on Mar. 07 2008,08:45
Could those tips for cutting Firefox size be posted somewhere? Would be very interesting to read..
Posted by roberts on Mar. 07 2008,18:57
That would have to come from John, as I know not. I never got into XUL.Regarding FFv2, it take so much more resources that v1.06.
So.... It is still not official - what and if or when. Is it worth the effort and the resource cost, especially for low end machines.
Posted by clivesay on Mar. 08 2008,03:51
| Quote (jaygeedsl @ Mar. 05 2008,17:07) |
| I'd like to comment on your "LEGO-like kit" suggestion from a newbie's perspective. IMO it's a difficult enough task for a newbie to get DSL up and running using only the apps he needs with a standard "everything bar the kitchen sink" DSL version. To be faced with the prospect of adding apps piecemeal from a barebones distribution would require a regularly updated single-stop documentation source allied to an all-GUI approach else it would be inviting a flood of additional help queries on this board. |
This is why I have always thought that a partially built "lego kit" would be the best compromise. Distribute a tiny core with a few extensions included to give the user a nice basic desktop environment. The newb can burn the iso and install the system as is with no issue while the advanced user can navigate the files and add/remove what extensions they want to make their custom system.