My Wish-List for TCL !

[Pats]

Due to TCs simplicity, the Distro is dafinately addictive to many users.
I would appriciate more, if TC has folowing user-friendly built-in features:

1) TC2.4 ,5,6 has more simple and easy2use interface including (CPanel and AB) - thats why I use curagas CLI-AB ext more than TCs built-in AB. CPanel has become somewhat more complicated with lot of clutter - ( it may be against TCs ease-of-use-and-simplicity philosophy ).

2) TC2.9rc4 stopped loading any ext from dafualt /tce dire on my W2k FAT partition. While making changes in /tce location, I wuold appriciate to keep some backwrd-compatibility. ( or am I missing something here myself ? )

3) Wish there would have some utitlities - which would convert .RPM or .Deb packages to .tcz format - for ready2use upgrades ( pl excuse me for my technical ignorance , if this is practically NOT possible ).

4) If a new app is loaded thru /tce (installed .tcz) , there should not be any more steps needed to perform from user-side to make it permenent or sticky to desktop and all the neccessary menu-entries should be avaiable in the menu-tree (Firefox etc).

I may be ignorant of above features - if already available in TCs recent version, in that case pl excuse me !
As usual - these are requests and NOT obligations towards TC developers !

~ Pats

[Juanito]

2) TC2.9rc4 stopped loading any ext from dafualt /tce dire on my W2k FAT partition. While making changes in /tce location, I wuold appriciate to keep some backwrd-compatibility. ( or am I missing something here myself ? )

Apart from Xprogs/Xvesa/Xlibs.gz and micrcore, where the three extensions are placed in /tce, from tc-2.9 onwards, all extensions go in /tce/optional and loading on boot is controlled by listing the required extension in /tce/onboot.lst - note that you can edit onboot.lst either via the appbrowser or manually.

3) Wish there would have some utitlities - which would convert .RPM or .Deb packages to .tcz format - for ready2use upgrades ( pl excuse me for my technical ignorance , if this is practically NOT possible ).

deb files can be unpacked with a one-line command - the problem is that some of the files inside are not required, some may overwrite files in tc base and some may not be in the preferred /usr/local location - all this means that deb/rpm files would really need to be treated on a case-by-case basis.

It really is not so difficult to compile a lot of applications on tc - maybe you could have a look at the relevant section of the wiki and have a go for yourself?

4) If a new app is loaded thru /tce (installed .tcz) , there should not be any more steps needed to perform from user-side to make it permenent or sticky to desktop and all the neccessary menu-entries should be avaiable in the menu-tree (Firefox etc).

If you load a new extension via the appbrowser, it will load automatically the next time you boot unless you use the "on demand" button - the icon/menu items are controlled by the extension maker and will be there next time you boot as long as the extension maker provided them in the first place...

[Pats]

<Quote>note that you can edit onboot.lst</Quote>
Will putting symlinks of the required ext already present in /tce in the onboot.lst do the same job?

<Quote>all this means that deb/rpm files.. </Quote>
Thnks for clarifying, I will have to try port deb/rpm file installation to TC in my spare time.

<Quote>the icon/menu items are controlled by the extension maker</Quote>
Can this condition be imposed on all the (old/new) ext. maker before submiiting the extension to repo ? It will ease the users experience with TC !

By the way, is there any way of unloading any extension on-the-fly while running TC (to free-up RAM and then load another ext into the freed RAM - a kinda garbage collection, you can say ) ?

~ Pats

[Jason W]

There is a script in Programming and Scripting section that will convert .debs to tcz's for ones own personal use.  The same could easily be done for rpm.  But I stress the term personal use as extensions made from converted Debian or other packages as a rule should not be submitted to the repo.  As for wanting to convert other distros packages for updates, you will find that most TC extensions tend to stay very current with frequent updates. 

Xtrlock is one I made in the very early stages of TC that is a small and simple Debian binary that works fine, and I will build it from source and update it soon to keep within principle. 

And I like menus for extensions to be up to the extension maker, especially for CLI apps. 

And live uninstalling of packages is not the TC way, Appsaudit will mark selected extensions for deletion upon shutdown or reboot. 

[OldAdamUser2]

My wish-list for Tiny Core is--keep it light! Have a Tiny Core. Have lots of tiny apps. Keep the demands of the OS on the cpu tiny. . . . Finally, (and I see this as something I might be able to help with) give some concise guidance to the end-user on how to make best use of the tiny apps.

The developers are doing a great job. . . . I can step it up a little in the future.

[Pats]

<div class="quote">There is a script in Programming and Scripting section that will convert .debs to tcz's for ones own personal use.  The same could easily be done for rpm. <br /></div>
Oh.. ! Now that is music to my ears ! A million thnks to you, sir ! You saved a lot of my pains ( and time too ) !! I will have search the script in that section !

<div class="quote">But I stress the term personal use as extensions made from converted Debian or other packages as a rule should not be submitted to the repo. <br /></div>
I will be the last person doing that kind of copy/paste/submit job ! If ever I will contribute to TC repo in future, I hope it will be totally my own personal creations !
That does not mean, I undermine the valuable efforts of other ext contributors to the repo. It is just that - that kind of thinga is not my cup of tea !

<div class="quote">  As for wanting to convert other distros packages for updates, you will find that most TC extensions tend to stay very current with frequent updates. <br /></div>
You can bet on it, that is for sure ! I can see even the MC and TC sizzling with frequest updates , now & then !
Only while doing so, it should not loss the original purpose of simplicity, ease and its prestine nature - if I am not wrong !


