iB::Topic::DSL v4.0 alpha1

	Damn Small Linux :: Damn Small Linux Board The DSL Forums

» Welcome Guest
[ Log In :: Register ]

Damn Small Linux Board » Damn Small Linux » Release Candidates » DSL v4.0 alpha1

		Mini-ITX Boards Sale, Fanless BareBones Mini-ITX, Bootable 1G DSL USBs, 533MHz Fanless PC <-- SALE $200 each!
		Get The Official Damn Small Linux Book. DSL Market , Great VPS hosting provided by Tektonic

Pages: (26) </ 1 2 3 4 [5] 6 7 8 9 10 ... >/

[ Track this topic :: Email this topic :: Print this topic ]

Topic: DSL v4.0 alpha1

< Next Oldest | Next Newest >

WDef

Group: Members
Posts: 798
Joined: Sep. 2005

Posted: July 18 2007,12:42

Re:

Quote

As far as the .tar.gz goes, is it time to drop it as unique MyDSL extension association and use only the standard definition of a compressed tarball? I would like to depreciate it as a MyDSL extension.

One idea would be to do away with the tar.gz extension type and instead just have .dsl for both in future, and add a line of code to the extension loading scripts to "prescan" the extension for non-writeable paths along the lines of:

EXTENSION=/path/to/extension

If mkwriteable has not yet been run, then do:

Code Sample

tar -ztf $EXTENSION | while read LN; do case ${LN} in usr*|bin*|sbin*|boot*|lib*|var/lib*|var/cache*) /etc/init.d/mkwriteable; break;; esac; done

Then mkwriteable only ever gets called if it needs to be and it doesn't matter anymore whether the extension has a .dsl or tar.gz suffix, so this would be backwardly compatible. This would also deal with "green" extensions that were mistakenly labelled .dsl when they only ever needed to be called .tar.gz

I think the .tar.gz extension suffix has always risked creating confusion for newbies with source tarballs and all kinds of other archives.

mikshaw

Group: Members
Posts: 4856
Joined: July 2004

Posted: July 18 2007,13:13

That sounds like a smart, simple solution to me.
I was wondering about certain extensions, such as the Tcl/Tk widgets, which could not work as uci or unc but would be a waste of resources as dsl. Your idea would fix that, and perhaps would prevent some existing *.dsl files to not bother with mkwriteable.

There would be an issue with installation time, though. Listing tar contents can take a noticeable amount of time, depending on how many files are in the archive.

--------------
http://www.tldp.org/LDP/intro-linux/html/index.html

WDef

Group: Members
Posts: 798
Joined: Sep. 2005

Posted: July 18 2007,17:17

Quote

Listing tar contents can take a noticeable amount of time,

The loop terminates as soon as a system dir is struck - since it's a pipe tar then stops listing files, so for "red" extensions it's quite fast. And, once mkwriteable has been called, it shouldn't get run at all.

The whole list will however get read for "green" extensions (a minority) if no red extensions have been loaded. I don't have any really big .tar.gz extensions, but on the 860K john-1.7.0.2.tar.gz it runs in 0.072s. On slow processors, maybe 10-15 times that delay is still tolerable.

As a backwards compatibility measure to get rid of the minority tar.gz's, I think it's probably wearable - people can wait a bit longer for the occassional large .tar.gz's to load?

If it proves to be a problem, another alternative might be to put an empty file in extensions for the sole purpose of flagging (for eg) that they are green and mkwriteable shouldn't be run, or to invent a new extension suffix, but I don't like either idea.

andrewb

Group: Members
Posts: 316
Joined: July 2005

Posted: July 18 2007,23:25

OK, so I probably missed something obvious, but... is there an easy way to turn the DFM desktop context menu menu back on after it has been turned off (via the 'Desktop Context Menu' checkbox')? Is there any documentation for DFM? The website http://www.kaisersite.de/dfm/ doesn't seem to have any .

roberts

Group: Members
Posts: 4983
Joined: Oct. 2003

Posted: July 18 2007,23:41

Quote

add a line of code to the extension loading scripts

How can this be backward compatible when such is the case?
You cannot go back and change the mydsl loading scripts on all previous versions of DSL. I would have to release another special extension (patch) to effect this change. Further more, word of such must somehow be easily made available, else low end machines would once again be unable to run many extensions. As the .tar.gz are no longer available as they have been renamed .dsl. And without the "loading patch" these machined would likely run out of inodes ( caused by unnecessarily running mkwriteable) than real memory. This issue was given much consideration years ago. With that kind of change I could simply renamed .tar.gz and be done with it. Still I don't find either very apealing.

Consider also that this only affects those still booting legacy. Most distributions have moved on to unionfs. Must I continue to still support both unionfs and legacy?

Does not declobber clean up poorly built .dsl extensions that cause grief in the past with unionfs?

If this is still to be considered, at a minimum, a test should be made for
1. The operating mode is legacy.
2. The extension is of type .dsl

126 replies since July 17 2007,04:58

< Next Oldest | Next Newest >

[ Track this topic :: Email this topic :: Print this topic ]

Pages: (26) </ 1 2 3 4 [5] 6 7 8 9 10 ... >/

Damn Small Linux Board » Damn Small Linux » Release Candidates » DSL v4.0 alpha1