tinycore_v4.0rc1

[hiro]

Impressive, but I expect multitasking to be a big factor here when measured in real time. Can you see how do their cpu times compare?

[floppy]

Good speed. My first experience with MC 4.0.1 + Xorg7.4:
a) my bootcodes had to be changed from "hdx" to "sdx"; example my TCE from "hdd3" to "sdc3".. no big issue, only an information (I know.. but labels etc. takes too many characters on my boot code line)
b) the error message appear on the screen during boot "hwclock: can t open dev/misc/rtc no such file or directory. No big issue
c) all Icons of wbar are gone. In the end of the dmesg log file I have..
[   81.286884] wbar[2516]: segfault at 8 ip b73975f7 sp bfa1bc3c error 4 in libc-2.13.so[b7338000+132000]
[   81.944419] wbar[2524]: segfault at 8 ip b74b05f7 sp bffa711c error 4 in libc-2.13.so[b7451000+132000]
[  111.960914] wbar[2595]: segfault at 8 ip b74e95f7 sp bfebb8bc error 4 in libc-2.13.so[b748a000+132000]
[  113.606922] wbar[2599]: segfault at 8 ip b748e5f7 sp bffc4edc error 4 in libc-2.13.so[b742f000+132000]
[  116.151117] wbar[2603]: segfault at 8 ip b74eb5f7 sp bfa5238c error 4 in libc-2.13.so[b748c000+132000]
[  116.899406] wbar[2607]: segfault at 8 ip b74905f7 sp bf994f1c error 4 in libc-2.13.so[b7431000+132000]
[  169.002069] wbar[2712]: segfault at 8 ip b73605f7 sp bfbe28ac error 4 in libc-2.13.so[b7301000+132000]
They takes a long boot time.

[Lee]

WRT wbar:

Did you get a fresh copy of wbar.tcz?  If so, it was updated around the end of August (see the .info) such that you have to fix your ~/.wbar to use "-pos" instead of "-p".  It segfaults if you don't.  That stumped me for a while, too, until I checked the .info file. 

Lee

[bmarkus]

It is great to have cpufreq modules in the base. Tested on three different machines, one notebook with Intel Core Duo and two desktops with AMD dual CPUS-s where one doesn't support scaling. Proper drivers (acpi and powernow_k8) were loaded, ondemand governor were activated and scaling was working after boot without doing any extra.

I love this behavior.

[bmarkus]

mdadm.tcz is missing in TC4 repo.

[bmarkus]

raid modules are not part of base, therefore raid devices are not recognized during boot. Please considere adding them to base even if they are big (?). Using any live distro without instant raid support is a pain when used for disaster recovery.

To have raid moduls included is much more important than cpu frequency scaling. Even if size matters, move out cpufreq modules to extension as it is now but add raid.

[maro]

bmarkus: I have not looked at the size of the RAID modules, but if they are big would not a more suitable place for such an add-on that probably only a few users need for disaster recovery be either in the 'multicore.iso' or in ones own re-mastered image?

[bmarkus]

bmarkus: I have not looked at the size of the RAID modules, but if they are big would not a more suitable place for such an add-on that probably only a few users need for disaster recovery be either in the 'multicore.iso' or in ones own re-mastered image?

If something is not in base, you can make your own version always. However raid is a bit different. But lets see what others are saying. I made my vote

[hiro]

You have computers without USB? I'm curious...

[curaga]

Wouldn't raid also need the mdadm userspace tools to be useful?

@hiro:
time loadcpufreq
real   0m 0.07s
user   0m 0.01s
sys   0m 0.00s

time loadcpufreq.sh
real   0m 1.02s
user   0m 0.66s
sys   0m 0.27s

[bmarkus]

Wouldn't raid also need the mdadm userspace tools to be useful?

normally mdadm is not needed, only to manage raid (add, remove devices, create arrays, etc., not on a daily bases.

Kernel detects raid devices at boot (if raid array supports autodetect which is the usual case) and next it can be mounted, etc on a usual way as any other block device.

Status can be displayed with 'cat /proc/mdstat'

[gutmensch]

RC1 is running great for me in VMWare Workstation, seems to be even a lot faster than 3.x, yeehaaw!

One problem appears (sometimes): udevadm settle from dhcp.sh doesn't quit, therefore no udhcpc starting for my network device... when I kill udevadm manually after startup, everything continues to work as expected. I can reproduce this with running udevadm settle myself, it's timeouting every second on polling some device (it seems) - attaching log, anyone else seeing this? Already loaded the scsi extension to make sure he's maybe not waiting for that (although I use an IDE hdd in VMWare).