Tiny Core Base > TCB Talk
Sugestion: XZ compression in kernel + tcz; squashfs with xz + biger block size
nick65go:
A summary of storage space for ALL the tcz of TC10x64 as of 16/05/19
size [bites] File count
4,341,977,088 Total 2458
679,399,424 dev only 689
87,920,640 doc only 114
22,732,800 gir only 134
54,812,672 lang only 60
232,706,048 kernel 71
3,264,405,504 rest 1390
This shows that less than 8GB storage (USB/HDD/SDD) is necesary to hold all packages.
Storage is not a big constrain anymore today (ok, lets not abuse it). Masive crowd linux users with a USB/HDD less than 8 GB, but can aford x64 CPUs?
Remark-1: storage is not a real problem that TCx64 solves today.
RAM is hard (near imposible) to upgrade in modern laptops. So lets optimize for RAM size :)
Any x64 CPU is (a little) more powerful than x86 CPU.
So a better compresion (and less size) for core.gz (=rootfs.gz + module.gz) will help.
Even better is, if bootcode is used (by some users) to copy (not mount) some firmware*.tcz or *-tinycore64.tcz in RAM
Proposal for x64 (not for x86):
- add xz compression built into kernel for loading modules
- add xz compression in {mk,un}squashfs.tcz,
- eventualy biger (> 4kb) block size for larger extension (such as > 50 MB?)
51,507,200 palemoon.tcz
54,022,144 fpc.tcz
54,099,968 wine.tcz
63,582,208 openshot.tcz
63,787,008 libclc.tcz
66,842,624 firefox-ESR.tcz
68,485,120 dotnet-runtime.tcz
68,829,184 qt-5.x-webengine.tcz
85,229,568 mono.tcz
91,643,904 chromium-browser.tcz
101,867,520 lazarus.tcz
105,447,424 clang.tcz
147,341,312 libreoffice.tcz
147,984,384 timidity-freepats.tcz
Starting with x64 versions, the TC target moves to powerfuly CPU (decompresion speed is not limiting anymore).
- x64 started in 2004, 15 years ago. What target CPU/audience is TCx64 for in 2019?
The future atraction for TC come from using less RAM and diversity of appl.
Summary: The strong points for TinyCore x64 (versus other/bigger linux distributions) remains only modularity and small RAM-size packages.
jazzbiker:
Hi, nick65go!
I've read the Corebook - it is my favorite book since not long ago! And there were explained the reasons to use gzip against xz for extensions. So if squashed extension is loop-mounted, it is not moved to ram as a whole, only compression overhead is consuming ram. And for gzipped extensions this overhead is much less than for xz. So using gzipped extensions decrease ram usage and increases disk space needed, everything as you want! Modern storage sizes will accept even uncompressed extensions.
andyj:
--- Quote from: nick65go on May 17, 2019, 08:40:20 AM ---Summary: The strong points for TinyCore x64 (versus other/bigger linux distributions) remains only modularity and small RAM-size packages.
--- End quote ---
Ever worked on embedded systems? Yes, they do exist, and yes, they are resource limited and frequently without local writable storage.
The RAM only design also works well for internet facing servers which face a continuous barrage of attack bots. If one were to be compromised or go down, a reboot would restore the root file system and executables to their new state (like the ghost twins in the Matrix).
Juanito:
--- Quote from: nick65go on May 17, 2019, 08:40:20 AM ---- add xz compression in {mk,un}squashfs.tcz,
--- End quote ---
squashfs-tools supports several compression formats, so you can try xz and others to see what difference it makes if you so wish :)
hiro:
lz4 might be more practical.
ram shouldn't be any issue.
also, don't use those big packages in the first place :P
btw, i always use copy2fs.flg. still plenty free. and my laptop is now nearly a decade old hahaha
Navigation
[0] Message Index
[#] Next page
Go to full version