Tiny Core Linux
Tiny Core Base => TCB Talk => Topic started by: meo on August 05, 2009, 04:45:54 PM
-
Hi Robert!
Just a couple of suggestions. I think that if the Application browser and the Control panel had the ability to use True Type Fonts (like Dejavu Sans for instance) that MC and TC would benefit from that. It would send the message that it really is a modern distribution. Furthermore, people who have a poor eyesight (like me) would benefit from it. Another suggestion that I have been pondering over is if the Application browser could be given the possibility to be enlarged (perhaps just the text within the window with the applications) that would make it even easier for the forementioned group. Well that was pretty much what I have been thinking of that would benefit the users of MC and TC.
Have fun continuing the development of this incredible distro,
meo
-
Hi again Robert!
I've been thinking about my suggestions, and maybe it would be best if the choise to have True Type Fonts would affect the whole system. I don't know how much this would cost, when it comes to system resources, but if it could be made a choice only the ones that have enough system resources would choose it. Maybe it's not possible, I don't know. But it would be a step that would give the "fullblown distributions" that comes with "everything but the kitchen sink" a match. If it is possible I think it would be a good idea, but you are more competent than I am to decide in this matter. Either way it's a very good distro we are talking about.
Have fun,
meo
-
Here are my suggestions for TC team.
kexec support
bootsplash
bzImage and core.gz with Xvesa GUI and mc (GNU Midnight Commander) in one file (compressed with upx)
dmesg timestamp and (dmesgdate (that will show log with date format)
windows programs (with wine) appbrowser (contains only installation scripts)
easy way to change .tce_dir from ControlPanel
function to force redownload and reinstall tcz extension if it was downloaded with error (I usually get md5sum error if my Ethernet cable is unplugged)
website based remaster creator like in slitaz
cooperation with netboot.xyz
include version number in wallpaper logo
changing design philosophy, based on 100% Debian compatibility (in the future tcz extensions will be converted from deb packages because there will be no voluntaries to compile new extensions)
create repository of compilation scripts for tcz extensions
-
function to force redownload and reinstall tcz extension if it was downloaded with error (I usually get md5sum error if my Ethernet cable is unplugged)
To clean up at least would be a good idea - patches gratefully received
changing design philosophy, based on 100% Debian compatibility (in the future tcz extensions will be converted from deb packages because there will be no voluntaries to compile new extensions)
Have you looked at dCore (or are you thinking of something else)?
create repository of compilation scripts for tcz extensions
see:
http://www.tinycorelinux.net/10.x/x86/tcz/src/
http://www.tinycorelinux.net/10.x/x86_64/tcz/src/
-
Have you looked at dCore (or are you thinking of something else)?
Yes. I tested dCoretrusty, but I don't have good experience with it. When I wanted to install Xvesa I got 100 dependencies. It consumed 100 MB RAM. When I installed jwm, it have 454 dependencies and with Xvesa, consume 771 MB of RAM. It's the same bloadware like in Debian but the difference from standard Debian is only LiveCD mode. Much better would be to created TinyCore version that is compatible with Debian but use tcz extensions instead scm. We will be able to easily convert some deb package to tcz without all this bloatware and pointless dependencies.
create repository of compilation scripts for tcz extensions
see:
http://www.tinycorelinux.net/10.x/x86/tcz/src/
http://www.tinycorelinux.net/10.x/x86_64/tcz/src/
Yes, but not all programs contains compilation script. It would be much faster to compile new version for the upcoming new TC version.
-
Hi,neonix! Are you talking about DebianDog project?
-
bootsplash
Tried using plymouth years ago, and it mostly worked, but it's very picky about hardware. You will need to edit /etc/init.d/rcS and put it in its own initrd (or remaster rootfs.gz) and start it in there.
dmesg timestamp and (dmesgdate (that will show log with date format)
Add printk.time=1 to the kernel command line to get kernel times in dmesg. Busybox dmesg doesn't support -T, so you'll need to use something else if you need actual times.
cooperation with netboot.xyz
Not sure what this means. PXE works for booting TC.
changing design philosophy, based on 100% Debian compatibility (in the future tcz extensions will be converted from deb packages because there will be no voluntaries to compile new extensions)
If you want it to be like Debian, run Debian. Also, just because you may not want to maintain extensions doesn't mean nobody else does. Almost all the other distros are maintained by by volunteers, so they do exist.
-
Hi,neonix! Are you talking about DebianDog project?
I was thinking rather about Puppy Linux that offer binary comparability with Ubuntu packages since version 5. DebianDog is more Debian than Puppy Linux.
Add printk.time=1 to the kernel command line to get kernel times in dmesg. Busybox dmesg doesn't support -T, so you'll need to use something else if you need actual times.
Thanks for tip.
cooperation with netboot.xyz
Not sure what this means. PXE works for booting TC.
netboot.xyz use http protocol to boot with iPXE
-
So netboot.xyz looks like a GUI for PXE. I'm not seeing how this is a especially different than pxelinux, which can bring up a menu as well. Besides, multi-boot scenarios are generally outside the control of any one distro, just like hypervisors are outside of the OS control.
-
Hi, Core people!
I want to suggest small change for .xession.
Last in order action of it is invoking ~/.X.d scripts [ -d "$HOME/.X.d" ] && find "$HOME/.X.d" -type f -print | while read F; do . "$F"; doneIf insert "sort" between "find" and "while" then tne order of execution of user scripts became predictable and controllable for case of several scripts present. Of course definite order can be achieved using one script in ~/.X.d starting other scripts from somewhere outside, but such tiny modification make things a little simpler, while this change won't make any harm or trouble. So i use [ -d "$HOME/.X.d" ] && find "$HOME/.X.d" -type f -print | sort | while read F; do . "$F"; done
-
Hi, Core people!
I want to suggest small change for .xession.
Last in order action of it is invoking ~/.X.d scripts [ -d "$HOME/.X.d" ] && find "$HOME/.X.d" -type f -print | while read F; do . "$F"; doneIf insert "sort" between "find" and "while" then tne order of execution of user scripts became predictable and controllable for case of several scripts present. Of course definite order can be achieved using one script in ~/.X.d starting other scripts from somewhere outside, but such tiny modification make things a little simpler, while this change won't make any harm or trouble. So i use [ -d "$HOME/.X.d" ] && find "$HOME/.X.d" -type f -print | sort | while read F; do . "$F"; done
This suggestion seems unnecessary . It’s often the case where ~/.X.d files are required to be run in a specific sequence.
For years I’ve simply renamed the files in numerical order of importance when files need to be parsed in specific order.
1.xxxx
2.xxxx
3.xxxx
Etc etc.
[emoji3166]
Sent from my iPhone using Tapatalk
-
This suggestion seems unnecessary . It’s often the case where ~/.X.d files are required to be run in a specific sequence.
For years I’ve simply renamed the files in numerical order of importance when files need to be parsed in specific order.
1.xxxx
2.xxxx
3.xxxx
Etc etc.
Exactly for this purpose i make the suggestion, "find" didn't sorts the directory entries. At least busybox's one. TC10 x86.
tc@box:~$ mkdir tmp; cd tmp
tc@box:~/tmp$ touch 1; touch 7; touch 3
tc@box:~/tmp$ find . -type f
./3
./7
./1
tc@boxOutput is simply reverse creation order.
-
It's my experience as well that find output is unsorted. When I proposed this change not so long ago http://forum.tinycorelinux.net/index.php/topic,22312.0.html (http://forum.tinycorelinux.net/index.php/topic,22312.0.html) I only had one file in mind so it didn't occur to me that sort would be necessary. But yes, predicable is better. Maybe post your patch to that thread?
-
I would argue that if those who didn’t already place ~/.X.d/* files in any numerical order, doesn’t actually need to parse files in any particular order...
Besides, files are currently executed in numerical order.
Therefore sort is an unnecessary additional complication.
my systems files are executed in the desired order already as they are numerically ordered, so why change anything ?
It’s not like we’re doing anyone any favors, whether sort is added or not we are still required to rename files to ensure commands are executed in the correct order as we have always done..
All existing TC users who know of and utilize numerical ordering may be negatively impacted by such a change.
If it’s for the greater good, I’m all for it. But since the capability already exists, why change?
I suggest when the OP hits a brick wall, he asks how to resolve his dilemma.
Just saying..
Sent from my iPhone using Tapatalk
-
Hi, coreplayer2!
I absolutely agree with you, changing of system files must be avoided as much as possible because of possible side effects, complicating some cases possible in future, and not to put rubbish everywhere. But i faced the case when ~/.X.d scripts execution order matters, and i think i am not alone. And my investigation (see code example above) showed that order is creation order, not alphanumerical. Of course, someone can create scripts according to alphanumerical order, and in this case creation order is identical to alphanumerical. But if no?
And, yes, this additional "sort" will harm those who already achieved desired script execution order with the help of creating them in appropriate sequence, while not naming scripts keeping in mind alphanumerical order like you (
So i modified my own .xsession and want the newbies like me to know about this workout on ~/.X.d scripts, maybe it will help someone else.
-
It's my experience as well that find output is unsorted. When I proposed this change not so long ago http://forum.tinycorelinux.net/index.php/topic,22312.0.html (http://forum.tinycorelinux.net/index.php/topic,22312.0.html) I only had one file in mind so it didn't occur to me that sort would be necessary. But yes, predicable is better. Maybe post your patch to that thread?
Hi, andyj!
Surprisingly, i think this additional "sort" for /usr/local/etc/X.d will cause problems.
If we are talking about ~/.X.d all staff exists in user domain and is fully changeable and though controllable and predictable.
But in the case of /usr/local/etc/X.d scripts come from different extensions and their sorting alphanumerically before execution may cause inappropriate execution order which can NOT be changed.
If this additional execution of /usr/local/etc/X.d/* will be added to .xsession, user can change the scripts execution order changing extensions order in onboot.lst (as they are executed in creation order). And "sort" will kill this possibility.
-
create repository of compilation scripts for tcz extensions
see:
http://www.tinycorelinux.net/10.x/x86/tcz/src/
http://www.tinycorelinux.net/10.x/x86_64/tcz/src/
How to upload sources there?
Is the format of the compile_XXX file described anywhere?
-
Hi edo1
Welcome to the forum.
... How to upload sources there? ...
You can't. If you submit an extension and include a source package, it will be added for you.
... Is the format of the compile_XXX file described anywhere?
There are no formal rules. Some of those files are just notes listing the basic steps taken. Others are full blown build
scripts.
Attached are a couple of examples I created. They build and package their respective extensions, then bundle all of
the required files into an archive so it can be submitted via email. Scripting it like this is more work, but it provides
consistency if someone else needs to update the extension. It's also helpful if you encounter compilation errors and
need to restart the build multiple times.
-
Thanks for your fast reply
If you submit an extension and include a source package, it will be added for you.
Ok, which format of source package could be used?
There are no formal rules. Some of those files are just notes listing the basic steps taken. Others are full blown build
scripts.
Indeed I'm very disappointed with TCL extension system. I sent the binary package and it was approved soon after. So any user can install this package using tce-load.
It is so easy to upload a package with a backdoor, and there is almost no way to check / prevent this.
IMO every package should have sources (or building scripts) published. And the binary package should be built in a trusted environment (or reproducible build used). All distributions I know do this way.
-
Hi edo1
... Ok, which format of source package could be used? ...
If you downloaded a source tarball, you could submit that.
If you used git to fetch the source in a build script, theoretically, the script could be sufficient.
My scripts tar up the build directory and include that in the email being submitted.
... Indeed I'm very disappointed with TCL extension system. I sent the binary package and it was approved soon after. So any user can install this package using tce-load.
It is so easy to upload a package with a backdoor, and there is almost no way to check / prevent this.
IMO every package should have sources (or building scripts) published. And the binary package should be built in a trusted environment (or reproducible build used). All distributions I know do this way.
Source code can contain mischievous code, so that means individuals well versed in understanding code that have the
time to review it. The same holds true for build scripts. This is a small distro with finite resources. As a result, we also
rely on volunteers to submit extensions.
-
My scripts tar up the build directory and include that in the email being submitted.
tcz and sources in one archive? Could you upload an example, please
Source code can contain mischievous code, so that means individuals well versed in understanding code that have the
time to review it. The same holds true for build scripts.
Sure. But binaries without a source are definitely riskier. Moreover, binaries provided by a third party.
-
Hi edo1
tcz and sources in one archive? Could you upload an example, please ...
The archive contains executables. Forum policy prohibits attaching binaries to posts. That rule applies to me too.
Check your email. I attached the exfat package as it was submitted.
-
I would like to suggest an update for the tc-install with:
1) getlocale.tcz & tzdata.tcz to select and get the regional settings by default.
2) Optional session login and a display manager (xdm ?)
3) internet connection settings
In short, all those features that another distros have in it's installer programs.