The Tiny Core Linux Retirement Home: oldtc.antihttps.com

[CNK]

This is an unofficial archive of Tiny Core Linux versions 1 to 10:
http://oldtc.antihttps.com/
ftp://oldtc.antihttps.com/

Thanks to Rich and CentralWare for providing access to their backups of the TC 1-3 repos that were deleted already. If anyone can upload backup of the tce/ directory for TC1, then please let me know.

[CentralWare]

@CNK: I just did a quick look at your OldTC - "Ya' did good!"

Once the dust settles and you're happy with the archive, create a separate account on your VPS with read/write access to the content and send a PM to @Rich, @Paul_123 and @Curaga with those credentials if you want the archive to become the official Retirement Home.  (The mistake was made once before where only one person had credentials for hosted content -- that turned into a true nightmare when that person was no longer available.)  @Rich and @Paul_123 I'd imagine would want to run their own comparisons of content between the live repository and the Retirement system to ensure things match up and then give @Curaga the green light at year's end when it comes time to retire 4.x and younger releases thereafter.  This would also give them the means to send in files, if any, which may be missing.

Add a paragraph to your README discussing HOW the retirement home can be used from within older TC releases:

Modify /opt/tcemirror to read

Code: [Select]

http://oldtc.antihttps.com/and then back up your changes by

Code: [Select]

filetool.sh -b
Beyond that, I'm reasonably certain I speak for the crew and members of the Tiny Core Forum when I say Thank You for investing the effort!

NOTE: Since you've completed the upload, I removed 2x and 3x from Git - no sense having duplicates!

[CNK]

Once the dust settles and you're happy with the archive, create a separate account on your VPS with read/write access to the content and send a PM to @Rich, @Paul_123 and @Curaga with those credentials if you want the archive to become the official Retirement Home.

