tinycore vs tinycore64

[wysiwyg]

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!

[coreplayer2]

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

[wysiwyg]

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

[pq5190362]

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.

[Misalf]

No.

[Juanito]

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.

[curaga]

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.

[andyj]

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.

[ulfr]

  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 

[wysiwyg]

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).

[Misalf]

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.

[gerald_clark]

Core WAS designed to be used on old hardware.

[Misalf]

Oh, I thought to be told differently. One more reason to stick with 32-bit.

[bmarkus]

Core WAS designed to be used on old hardware.

x86 base and extensions compiled for i486 architecture which is not very common novadays.

[andyj]

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.