Tiny Core 14.0 Alpha 1 Testing

[curaga]

The busybox build is not static, old glibc CVEs are not affecting anything. It's simply dynamic linking to code that still exists in the current glibc, but is just not allowed to be linked against anymore.

[adb014]

Reading a bit, it seems that removing CONFIG_FEATURE_MOUNT_NFS won't stop NFS from working with kernels move recent than 2.6.23. See http://lists.busybox.net/pipermail/busybox/2017-September/085848.html where the busybox developer seem to have MOUNT_NFS desactivated by default

[CNK]

Reading a bit, it seems that removing CONFIG_FEATURE_MOUNT_NFS won't stop NFS from working with kernels move recent than 2.6.23. See http://lists.busybox.net/pipermail/busybox/2017-September/085848.html where the busybox developer seem to have MOUNT_NFS desactivated by default

The "If im reading the docs correctly" bit of the post at that link makes one wonder where those docs are. After some searching it turns out the CONFIG_FEATURE_MOUNT_NFS has been depreciated and removed from the BusyBox config docs. You can see the old description in this git commit:

-     Enable mounting of NFS file systems.
+   Enable mounting of NFS file systems on Linux kernels prior
+     to version 2.6.23. Note that in this case mounting of NFS
+      over IPv6 will not be possible.
+
+       Note that this option links in RPC support from libc,
+          which is rather large (~10 kbytes on uclibc).

But in the same year someone on the Debian mailing list described it here as if it were more of a behaviour changing option, and suggested turning it on (without anyone raising objections):

- # CONFIG_FEATURE_MOUNT_NFS is not set
+ CONFIG_FEATURE_MOUNT_NFS=y

this enables mounting of nfs filesystems just like
old mount from util-linux did (now it all is moved
to nfs-common with a helper mount.nfs).  This is to
support nfs root.  NFS mount needs rpc library, which
is not very large.  RFC.

The BusyBox mailing list thread also mentions a solution for building with newer glibc versions when  CONFIG_FEATURE_MOUNT_NFS is set:

The cause of this is that rpc.h is no longer included in glibc-2.26. See
the announcement and release notes here:

https://sourceware.org/ml/libc-alpha/2017-08/msg00010.html

* Sun RPC is deprecated. The rpcgen program, librpcsvc, and Sun RPC
headers will only be built and installed when the GNU C Library is
configured with --enable-obsolete-rpc.  This allows alternative RPC
implementations, such as TIRPC or rpcsvc-proto, to be used.

So there are workarounds that work (enable obsolete-rpc).

That seems like the safest/easiest option if it still works, but my aim is just to clarify the facts for the TC developers.

[Rich]

Hi CNK
I think  --enable-obsolete-rpc  may have been removed:

Deprecated and removed features, and other changes affecting compatibility:

* Remove configure option --enable-obsolete-rpc.  Sun RPC is removed
  from glibc.  This includes the rpcgen program, librpcsvc, and the Sun
  RPC header files.  Backward compatibility for old programs is kept
  only for architectures and ABIs that have been added in or before
  glibc 2.31.  New programs need to use TI-RPC
  < http://git.linux-nfs.org/?p=steved/libtirpc.git;a=summary > and
  rpcsvc-proto < https://github.com/thkukuk/rpcsvc-proto >.

Dated 6 Aug 2020 for GNU C Library version 2.32 found here:
https://lwn.net/Articles/828210/

Similar information plus a little history:
https://stackoverflow.com/a/71976359

[curaga]

If the option were disabled, NFS mounting would require the nfs-utils mount.nfs and helpers. Having minimal NFS support (nolock and ipv4) without bloat is good.

[CNK]

Sounds like the current build tricks are the best for full features with the smallest size then.

[alphons]

@alphons: You test TC in VMware (not free software), but I use poor-man Qemu (free software).
- what you MEASURABLLY gain (in speed, size) using SMB versus NFS ?
- I think qemu NBD (network block device) allows loops still fast enough. YMMV.

