Tiny Core Linux
Tiny Core Extensions => TCE Q&A Forum => Topic started by: wysiwyg on June 22, 2016, 11:05:42 AM
-
Good morning everyone! I have been looking through some of the extensions for the 32bit version of TC and noticed that there are two different packages for things like alsa-modules. Whats the difference between alsa-modules-4.2.9-tinycore64.tcz and alsa-modules-4.2.9-tinycore.tcz? I would assume that the former is for the 64bit version of the OS whereas the latter is for 32bit, but then why is it in the 32bit repo?
Thanks,
Dave
-
You can have three versions of tinycore:
core - 32-bit kernel modules + 32-bit apps
core64 - 64-bit kernel modules + 32-bit apps
corepure64 - 64-bit kernel modules + 64-bit apps
core - core.gz (or rootfs.gz + modules.gz) + vmlinuz
core64 - rootfs.gz + modules64.gz + vmlinuz64
corepure64 - corepure64.gz (or rootfs64.gz + modules64.gz) + vmlinuz64
The difference between alsa-modules-4.2.9-tinycore64.tcz and alsa-modules-4.2.9-tinycore.tcz is that the former contains 64-bit kernel modules and the latter contains 32-bit kernel modules.
-
I'm guessing it's not multilib? Meaning you can't mix 32 and 64 bit apps, it's one or the other?
-
core and core64 can only use 32-bit extensions
corepure64 can only use 64-bit extensions
-
Thanks for the response Juanito. Why would there be the core64 - what purpose or use case would that satisfy?
-
core - all apps have to share up to a maximum of 4gb ram
core64 - each app can use up to a maximum of 4gb ram
-
Thanks again for the reply Juanito. I guess I could ask the question like this, why not just have a 32 and 64 bit version? Why would someone want a mixed environment between 32 and 64bit?
-
core64 came quite a while before corepure64...
-
If your hardware is capable, it's always worth it to run a 64-bit kernel. It's faster, more secure, and has less limitations. Whether 64-bit userspace is useful to you, that depends on many things: do you have programs that need more than 4gb RAM, or heavily use the cpu, etc.
-
There is no PAE enabled kernel of Core. If one wants to use more than 4 GB RAM, a 64 bit kernel can be used.
The webs says that many 64 bit compiled apps are not optimized for 64 bit code-wise, but actually provide the same performance as if they would run on 32 bit. Any truth in this?
-
It's a "it depends". Most programs are faster on x86_64 due to additional registers, but use more RAM due to larger pointers.
-
Thanks for the continued replies everyone! I would assume that if someone has a 64 bit machine, they will have upgraded specs (since that will be a newer machine than older 32bit) so they should have the resources to take advantage of a complete 64 bit environment - I agree with Curaga. I think the answer (at least that makes sense to me) was given by Juanito in that core64 was released before corepure64. In that instance, and since no clear advantage was pointed out about having a mixed 32/64bit environment, does it make sense to continue the core64? Just curious...
Thanks,
Dave
-
does it make sense to continue the core64? Just curious...
It doesn't use any resources. The kernel is the same for both 64-bit combinations.
-
does it make sense to continue the core64? Just curious...
It doesn't use any resources. The kernel is the same for both 64-bit combinations.
Not necessary true. Someone has to compile and maintain those packages. And without any clear advantage to using them, it would seem like a waste of that persons resources (time, power, etc) - at least to me. As stated, if someone is already going to be running a 64bit kernel, why not just run with the 64bit extensions to get the advantages of them...
-
Someone has to compile and maintain those packages.
core64 shares application extensions with core and kernel extensions with corepure64
-
That's what I was originally thinking until I started looking at the hashes between certain extensions the other day. I don't know if I was (mistakingly) looking at a 4.2.7 vs a 4.2.9 kernel module, or if the hash file was not up-to-date, but the two I was looking at didn't match (using the same 64bit cpu) hence me trying to figure out what was going on. Looking at a random extension again after this discussion shows that they are the same, in which case my prior statement is null and void.
I still haven't seen anything that would indicate why someone would want to run in a mixed 32/64 bit environment, but to each their own I suppose. :)
Thanks to everyone for the discussion!
-
Here's another aspect of this discussion not yet revealed..
While there is a an expanding library of applications available in the corepure64 repo, I think historically there have been a greater variety of application extensions available in the 32bit repo.
Having the ability to run a desired application which is not yet available in the 64bit repo on a 64bit system provides considerably greater flexibility.
Sent from my iPhone using Tapatalk
-
Thanks for chiming in coreplayer2, that's actually exactly what I'm working on now! I was going to relay back to the TC team the differences between the two repo's so that efforts can be made to get the same extensions in both. Since I use 64bit hardware, I prefer to use pure 64 bit for its advantages (as curaga pointed out) and have noticed there is a difference between the two repo's as you've pointed out. Once I get done with the analysis, I will share the results here.
Dave
-
Someone has to compile and maintain those packages.
core64 shares application extensions with core and kernel extensions with corepure64
Yeah, but corepure64 doesn't.
For example, xf86-video-ati was updated for the 32-bit repo, but not for the 64-bit repo:
http://forum.tinycorelinux.net/index.php/topic,20039.0.html
Suggestion:
How about getting rid of 32-bit support entirely with Tiny Core Linux 8.x?
So that Tiny Core Linux 8.x will only be available for 64-bit.
Users that need 32-bit support could use earlier versions of Tiny Core Linux.
-
No.
-
In case it might have been forgotten..
Apart from important extensions such as the toolchain, kernel modules, Xorg and similar, the idea of the repos is that they are for user submitted extensions.
This gives users that have benefitted from tinycore the opportunity to give something back.
-
How about getting rid of 32-bit support entirely with Tiny Core Linux 8.x?
So that Tiny Core Linux 8.x will only be available for 64-bit.
Users that need 32-bit support could use earlier versions of Tiny Core Linux.
No.
Well said, heh ;)
486 support is one of our strong points, and almost unique now. We are not going to dump it as long as the components of the Linux world don't.
-
I was going to relay back to the TC team the differences between the two repo's so that efforts can be made to get the same extensions in both.
I'm not sure that's going to be all that helpful. That's based on the assumption that the TC maintainers have the time to build and test all the extensions, which I suspect is not the case. For me, I wanted/needed LAMP for 64 bit, and since it wasn't in the repo, I took it on. Dozens of extensions later now everyone can have a TC 64-bit LAMP. I built MariaDB so PHP would have that support so the package would be complete, but I'll never use it. I don't have the time or desire to completely test it so I'm pretty sure that nobody else who isn't using it wants to do that either. If there is something near and dear to your heart I hope that you will roll up your sleeves and get your hands dirty.
-
hi tiny core team
thank you very much for keeping 32 bit support in tiny core
its very important to many people for many reasons
and thank you for a great distro over all
its a masterpiece
ulfr
-
I don't think support for 32 bit should end either. There are still a ton of devices that utilize that arch. It would be nice to get the repo contents matching so that the advantages of the newer hardware can be used however. There is quite a difference between the 32 and 64 bit repos.
I can't say for sure, but it looks like there are also compile scripts for the extensions to do get added to the repo so why can't those be used to compile for each supported arch as they are added? Or perhaps have submissions taken with a compiled version of each arch (maybe explain how to compile for those using something like qemu in the wiki).
-
That's just a question of how many kind people there are who compile, pack, test (!) and submit extensions. Doing that can be a lot of work, especially for younger penguins like me.
The fact that the 64-bit repo has less extensions just shows, I guess, that there are probably more people interested in / using the 32-bit variant of Core. One reason could be that, while Core Linux is not designed to be used on old hardware, It's still a good choice for resurrecting those old boxes.
I did submit every extension I made when I thought it's usable enough for others. Just started playing with Core64 today (just to see what happens) but will probably not switch to CorePure64 in the near future, since I don't really see the benefit for my case ( < 4GB RAM and not too much storage for 'redundant' installations on my x86_64 Desktop - my Netbook is x86 only).
The 64-bit era has arrived but it hasn't redeemed the 32-bit era yet.
-
Core WAS designed to be used on old hardware.
-
Oh, I thought to be told differently. One more reason to stick with 32-bit.
-
Core WAS designed to be used on old hardware.
x86 base and extensions compiled for i486 architecture which is not very common novadays.
-
One thing about TC that seems to be overlooked is that it makes a good base for VM's. When I want a web server I don't need 4 gigs of unrelated packages, just a base OS, apache and a few libs. Same for a database server, a name server, etc. While keeping hardware on the trailing edge alive can save some landfill space, don't forget there's a leading edge too.