Tiny Core Linux
Tiny Core Extensions => TCE Talk => Topic started by: xor on October 16, 2024, 02:02:50 PM
-
Is TCL's philosophy of minimalism going the wrong way!?
TCL's philosophy of minimalism should not be adopting the latest kernel, but the most stable, oldest-based, minimum-consumption kernel!
low-level legacy users; clearly looking for early TCL releases, my suggestion is to support both the latest and oldest versions at the same time!
Would our TLC community consider a democratic vote on this?
-
Hi xor
... Would our TLC community consider a democratic vote on this?
Absolutely. All forum members are encouraged to exercise
their right to vote in the attached poll.
Good luck xor, I hope you win. ;D
-
Should xor be required to support the oldest versions of Tinycore?
go big or go home, how about this:
"Should xor be required to maintain a complete and up-to-date TinyCoreLinux mirror?
(including any/all versions that are removed for space constraints. see https://forum.tinycorelinux.net/index.php/board,49.0.html for additional information)
-
speaking of space...
@curaga, will there be a post regarding version 4 shortly?
(last year's post was dated October 20th)
-
@xor: Is it going the wrong "way" -- not really.
Is that way antiquated?
Maybe a little.
Bare in mind, Tiny Core Linux / DSL was spawned back in the day when the general public DID NOT have computers in their pockets, when a USED 80486 computer was still astronomically priced compared to today's machines, back when RAM was still a commodity due to natural disasters overseas (and "under" seas) but most importantly, the general PEOPLE were still clueless for the most part and WinXX was their tool of choice to break in the new age. DSL/TCL was visualized because people wanted to take USED machines and give them NEW life.
Now, in the past couple of decades things have progressed, become cheaper (price AND quality), more portable, etc. Tiny Core Linux is still leaning toward the 486/586 days mentally, though.
Is a CLEAN, LEAN, RIPPED operating system a good thing? Of course it is.
Does it have to be byte-counted? Probably not as much as it is currently, but to do anything different would open debates that can't be resolved as someone out there is going to ask "how much is too much?"
Hard drive storage, Flash storage and RAM are a fraction of the cost they were when DSL (2005) and TCL (2009) were launched so there's room to wiggle unless you're trying to resurrect a 486dx and turn it into a kiosk or something... a feat to have fun doing, no doubt, but for day to day use... not the wisest path to take if you have other means.
Does it have to have CURRENT kernel releases? Most definitely.
You have to understand, the KERNEL isn't just basic functionality and foundation... it's HARDWARE SUPPORT.
The newer the hardware, the newer the kernel. Period.
If you have older hardware, you can get away with an older kernel.
Should Tiny Core offer multiple kernels?
Technically, it already does. Pick a TCL version from 5.x to the recent 15.x release - you have plenty to choose from!
Now, if we were to keep EXTENSIONS in each of those versions up to date... THAT would be a feat!
A very unlikely one, though, as some extensions depend on kernel content so the extension cannot be any "newer" than the kernel without it potentially breaking.
It's a blissful thought, though!
You have a valid question, but it's not really an opinion based topic in need of a vote.
Tiny Core doesn't have to be "as tiny" as it is - but I do like the methodology behind it.
Tiny Core doesn't HAVE to be as "new" (kernel) as it is... but if it weren't, it wouldn't support things like USB3.x, the latest graphics cards, the latest CPUs, etc. so it would become an operating system that ONLY supports OLD hardware...
-
Thanks for the reminder gadget42.
-
@CentralWare: Very Well Said! Ditto!
-
Thanks for the reminder gadget42.
https://forum.tinycorelinux.net/index.php/topic,27321.msg175797.html#msg175797
if the logic driving the removal of old versions is reduce space could / should tcz/src (build scripts) be retained ?...
*more* on that tangent :
reinstating ./src from the removed/archived repository's ?
& ftr the downloads.html still links to 1/3 .x
-
Thx :)
Hi xor
... Would our TLC community consider a democratic vote on this?
Absolutely. All forum members are encouraged to exercise
their right to vote in the attached poll.
Good luck xor, I hope you win. ;D
-
It may be a very idealistic approach,
but my personal opinion is that the latest hardware can be supported by preserving the kernel architecture of the 2.6 series.
-
if the logic driving the removal of old versions is reduce space could / should tcz/src (build scripts) be retained ?...
@Curaga: @mocore brings up a good point regarding sources and build scripts
For the time being, at least until we have a solid source repository/archive, please LEAVE source directories when disposing of antique versions.
x86/x64: ./release/src and ./tcz/src
arm/etc: ./releases/RPi/src and ./tcz/src
It may be a very idealistic approach,
but my personal opinion is that the latest hardware can be supported by preserving the kernel architecture of the 2.6 series.
@xor: You do realize that 2.6 was given a warrior's funeral around eight years ago?
Maybe I am not seeing something you're trying to get across... please enlighten me?
I have kernel.org on the screen to my right showing that the oldest long-term kernel still being supported with security/bug patches is v4.19
Please be aware, 4.19 is old enough that it probably doesn't know what USB3.2 ports are or how to communicate with them, so loading that kernel on a newer motherboard is probably not a good idea unless you have no use for the newer hardware chips.
From the sound of it, you're asking to resurrect kernel v2.6.32 (which we were using back in Tiny Core Linux v2.x! Kernel 2.6.29 specifically.)
In YOUR eyes, what would be gained by making the kernel from ~2010 available today?
(I can send you a copy of Tiny Core 2.x, but I'm not sure the general public has much use for the same.)
-
I'm posting from a PC running old DSL with kernel 2.4. A fair bit of software does still build for such old kernels/glibc, though things like current Firefox versions are way out.
My main use of Tiny Core is running software like Firefox which needs an up-to-date environment. For some other systems I run old TC versions as long as I can get away with because it's not worth the time of upgrading and there's little advantage. I don't care about recent hardware support, the cutting edge has been beyond my needs for decades now.
Ideally I want a distro like Tiny Core based on the work of the CIP Core (https://wiki.linuxfoundation.org/civilinfrastructureplatform/cip-core) project that aims to keep Linux kernels and a base set of Linux software maintained for ten years. Ten years is a sensible upgrade cycle in my opinion. I'm happy with hardware much older than that, especially running older, and therefore less bloated, software. If that existed, and projects like Firefox saw the light and made an effort to keep working with those old kernels, I wouldn't need Tiny Core and its modern kernels anymore. It's very unlikely that projects like Firefox would do that though (Debian have even struggled to build new Firefox for their stable releases in the past), so really I want Tiny Core to keep doing what it's doing letting me run a bare minimal system for flashy software, while I just use old unmaintained Linux for other tasks where flashy modern software (and good security) isn't needed. It's not ideal for me, but beggers can't be choosers.
-
My 2cents,
I have been running DSL on a board with 500MHz ultra low power Eden processor since 2008. This had 2.4 Linux kernel. This summer I upgraded to Linux 6.6 (which forced me to tiny core because dsl is no longer maintained) for simple reason “it was no longer practical to stay on 2.4”.
With that I mean:
- sure everything keeps running if you don’t want to upgrade apps.
- but extending became close to impossible.
- I for instance was not able to use https calls.
The board runs my home automation system that I have programmed from scratch in C. In itself “it works” so I could have chosen to “not extend further”, but new devices come to the market. New protocols get introduced. So….. I had to choose to either go for a more modern board like raspberry pi OR get Linux kernel updated. I was happy that tiny core allowed me to upgrade.
With all that said…
- I think it is very helpful to keep earlier versions of tiny core downloadable.
- very old hardware can than at least brought to life.
- I also think it’s helpful to keep the associated tce extension library downloadable, and especially the programming tools (gcc). That allows such board to do something useful instead of just showing a desktop and will allow to program simple appplications perfectly suited for outdated hardware.
- but trying to keep the newest applications runnable on that old Linux I would consider a bridge too far. It likely runs into many “new kernel must haves”.
In other words:
- there is nothing wrong with the ability to still download a 15 year old ecosystem to use on hardware that once did cost 500 to 1000euro or dollar and can now be achieved for under 10.
- there can be lot of fun in operating that hardware on that 15 year old ecosystem. I remember I had lots of fun 10 years ago. No problem to relive that.
- but trying to bring that hardware into a modern ecosystem I consider a bridge too far.
While of course: if someone want to try: fun! But just not as a “general strategy”.
And as said…
I say that as a guy who had spent about a year to think about best way to “re vitalize” his low power board with linux 2.4. Finally concluding that it either had to go to 6.6 or abandoned.
If your interested, I posted some of that transition here: https://forum.tinycorelinux.net/index.php/topic,27188.0.html
-
at this point in the thread progression perhaps a good question to have answered definitively would be is there a way for someone to pay-for-and-receive-via-mail-post-etc a hard-copy of releases that have been removed?
naturally it is to be expected that whomever might offer/provide this service should be compensated for all time/expenses incurred.
to that end, if someone wanted just the TinyCoreLinux 1.x release in its entirety, how much data is that actually? and if compression is used, checksums would probably be a good idea for both the originals and the compressed tarball?
realistically, this is/might/would-be a very rare occurrence but i can see it having value moving forward into the future as more releases are taken offline.
let the fun begin...lol.
-
@gadget42: Tiny Core 2.x ISO files and TCZ extension library would fit cleanly on a DVD (does not necessarily include tcz/src, the archive directory, updates, etc.)
The TCE extensions are another gig and change
The SRC directories are unreliable in size as many are uncompressed
All versions older than 5.x have their own "way of doing things" and IMO should not be supported for this debate.
That said, it may be more prudent for DVD or USB pen drive sales as opposed to hosting the older content live 24/7
@Stefann: Please note which version(s) of TCL you want/need from the archive (v4.x and older)
@CNK: Please do the same
@xor: Please do the same
Gadget42: Ditto
naturally it is to be expected that whomever might offer/provide this service should be compensated for all time/expenses incurred.
Anything "hard copy" by post would incur a cost; how much depends on media, time and shipping costs - I MAY have a postage-free method in mind for the time being.
I'm working on a couple ideas right now as to how we can accommodate archive members; bare with me!
-
@CentralWare, i just used TCL 1.x as an example. keep us posted as you progress and hopefully we can come to some viable solution(s)!
-
@gadget42: TCL 1.x is kind'a in the ether as it was blended throughout the main repository website (unless someone has a backup pre-2009?? we cleaned house quite a long time ago and TCL 1.x went with it.) HOWEVER, 2.x is currently uploading as we speak! (If memory serves, 1.x pointed to http://tinycorelinux.net/tcz instead of our current method of tinycorelinux.net/[VERSION]/tcz but it's been SO long ago I cannot be 100% certain.)
ATTEMPT #1 : Caveats
1. I'm using GIT as a storage container for the first attempt; thus far there's no problems... "except..."
* There IS a file size limitation of 100MB for any one file -- and there's only ONE file that falls into that category for 2.x ... OpenOffice (so for the moment it's being left out, possibly to be broken into smaller pieces later which should be reasonably simple to do - just add openoffice-part2.tcz to the .dep and create part2 to contain half of the original :) )
* TCL 2.x is showing 11,723 files being pushed at the moment and we've been kicked (connection) three times now, so pushing commits has to be done in small doses.
2. GIT is public-open-door which we want... but probably not the "ideal" platform for noob/rookie users... then again, rookies probably should be pressed to update if they're still running single-digit TCL as it's deemed unsupported.
3. I could easily be wrong, but I thought GIT had a 2GB per repo ceiling once upon a time. IF SO I'll be looking at one of the other options OR possibly a Split-GIT as size dictates... we'll see!
If the above is successful and if our only real limitation is the 100mb file size @MAINTAINERS please consider this for all future submissions as it's a small price to pay for archival services!
-
Tiny Core Linux 2.x x86 (the only platform of the time) is almost finished uploading to GH.
1. I've been pushing ~1,000 files at a time without issue - beyond taking a long time to do so manually (hurry up 'n wait...)
2. We're already at ~6GB on GIT without complaint about storage space, but too soon to tell if ALL of the archives will hit an unforeseen cap
The last batch of ~1,500 files is going up now just to press my luck :)
If successful, each release will be found in its own repository (ie: 5.x x64 will have its own apartment next to 5.x x86)
The archives will NOT include older ISO releases (Version tinycore_2.11.iso, for example, should be plenty... 2.07 doesn't make sense TO ME to hang onto.) If anyone disagrees please post your thoughts here.
SUCCESS!
https://github.com/centralware/TinyCoreLinux_2.x_x86 (https://github.com/centralware/TinyCoreLinux_2.x_x86)
I'm going to scour through 2.x and see if there are any remaining files that would be necessary if I were running a device on 2.x, otherwise it looks like we're good to go!
@Rich @Curaga @Paul_123 @Etc please review your thoughts as to how you want (C)opy and README to read
@xor: This work for you?? :)
-
@Stefann: Please note which version(s) of TCL you want/need from the archive (v4.x and older)
@CNK: Please do the same
@xor: Please do the same
Gadget42: Ditto
Thanks!
But I’m super happy with 15.
That was the whole point of my post.
I really liked that I was able to upgrade my board from 2008 to a Linux kernel from 2024 as that discloses basically all new software to it.
I very much appreciate the drive for tiny core to stay small footprint because that allows to run frugal in memory within the memory size of my board.
-
Hi CentralWare
... SUCCESS!
https://github.com/centralware/TinyCoreLinux_2.x_x86 (https://github.com/centralware/TinyCoreLinux_2.x_x86) ...
Just a couple of observations:
1. When I looked in the tcz directory, I saw this message:
Sorry, we had to truncate this directory to 1,000 files. 9,593 entries were omitted from the list. Latest commit info may be omitted.
The tce directory displayed a similar message.
2. There's a separate dep directory that looks like it might contain duplicate
.dep files that are already in the tcz directory.
-
@Rich:
Yes, their WEBSITE truncates at 1,000 listed files - I'm thinking it's a browser related limitation so as not to overwhelm a single session.
I just tested a few minutes ago using git command-line and the entire repo is there and downloaded successfully.
(Just saw the 1,000 limit ~20 minutes ago myself :) )
For 2.x, I am not sure why there's a "deps" directory but instead of trying to trace back that far into history I just left it in.
We can run a file comparison and if all of the needed .dep files are inside ./tcz we can rid ourselves of it once it's confirmed
-
The problem with GitHub is that although you can access it like a repo mirror via URLs like this:
https://raw.githubusercontent.com/centralware/TinyCoreLinux_2.x_x86/master/tcz/bootchart-pl.tcz
If you try with http:// instead of https:// it redirects to https://. This means it won't work to fetch extensions on systems running old TC versions because they won't support the new HTTPS encryption methods so the downloads will fail. You could manually copy the files over, but that's never easy and now we see there's no way to list the full directories in order to manually select files to download in a browser.
Since I thought it was getting off-topic, I cut out my suggestion for archiving the old extension repos from my last post:
-----
On the old repos going offline - if I ever get enough time in the presence of a fast, unlimited, internet connection (this opportunity hasn't presented itself to me in a few years, I usually just have a few GB/month of mobile broadband data), I intend to do the following:
- Download all of the repos set to go in the next new years, say up to TC 10
- Unless I can find a way to avoid duplicate extension downloads with Rsync, run a file de-duplicator program (eg. rdfind) that turns copies of extensions or source code archives that were reused from earlier versions into symlinks
- Compress it all in an archive format supported by the Internet Archive's "view contents" function - zip or maybe tar.xz. This does still allow individual files to be accessed via direct HTTP URLs, such as for the /opt/tcemirror setting. Need to confirm whether this works with symlinks though.
- Upload it to the Internet Archive, maybe using their command-line uploader tool if the size of the file causes issues with Firefox
I suspect that many people here are in a better position connectivity-wise to do this than me, but although some have stated intentions to do so, I haven't seen any sign of people doing it. For now I've just managed to keep saving each version before it goes offline in preparation to do this one day.
-----
Currently Archive.org downloads work over HTTP and HTTPS (even though browsing the main website redirects to HTTPS). Or did before they recently got hacked and DDoSed, leaving the archive offline at the moment.
I've also been thinking about using a free Oracle Cloud VPS to run a HTTP server from its 200GB free "block" storage, but I think I measured that the later TC repos have a lot more data than that (although I don't know how much of that is duplicate extensions).
P.S. I guess the main TC extension repo server does itself de-duplicate extensions that are the same between TC versions to save space? I sure hope that would be attempted before hitting the delete button on the old versions.
-
I've also been thinking about using a free Oracle Cloud VPS to run a HTTP server from its 200GB free "block" storage, but I think I measured that the later TC repos have a lot more data than that (although I don't know how much of that is duplicate extensions).
Damn, I just went to check the sizes and the HDD I put them on has died. I remember they didn't fit on my backup drive, and I don't think I backed them up elsewhere, so I think my hours downloading them while 'on holiday' before they went offline are all down the drain.
Excuse me while I walk around swearing loudly for the rest of the day...
-
P.S. I guess the main TC extension repo server does itself de-duplicate extensions that are the same between TC versions to save space?
Sorry, I don't have access to the live repository server to know what's an actual file and what's a link, but I do know that a lot of copying goes into play when a new version is released (where extensions are copied from their predecessor into the new TCZ directory - whether it's real or linked maybe @curaga could shed a little light on the subject?
De-duping... to be honest I doubt it is going to be handled in such a fashion as that takes a good deal of time... but like I said, I don't have server access to know one way or the other for certain.
@CNK: If you would like a hard copy, please send me a private message with your full name and mailing address along with the version(s) of TCL you want to have shipped and I can send you a quote based on the required media size and shipping from the States. Please include a note as to whether or not you require source code files as this will definitely affect media size!
PS: Sorry about your HDD :(
-
...
Excuse me while I walk around swearing loudly for the rest of the day...
glad to see i am not the only one who does that...still...argh!
-
There is no dedup between versions. Not that it would affect anything, as our mirrors do their own thing, and the space usage affects them as well.
-
My 2 cents,
I guess you do not need "all" older versions.
I just got v15 working on a board that launched 2005 so I kind of feel V15 covers most post 2005 hardware.
With CentralWare succeeding to get the oldest practically functional version to live (v2) that should either be enough to cover hardware until 2005 OR maximally 1 other "smartly selected release" would make sense.
-
@Curaga: @mocore brings up a good point regarding sources and build scripts
For the time being, at least until we have a solid source repository/archive, please LEAVE source directories when disposing of antique versions.
x86/x64: ./release/src and ./tcz/src
arm/etc: ./releases/RPi/src and ./tcz/src
some of the reasoning wrt to build scripts quoted in the below link
https://forum.tinycorelinux.net/index.php/topic,27148.msg174366.html#msg174366
just to make the logic behind this reasoning it explicit ( idk if this (useful info) is in the fqa or wiki but imho it should be! )
If you don't see the source it probably has not changed since the previous release, so look in the download area of previous releases.
---> so N.x/ version directory's do not necessarily contain all relevant data <----
extensions might be copied from previous version
leaving build scripts
EG you can not " look in the download area of previous releases" if it has been deleted ::) ( see also : https://forum.tinycorelinux.net/index.php/topic,18712.msg175870.html )
.... perhaps im missing the point and this is desirable outcome
... but i struggle to see the benefit of repo purge
... archiving (eg copy to some other dir like /unsuported/*.x ) i understand deletion seams nu-advantageous
fwiw
(imho) it seams a shame to loose the work/data of the tiny core team and community
however useful(or not) old versions might be to run on old hw ect
im not shore there is any disadvantage to keep the data available (even if not in `working` mirror/dir structure ) for historical reference
???
... i dont set out to "go against the grain" , it just seams that often that is the way things are :-[
-
@CNK: If you would like a hard copy, please send me a private message with your full name and mailing address along with the version(s) of TCL you want to have shipped and I can send you a quote based on the required media size and shipping from the States. Please include a note as to whether or not you require source code files as this will definitely affect media size!
Thanks, but that's probably more trouble for you than uploading them to the Internet Archive which is what I've had in mind to do all along - just limited by internet access. Then I don't need everything myself, I can just set the repo to archive.org URLs in old TC versions.
There is no dedup between versions. Not that it would affect anything, as our mirrors do their own thing, and the space usage affects them as well.
Well Rsync can copy symlinks, so I'm not sure why it has to be that way. If that's just how distro mirrors work traditionally then that's unfortunate.
My 2 cents,
I guess you do not need "all" older versions.
I just got v15 working on a board that launched 2005 so I kind of feel V15 covers most post 2005 hardware.
With CentralWare succeeding to get the oldest practically functional version to live (v2) that should either be enough to cover hardware until 2005 OR maximally 1 other "smartly selected release" would make sense.
I want to be able to get extensions for any version that was installed before, and try extensions that weren't carried forward to later versions. A lot of TC4 extensions (next to go) aren't available for later TC versions. If others don't care about that, OK. I was hoping to sort it all out for myself, but I failed. So in the end maybe it's just my bad luck and no point discussing it further at this point. I'm pretty grumpy about it now anyway.
-
Hi CNK
I just finished creating backups of TC4 - TC8 x86 and x86_64
from distro.ibiblio.org/tinycorelinux. I currently have TC1 - TC8.
In case someone is interested in the storage required for this:
tc@E310:/mnt/sdb1$ for C in `seq 1 8`; do du -hs "$C".x/; done
2.3G 1.x/
8.4G 2.x/
14G 3.x/
26G 4.x/
9.1G 5.x/
13G 6.x/
15G 7.x/
16G 8.x/
tc@E310:/mnt/sdb1$ calc 2.3+8.4+14+26+9.1+13+15+16
103.8
tc@E310:/mnt/sdb1$
This is a breakdown of storage used just for tcz/ (files only), tcz/src/, and tcz/backup/.
Add in release_candidates/, release/, and archive/ and you have another 500M to 3.5G.
x86:
tcz/=8.6G tcz/src/=4.9G tcz/backup/=1.4G x86 Ver. 4
tcz/=2.5G tcz/src/=1.5G tcz/backup/=954M x86 Ver. 5
tcz/=2.6G tcz/src/=1.2G tcz/backup/=1.6G x86 Ver. 6
tcz/=3.3G tcz/src/=942M tcz/backup/=1.2G x86 Ver. 7
tcz/=3.5G tcz/src/=182M tcz/backup/=754M x86 Ver. 8
tcz/=3.9G tcz/src/=514M tcz/backup/=887M x86 Ver. 9
tcz/=4.6G tcz/src/=396M tcz/backup/=1.9G x86 Ver. 10
tcz/=4.1G tcz/src/=565M tcz/backup/=1.5G x86 Ver. 11
tcz/=4.1G tcz/src/=447M tcz/backup/=332M x86 Ver. 12
tcz/=4.3G tcz/src/=260M tcz/backup/=385M x86 Ver. 13
tcz/=5.2G tcz/src/=290M tcz/backup/=1.2G x86 Ver. 14
tcz/=5.3G tcz/src/=379M tcz/backup/=1.5G x86 Ver. 15
x86_64:
tcz/=374M tcz/src/=343M tcz/backup/=25M x86_64 Ver. 4
tcz/=1.1G tcz/src/=1.4G tcz/backup/=481M x86_64 Ver. 5
tcz/=1.6G tcz/src/=1.5G tcz/backup/=1.5G x86_64 Ver. 6
tcz/=2.7G tcz/src/=2.3G tcz/backup/=2.2G x86_64 Ver. 7
tcz/=3.4G tcz/src/=2.4G tcz/backup/=1.8G x86_64 Ver. 8
tcz/=4.5G tcz/src/=2.4G tcz/backup/=2.7G x86_64 Ver. 9
tcz/=5.2G tcz/src/=2.3G tcz/backup/=2.7G x86_64 Ver. 10
tcz/=5.6G tcz/src/=3.6G tcz/backup/=2.2G x86_64 Ver. 11
tcz/=6.6G tcz/src/=2.5G tcz/backup/=1.4G x86_64 Ver. 12
tcz/=7.3G tcz/src/=1.4G tcz/backup/=2.0G x86_64 Ver. 13
tcz/=8.4G tcz/src/=3.3G tcz/backup/=3.1G x86_64 Ver. 14
tcz/=8.4G tcz/src/=3.9G tcz/backup/=3.2G x86_64 Ver. 15
If anyone wants to download a repo from a mirror:
# Copy repos using wget.
# ipv4 only, quiet, recurse, no clobber, no parent, reject index.html files, no host directories, ignore NUMBER remote directory components
# The --cut-dirs prevents wget from recursing up the tree.
tc@E310:/mnt/sdb1/8.x$ wget -4 -q -r -nc -np -R "index.html*" -nH --cut-dirs 2 http://distro.ibiblio.org/tinycorelinux/8.x/x86/
As soon as it finishes, run this and make sure it returns zero:
tc@E310:/mnt/sdb1/8.x$ echo $?
0
If it does not return zero, this will provide a list of which files were problematic:
# Find download errors:
# ipv4 only, no verbose, recurse, no clobber, no parent, reject index.html files, no host directories, ignore NUMBER remote directory components
# The --cut-dirs prevents wget from recursing up the tree.
tc@E310:/mnt/sdb1/8.x$ wget -4 -nv -r -nc -np -R "index.html*" -nH --cut-dirs 2 http://distro.ibiblio.org/tinycorelinux/8.x/x86/ 2>&1 | grep -v "index.html.tmp"
-
Thanks for that Rich, based on that size I should be able to set up a mirror for old versions myself on free Oracle Cloud storage, and maybe someone else can upload the old files that have gone offline to it. I'm already in the middle of something at the moment, but I'll see if I can get something set up this week (probably optimistic).
-
Hi Rich.
In case someone is interested in the storage required for this:
tc@E310:/mnt/sdb1$ for C in `seq 1 8`; do du -hs "$C".x/; done
2.3G 1.x/
8.4G 2.x/
14G 3.x/
26G 4.x/
9.1G 5.x/
13G 6.x/
15G 7.x/
16G 8.x/
tc@E310:/mnt/sdb1$ calc 2.3+8.4+14+26+9.1+13+15+16
103.8
tc@E310:/mnt/sdb1$
Why is TCL4 such an outlier? It would be interesting to know the history behind that.
-
Hi Rich.
...
Why is TCL4 such an outlier? It would be interesting to know the history behind that.
yes, i was wondering the same thing but hadn't posed the question yet. Thanks @GNUser!
-
Hi GNUser
I would say there was a lot more participation when it
came to extension submissions.
Extension counts:
TC4=4268 TC8=2431
TC4 top 25 submitters:
1089 Arslan S.
404 bmarkus
334 juanito
305 Jason W
293 Curaga
144 robc
125 gutmensch
78 aus9
77 AbNoRMiS
67 vinnie
64 TaoTePuh
60 solorin
59 jls_legalize <jlslegalize@gmail.com>
53 jlslegalize@gmail.com
47 Daniel Barnes
44 AmatCoder
41 andriscom
37 juanito, Arslan S.
37 jls_legalize (jlslegalize at gmail dot com)
36 jls_legalize (unsenepopiu at tin dot it)
35 AlabamaPaul
25 jls_legalize <unsenepopiu at tin dot it>
25 dentonlt
23 SvOlli (using tcbuild
21 Kingdomcome
TC8 top 25 submitters:
618 bmarkus
517 juanito
202 Curaga
134 Arslan S.
106 Jason W
88 andyj
44 gutmensch
34 madRat
31 justincb
29 aus9
28 jlslegalize@gmail.com
25 robc
24 polikuo
21 gordon64
18 jls_legalize <jlslegalize@gmail.com>
17 gordons64
17 coreplayer2
17 Onyarian
16 roberts
16 rhermsen
14 dentonlt
13 oeai
13 malbo
12 Misalf
12 Daniel Barnes
Individual extensions appeared to be larger.
TC top 25 extensions by size:
-rw-r--r-- 1 tc staff 441M Oct 22 2011 /flightgear-data.tcz
-rw-r--r-- 1 tc staff 159M Mar 20 2011 /libreoffice.tcz
-rw-r--r-- 1 tc staff 152M Sep 22 2010 /openoffice3.tcz
-rw-r--r-- 1 tc staff 152M Jun 9 2012 /gcompris.tcz
-rw-r--r-- 1 tc staff 131M Jan 13 2013 /fluidsynth-soundfont.tcz
-rw-r--r-- 1 tc staff 128M Apr 29 2013 /bullet-docs.tcz
-rw-r--r-- 1 tc staff 122M Oct 3 2011 /hedgewars.tcz
-rw-r--r-- 1 tc staff 122M Apr 29 2010 /oo2.tcz
-rw-r--r-- 1 tc staff 110M Dec 10 2011 /kdeartwork.tcz
-rw-r--r-- 1 tc staff 103M Apr 13 2013 /lazarus.tcz
-rw-r--r-- 1 tc staff 97M Jun 3 2010 /wormux.tcz
-rw-r--r-- 1 tc staff 81M May 9 2010 /openclipart-svg.tcz
-rw-r--r-- 1 tc staff 74M Apr 29 2010 /openlierox.tcz
-rw-r--r-- 1 tc staff 65M May 7 2011 /blobwars.tcz
-rw-r--r-- 1 tc staff 65M Jun 13 2011 /sun-jdk.tcz
-rw-r--r-- 1 tc staff 65M Aug 26 2012 /qt-4.x-htmldoc.tcz
-rw-r--r-- 1 tc staff 63M Mar 5 2011 /kdeedu.tcz
-rw-r--r-- 1 tc staff 60M Dec 10 2011 /kdegames.tcz
-rw-r--r-- 1 tc staff 57M Oct 8 2011 /plt.tcz
-rw-r--r-- 1 tc staff 55M Aug 26 2012 /qt-4.x-doc.tcz
-rw-r--r-- 1 tc staff 51M Nov 25 2010 /erlang.tcz
-rw-r--r-- 1 tc staff 51M Jul 3 2012 /ati-fglrx.tcz
-rw-r--r-- 1 tc staff 49M Jun 13 2011 /sun-jre.tcz
-rw-r--r-- 1 tc staff 48M Dec 10 2011 /kde-wallpapers.tcz
-rw-r--r-- 1 tc staff 47M Apr 13 2013 /fpc.tcz
TC8 top 25 extensions by size:
-rw-r--r-- 1 tc staff 137M Jun 10 2017 /libreoffice.tcz
-rw-r--r-- 1 tc staff 123M Mar 7 2017 /lazarus.tcz
-rw-r--r-- 1 tc staff 81M Mar 7 2017 /mono.tcz
-rw-r--r-- 1 tc staff 77M Mar 7 2017 /qt4-htmldoc.tcz
-rw-r--r-- 1 tc staff 65M Jun 5 2017 /firefox-ESR.tcz
-rw-r--r-- 1 tc staff 65M Sep 16 2017 /clang.tcz
-rw-r--r-- 1 tc staff 60M Mar 7 2017 /openjdk-8-jdk.tcz
-rw-r--r-- 1 tc staff 57M Mar 7 2017 /qt4-doc.tcz
-rw-r--r-- 1 tc staff 54M Mar 7 2017 /seamonkey.tcz
-rw-r--r-- 1 tc staff 50M Mar 7 2017 /fpc-src.tcz
-rw-r--r-- 1 tc staff 49M Nov 8 2016 /qemu-all.tcz
-rw-r--r-- 1 tc staff 47M Jun 5 2017 /wine-gecko.tcz
-rw-r--r-- 1 tc staff 45M Mar 7 2017 /sun-jre7.tcz
-rw-r--r-- 1 tc staff 44M Jun 5 2017 /wine-mono.tcz
-rw-r--r-- 1 tc staff 44M Mar 7 2017 /chromium-browser.tcz
-rw-r--r-- 1 tc staff 43M Dec 1 2017 /nvidia-384.90-4.8.17-tinycore.tcz
-rw-r--r-- 1 tc staff 43M Mar 7 2017 /openjdk-8-jre.tcz
-rw-r--r-- 1 tc staff 38M Mar 7 2017 /openjdk-7-jre.tcz
-rw-r--r-- 1 tc staff 37M Dec 1 2017 /nvidia-384.90-cuda-4.8.17-tinycore.tcz
-rw-r--r-- 1 tc staff 37M Mar 7 2017 /fpc.tcz
-rw-r--r-- 1 tc staff 37M Mar 7 2017 /db-doc.tcz
-rw-r--r-- 1 tc staff 37M Mar 7 2017 /go.tcz
-rw-r--r-- 1 tc staff 35M Jun 10 2017 /libreoffice_lang.tcz
-rw-r--r-- 1 tc staff 35M Mar 7 2017 /samba3.tcz
-rw-r--r-- 1 tc staff 34M Apr 19 2017 /wine.tcz
-
Final Diagnosis:
@CNK suggests uploading 2.x through x.x to archive.org. This is a painfully slow process (though if arrangements were made, a physical drive could probably be mailed to them and possibly someday that content would become available through their system) but thus far testing their history with repo.tinycore and distro.ibiblio.org/tinycore none of the actual binary content (.tcz files, for example) looks to have ever been crawled and saved. This IS, however, the closest to a drop-in replacement where /opt/tcemirror could possibly be updated to utilize if necessary. Additionally, there's really no telling whether or not archive.org is going to stand the test of time.
GitHub - this direction is much, much faster than Archive.org, SEEMS so far to be unlimited in space and speed, but isn't overly drop-in friendly "as is"
Google Drive(s) - again, much faster than Archive, but not drop-in friendly at all.
Free web hosting services - so far I have not found a service with the amount of space and speed needed to make it worthwhile
PLAN "F" - THE OTHER: Don't hold your breath yet as I am not in a position yet to make promises, BUT I have one effort in mind that might make a lot of this (including NEW releases) so much more lean and efficient while utilizing third party systems such as GitHub by merely making a few CORE logic changes with the tce* files. This will take a bit to experiment with.
-
PLAN F : INQUIRY
@Rich @Curaga and crew, is there any reason you guys can think of as to why Ibiblio doesn't mirror the "entire" release/src content?
Example: http://repo.tinycorelinux.net/14.x/aarch64/releases/RPi/src/busybox/
Versus: https://distro.ibiblio.org/tinycorelinux/14.x/aarch64/releases/RPi/src/busybox/ (empty)
../toolchain is wonky, too
Now that I'm aware of this I can adjust our mirror accordingly (ours is empty, too - domino effect) but I figured I'd ask :)
-
Hi GNUser
I would say there was a lot more participation when it
came to extension submissions.
Extension counts:
TC4=4268 TC8=2431
Hi Rich. Thank your for piecing this together. Yes, more numerous contributors sending in more and bigger extensions would certainly explain why TC4 was such an outlier.
TCL is still here and doing fine, so it obviously still has a critical mass of developer/contributor manpower.
Even though TC4 may represent a peak in extension submissions, my prediction is the future will bring similar or taller peaks. As other distros become increasingly complex, TCL will become increasingly appealing to users who desire to understand and control their OS.
-
@CNK suggests uploading 2.x through x.x to archive.org. This is a painfully slow process
I'm not sure what you mean by this. Slow servers? Or I've seen people reference the clunky uploader interface but others seem to get around that by uploading ZIPs which get expanded into directories (example (http://archive.org/download/mame-0.221-roms-merged/elecbowl.zip/) - bigger ZIP links that I know are still broken).
but thus far testing their history with repo.tinycore and distro.ibiblio.org/tinycore none of the actual binary content (.tcz files, for example) looks to have ever been crawled and saved.
That's their Wayback Machine project, which often doesn't save everything. Submitted items are different, eg. people submitting 66GB archives of MAME ROMs (https://archive.org/details/mame-0.221-roms-merged).
This IS, however, the closest to a drop-in replacement where /opt/tcemirror could possibly be updated to utilize if necessary.
That's the whole point of it to me. With GitHub, Google Drive, etc. no good for using as repo settings in TC itself, I don't see how uploading them there achieves much.
Free web hosting services - so far I have not found a service with the amount of space and speed needed to make it worthwhile
Oracle Cloud can store 200GB for free. I've already started setting up a VPS there but I'm picky about avoiding Systemd and am battling to get Devuan installed there at the moment - three 'bricked' virtual servers and counting... Real hardware is so much easier.
-
PLAN F : INQUIRY
@Rich @Curaga and crew, is there any reason you guys can think of as to why Ibiblio doesn't mirror the "entire" release/src content?
Example: http://repo.tinycorelinux.net/14.x/aarch64/releases/RPi/src/busybox/
Versus: https://distro.ibiblio.org/tinycorelinux/14.x/aarch64/releases/RPi/src/busybox/ (empty)
../toolchain is wonky, too
Now that I'm aware of this I can adjust our mirror accordingly (ours is empty, too - domino effect) but I figured I'd ask :)
This dir appears to contain absolute symlinks, when they should be relative. Paul?
-
does anyone have or have_access_to ibiblio stats regarding repository activity?
for example, traffic/downloads/etc at this directory level(and perhaps below)?
https://distro.ibiblio.org/tinycorelinux/4.x/x86/archive/
if this data is available it would give a better understanding of the necessity or lack_thereof of more specific offerings.
also, how are/were releases 1.x/2.x/3.x removed from ibiblio? does this happen automatically when they are removed from http://repo.tinycorelinux.net/downloads.html ?
-
Hi gadget42
... also, how are/were releases 1.x/2.x/3.x removed from ibiblio? does this happen automatically when they are removed from http://repo.tinycorelinux.net/downloads.html ?
Maybe ibiblio was mirroring our repo?
If mirroring is a literal term, then what happens on their site would
be a reflection of what happened on our site:
We add a file, they add that file.
We update a file, they update that file.
We remove a directory, they remove that directory.
I'm not involved in this aspect, so this is just guesswork on my part.
-
This dir appears to contain absolute symlinks, when they should be relative. Paul?
Not intentional
-
@Rich: The Ibiblio project was likely signed up for quite some time ago (very likely they're found in mirrors.tcz) and it's one we found to be fast and frequently updated with TCL and a number of other useful repositories so we tend to lean on them instead of repo.tinycore and other master resources, but yes, when we add/remove something on our repo.tinycorelinux.net server, they'll reflect those changes usually within 24 hours or so, many times much less than that it seemed.
@Curaga @Paul_123: We just found something odd and passed it along; I have not tested 15x as 14x was our focus group for a server test, being seen a little more as "tried and tested." If memory serves, 13.x only has KERNEL source; busybox and toolchain don't exist on repo - how far back I don't know; that was Béla's wheel house back then if I'm not mistaken and may just not be posted or may be elsewhere.
@CNK: I'm not sure what you mean by this. Slow servers?
Yes, very slow both for uploading and downloading. Fear not, though... a functional method will present itself in the end!
Oracle Cloud's 200GB of "Block Volume Storage" does not sound, from what I just read, as though it would be useful for drop-in functionality (ie: could be made to work with apps or tce-load) BUT you also note VPS and SystemD so maybe there's a web based functionality I didn't see in their Always Free tier.
-
@CNK: I'm not sure what you mean by this. Slow servers?
Yes, very slow both for uploading and downloading. Fear not, though... a functional method will present itself in the end!
Oracle Cloud's 200GB of "Block Volume Storage" does not sound, from what I just read, as though it would be useful for drop-in functionality (ie: could be made to work with apps or tce-load) BUT you also note VPS and SystemD so maybe there's a web based functionality I didn't see in their Always Free tier.
Ah right, well I have downloaded a lot from the Internet Archive but my internet's so slow usually, especially from overseas servers, that it doesn't make much difference. Someone might have uploaded the TC3 files to it at Tiny Core Linux ver. 3.x Full Archive (https://archive.org/details/tinycore_3.x), but since that's offline I'm just going from the description that was in a web search result: "Its contains all Tiny Core v 3.x data files - ISO, repository, source files, etc."
As for Oracle Cloud, the block storage allows you to create a drive that is used by a VPS, but there are quite a few hoops to jump through. Anyway I gave up on avoiding Systemd (I think the cloud-init system it uses requires Systemd), it's now stock Debian and downloading TC 4 - 10 extension repos via Rsync. When it's done I'll set up a way for someone here to (hopefully) upload the repos that are offline.
-
Do you gain some size of compressing the files (like iso) before uploading them?
Archiving files can be stored compressed.
-
Do you gain some size of compressing the files (like iso) before uploading them?
Archiving files can be stored compressed.
ls -lh /mnt/data/oldtc/4.x/x86/release/CorePlus-4.7.7.iso
-rw-rw-r-- 1 debian debian 65M Sep 15 2013 /mnt/data/oldtc/4.x/x86/release/CorePlus-4.7.7.iso
xz -z -c CorePlus-4.7.7.iso > /tmp/CorePlus-4.7.7.iso.xz
ls -lh /tmp/CorePlus-4.7.7.iso.xz
-rw-rw-r-- 1 debian debian 64M Oct 23 23:12 /tmp/CorePlus-4.7.7.iso.xz
Since the initrd and squashfs files inside are already compressed, there's not much to be gained from compressing the ISOs.
There's probably more to be gained from compressing all the text files in the repo. That could be done automatically by putting everything on a compressed filesystem, but I don't want to try setting that up at this point.
For my archive I've decided to exclude the /archive, /release_candidates, and /tcz/backup directories, so I just keep the final state of each version. The actual command I'm using with Rsync is:
rsync --progress --skip-compress=tcz,gz,bz2,xz,zip,rar,7z,iso --chmod=a+r -p -h -l -z -t -r --exclude='*/archive/*' --exclude='*/release_candidates/*' --exclude='*/backup/*' rsync://mirrors.dotsrc.org/tinycorelinux/[1-9][0.]*x oldtc
Looks like it should be done by the morning. The web server is running here:
http://130.162.192.79/oldtc/
It'll get a domain name when I get around to doing the DNS settings, and I'll set up an FTP server too.
-
Is TCL's philosophy of minimalism going the wrong way!?
Yes, it goes wrong way many years ago.
Removing tce extensions (copy2fs is too complicated for newbies, tce and tcz directory would be simpler)
Prohibition of posting links of extensions (puppy linux forum don't have this problem)
Removing 1/2/3/ repo (you should rent commerial server for 1/2/3) tinycorelinux.com
Slitaz has its own iso generator
Standard iso should have web browser out of the box.
TinyCore and Core Plus should have desktop extensions inside core.gz
rootfs.gz and modules.gz should be only in microcore
Linux community suffers from lack of minimalistic web browser, office editor, xserver, fast booting/hibernation, gpu support/widescreen, eyecandy minimalistic window manager, complicated instalation.
-
Yes, it goes wrong way many years ago.
...
Linux community suffers from lack of minimalistic web browser, office editor, xserver, fast booting/hibernation, gpu support/widescreen, eyecandy minimalistic window manager, complicated instalation.
+1 ; LINUX (with millions of genial brains?) missing a SMALL web-browser capable of basic/simpler Javascript (need by banking logins)
+2; firmware "stupid" /greedy manufactures (HP, DELL, ASUS) not care about linux, make many not-functional keyboards, power consumption huge vs. M$winbloat-10/11
+3; stupid huge GPU-blobs for AMD CPU firmware; LLVM of 100+ MB for mesa? O.M.G.
+4; GTK3/4 big dependency for even simple editors, file managers?
+5; big Xorg, need for UEFI; almost nobody could buy today a PC with BIOS.
FYI: Why you use an OS (Linux, Max, Windows) for?
1.For employees, the employer provides the tools (computer with its policy restrictions).
2. For entrepreneurs (with a business to run) you use OS with strong security (not toys!).
3. So yeah, Linux could be for personal/community hobbies, for games and wasting spare time. <- Me here.
-
+4; GTK3/4 big dependency for even simple editors, file managers?
Hi nick65go. There are several GUI text editors and file managers that don't require GTK or qt. xfe file manager and xfw text editor immediately come to mind. I've been using xfe for years and have been extremely happy with it.
-
GNUser, thank you. I am very aware about many alternatives ;) , and indeed I used xfe & co. But I am upset with the rest.
I was forced to use UEFI from January 2016 (near latest laptop) until 2023. It allows BIOS simulation but then it saw just 4 GB RAM instead of 8 GB RAM. Also HP (f**k them!) firmware has bugs: dmesg shows that it does not allow PCI ACPI low SATA power management, few Fn-keys (video luminosity +/-) not reconised, so I need to map them to scripts to use them etc. But in Windows 10 all was OK. Because extra heating, these bugs prematury destroyied my APU /GPU + the cooling pasta and now the latop runs noisy. In the end I bought a new laptop (again UEFI +Win11). :P
But there are other linux not solved problems , in general: huge CPU microcode to load initialy, huge GPU firmware for AMD kernel drivers. Then Xorg ask for its 3D drivers which depend on LLVM (100+MB). :(
Now, even without all those (firmware + drivers big size), I need a secure browser for banking, so firefox is mandatory. But this sucker asks for GTK3 and all its dependency hell. :(
Summary: it does not help me too much if FEW software are small, but mostly all others have huge demands.
Today I have no problem because I have a lot of RAM (32 GB) +SSD (1000 GB) +CPU (13th gen) for shiny/bloated Win11. But I am still afraid about extra heating because HP firmware not suitable for linux (distroing my investment/laptop).
My observation is that LINUX (not necesary Tinycore) goes in the wrong direction for me. And TC must keep aligned with increased kernel, bloated software (asking for biger libc, not compiling old software, etc). And today Win11 is 10x over my needs in Security + Functionality: Edge/Firefox + 7zip + Notepad++ , MSOffice/LibreOffice and VLC covers 110%. The incentives to switch back to Linux are constantly dimishing. I like linux and minimalism but sometime the price is too harsh.
-
Looks like it should be done by the morning. The web server is running here:
http://130.162.192.79/oldtc/
It'll get a domain name when I get around to doing the DNS settings, and I'll set up an FTP server too.
All done. See the announcement thread (https://forum.tinycorelinux.net/index.php/topic,27331.0.html)
-
First CNK thanks for this. If there was a thankyou button inwon”d have used it.
And others thanks for the ramblings to get tot this point.
Second, to counterweight the comments of neonix,
I very much like the minimalistic approach.
I like the concept of “minimal out of the box” with application browser that allows app install for many needs.
It is very true that without installing extra applications one can not do much with tinycore, but actually that is the function of an os. “Be just that”.
To bring tinycore to become a useabale desktop one indeed needs to install applications, but the process to that I consider reasonably smooth.
The big advantage of keeping it minimal is the ability to have a full functional very small footprint Linux system with latest kernel and latest gcc.
For me that makes tinycore the ideal base to create a “luxerous plc”. Like arduino it allows to create a low ram, low cpu board and than adds the advantage of having a full functional Linux on it running from ram (not wearing flash storage). Ideal for small tasks. I really like that I don’t have to carry a full fetched multi gigabyte os to achieve that.
Also… I’m tuning my tinycore to be super stable. (Ref to thread about making sure /var/log/wtmp rotating). I’m very happy I don’t have to do that towards a much bigger package.
So… yeah… it’s minimal. It’s tiny.. for me that is the beauty. That is the “reason to choose tinycore”. Example the DSL 2024 project is going in a direction of “minimal but more complete”. It’s there. No reason for tinycore to do the same. I feel each projects has its focus. That focus gives it its value for a specific range of users. I would really advocate to keep that focus. That will secure a good plurality of choices for those who want to select a distribution that fits their needs.
A bit of a long post. But I did feel the need to post a counter word.
-
@nick65go congratulations on the new laptop! which model number did you purchase?
-
searched the forum for "tinycore is a toolkit", got 4 hit, seem legit, indeed, fantastic!
awesome crew, thanks to all who do!
does that qualify as a Haiku?
as in: https://en.wikipedia.org/wiki/Haiku
but you could also enjoy: https://en.wikipedia.org/wiki/Haiku_(operating_system)_
20241025-0355am-cdt-usa-modified: added content and links
-
@nick65go congratulations on the new laptop! which model number did you purchase?
laptop model: HP 17-cn34, with 17 inch display, 32 GB RAM, 500 GB SSD, Intel core i5-1335U (an APU=CPU+GPU, CPU=13th gen low power, GPU=Intel Iris Xe), software Windows 11 Pro + MS Office 2021 Pro (perpetuate license for life), price 779 euros (on October 2023).
something like this, for details:
APU: https://en.wikipedia.org/wiki/Raptor_Lake#Raptor_Lake-U (https://en.wikipedia.org/wiki/Raptor_Lake#Raptor_Lake-U)
laptop: https://www.amazon.de/HP-17-Windows-Funkmaus-Notebooktasche/dp/B096S8L2ZG/ (https://www.amazon.de/HP-17-Windows-Funkmaus-Notebooktasche/dp/B096S8L2ZG/)
PS: It is not Tiny Core TEAM fault for the bad HP/DELL/ASUS firmware in my PC/laptops. Unfortunately I buy laptops using public/EXTERNAL specifications (CPU/RAM/SDD, price). IF/when the UEFI firmware is proper for Linux kernel then I prefer linux instead of Windows11. But was seldom happen for me until now.
-
@nick65go thanks for the information. i visited that amazon link you provided and saw this
Product description
Note:
This device is a new product, which has been optimised for you in cooperation between manufacturer and seller.
The device has been modified and optimised - it is already configured and installed.
All required drivers and Windows updates are installed and the device is delivered completely free of advertising software.
Just turn it on and get started!
Legal Disclaimer
Disclaimer does not exist.
yikes! sounds like something Edward Snowden warned us about!
https://en.wikipedia.org/wiki/Edward_Snowden
-
@gadget42: This toy (was new, now it is one year old) has no personal documents on it (they lay in on-demand external USB, for offline use) is for my ground play (learning, entertainment). So any agency of 3 or more letters (CIA, FBI, NSA, bla bla) from USA, UK, EU, China, Russia, (or other with imperialist dreams) ... are welcome to waste their time to spy my ass.