Next kernel wishlist

[curaga]

It already did that of course hw-dependant, the floppy delay in particular was nasty on affected hw.

There will also be other improvements; busybox 1.19 in particular will speed up boot nicely too, when it's released.

[hiro]

Sure, looking forward to it.

My only fears are about Xorg, getting it to work was always a hassle with new kernels.

[roberts]

I can report that much is working for me.
Xvesa with 915resolution 1024x600, flwm, atheros WPA2 wifi network
I am posting this from opera-next + flash. flit battery monitor is working.
Only caveat on this machine is sound.
Just note the kernel + base modules are larger.
Appears so far that we will grow to 12MB
But for a very early rough cut of TinyCore 4.0 it is impressive.

[curaga]

Xorg 7.5 is working for me so far, I just had to update xf86-video-ati to support the chip in the netbook.

[Guy]

Would there be any advantages in using XZ compression for extensions in Tinycore version 4.x?

[Jason W]

XZ would be space saving but slower in performance (I don't know right now as of by what margin), so I am not sure we are at the point of wanting to sacrifice performance for smaller extension size.

[curaga]

No XZ included in the current build, for those reasons. OTOH LZO is there, since it comes "for free" (it's required by zram and zcache).

[bmarkus]

xz BusyBox applet is part of the base. This can decompress archives.

[hiro]

I'd rather like speed improvements of mount than smaller tczs.

[curaga]

xz BusyBox applet is part of the base. This can decompress archives.

I was talking about kernel code; the kernel can't use the busybox applet

[bmarkus]

xz BusyBox applet is part of the base. This can decompress archives.

I was talking about kernel code; the kernel can't use the busybox applet

I see. I made som test a while ago on my daily backups. xz could result smaller files than gzip bzip significantly slower using much more resources. Tuning it for same time were no benefits so decided not to use xz. It is about compression. Decompression can be better.

[caminati]

No XZ included in the current build, for those reasons. OTOH LZO is there, since it comes "for free" (it's required by zram and zcache).

Including xz or lzma support in kernel's squashfs to me would present only advantages:
tce-load would transparently handle both zip and xz tcz modules without no added work needed.
You would get more possibilities for free, without having anything to lose.
Official repository modules would still be zip, but custom modules could be packaged in xz if a user needs more compression.
What is the problem, seriously?
Or am I missing something? Maybe kernel with xz support has big size increase/performance loss?

[curaga]

It would increase the kernel size, for a small minority of users. It's a tradeoff that's not worth it right now, in my opinion.

Note that you can get better compression by using bigger gzip block sizes too; the official repo is limited to 4kb only because of ram use.

[robc]

It would increase the kernel size, for a small minority of users. It's a tradeoff that's not worth it right now, in my opinion.

Note that you can get better compression by using bigger gzip block sizes too; the official repo is limited to 4kb only because of ram use.

Though wouldn't it at the same time decrease the size of the tc/mc image by using xz over gz?

[curaga]

Yes, at the cost of much longer boot & higher ram requirement.