Tiny Core Linux
Tiny Core Base => TCB Talk => Topic started by: GNUser on September 18, 2024, 11:23:00 AM
-
Hi curaga. If possible, here are 3 features I think would be nice to have in TCL16:
* remove the useless /linuxrc symlink (https://forum.tinycorelinux.net/index.php/topic,26883.msg173133.html#msg173133)
* implement /usr merge (https://forum.tinycorelinux.net/index.php/topic,26879.msg173120.html#msg173120)
* turn on support for wifi usb adapters with rt53XX and rt55XX chipsets, which have been working great (https://github.com/morrownr/USB-WiFi/blob/main/home/The_Short_List.md) with the in-kernel rt2800usb driver for years
For third item, the kernel config options are CONFIG_RT2800USB_RT53XX and CONFIG_RT2800USB_RT55XX
-
I don't really deal with the first two much anymore, that'd be Juanito's alley. For wifi modules, are they still marked experimental? Generally we follow that mark.
-
I’d prefer to continue using /usr for everything in the base and /usr/local for extensions.
-
Hi curaga. I'm not sure if still marked "experimental" today. But I and others have tested these chipsets and they among the few that are stable enough on linux to recommend without reservations. The driver is already provided by wireless-KERNEL.tcz. Only users trying to use these chipsets would be affected if these config options were enabled.
Hi Juanito. Absolutely. That's not what /usr merge is about. The merge is about:
* eliminating /bin (which becomes a symlink to /usr/bin)
* eliminating /lib (which becomes a symlink to /usr/lib)
* eliminating /sbin (which becomes a symlink to /usr/sbin)
/usr/local and everything under it would be unaffected.
/usr merge simplifies the file system, leads to fewer broken absolute paths (for example, an application can look for either /bin/foo or /usr/bin/foo and both would work) and would increase compatibility between applications and TCL in the long run.
All that being said, TCL is already the best distro as-is. This would be a minor upgrade.
-
Juanito, if /usr merge feels like too radical a change, then please disregard. One of TCL's strengths is that it is conservative and avoids big changes.
-
Okay, if you've tested those drivers, they can be enabled.
-
Okay, if you've tested those drivers...
I have tested them and they work great.
...they can be enabled.
Many thanks! It will remove a long-standing rock in my shoe (recompiling this kernel module with each TCL release).
-
with respect to the /usr merge i have reviewed the following:
https://forum.tinycorelinux.net/index.php/topic,26879.0.html
https://wiki.debian.org/UsrMerge
https://www.debian.org/releases/bookworm/amd64/release-notes/ch-information.en.html#a-merged-usr-is-now-required
https://www.freedesktop.org/wiki/Software/systemd/TheCaseForTheUsrMerge/
https://fedoraproject.org/wiki/Features/UsrMove
Understanding the bin, sbin, usr/bin , usr/sbin split - Rob Landley, 2010
http://lists.busybox.net/pipermail/busybox/2010-December/074114.html
and i also support Bruno's wishlist (as long as Juanito approves, naturally)
-
[Edit]: Continued from here https://forum.tinycorelinux.net/index.php/topic,27363.msg176504.html#msg176504 Rich
Hi Rich. What curaga was saying is that he doesn't want to move anything out of /usr/sbin into /usr/bin. I agree with him. That's called sbin merge and is not what polikuo and I are proposing.
usr merge is about doing away with the pointless splitting of some things into /usr/bin and other things into /bin, for example. This serves no purpose other than to break things (e.g., an application looks for /usr/bin/foo but cannot find it because on that distro it happens to be /bin/foo). usr merge forever fixes this kind of breakage while also simplifying the file system. It's win-win.
-
Hi Rich. Please feel free to move these posts from this thread to the "wishlist for TCL16" thread here:
https://forum.tinycorelinux.net/index.php/topic,27276.0.html
After all, /usr merge has nothing to do with provides.sh (other than both being on TCL16 wishlist) ;D
-
Hi GNUser
What curaga was saying is that he doesn't want to move anything out of /usr/sbin into /usr/bin. ...
Sorry, I missed that part.
-
Hi GNUser
I just got this interesting error message while loading an extension on TC15 x86_64:
ldconfig: invalid option -- 'q'
Try `ldconfig --help' or `ldconfig --usage' for more information.Turns out it was ldconfig from glibc_apps.tcz which doesn't support the quiet flag.
So I checked TC10 x86, and it defaults to the base ldconfig with glibc_apps.tcz installed.
Now here's the interesting part.
I grepped for ldconfig in glibc_apps.tcz.list for TC10-TC15 both 32 and 64 bit:
10.x x86 /sbin/ldconfig
11.x x86 /sbin/ldconfig
12.x x86 /sbin/ldconfig
13.x x86 /usr/sbin/ldconfig
14.x x86 /usr/sbin/ldconfig
15.x x86 /usr/sbin/ldconfig
10.x x86_64 /sbin/ldconfig
11.x x86_64 /sbin/ldconfig
12.x x86_64 /sbin/ldconfig
13.x x86_64 /usr/sbin/ldconfig
14.x x86_64 /usr/sbin/ldconfig
15.x x86_64 /usr/sbin/ldconfig
TC10 defaulted to the base ldconfig because:
tc@E310:~$ grep "Overwrite" /usr/bin/tce-load
FORCE="n" # Overwrite system files default to no. Use -f to force overwrite.
tc@E310:~$That's probably why it got moved to /usr/sbin/ldconfig in TC13.
Base install also includes /usr/bin/ldd. glibc_apps.tcz provides:
10.x x86 /usr/bin/ldd
11.x x86 /usr/bin/ldd
12.x x86 /usr/bin/ldd
13.x x86 /usr/bin/ldd
14.x x86 /usr/bin/ldd
15.x x86 /usr/bin/ldd
10.x x86_64
11.x x86_64 /usr/bin/ldd
12.x x86_64 /usr/bin/ldd
13.x x86_64 /usr/bin/ldd
14.x x86_64 /usr/bin/ldd
15.x x86_64 /usr/bin/lddI wonder why it's missing in the 10.x x86_64 version?
Anyway, I thought I'd point those two out since they conflict with the
merge and you'll want a fix that doesn't cause unexpected behavior.
-
Hi Rich. Interesting find. Thanks for sharing.
Before usr merge gets too much of our mindshare, it would be nice if Juanito would weigh in on whether it will happen for TCL16 (or ever). If not, we don't have to worry about wrinkles. If so, I'll be happy to roll up my sleeves and help sort out this issue and any others that may arise.
-
I’m not that keen as the current setup doesn’t cause me any problems, but that makes Curaga, Rich and yourself that are for it/not against it, so we could try it.
-
Hi Juanito. I'm glad you are willing to try it. I think you'll like it. If not, we can just go back to the traditional filesystem layout and put the usr merge idea to rest.
-
Hi Rich. If we go with usr merge, it would decrease the number of available places to put executables in base, somewhat simplifying this problem.
For base, the options would be /usr/bin or /usr/sbin. So ldd can stay where it is (at /usr/bin/ldd) and ldconfig would be moved from /sbin/ldconfig to /usr/sbin/ldconfig.
Is there a reason why glibc_apps.tcz uses /usr/bin, /usr/sbin, and /usr/lib rather than follow our convention for extensions and use /usr/local/bin, /usr/local/sbin, and /usr/local/lib? It was either an oversight or the intention was to overwrite the versions in the base system.
Since some users may be using the glibc_apps.tcz version of ldconfig, TCL scripts should either a) use only flags that work with both versions of ldconfig or b) if the two versions of ldconfig can coexist on same system, force the base system version by using full path.
-
Silly question, ldconfig is not part of core scripts. If it’s not from glibc, where does it come from?
-
Hi Paul_123. I assumed the ldconfig in base system was either part of BusyBox or a shell script by Robert, but I just checked and it seems to be neither. So I have no idea where it comes from. That's not a silly question.
Can one of the other developers shed light on where the ldconfig in base system comes from?
-
Hi Juanito
... but that makes Curaga, Rich and yourself that are for it/not against it, so we could try it.
I never said I was for it.
To be honest, I had concerns there might be conflicts, but I couldn't find any examples
at the time. Since I couldn't provide any examples, I didn't raise any objections.
I preferred:
/bin/ = Base
/usr/bin/ = Unique to distro (tce-load, tce-audit, etc) and basket case hard coded stuff.
/usr/local/bin/ = Extensions
I like the separation and it works.
-
I never said I was for it ... I had concerns there might be conflicts ... I like the separation and it works.
Hi Rich. Wish you guys had expressed your reservations sooner :) Knowing Juanito is not keen on it and Rich has concerns would have caused me to stop barking up this tree a long time ago.
To be honest, most of the path-related breakage I run into is because we keep extension stuff in /usr/local. I'm not suggesting we change this! The system makes sense, problems are uncommon, and workarounds are easy. Problems arising from some things being in /bin while others are in /usr/bin are rare in comparison, so it is certainly possible that implementing usr merge would cause more problems than it would fix.
I'll drop the topic, but am glad it was considered and discussed.
-
Silly question, ldconfig is not part of core scripts. If it’s not from glibc, where does it come from?
I believe Curaga provided it, maybe from uglibc?
-
I preferred:
/bin/ = Base
/usr/bin/ = Unique to distro (tce-load, tce-audit, etc) and basket case hard coded stuff.
/usr/local/bin/ = Extensions
I like the separation and it works.
That’s also my preference
-
Is there a reason why glibc_apps.tcz uses /usr/bin, /usr/sbin, and /usr/lib rather than follow our convention for extensions and use /usr/local/bin, /usr/local/sbin, and /usr/local/lib? It was either an oversight or the intention was to overwrite the versions in the base system.
The reason is that glibc is compiled to /usr because it’s in the base and I was concerned that some of the scripts would point to the wrong place if I recompiled the parts not in the base to /usr/local
-
I like the separation and it works.
That’s also my preference
Case closed, then. Thank you guys for considering it.
-
Hi GNUser
... Hi Rich. Wish you guys had expressed your reservations sooner ...
I didn't feel it was right to cry wolf before I'd seen one. ;D
-
Hi Paul_123
Silly question, ldconfig is not part of core scripts. If it’s not from glibc, where does it come from?
I did a search of the repositories and all I could find was this:
http://tinycorelinux.net/5.x/x86/release/src/ldconfig/
I also unpacked microcore.gz from TC2 and found this:
tc@E310:~/UsrMerge/tmp$ ls -l sbin/ldconfig
-rwxr-xr-x 1 root root 40476 Dec 7 15:41 sbin/ldconfig
tc@E310:~/UsrMerge/tmp$
-
Well piCore is using ldconfig from glibc in the base. I’ll have to check/try that source
-
Hi Paul_123
I also found this:
Our kernel is vanilla, ie it supports firmware blobs. Only ldconfig is statically linked (and from uclibc), everything else is dynamic. ...
-
Also running "ldconfig -v" on TC15 x86_64 the terminal output starts with:
ldconfig: uClibc version
-
Hi Paul_123
... I did a search of the repositories and all I could find was this:
http://tinycorelinux.net/5.x/x86/release/src/ldconfig/ ...
I revised my search. I think this may be more useful:
http://tinycorelinux.net/4.x/x86/scm/src/gentoo-buildhost/distfiles/gcc-4.6.3-uclibc-patches-1.0.tar.bz2
http://tinycorelinux.net/5.x/x86/release/src/ldconfig/uclibc-ldconfig-glibc-compat.patch
http://tinycorelinux.net/5.x/x86/release/src/ldconfig/uClibc-a9bdc5d28e692c04f51bcea1bb8e87f9c72ad09f.tar.xz
http://tinycorelinux.net/8.x/x86/release/src/toolchain/uclibc_x86.config
http://tinycorelinux.net/8.x/x86/release/src/toolchain/uclibc-ldconfig-glibc-compat.patch
http://tinycorelinux.net/8.x/x86/release/src/toolchain/uClibc-0.9.33.2-ldconfig-x64-p-option.patch
http://tinycorelinux.net/8.x/x86/release/src/toolchain/uClibc-0.9.33.2.tar.xz
http://tinycorelinux.net/8.x/x86/release/src/toolchain/compile_uclibc
http://tinycorelinux.net/8.x/x86_64/release/src/toolchain/uClibc-0.9.33.2-ldconfig-x64-p-option.patch
http://tinycorelinux.net/8.x/x86_64/release/src/toolchain/uclibc_x86_64.config
http://tinycorelinux.net/8.x/x86_64/release/src/toolchain/uClibc-0.9.33.2.tar.xz
http://tinycorelinux.net/8.x/x86_64/release/src/toolchain/compile_uclibc
http://tinycorelinux.net/11.x/x86_64/release/src/toolchain/uClibc-ng-1.0.33.tar.xz
http://tinycorelinux.net/11.x/x86_64/release/src/toolchain/glibc-uclibc-compat-ld-cache.patch
http://tinycorelinux.net/11.x/x86_64/release/src/toolchain/uclibc-ldconfig-x64-p-option.patch
http://tinycorelinux.net/11.x/x86_64/release/src/toolchain/compile_uclibc
http://tinycorelinux.net/12.x/x86/release/src/toolchain/glibc-uclibc-compat-ld-cache.patch
http://tinycorelinux.net/12.x/x86_64/release/src/toolchain/glibc-uclibc-compat-ld-cache.patch
http://tinycorelinux.net/13.x/x86/release/src/toolchain/glibc-uclibc-compat-ld-cache.patch
http://tinycorelinux.net/13.x/x86_64/release/src/toolchain/glibc-uclibc-compat-ld-cache.patch
http://tinycorelinux.net/14.x/x86/release/src/toolchain/glibc-uclibc-compat-ld-cache.patch
http://tinycorelinux.net/14.x/x86_64/release/src/toolchain/glibc-uclibc-compat-ld-cache.patch
http://tinycorelinux.net/15.x/x86_64/release/src/toolchain/glibc-2.38-uclibc-compat-ld-cache.patch
I unpacked core.gz for a bunch of TC x86 versions to see when ldconfig changed size:
CorePlus 4.7.7 40476
CorePlus 5.4 40476
CorePlus 6.4.1 35104
CorePlus 7.2 35104
CorePlus 8.2.1 37116
CorePlus 10.1 37116
CorePlus 15.0 37116The 35104 size matches the copy in http://tinycorelinux.net/5.x/x86/release/src/ldconfig/
It appears ldconfig is unchanged starting with TC8 through TC15.