Apps :: Two new applications



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.?
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.
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.
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.
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. :)
Next Page...
original here.