Tiny Core Linux
Tiny Core Base => TCB News => Alpha Releases => Topic started by: roberts on August 24, 2011, 05:27:42 PM
-
Team Tiny Core is pleased to announce Tiny Core 4.0 Alpha1 is available for public testing.
http://distro.ibiblio.org/pub/linux/distributions/tinycorelinux/4.x/x86/alpha/
One of the primary reasons for an alpha release, is so that extension makers, are able to update their work for
the new environment.
This is an alpha level cut. If you decide to help test, then please test carefully. Please make a separate directory
for the new extensions. We don't want anyone to lose data or otherwise corrupt a production system.
Although the team has 8 preview cuts this is still to be considered alpha level. As such we ask that only experienced users test.
This cut is not for general use. Expect bugs, anomalies, missing libraries, modules, and extensions.
The features in any alpha are not fixed and may change before a public release candidate is made available.
We appreciate testing and feedback. Please leave all feedback for this alpha here and not mixed in with the general forums.
Download the new iso, and test features and extensions via the desktop appbrowser.
If you use distribution files note that you need both a new vmlinuz and tinycore.gz.
Notice too, the kernel is now named vmlinuz, so adjustments will need to be made for your boot loader.
Do not mix Tiny Core 3.x with Tiny Core 4.x. They have different modules and major library changes.
Changelog for 4.0 alpha1:
* Updated kernel to 3.0.3
* Updated udev to 173
* Updated glibc to eglibc-2.13
* Updated e2fsprogs base libs to 1.41.14
* Updated gcc base libs to 4.6.1
* Updated util-linux base libs to 2.19.1
* Updated all the custom core utilities to use the new repository area:
http://distro.ibiblio.org/tinycorelinux/4.x/x86/tcz/
alpha1 is based off of 3.8.3 so also included are the following recent changes:
* Updated mnttool to allow user to anchor widget position.
* New autolgin replaces rungetty.
* Updated inittab to use autologin.
Note:
* many kernel config changes, most visible ones are zcache enabled with zswap,
and pc speaker beeps (blacklist=pcspkr for no beeps)
* faster boot to base.
-
All right, let the "games" begin (I mean to say: here are my very initial observations):
(1) 'Xvesa' crashes with a segfault when using QEMU (v0.11.1 on WinXP with KQEMU)
(2) A library (i.e. '/usr/lib/libstdc++.so.6.0.13') seems to be replaced by a newer version, but the old file is still around just wasting some space.
EDIT:
(3) The minimum memory requirement seems to have increased to 53 MBytes. But maybe addressing (2) will claw back a little bit of that.
-
Installed mc.tcz it works fine. Then tried to install compiletc.tcz and got error message in AppBrowser:
mount: mounting /dev/loop30 on /tmp/tcloop/compiletc failed: invalid argument
-
AppBrowser beeps on connection error via PC's speaker. Would be better to disable it by default and possibly enable via boot code, environment variable, etc.
-
Installed mc.tcz it works fine. Then tried to install compiletc.tcz and got error message in AppBrowser:
mount: mounting /dev/loop30 on /tmp/tcloop/compiletc failed: invalid argument
It happenes at the end, after compiletc.tcz loaded. So expected dependencies are loaded correctly. Tried to build two simple extensions with no dependencies, but configure failes in both cases with
gcc -V
invalid option error.
-
Installed mc.tcz it works fine. Then tried to install compiletc.tcz and got error message in AppBrowser:
mount: mounting /dev/loop30 on /tmp/tcloop/compiletc failed: invalid argument
Looks like the behavior with empty extensions has changed. Perhaps we need to change such to have the /usr dir or something similar.
-
linux-3.0.1_api_headers.tcz was missing from the compiletc dep file and imlib2_base-dev.tcz was repeated - corrected now
-
linux-3.0.1_api_headers.tcz was missing from the compiletc dep file and imlib2_base-dev.tcz was repeated - corrected now
Now it works, I can build extensions. What is interesting resulted .tcz files are a bit larger then in 3.x environment.
-
Now it works, I can build extensions. What is interesting resulted .tcz files are a bit larger then in 3.x environment.
With the new gcc you can try -flto (to both cflags/cxxflags and ldflags), it should decrease binary size at the cost of compile time and linker memory use.
-
Applying -flto doesn't change the size. Maybe it is not gcc but squash?
-
Took alook on GCC 4.6.1 docs. -flto itself dosn't guarantee smaller code. Optimisitaion is much more complex issue and requres more attention :(
-
Just found this article:
http://www.luxrender.net/forum/viewtopic.php?f=21&t=6509
Lets find the optimal compile options for TC extensions in TC 4.0 for extension makers as the old options seems to be far from optimal now.
Tried different proposed settings. Either no size reduction or internal compiler failure :(
-
Fails to boot on Vortex86.
Looks like a library problem again.
Freeing unused kernel memory: 448k freed
Kernel panic - not syncing: Attempted to kill init!
Pid: 1, comm: init Not tainted 3.0.3-tinycore #90210
-
Which compiler flags used to build base components?
-
The standard tc ones, in the case of eglibc, gcc, e2fsprogs and util-linux
-
The standard tc ones, in the case of eglibc, gcc, e2fsprogs and util-linux
Do you mean these?
export CFLAGS="-march=i486 -mtune=i686 -Os -pipe"
export CXXFLAGS="-march=i486 -mtune=i686 -Os -pipe -fno-exceptions -fno-rtti"
-
There are
/usr/lib/libstdc++.so.6.0.13
/usr/lib/libstdc++.so.6.0.16
Guess /usr/lib/libstdc++.so.6.0.13 is not needed and can be removed from base.
-
1) Please add support BTRFS to kernel and utilites. It's stable now and better for SSD.
2) Sometimes boot options works not correct. For examle norestore not processed always (3.8.x, 4x)
3) Need instruction for using apps in modes Onboot, Ondeamond. How many possible to Onboot with 128Mb memory for example.
-
Correct, except binutils, gcc and deps compiled without "-fno-exceptions -fno-rtti"
-
cpufreq kernel modules and tools are missing in 4.x repo
-
1) Please add support BTRFS to kernel and utilites. It's stable now and better for SSD.
It is not. There is still no fsck, and it is still marked as having an unstable disk format in 3.0.
3) Need instruction for using apps in modes Onboot, Ondemand. How many possible to Onboot with 128Mb memory for example.
Depends on the apps.
cpufreq kernel modules and tools are missing in 4.x repo
The modules are now in the base. Better power-saving.
-
cpufreq kernel modules and tools are missing in 4.x repo
The modules are now in the base. Better power-saving.
I see kernel modules but cpufreq-info and cpufreq-set are still missing.
-
I don't know the state of the cpufreq tools, never used them myself. I don't really see the need for tools when the kernel is enough.
-
cpufreq utils are in the 3.x repo as an extension. Theay are handy cli tools to change and displays settings. Of course no need for them in the base and there are other tools also, but these are the 'official' programs. Extension is maintained by Juanito for sure he will add it to 4.x repo.
-
Fails to boot on Vortex86.
Looks like a library problem again.
Freeing unused kernel memory: 448k freed
Kernel panic - not syncing: Attempted to kill init!
Pid: 1, comm: init Not tainted 3.0.3-tinycore #90210
re-compiled eglibc, which will hopefully work on i586/i686, should be in the next cut
-
Extension is maintained by Juanito for sure he will add it to 4.x repo.
I'll look at this as soon as I can
-
cpufreq kernel modules and tools are missing in 4.x repo
The modules are now in the base. Better power-saving.
Not for my laptop:
tc@box:~$ cpufreq-info; cat /proc/cpuinfo|grep "model name"
cpufrequtils 006: cpufreq-info (C) Dominik Brodowski 2004-2009
Report errors and bugs to cpufreq@vger.kernel.org, please.
analyzing CPU 0:
no or unknown cpufreq driver is active on this CPU
maximum transition latency: 0.00 ms.
analyzing CPU 1:
no or unknown cpufreq driver is active on this CPU
maximum transition latency: 0.00 ms.
model name : Intel(R) Core(TM) Duo CPU L2400 @ 1.66GHz
model name : Intel(R) Core(TM) Duo CPU L2400 @ 1.66GHz
If I understand correctly newer CPUs with C4 don't need cpufreqd.
-
Did you try "sudo modprobe acpi-cpufreq' first?
-
Yes, the autodetection could certainly use some work.
edit: Well, turns out udev still doesn't do that, the first requests on that are from 2003. Will check the script Debian uses.
-
I'll look at this as soon as I can
cpufrequtils, cpufreqd uploaded to 4.x repo
-
I'll look at this as soon as I can
cpufrequtils, cpufreqd uploaded to 4.x repo
Thanks, it works
-
Fist impressions are good. It works fine till now. For testing I rebuilt few extensions. Result is OK, excepte that in all cases I get a 10-15% bigger .tcz than on 3.x Played a bit with gcc options with no result. gcc 4.6.1 expected to have better optimization but how to use?
Does optimization depends on gcc itself and how it was built too?
-
Juanito: I'm very much hoping that the re-compiled 'eglibc' will also address the failure of 'Xvesa' when run in a QEMU VM with either '-enable-kqemu' or '-kernel-kqemu' (as reported as (1) in reply#1 above).
I somewhat recalled that I'd seen something similar a while ago, and indeed as this pretty old thread (http://forum.tinycorelinux.net/index.php/topic,1776.msg26835.html#msg26835) shows the 'glibc' was the culprit then. After a quick test where I remastered TC 4.0a1 with 'glibc' 2.11.1 (from MC 3.8.3) I'm pretty sure it is again the "guilty party". So there is some hope that this regression can be overcome again with a differently built 'glibc'.
-
The glibc referred to in the "pretty old thread" was not built with either '-enable-kqemu' or '-kernel-kqemu'.
Let's first see if the recompiled eglibc works on i486/i586 (I have neither to test with) and qemu vm (which I don't have either).
-
The glibc referred to in the "pretty old thread" was not built with either '-enable-kqemu' or '-kernel-kqemu'.
I guess you misunderstood (probably as a consequence of my convoluted description): It does not matter on which system the glibc was built, but take a TC ISO image and boot it with:
qemu -m 64 -cdrom tc.iso -kernel-kqemu
If there is a "bad" glibc in the initrd: 'Xvesa' fails.
Let's first see if the recompiled eglibc works on i486/i586 (I have neither to test with) and qemu vm (which I don't have either).
Don't you worry. It is always my very first test with any freshly downloaded TC version, and I'm not too shy to speak up.
-
Is there any benefit using extension on TC 4 built on TC4 compared to TC3 build? Does it worth to recompile extensions?
-
The newer build will be able to use functions not available in the older glibc and kernel. Since not much software does this, no need for mass rebuilds, normal version upgrades will do.
-
Tried to build my heavily customized "minidistro" with the new alpha....
Here are my comments and experiences (yes I know it's the very first alpha)
- biggest problems for the buildscripts were the changed drive names (hdax --> sdax) and the new /run root-level directory that I forgot to include in the remaster.
- boot time is improved (8 seconds from start to logon screen is not too bad for a 9-year old desktop). Also shutdown/reboot time is improved.
- the Xorg-7.5-3d.tcz extension is missing, so I dropped 3d acceleration for now.
- OSS sound does not work as the download in Appbrowser fails with an "MD5SUM Error: Error on OSS-modules-3.0.3-tinycore.tcz". I prefer OSS as in my experience it consumes less memory, initalizes faster and is more reliable than ALSA.
- Then tried to build OSS myself, like I did without problems in TCv3, but failed. Reason as far I could determine: incomplete kernel headers, missing stuff that is present in the Tinycore version 3 header files (like some makefiles).
- Then tried ALSA. If you click the "Depends" tab in Appbrowser it still lists obsolete dependencies, like alsa-modules-2.6.33.3-tinycore.tcz. But if you try to download ALSA it downloads the correct modules. It seems to download even more than what is mentioned in the dependency list (like the v4l-dvb-3.0.3-tinycore.tcz extension)
- ALSA didn't work first time. It seems I have the same problem as what was mentioned in this post: http://forum.tinycorelinux.net/index.php/topic,11224.msg58729.html (http://forum.tinycorelinux.net/index.php/topic,11224.msg58729.html). The mentioned depmod.tcz extension is missing in the v4 repository, but after copying it from TCv3 and installing it I got the sound working.
- when I boot the original Tinycore ISO I experience a slight but annoying issue with the left mouse button: it only reacts if you hold it down a couple of tenths of seconds. A short click does nothing so the system tends to miss clicks.
Apart from the aforementioned issues, the new alpha runs absolutely perfect: internet browsing, flash, fullscreen movies, sound etc. etc. For a first cut it is fantastic!
Keep up the good work!
-
I haven't yet had time to check out OSS. While I plan to do Xorg 7.6 for tc4, 7.5 3d is working fine, I'll copy it over.
edit: Checking the .tree file situation.
-
.tree files cannot be copied over from 3.x and should be regenerated, especially true for extensions needing modules.
-
Generating trees for 4.x some ~150 were freshly created and a similar amount were updated. I didn't force a full rebuild.
-
Hi guys!
Can't get the sound to work neither with alsa or OSS. Have tried the tricks mentioned above but with no success. Thankful for any hints that could lead me in the right direction. Apart from the sound all seems to work pretty well. Good job!!!
Have fun improving TC further,
meo
-
Very nice -- glad you included support in the kernel for multicast.
Miniupnpc tested and working.
-
In 'Wbar Conf' there are no value displayed for 'Wbar Icon Size' and 'Wbar Zoom' sliders and no 'Set default'. If you change icon size result is loss of WBAR. The only way to restore (what I found) delete ~/.wbar, exit to prompt and restart X. Not very convenient.
-
With this wired hardware:
02:00.0 Ethernet controller: Broadcom Corporation NetXtreme BCM57765 Gigabit Ethernet PCIe (rev 10)
..the tc-3.x tg3 driver will not work, but with tc-4.x it does :)
Edit: adding this from tc-4.x (dual) booted on a unibody mac mini
-
In 'Wbar Conf' there are no value displayed for 'Wbar Icon Size' and 'Wbar Zoom' sliders and no 'Set default'. If you change icon size result is loss of WBAR. The only way to restore (what I found) delete ~/.wbar, exit to prompt and restart X. Not very convenient.
Corrected. wbar.tcz is now posted in 4.x/x86/tcz for micorcore. Tinycore will have to wait until next cut.
-
FLRun: please add 'Run in terminal' checkbox
-
I am still considering how I want to handle this. A checkbox would require intimate knowledge of target.
Instead I wouid thing it better to reference our standard freedesk item which handles how to launch. I have been very busy of late, but am considering a freedesktop applicaton launcher independent of any window manager. It would likely combine the current menu, ondemand menu, and load local functions.
-
I am still considering how I want to handle this. A checkbox would require intimate knowledge of target.
Instead I wouid thing it better to reference our standard freedesk item which handles how to launch. I have been very busy of late, but am considering a freedesktop applicaton launcher independent of any window manager. It would likely combine the current menu, ondemand menu, and load local functions.
Typically you need a terminal window to run cli applacitions like ibam, top, ... These do not have freedesktop items and I do not see any reason to add it. This is simple issue and let users to check and uncheck this box. There are no need for any additional system stuff.
The only issue is to find out what is the default terminal to run. Xfce4, LXDE, ... are managing on their own this setting, but base is different. The most TC-like solution is /etc/sysconfig/terminal default to aterm.
That's all needed in my opinion.
-
Note libstdc++ devs split out of gcc, you will need to update gcc & compiletc.tcz.dep and download gcc_base-dev
-
We have already seen users trying to run terminal hosted cli items without X, e.g. mc .
With mc in OnDemand I get (at the console):
aterm: can't open display : 0
Those not familiar with an application would not know. Unless you are suggesting that such info should be listed in the .info file! It is far easier for me to add a checkbox.
My concern is where is the information that such is required. I would think that any application that offers an icon, e.g. mc, should have a freedesktop item and such should use cliorx instead of aterm.
One thing is for sure, we should be consistent and not some cli items one way and others not and then expect base system functions to know how to handle.
-
Using microcore64/vmlinuz64, the boot sequence hangs with:
Starting udev daemon for hot plug support...Done
modprobe: chdir (3.0.3-tinycore64): No such file or directory
-
The 64 initramfs seems to have old modules (.33.3) and the empty dir of a previous test version, usr/local/lib/modules/3.0.1-tinycore.
-
For testing I rebuilt few extensions. Result is OK, excepte that in all cases I get a 10-15% bigger .tcz than on 3.x
Could you try again with latest gcc, compiletc.tcz.dep, gcc_base-dev?
-
For testing I rebuilt few extensions. Result is OK, excepte that in all cases I get a 10-15% bigger .tcz than on 3.x
Could you try again with latest gcc, compiletc.tcz.dep, gcc_base-dev?
I did. Result is the same, except ibam compilation gives a normal size now, (with 15% extra size).
-
When opened window positioned to the bottom it tends to fully cover WBAR so it becomes invisible, window must be moved away manually. Is it possible to bring WBAR to the front automatrically or to keep clean bottom part?
-
I played around with intel hd 3000 graphics:
Xvesa:
- xsetup.sh displays a maximum resolution of 1024x768 (my screen's native resolution is 1280x1024)
- manually editing .xsession to 1280x1024x24 doesn't change anything
- i915resolution doesn't recognise the graphics device
Xorg-7.5
- worked "confless" for the first time ever for me - but at 800x600
- using graphics-3.0.3/Xorg-7.5-3d "confless" gave the bottom left-hand quadrant of the display positioned part way up the screen
I guess for Xorg, a later version is required and/or an xorg.conf suited to the hdmi -> dvi output
-
bluez recompiled on tc-4, tested and uploaded to repo
-
Yeah, Sandy needs rather new X.
-
Hi,
I'm looking at installing Tiny Core v4.0 Alpha 1 Testing on a harddrive, and i don't see tci or tc-install. Since it's new, can't complain that it's not there.
Any steps to install it manually? Thanks!
regards,
Steadph
-
The manual install guide will work: http://distro.ibiblio.org/tinycorelinux/install_manual.html
-
Any steps to install it manually? Thanks!
Given that it is in alpha testing, this is a bit like "if you have to ask, you can't afford it" ;)
-
Given that it is in alpha testing, this is a bit like "if you have to ask, you can't afford it" ;)
!Like
-
@Curaga,
Thanks! that is perfect. Was just reading the installation and did not see the manual install. I'm going to step 4 on these as i have already done step 1 to 3.
@Juanito,
And for the affordability, I can since i'm a long time Linux guy since the slackware 2.x days. Long time desktop user of tinycore, but have not delved that much on the dev part. If it breaks, we'll I keep the pieces. :D
regards,
steadph
-
The manual install works perfect (though i have to change to vmlinuz kernel on the grub menu.lst) and the Alpha is now installed on the HDD. Also installed my favorite terminator and a ton of dependencies and it works as well too.
regards,
steadph
-
Network Block Devices ( nbd ) were not included in kernel or modules.
-
When opened window positioned to the bottom it tends to fully cover WBAR so it becomes invisible, window must be moved away manually. Is it possible to bring WBAR to the front automatrically or to keep clean bottom part?
This is configurable in .xsession if your using FLWM. Change this line:
"$DESKTOP" 2>/tmp/wm_errors &
To something like this:
"$DESKTOP" -g 1024x720+0+0 2>/tmp/wm_errors &
This will limit FLWM to only using 1024x720 (starting at 0,0) of the screen when you maximise windows or open new windows, so that you can make it so wbar is always visible.
-
This will limit FLWM to only using 1024x720 (starting at 0,0) of the screen when you maximise windows or open new windows, so that you can make it so wbar is always visible.
Thanks. Why not apply it by default in the base?
-
Network Block Devices ( nbd ) were not included in kernel or modules.
lib/modules/3.0.3-tinycore/kernel/drivers/block/nbd.ko.gz in base?
Thanks. Why not apply it by default in the base?
It would be a big change in existing behavior, and many like that it won't override the windows. Also, vertical space is a premium nowadays (netbooks, 16:9 screens).
-
Agree, we need every part of the screen. Same on my norebook too. However it makes me angry to move away windows with the notebook touchpad just because it covers WBAR (which is not my favorite BTW). Also if WBAR would be always on top I would hate it.
In other DE environment I prefer autohide panels.
So do not know what is the best solution on stock TC.