<div class="quote"> And I like menus for extensions to be up to the extension maker, especially for CLI apps.<br /></div>
I support it whole-heartedly !


<div class="quote">And live uninstalling of packages is not the TC way, Appsaudit will mark selected extensions for deletion upon shutdown or reboot.<br /></div>
No problem ! I hope some scripting expert will dafinately solve that problem also sooner or later !


<div class="quote">Finally, (and I see this as something I might be able to help with) give some concise guidance to the end-user on how to make best use of the tiny apps.<br /></div>
How and when ? We are waiting for that eagerly !

[Jason W]

This "scripting redneck" has already pondered and gone through the motions of uninstalling packages on a live system.  Spent many months on it.  It can be done, and even done to a great degree of safety.  But then it comes down to the issue of dependencies and such that even a mainstream package manager is weak on. So I considered my time better spent on making packages and handling the submissions of the community rather than on my own hobby horse of uninstallation.  In other words, having to support live uninstallation would have to slow down development of the TC ecosystem.  And I think that we all can appreciate the pristine reboot and other concepts of TC while using backup functions to achieve the behavior of a "normal" linux system.  And there is an uninstall function of AppsAudit that will remove packages upon the next reboot.

Hope this helps.

[Pats]

<quote>
So I considered my time better spent on making packages and handling the submissions of the community rather than on my own hobby horse of uninstallation. ...  And I think that we all can appreciate the pristine reboot and other concepts of TC while using backup functions to achieve the behavior of a "normal" linux system.   
</quote>
I whole-heartedly appriciate your ( and many others - as well ) honest efforts towards development of TC and bringing it to present days marvelous (open-source) product !

<quote>
This "scripting redneck" has already pondered and gone through the motions of uninstalling packages on a live system.  Spent many months on it.  It can be done, and even done to a great degree of safety. 
</quote>
Actually a few people around me have some very old pc with only 64MB RAM. When I introduce them to TC, they really too happy to use it in its prestine state, but due to memory limitations, they have to reboot the m/c to unload/load the new exts every now-n-then. Thats the actual requirement for these guys to avoid repeated reboots to use diff apps on-the-fly.
So if possible , kindly post the method and/or the script to achieve this task ( on-the-fly unloading the ext. ) . Otherwise I will just accept yr above explanation and be happy !

By the way, suppose we connect 2/3 pcs together thru - say some null modem cable or thru NWcards, will it be possible to use idle RAM of connected idel PC to increase the total RAM quota of TC installed m/c. Just curious !

~ Pats

[Jason W]

With a machine with 64mb ram (which was the specs of my normal desktop just a couple of years ago), it is better to just choose carefully the apps you want to run, and if needed delete them and reboot to a clean state, than to manage that system by an uninstall/reinstall method.

 

[curaga]

Ram itself can't be, but swap can be used over network. I would recommend though having a local swap partition, or if that's not possible, even a swap file.

[robc]

This "scripting redneck" has already pondered and gone through the motions of uninstalling packages on a live system.  Spent many months on it.  It can be done, and even done to a great degree of safety.  But then it comes down to the issue of dependencies and such that even a mainstream package manager is weak on. So I considered my time better spent on making packages and handling the submissions of the community rather than on my own hobby horse of uninstallation.  In other words, having to support live uninstallation would have to slow down development of the TC ecosystem.  And I think that we all can appreciate the pristine reboot and other concepts of TC while using backup functions to achieve the behavior of a "normal" linux system.  And there is an uninstall function of AppsAudit that will remove packages upon the next reboot.

Hope this helps.

Probably the safest way for uninstall for an extension would be to have the extension maintainers create a specific uninstall script for the extension. This way each extension is handled in a specific way instead of trying to force every extension into a generic uninstall as done before.

Or perhaps a combination of both? Have a generic uninstall that will run the extension's uninstall script (if present) then perform the generic uninstall (ie kill processes? and umount tcz)

[Pats]

(  RAM  itself can't be, but swap can be used over network. I would recommend though having a local swap partition, or if that's not possible, even a swap file. )

Swap is with these guys , which they are using currently as real estate (HDD) is not a problem for them.

(
Probably the safest way for uninstall for an extension would be to have the extension maintainers create a specific uninstall script for the extension. This way each extension is handled in a specific way instead of trying to force every extension into a generic uninstall as done before.

Or perhaps a combination of both? Have a generic uninstall that will run the extension's uninstall script (if present) then perform the generic uninstall (ie kill processes? and umount tcz)
)

Good suggestion ! One more point here, since many of the apps loaded thru /tce dire. are loop mounted, can a user  unload the loop device himeself by a command, rm the ext.tcz from the /tce dire ( with all its dependent ext ) and then load the desired ext thru /tce/optional on the fly (off-cource how to achieve the garbage collection - freeing of used memory if any - may be challanging ).
Off-cource, I am a NO-No, in this loading/unloading intricasies of TC. Just a thought (for low RAM pcs) ! Pl do not laugh at my ignorance !

~ Pats

[jls]

I've attached to this post a tcz-uninstall script written by jasonw and modified by ^thehatsrule^

[Pats]

Thnks , jls for the script !
Will report back abt it after using it to-night !

~ Pats

[Jason W]

Remember that tcz-uninstall has not been maintained in a while, and there have been changes in base that are not accounted for in the script.  I don't recommend using it now.