Tiny Core Base > TCB Talk
tce/app-browser , sparing of storage or network
mocore:
thinking about repository and related tools
using app browser or tce to browse the extention info , request's separatly each .info/ect file viewed
and also afair separate request for each dependent tcz
i have in the past wandered ,..
0) could the time/bandwidth be reduced ?
if repo metadata (as mentioned in the below quote ) and individual extention metadata files could be
downloaded once then used/viewed localy?.. as apposed to repeatedly requested
i guess this makes less diffrence to those with a local mirror or who know which packages are required
for the case of browseing the apps and searching/exploring posilities before testing ( if the build works at all / has required dep's ect )
waiting for many request to compleate takes time , at this point storage and bandwidth are abubdent for the most part , time is however constrained constantly
1) when downloading extentions & dependencies could the initial conection be reused ??!!
which rased the question *exactly* what version of http is suported by tce/app-browser / tce-fetch.sh /wget and or the by the server
as this is sort of an implicit dependency of tc operation
one imho woth some consideration
and which seem a fair question(s) considering tc philosophies
http://tinycorelinux.net/concepts.html - 'Easy, fast, and simple renew-ability and stability is a principle goal of Tiny Core.'
this appears to fall under speed consideration
i wander if anyone else has given this any thaught ( dont remenber finding any post with similar jist in the past )
all though i except ( statisticly) nothing has explicitly changed since 1.x ( apart from perhaps the server to nginx https://forum.tinycorelinux.net/index.php/topic,20499.0.html )
so it is statistically unlikely to do so in the future :P
--- Quote from: CentralWare on October 14, 2022, 09:08:42 PM ---
@mocore: I'm not certain the purpose you're after, but we already have a number of text based files found in the repo itself which may suit your purpose.
Bare in mind they're a part of the repository as opposed to the forum.
tcz/info.lst is basically a file listing of TCZs
tcz/sizelist is the above plus file lengths
tcz/tags.db is a g-zipped version of info plus tag words
tcz/provides.db is similar to an INI file with file listings for each extension
tcz/md5.db is, as you guessed it, the signatures for each file
* most of the items above are available in g-zip form, some are gz only.
--- End quote ---
mocore:
some similar/relevant observations
wrt network connections ect ... apparently inspired an alternative backed for the core package manager
( at least that's the gist i get from scanning the thread )
http://forum.tinycorelinux.net/index.php/topic,12458.0.html - "corepkg - a new core package and updates manager"
--- Quote from: martin on January 28, 2012, 09:28:19 PM ---to match all current md5 files against the ones in the repository, which generates a LOT of small web server requests to the repository and can take a long time, depending on how many extensions you have,
--- End quote ---
nick65go:
@mocore: I'm inclined to think like you.
To change a little the main scripts, like tce-fetch.sh for (tags.db.gz + provides.db.gz + sizelist.gz + md5.db.gz), such as it will first check (for example) and if the files are ALREADY in /tmp then it will not download them again :)
(eventually check also they date, hm.. not sure why these files could not-authorized arrived in /tmp, so maybe not-necessary to touch/check they date).
[rant] Time is vital in our life! because is finit on this planet. Storage space not so. So speed (time involved) is the focus, for me. Even [hated] M$soft at one moment break-it with DOS compatibility, from win 9.x to advance in winNT.
I am not suggesting to break tcz compatibility regarding running locally on host machine/PC/laptop; however some tcz do not fit with core 486 CPU compatibility (see firefox which needs CPU with SSE instructions, etc).
But TC started in 2009, we are now in 2023, so servers (or their MIRRORS) storage and protocols advanced in the mean time. The assumptions today are not like they were 14 years ago. [/rant]
nick65go:
looking in /usr/bin/tce-ab, it download specific *.tcz.tree or *.tcz.dep for each on-demand; But on the server there is no file to contain all / concatenated *.tcz.tree or *.tcz.dep;
So, when the used look-around in tce or it app-GUI, lets say for 100 individual programs (because the user just evaluate the TC software repository potential), the user will download (connect + disconnect) to server for 100 times (with wget).
I re-discovered (LOL, some will say: the cold water, :P ) a small program in TC14 also:
--- Code: ---Title: tdb.tcz
Description: trivial database
Version: 1.2.12
Size: 48KB
Extension_by: juanito
----------
Change-log: first version
Current: 2013/11/21
--- End code ---
I wonder (play with it) if is faster /more usefully instead of classic tce (awk, sed, grep), to process a local database, created from downloaded server files (tags.db.gz + provides.db.gz + sizelist.gz + md5.db.gz). Anybody can share their experience of tcz alternative-management?
GNUser:
--- Quote from: nick65go on February 27, 2023, 08:29:39 AM ---Anybody can share their experience of tcz alternative-management?
--- End quote ---
My tcz alternative for large applications that I only use rarely (e.g., libreoffice, gimp, qbittorrent, electrum) is AppImage. AppImages work perfectly, load quickly, and add nothing to boot time.
Two caveats:
1. Most AppImages these days are 64-bit only, so 64-bit TCL is needed
2. A few minor tweaks are needed to allow AppImages to work on TCL (see here)
Navigation
[0] Message Index
[#] Next page
Go to full version