I am sorry but i do not use NFS any more myself, since ... 1996 !!
Stopped when not using Sun sparc stations anymore.
Seen implementations in de wild, preferable version NFS 4.0

I use Qemu also. But, most of my systems all are running esxi (vmware), tesing can be done on the free vmware player, and then you can copie 1 on 1 over to the esxi environment.
For personal usage, esxi is also free.

[nick65go]

@alphons: Lets not confuse "free" to use (close source) software (like VMware) with "open source" software (like qemu). Then, at lest for me, is important:
1. FLEXIBILITY (to change arch 32/64 on the fly, or use libc and musl in-parallel). to have access to various apps.
2. perceived SECURITY, in isolated environment, especially network exposed  (ex: firefox in separateVM). With "security" I can even run Kolibri-OS in a small VM, to have txt / pdf / audio / video etc.

The main goal is to use apps which ask for less RAM in VM. Because it is hard to upgrade my RAM on old machine. And qemu has snapshot storage (layer over layer). to reuse same "hdd" micro-core in simultaneous VM, etc.
PS: I am sorry to deviate from the main topic, which is TC14-alpha.

[Rich]

Hi nick65go

I did some more work on the ANSI color escape sequence patch.
I have not posted it to the repo yet.

The person that created the patch didn't do a good job on the
color handling, so I thought I'd try to fix that. ...

Sorry, I've been kind of busy.

Fltk-1.3 has been updated in TC10 through TC14, both x86 and x86_64 to better
match the colors displayed in a terminal.
 

[Rich]

Hi nick65go
If you or anyone else wants to review the changes, a tarball containing the
source package, patches, AnsiMode.H, and build script can be found here:
http://tinycorelinux.net/14.x/x86/tcz/src/fltk/
and here:
http://tinycorelinux.net/14.x/x86_64/tcz/src/fltk/
Both of tarballs are the same.

[nick65go]

http://tinycorelinux.net/14.x/x86_86/tcz/src/fltk/
Both of tarballs are the same.

Hi Rich, Thank you!
PS: should be _64/ not _86

[nick65go]

feed-back for TC14 64 bits alpha (and tc13 64):
from aterm I run mntool, it works OK, but I see:

Code: [Select]

tc@box:tc@box:~$ mnttool
XOpenIM() failedmntools works OK.

now I define a file-manager variable, FILEMGR , and mntool can unmount many disks. OK.
I try to mount any disk, it will do it, BUT it will crash /close instant! Lucky it works correctly and mount that disk/partition.
in aterm I see

Code: [Select]

tc@box:~$ export FILEMGR=fluff
tc@box:~$ mnttool
XOpenIM() failed
sh: fluff: not found
tc@box:~$
so the bug is that mntool will "uselessly" search for this variable FILEMGR, and allow just one partition/disk to be mounted before it exit.

[nick65go]

I forgot to mention that even if I load the fluff.tcz is the same behavior for mntool, with (or not) fluff opened, as long as FILEMGR is not an empty string. Which of course I can empty in the $user./profile.

[nick65go]

Hm, I think I got it:
IF a variable FILEMGR is defined in environment, then mnttool  will mount the slected partition AND open that file-manager (fluff, xfe, whatever) with that partition already selected AND it close itself. Nice.

However, if no FILEMGR is defined (is empty string) then mnttool will mount the partition AND stay alive for next command (mount another partition). Very clever, but nowhere explained in the wiki neither in forum, book etc.

PS: "strings which (mnttool)" found another variable, MNTTOOL. I wonder what it will do undocumented.
      From source code it seams that it defines position (x y) to show on desktop, maybe from top-left (found by try and error).
PS2: in aterm, the message "XOpenIM() failed" remains.

[Rich]

Hi nick65go

... PS: should be _64/ not _86

Thanks, fixed.