With official/unofficial my only issue is that I do intend to share the VPS with other projects of mine (there's already another website backup saved there in fact), so I don't want decisions about the web server and storage space to be dictated by the TC archive and forcing me to use a paid service to run my own projects separately. I decided I can spare space for TC 1 to 10, minus the excluded directories. In theory if everyone agrees that they're archived correctly now, there's unlikely to be much change before they're deleted so it's set-and-forget until TC11 is due to go (besides OS upgrades, but I picked Debian 13 so it'll be supported for a long time, and enabled automatic security updates). Then I'll see if I have space to add more versions to the archive at that point.

Rich already used an FTP account I made with permission to upload to a non-public-readable uploads directory. I'll send Paul_123 and Curaga those details so they can upload anything missing (that's not deliberately excluded). It requires me to copy their uploads to the public space, but otherwise making it all writable it'd be better to use SFTP for security which means a much more complex OpenSSH configuration, ideally a filesystem space quota, maybe automatic de-duplication. I'm not sure there's a point to all that work if we're sticking to my current TC 1 to 10 archive range.

By the way, on de-duplication:
Before: 135GB
After: 91GB
44GB of space saved (using jdupes)!

Add a paragraph to your README discussing HOW the retirement home can be used from within older TC releases:

Modify /opt/tcemirror to read

Code: [Select]

http://oldtc.antihttps.com/and then back up your changes by

Code: [Select]

filetool.sh -b

Done.

Beyond that, I'm reasonably certain I speak for the crew and members of the Tiny Core Forum when I say Thank You for investing the effort!

Thanks! Maybe one day some more TC-related projects I've got in mind will be hosted there too...

NOTE: Since you've completed the upload, I removed 2x and 3x from Git - no sense having duplicates!

Well I don't know, Oracle might pull the plug on their free cloud accounts before Microsoft pull the plug on GitHub. Both will probably happen eventually. Then again, eventually I might get rich and be able to shout the TC team a whole datacentre.

[nick65go]

@CNK: First many thanks for your effort!
then ... may I point you some "not OK" archive format your automaticaly used?
FYI: I personaly can manage, it is just a head-up for other to not hit the wall with their head

using http://oldtc.antihttps.com/1.x/tcz/ as an example:
normaly all TCZ / TCZL should be "CramFS compressed", like gtk2.tczl
but some TCZ are (wrongly) ISO type, such as: poppler.tczl or xpdf-3.02pl2.tcz

my 7zip shows in Win11 this is OK:

Code: [Select]

Path: \\wsl.localhost\Archlinux\chroot\tc1\tcz\gtk2.tczl
Type: CramFS
Physical Size: 3 026 944
Label: Compressed
Big-endian: -
Characteristics: Ver2 SortedDirs
Cluster Size: 4 096
Method: ZLIB
Headers Size: 2 332
Files: 79
Blocks: 1 680
my 7zip shows in Win11 this is not OK:

Code: [Select]

Size: 876 312
Packed Size: 876 312
Folders: 4
Files: 13
------------------------:
Path: \\wsl.localhost\Archlinux\chroot\tc1\tcz\poppler.tczl
Type: Iso
Physical Size: 1 253 376
Comment: System: LINUX
Volume: CDROM
Application: MKISOFS ISO 9660/HFS FILESYSTEM BUILDER & CDRECORD CD-R/DVD CREATOR (C) 1993 E.YOUNGDALE (C) 1997 J.PEARSON/J.SCHILLING
VolumeSpaceSize: 1253376
VolumeSetSize: 1
VolumeSequenceNumber: 1
Created: 2008-10-23 12:35:39.00
Modified: 2008-10-23 12:35:39.00

prove, I can MOUNT it:

Code: [Select]

[root@HP17 tc1]# mount ./tcz/poppler.tczl ./mnt/
mount: /chroot/tc1/mnt: WARNING: source write-protected, mounted read-only.
[root@HP17 tc1]# ls -alR ./mnt/
./mnt/:
total 8
dr-xr-xr-x 3 root root 2048 Oct 23  2008 .
drwxr-xr-x 9 root root 4096 Oct 25 21:00 ..
dr-xr-xr-x 3 root root 2048 Oct 23  2008 usr
same for

Code: [Select]

Path: \\wsl.localhost\Archlinux\chroot\tc1\tcz\xpdf-3.02pl2.tcz
Type: Iso
Physical Size: 4 429 824

[CNK]

@nick65go

That's interesting to note, but the idea of an archive isn't to start improving the TC1 repo, it's supposed to be a copy of everything that was on the main repo mirrors originally. So if that's how those extensions were then, that's how they should be archived now, and I expect that's the case (I didn't tamper with them).

[Rich]

Hi nick65go
It worked for me:

Code: [Select]

tc@E310:/mnt/sdb1/1.x$ mkdir mnt
tc@E310:/mnt/sdb1/1.x$ sudo mount tcz/poppler.tczl mnt
mount: /mnt/sdb1/1.x/mnt: WARNING: device write-protected, mounted read-only.
tc@E310:/mnt/sdb1/1.x$ ls -alR mnt/
mnt/:
total 8
dr-xr-xr-x 3 root root  2048 Oct 23  2008 ./
drwxr-xr-x 5 tc   staff 4096 Oct 25 20:39 ../
dr-xr-xr-x 3 root root  2048 Oct 23  2008 usr/

mnt/usr:
total 6
dr-xr-xr-x 3 root root 2048 Oct 23  2008 ./
dr-xr-xr-x 3 root root 2048 Oct 23  2008 ../
dr-xr-xr-x 4 root root 2048 Oct 23  2008 local/

mnt/usr/local:
total 8
dr-xr-xr-x 4 root root 2048 Oct 23  2008 ./
dr-xr-xr-x 3 root root 2048 Oct 23  2008 ../
dr-xr-xr-x 2 root root 2048 Oct 23  2008 bin/
dr-xr-xr-x 2 root root 2048 Oct 23  2008 lib/

mnt/usr/local/bin:
total 77
dr-xr-xr-x 2 root root  2048 Oct 23  2008 ./
dr-xr-xr-x 4 root root  2048 Oct 23  2008 ../
-r-xr-xr-x 1 root root 12288 Oct 22  2008 pdffonts
-r-xr-xr-x 1 root root 20508 Oct 22  2008 pdfimages
-r-xr-xr-x 1 root root 15612 Oct 22  2008 pdfinfo
-r-xr-xr-x 1 root root 64468 Oct 22  2008 pdftohtml
-r-xr-xr-x 1 root root 12712 Oct 22  2008 pdftoppm
-r-xr-xr-x 1 root root 13472 Oct 22  2008 pdftops
-r-xr-xr-x 1 root root 14940 Oct 22  2008 pdftotext

mnt/usr/local/lib:
total 789
dr-xr-xr-x 2 root root    2048 Oct 23  2008 ./
dr-xr-xr-x 4 root root    2048 Oct 23  2008 ../
lr-xr-xr-x 1 root root      24 Oct 23  2008 libpoppler-glib.so -> libpoppler-glib.so.4.0.0
lr-xr-xr-x 1 root root      24 Oct 23  2008 libpoppler-glib.so.4 -> libpoppler-glib.so.4.0.0
-r-xr-xr-x 1 root root  208789 Oct 22  2008 libpoppler-glib.so.4.0.0
lr-xr-xr-x 1 root root      19 Oct 23  2008 libpoppler.so -> libpoppler.so.4.0.0
lr-xr-xr-x 1 root root      19 Oct 23  2008 libpoppler.so.4 -> libpoppler.so.4.0.0
-r-xr-xr-x 1 root root 1949864 Oct 22  2008 libpoppler.so.4.0.0
tc@E310:/mnt/sdb1/1.x$

[nick65go]

@CNK: Right, it is just as you said: That's interesting to note, nothing more to do.

@Rich: As long as the kernel has the modules (or compiled inside) it can mount whatever it recognize, isoFs cramFs, etc.
It works for me also, but with a trick! I am in a VM (virtual machine), auto-build by Windows, and its default kermel does not have cramfs module loaded.

Code: [Select]

[root@HP17 /]# uname -a
Linux HP17 5.15.153.1-microsoft-standard-WSL2 #1 SMP Fri Mar 29 23:14:13 UTC 2024 x86_64 GNU/Linux
[root@HP17 /]# ls /proc/fs
cifs  ext4  fscache  jbd2  lockd  nfs  nfsd  nfsfs  xfs
[root@HP17 /]#
I was trying a (not recomended) hard disk scarted instalation, by hand, for only the programs (+dependencies) I focus. For example I was curios what size takes a simple PDF reader in linux 2.x. And this "instalation" was in a chroot folder in the VM, so using my kernel, not linux 2.x kernel. And drag+drop selected files from inside 7zip in Win11 directly in Archlinux VM, etc. Short story: 7zip extaction in VM was OK for cramFS but not for iso, even if both are corectly extratced in normal NTFS by 7zip, but not OK in virtual disk formated as ext4, ...

But I re-checked that a simple PDF-reader in linux takes over 21 MB (excluding the kernel) versus 3 MB in a Kolibri OS.
Yeah, I re-discovred the warm water. Sorry for the noise.

[Rich]

Hi nick65go
I guess my point was to show the extension was not broken.
Since epdfview-0.1.6.tcz, gimp2.tczl, and inkscape.tczl all
depend on poppler.tczl, TC1 users would likely have reported
any issues with the extension.

[nick65go]

I guess my point was to show the extension was not broken.

Correctly! I do not want to waste your time, but maybe long term users could share their knowledge about: Why Roberts & developers choosed to use iso versus cram as container type for few of tcz, at that time? iso/cdrom has clusters of 2048 bytes size; https://www.kernel.org/doc/html/latest/filesystems/isofs.html
isofs was also used for SMALLER tcz vs cramfs (maybe an involuntary inconsistency?). Thank you in advance.

TC1 users would likely have reported any issues with the extension.

It is out of the main topic, but can we have a voting pool for how many of TC [registered] users use each version Tc 1/2/...15 ? Rich, you could move this part/voting as a new subject, if is apropiate.

[mocore]

share their knowledge about: Why Roberts & developers choosed to use iso versus cram as container type for few of tcz, at that time?

apparently it was the default for this script , and size are likely to have been considerations *at the time*

the tce2tcz script uses zisofs which adds about 300kb or more of size to small extensions. 
Using cramfs will result in only a slightly larger sized extension if they are small

some history `straight from the horse's mouth` as they say

While true, you have to realize hindisght is typically better than foresight. TC in very short time has evolved very quickly. Some complain that it moves to quick.

We started with tce, tcz came later. tcz has gone through several iterations, ziofs, cramfs, and now squashfs.

this seams relevent

Cramfs extensions are now considered a bug as they don't support copy-to-system well on all extensions.  Same as the bad permissions of /usr/local/tce.installed.  So if any of those extensions exist in a tce directory I would certainly advise updating.

The transfer of extensions should finish by tomorrow morning.  This change is transparent to the user and does not affect functionality, and  I wasn't thinking of update functions or I would have announced this.  All previous extensions have been backed up as always just in case.

+

cramfs does not store dates. One of the limitations it has.

Yes. squashfs is preferred. Feel free to update the wiki.

[nick65go]

@mocore: Thank you! very good answer, you spared a good piece of time for me to search for it.