WelcomeWelcome | FAQFAQ | DownloadsDownloads | WikiWiki

Author Topic: future plans regarding libc implementation and init software  (Read 7926 times)

Offline GNUser

  • Wiki Author
  • Hero Member
  • *****
  • Posts: 1499
future plans regarding libc implementation and init software
« on: April 30, 2020, 02:27:27 PM »
I, for one, am happy that TCL uses  glibc  because it's tried and true and is the de facto standard libc implementation for linux distros. That being said, I have sometimes wondered why has TCL stuck with  glibc  rather than switching to a minimalistic alternative such as musl. Is it for the same reasons I prefer glibc (see above), or for some other reason(s)?

While on the topic of infrastructure, is the plan to always remain a systemd-free distribution?

P.S. I don't want to be political or start flame wars. These are just factual questions for the developers regarding their plans for their project's future.

Offline andyj

  • Hero Member
  • *****
  • Posts: 1036
Re: future plans regarding libc implementation and init software
« Reply #1 on: April 30, 2020, 03:35:35 PM »
Every once in a while I have an issue with the init system/structure or whatever you want to call it. Not a full sys-v style system, but maybe break up tc-config into a loop through smaller files? Something like:

Code: [Select]
for IFILE in /etc/init.d/rc.d/*; do
    [ -x "$IFILE" ] && . "/etc/init.d/rc.d/$IFILE"  # notice the period, execute in the same shell, same as before
done

Start the file names with numbers so they stay in order. It would also be nice if the /proc/cmdline variables weren't scattered across files in different directory trees. /etc/init.d/tc-config and /usr/bin/tc-setup come to mind.

Offline nick65go

  • Hero Member
  • *****
  • Posts: 833
Re: future plans regarding libc implementation and init software
« Reply #2 on: April 30, 2020, 03:55:02 PM »
my novice opinion here:
1- musl (instead of glibc) has been already succesfuly tested by Apline linux, for many years.
2- the purpose of systemd is very-fast booting by starting programs at booting in parallel, taken care of their dependencies. Apline linux use the openRC to do the same things (taken care of their dependencies) and can (theoreticaly) start them in parallel. Without encapsulaing itself in the kernel like a cancer (aka systemd).So regarding systemd, the modularity of TC (onboot/ondemand/~X.d, etc) will make systemd useless in gaining boot-speed.
Apline also has a big advantage versus (Tiny)Core: programatic building (and upgrading!) of aplications, automaticaly by the developers of the core, not as in tinycore where it is based (mostly) on user contributions (from alien pakages ubuntu/debian?)So IMHO, maybe tinycore developers are afraid to not become a (2-nd class) clone of Alpine linux, if they adopt musl.
Ex: the formum is fulll of user asking for help, or reporting bugs, because binding together appl + libs (missing dependency, old version).
« Last Edit: April 30, 2020, 04:10:23 PM by nick65go »

Offline GNUser

  • Wiki Author
  • Hero Member
  • *****
  • Posts: 1499
Re: future plans regarding libc implementation and init software
« Reply #3 on: April 30, 2020, 06:39:38 PM »
@andyj - I agree with you on both counts: It would be nice to breakup tc-config into smaller files and it would also be nice to see "boot commands" parsed by a single script. If developers are interested in moving in that direction, I could contribute manpower to develop and/or test.

@nick65go - The main reason I like glibc in TCL is that I can pull "alien" binaries and shared libraries from other distros with vast repositories (e.g., Debian), so I see this as a tremendous plus. Actually, about half of the applications I use on my TCL laptop are official extensions, other half I've pulled from Debian and created unofficial extensions for my personal use.

I'd be interested in knowing what the developers themselves have in mind regarding libc implementation and init plans for the future.

Offline andyj

  • Hero Member
  • *****
  • Posts: 1036
Re: future plans regarding libc implementation and init software
« Reply #4 on: April 30, 2020, 10:25:28 PM »
Step 1: Here's what I have done so far for /init:

Code: [Select]
tc@box:~$ cat /init
#!/bin/sh
#
mount proc

mkdir -p /etc/cmdline
for i in $(cat /proc/cmdline); do
var=${i%=*}
var=${var//\//_}
val=${i#*=}
[ "$var" == "$val" ] && touch /etc/cmdline/$var || echo -n "$val" > /etc/cmdline/$var
done

[ -f /etc/cmdline/multivt ] && sed -i s/^#tty/tty/ /etc/inittab
if [ ! -f /etc/cmdline/noembed ]; then

  inodes=$(awk '/MemFree/ {printf "%d",$2/3}' /proc/meminfo)

  mount / -o remount,size=90%,nr_inodes=$inodes
  umount proc
  exec /sbin/init
fi
umount proc
if mount -t tmpfs -o size=90% tmpfs /mnt; then
  if tar -C / --exclude=mnt -cf - . | tar -C /mnt/ -xf - ; then
    mkdir /mnt/mnt
    exec /sbin/switch_root mnt /sbin/init
  fi
fi
exec /sbin/init

This change to /init creates /etc/cmdline (which would eventually be in the core.gz filesystem so this line would go away) and creates a file for each variable and places the value of the variable in it, if it has one. Then instead of grep'ing for variables every time you need to look for one just check to see if the variable file exists and grab the value if you need it.

Code: [Select]
tc@box:~$ la /etc/cmdline/
total 36
drwxr-xr-x    2 root     root           280 Apr 30 22:09 ./
drwxr-xr-x   10 root     root           760 Apr 30 22:09 ../
-rw-r--r--    1 root     root            18 Apr 30 22:09 BOOT_IMAGE
-rw-r--r--    1 root     root            69 Apr 30 22:09 initrd
-rw-r--r--    1 root     root            11 Apr 30 22:09 lang
-rw-r--r--    1 root     root             1 Apr 30 22:09 loglevel
-rw-r--r--    1 root     root             0 Apr 30 22:09 noswap
-rw-r--r--    1 root     root             0 Apr 30 22:09 nozswap
-rw-r--r--    1 root     root             1 Apr 30 22:09 printk.time
-rw-r--r--    1 root     root             0 Apr 30 22:09 syslog
-rw-r--r--    1 root     root            13 Apr 30 22:09 tce
-rw-r--r--    1 root     root             3 Apr 30 22:09 tz
-rw-r--r--    1 root     root             2 Apr 30 22:09 udev.children-max
-rw-r--r--    1 root     root             3 Apr 30 22:09 vga

The obvious flaw with this approach is this:

Code: [Select]
tc@box:/etc/cmdline$ du -asc *
4.0K BOOT_IMAGE
4.0K initrd
4.0K lang
4.0K loglevel
0 noswap
0 nozswap
4.0K printk.time
0 syslog
4.0K tce
4.0K tz
4.0K udev.children-max
4.0K vga
36.0K total

Each variable takes 4k of RAM. I don't know how to solve this last problem without packing everything, then we're back where we started.

Offline Rich

  • Administrator
  • Hero Member
  • *****
  • Posts: 11594
Re: future plans regarding libc implementation and init software
« Reply #5 on: April 30, 2020, 11:24:06 PM »
Hi andyj
... Each variable takes 4k of RAM. I don't know how to solve this last problem without packing everything, then we're back where we started.
Maybe you could export them as system wide environmental variables instead? Something like:
Code: [Select]
export nozswap="1"
export printk.time="1"
export tce="/mnt/sda1/tce"

Testing for existence and value is straightforward:
Code: [Select]
tc@E310:~$ [ "$tce" ] && echo $tce
tc@E310:~$ export tce="/mnt/sda1/tce"
tc@E310:~$ [ "$tce" ] && echo $tce
/mnt/sda1/tce
tc@E310:~$

Offline andyj

  • Hero Member
  • *****
  • Posts: 1036
Re: future plans regarding libc implementation and init software
« Reply #6 on: April 30, 2020, 11:39:45 PM »
What I came up with, that would need to be the first thing that gets done, maybe in /init or /etc/init.d/rcS, looks like this:

Code: [Select]
#!/bin/sh
#
while read CVAR TCVAR; do
[ -f /etc/cmdline/$CVAR ] && echo $TCVAR=$(cat /etc/cmdline/$CVAR) >> /etc/cmdline.sh
done <<EOF
waitusb WAITUSB
lang LANGUAGE
kmap KEYMAP
tz TZ
desktop DESKTOP
ntpserver NTPSERVER
icons ICONS
noicons NOICONS
user USER
home MYHOME
tcvd TCVD
opt MYOPT
swapfile SWAPFILE
resume RESUME
host HOST
nfsmount NFSMOUNT
tftplist TFTPLIST
httplist HTTPLIST
aoe AOE
nbd NBD
mydata MYDATA
pretce PRETCE
xvesa XVESA
rsyslog
blacklist BLACKLIST
iso ISOFILE
nozswap NOZSWAP
nofstab NOFSTAB
nortc NORTC
syslog SYSLOG
noutc NOUTC
nodhcp NODHCP
noicons NOICONS
text TEXT
xonly XONLY
superuser SUPERUSER
noswap NOSWAP
secure SECURE
protect PROTECT
cron CRON
xsetup XSETUP
laptop LAPTOP
base ONLYBASE
showapps SHOWAPPS
norestore NORESTORE
noautologin NOAUTOLOGIN
pause PAUSE
EOF

Results in this:

Code: [Select]
tc@box:/etc$ cat cmdline.sh
LANGUAGE=en_US.UTF-8
TZ=UTC
NOZSWAP=1
SYSLOG=1
NOSWAP=1

Then just source it at the beginning of tc-config:

Code: [Select]
. /etc/cmdline.sh
Seems simple enough. The list of variables isn't complete, this is only from tc-config. I have to go through all the scripts in /etc and /usr to get the rest of them. If someone needs the space back they can delete the /etc/cmdline directory.

Better still would be to combine the above with this somehow (slightly improved version of loop in /init):

Code: [Select]
for i in $(cat /proc/cmdline); do
var=${i%=*}
val=${i#*=}
[ "$val" == "$var" ] && val="1"
echo -n "$val" > /etc/cmdline/${var//\//_}
done

It wasn't obvious to me (like the rest of this was?)

Offline Juanito

  • Administrator
  • Hero Member
  • *****
  • Posts: 14801
Re: future plans regarding libc implementation and init software
« Reply #7 on: May 01, 2020, 01:42:04 AM »
...on user contributions (from alien pakages ubuntu/debian?)

Why do you say that?

Offline curaga

  • Administrator
  • Hero Member
  • *****
  • Posts: 11044
Re: future plans regarding libc implementation and init software
« Reply #8 on: May 01, 2020, 04:14:05 AM »
Glibc is used because of its compatibility. Alternative libcs may be smaller, but they lose in both binary and source compatibility. Systemd will not be used, it brings too much complexity and trouble.

On the proposed init and cmdline changes, I don't really see the advantages; changes with risk but not many pros. There's little difference between
"grep VAR /proc/cmdline" and "[ -e /etc/cmdline/VAR ]" IMHO.
The only barriers that can stop you are the ones you create yourself.

Offline GNUser

  • Wiki Author
  • Hero Member
  • *****
  • Posts: 1499
Re: future plans regarding libc implementation and init software
« Reply #9 on: May 01, 2020, 08:29:31 AM »
@curaga - I'm so happy to hear that there are no plans for compatibility-breaking libc changes (I forgot to mention that I love AppImages and couldn't do without them) or complexity-increasing init changes! Thank you for confirming. Regarding the small changes proposed in this thread, I agree that it's not clear they would be worth the effort and risk.

@juanito - It seems nick65go is unaware that official TCL extensions (including user contributions) are compiled on TCL, not cobbled together from "alien" packages. Only very rare "binary only" extensions are from alien components.

@nick65go - TCL will never be "2nd class" because it is built on 1st class concepts. To name just my 3 favorites:

1. The OS lives on the harddrive in a non-scattered way:


2. "Installing" TCL consists of putting two files on the harddrive (boot/core.gz and boot/vmlinuz) and pointing the boot loader to those two files.

3. At every boot, your personalized TCL is overlayed on a "fresh install" based on two files (tce/onboot.lst and tce/mydata.tgz).

Despite its many qualities, Alpine Linux cannot boast any of the above.

Thank you all for the lively discussion :)
« Last Edit: May 01, 2020, 08:33:20 AM by GNUser »

Offline andyj

  • Hero Member
  • *****
  • Posts: 1036
Re: future plans regarding libc implementation and init software
« Reply #10 on: May 01, 2020, 10:27:04 AM »
My frustration comes from this:

Code: [Select]
/etc/init.d/tc-config                               

waitusb*
lang*
kmap*
tz*
desktop*
ntpserver*
icons*
noicons*
user*
home*
tcvd*
opt*
swapfile*
resume*
host*
nfsmount*
tftplist*
httplist*
aoe*
nbd*
mydata*
pretce*
xvesa*
rsyslog=*
blacklist*
iso*
nozswap
nofstab
nortc
syslog
noutc
nodhcp
noicons
text
xonly
superuser
noswap
secure
protect
cron
xsetup
laptop
base
showapps
norestore
noautologin
pause

/etc/init.d/tc-restore.sh

restore*
restore
protect

/etc/init.d/rc.shutdown

noswap

/usr/bin/filetool.sh

safebackup
comparerestore

/usr/bin/tce-update

tce*
base
norestore

/usr/bin/tce-setup

tce=*
lst=*
cde
base

/init
multivt
noembed

These are all the codes I could mine out of rootfs.gz. There seems to be some amount of "ad-hoc-ness" to it. Just wondering if there might be a better way. Doesn't sound like there is any interest.

Offline nick65go

  • Hero Member
  • *****
  • Posts: 833
Re: future plans regarding libc implementation and init software
« Reply #11 on: May 01, 2020, 12:14:33 PM »
I do aknowledge the positive points of TC (class concepts!). My atraction is for small/fast/secure linux, whatever the "distribution".Sorry, I do not intend o offend anyone. I am glad that I can grab for free a quality linux distro like TC.

But I am unhappy with the focus of linux (in general, not TC specific) on comercial (greedy capitalism) and server type improvments. For me linux is a hobby. I hate Windows (embrace and destroy), same for Mac OS (closed source), and not happy with linux:
-bad evolution (IMHO) from OSS sound (cobra speed) to ALSA (monkey) further to Puls-audio (the elephant in the room). And Firefox (the only free and trusted browser need for bank-account secure transactions) is bloated with less-useful things and linked to pulse-audio.-UEFI forced on us, useless GPT partition for laptops.-systemd like a cancel, never ending in useless feature for home-office user.

For me, as a common desktop user, what maters is longer batetry life (less electricty), low fan speed (less noise), less used RAM (cheaper laptop), functional keyboard etc. So much energy is used today to develop linux, with so less improvment in my needs. I realy do not care about extra colors, extra menus. FLTK is just enought/beautiful.My "productivity" increase is ZERO with new GNOME, KDE trimings. And yes, security matters more and more today.Sorry, for providing unsolicited information.
« Last Edit: May 01, 2020, 12:17:45 PM by nick65go »

Offline GNUser

  • Wiki Author
  • Hero Member
  • *****
  • Posts: 1499
Re: future plans regarding libc implementation and init software
« Reply #12 on: May 01, 2020, 12:43:31 PM »
@nick65go - I share all your frustrations, which partly explains why I choose TCL. Welcome to the club ;)

So much energy is used today to develop linux, with so less improvment in my needs. I realy do not care about extra colors, extra menus. ... My "productivity" increase is ZERO with new GNOME, KDE trimings.
I have said this before (almost verbatim) many times.
« Last Edit: May 01, 2020, 12:45:05 PM by GNUser »

Offline ferran

  • Full Member
  • ***
  • Posts: 159
Re: future plans regarding libc implementation and init software
« Reply #13 on: May 01, 2020, 04:23:41 PM »
It's very reassuring for me not to have to change what works. I am still in Linux almost by miracle, since no other distribution has been able to accept my equipment.

I still have some difficulties, some of them have led me to the disaster of having to reinstall TC again and I don't want to waste any more time looking for 100% compatibility, now I have in mind to do what I wanted: to learn how to program and I hope that in the near future I can contribute a lot here.

I will need to drink a lot of coffee to get to learn everything here...
TC CorePlus v.11.1 i686 & lots of coffe

aus9

  • Guest
Re: future plans regarding libc implementation and init software
« Reply #14 on: May 01, 2020, 07:56:33 PM »
SNIP And Firefox (the only free and trusted browser need for bank-account secure transactions) is bloated with less-useful things and linked to pulse-audio.SNIP

Not true but as it breaks the pristine concept I show how I run FF without pulseaudio  in this post
http://forum.tinycorelinux.net/index.php/topic,23838.0.html