Tiny Core Linux
General TC => General TC Talk => Topic started by: nick65go on October 22, 2014, 03:43:49 PM
-
I want to underline that I like very much tiny-core. Few distributions rise to his implementation of technical know-how AND "simplicity". But maybe few things could be trimmed down ...
So, I discovered sabotage distribution: https://github.com/sabotage-linux/sabotage
The concepts I like about it are:
- compiling the kernel without using perl (it was possible for few years).
- static link the core tools (busybox); less exposure to attacks, easier chroot/sandbox on the fly.
(would you like chroot from 64 bits into 32 bits, run sandboxed browser, or install 32 bits tcz aka syslinux)
- smaler auxiliar libs: (libnl-tiny?); libnl-tiny is known to work without issues with at least: iw, wpa-supplicant, kismet, aircrack-ng, libpcap
- simple package and build manager, ala archlinux pacman AUR repository; so both the core AND the tcz extensions could be scripted if you are security concerned about alien (not exposed) tcz recipes..
I like the freedom of (better) alternatives:
- to use llvm vs gcc (gcc is surviving because it is still the only one who can compile the full kernel)
- smaller C libs, like musl (not uclib) vs glibc.
- smaller core tools (like toybox vs busybox partial/total replacment ?). Imagine even a static compiled busybox (with musl) and part of tinycore rootfs64.gz is the same as rootfs32.gz, because any CPU (32/64 bits) can run same code. core.gz= commonFs.tools +libs.spec+ modules.
I am just skimming the top of the iceberg...would you like a recipe for a controlled build firefox?
https://github.com/sabotage-linux/sabotage/blob/master/pkg/firefox
-
IMHO I think that the (tiny-)core success could arrive just from the FINAL product (small and modular).
The analogy with cellphone: does not matter how complicated or huge resources you use (manpower, big factories) if the final product is optimized (a tiny cellphone/tablet) for large consumer (linux user).
The manufacture has no intention to explain to final user the process of production, the recipes and pieces used to build, or the specs of the pieces. Of course you can smash it, look inside and google etc.
The emphasis in tiny-core is NOT on self-sufficient (re-build from himself like Phoenix bird, sorry like aboriginal Linux). Of course you can dismantle it in pieces and rebuild again. Or read the wiki pages and hunt for strings in the forum etc. Or said after me: compile the kernel, and busybox, read and learn the smart home- made scripts (init, mount shuashfs tcz, etc) and be happy.
But this statement is true, it is not a vast interest to provide a recipe of it:
- a list with links to all virgin sources used (kernel, busybox, patches)
- a tarball with specific home-made scripts, for core and tcz extensions.
- an automated script to rebuild it on the fly, if you have willing, time, resources CPU/RAM, knowledge.
- a know-how philosophy, about why use some options against others; like eglib -> glic but not use uclib or musl as a base C library; why libz and not lzma/xz for compression of squash modules; why some kernel modules build-in, etc
Of course the developers KNOW all these, because they did tested various options (but not publicly shared the benchmarks) before settle for some options. Like it is said, use it as it is, or switch to another distribution.
Anything which grows way-out of it originally declared scop (gcc, systemd, pulseaudio) is as cancer by definition, so should by avoided (fork), if you can.
I like this tiny-core "distribution", and I would like to contribute to improve it, but unfortunate I am not a programmer, neither a developer. I am just an end-user learning linux and I try avoid the bloat.
I search for things to improve linux hobby; some of them are just old news, only news for me; but because I have found no explanation here in the forum, I try to expose them. And maybe other more knowledgeable people will implement them, or at least say why are not suitable.
-
"Like it is said, use it as it is, or switch to another distribution."
Yes... well... that's how we arrived at this mess:
https://en.wikipedia.org/wiki/List_of_Linux_distributions
Look at that image...
The *insanity* of crowds in this instance -- no single person would design such a thing.
So we have yet to establish a core upon which everything else can be built!
If we had it, I think it would explode in adoption and contributions, and we would see more interesting projects than useless new distros.
I think the idea of a base/core distro, which can be built upon, should be the goal of TC.
Especially now as dCore is becoming stable and practical, then it can replace a Debian distro, but be much smaller, and have more use-cases by it's great performance and small size.
I think we need to focus on making dCore as complete as possible -- a purpose not at all interfering with the improvements of the core. Though such a different core as Sabotage Linux would interfere with all the Debian packages (I would expect).
But if we had our own build-system, like Gentoo or Arch, we could certainly use all kinds of crazy cores if we would like to.
I think such a unified core distro would require to have an easy build-system.
TC is not overly minimalistic, and you can still get a regular build-environment with TC quickly, without tinkering (just downloading packages).
It's a sound, yet extremely minimal distro.
And I think we can have a beautiful unified core from Micro Core / dCore, without forking -- just extending.
Instead of focusing what tools we could switch out to make it even smaller and more performant, we should focus on removing limitations / expanding the limits.
Like how we could have dCore on Android phones!
Now that's a huge problem to tackle, yet Ubuntu and Arch (and others?) are expanding quickly into the mobile space.
So we should just be able to run a droid-phone-install.sh script, and have drivers fetched for the phone automatically.
Just some terminal-lines flashing by, and then -- BAM! A graphical futuristic touch interface! hehe...
This relies on the manfacturers releasing their source-code, and providing binary blobs for other drivers.
You may not see immediate benefits from running a pure Linux distro on a phone, nor do Android smartphone manufacturers see it. But it's entirely possible to create superior user interfaces in a regular distro (though not really from existing applications).
Well, in the future there won't be any difference, there will just be Linux, as there are quite a lot of companies interested in this.
Too bad that there isn't a more open and unified effort, but at least we have Linaro:
http://www.linaro.org/
Commercial entities tend to not be as idealistically guided... obviously in favour of money, or some direct results.
And don't think the manufacturers are oblivious to the real Linux world, and free open software, look at this link:
http://www.cnx-software.com/2014/09/18/mediatek-releases-linux-source-code-for-android-one-smartphones/
They just need more incentive, and be pushed more from the FOSS community. The FOSS world is after all much older and much bigger than some silicon company, or smartphone manufacturer.
I see it as an titanic slumbering chthonic entity, of pure energy, waiting for the moment to pounce.
Back on subject: :)
To have a core built entirely from scripts would be great. It would remove some limitations, and we would have more eyes on the most basic system. So building everything from scratch would be one command away, instead of fetching everything yourself.
Awesome stuff for sure.
But I'm very focused on the unification of GUI tools now, something which would make all this much more easy, and also make it appealing to new and learning users.
More personal:
I hope you are at least learning scripting (bash), as if more people knew and liked to work with scripts, we would have more eyes in the project.
And surely have a great future Linux developer, as you already seem to think like a developer in some ways :)
You have learned well, keep going!
-
i like that the pkg mgr is an awk script =]
"sabotage-linux/butch pkgmgr ( in shell/awk)" @ https://forum.tinycorelinux.net/index.php/topic,27217.0.html
-
Necromancy of an old topic. Time is passing by and our goals and priorities are changing.
1. I would prefer ARM architecture (most energy efficiency), but unfortunatly most Applications I "need/want" are for x86, so the future is for x86_64[_v3] appls colection, from year 2025+.
2. The base LIB is musl (not libc) because is smaller (means more secured).
3. X-org as implementation of X-server is dying, so future could be Wayland (more secured) of any impementation.
4. Then, for the few app that we are not often comuting between, we could just use JWM /FLWM.
5 .My ideal (for now) linux system will start with a GUI like FLTK; see that it has all wigets that the big/bloated brothers (GTK, QT) have https://www.fltk.org/shots.php
6. And of course a small (less RAM used) browser like a nestsurf, compiled with FLTK interface (not GTK). It should allow Java-script ondemands.
7. Maybe NOT apps wtitten in Rust, maybe not init system-d, etc.
For now the big demanding is X-org + mesa-3D-drivers +firmware (GPU/CPU) + Firefox (GTK3+) + audio/video HD decoders => the minim productive system, or for entertainment is very demanding; not so tiny, even if we start with tiny*.*
But there there are signs that (a part of) world is moving in that direction...
FLTK 1.4 Released With Wayland & HiDPI Display Support
FLTK 1.4 Released With Wayland & HiDPI Display Support - Phoronix (https://www.phoronix.com/news/FLTK-1.4-Released)
-
our goals and priorities are changing.
Not mine. And hopefully not TCL's ;D
1. Like ARM? Knock yourself out. See current ports here: http://repo.tinycorelinux.net/15.x/
2. curaga has spoken about libc in the recent past (search the forum). TCL considered musl but will stick with glibc for wider cross-distro compatibility.
3. curaga has also spoken about X in the past (ditto). TCL controls TinyX in case Xorg kicks the bucket. Wayland and a lot of nice wayland userland tools are already in the repo.
4. repo already has jwm and flwm. I prefer fluxbox and labwc but this is a matter of taste. If a WM arises that you like better than what's in the repos, just create an extension and submit it.
5. You can already create your ideal linux system using TCL and existing repo extensions.
6. netsurf is already in the repo. I prefer brave-browser, others prefer firefox, etc. TCL can accommodate all of this.
7. Nobody will force a user to use an app written in Rust. But I think if a user submits an app written in rust, Juanito will not reject it. TCL uses busybox init and last I checked with curaga, there are no plans to use systemd because it would add complexity without adding any tangible benefit to TCL.
I think TCL is in great shape for the present and the future. TCL bucks the trend of most other distros, which become increasingly complex over time.
-
Taken into account that TC focuses on compatibility to older CPU (ex:i486), but just partially (because firefox asks for better CPU), plus not many users contributing back to TC, then is OK to take for free what someone can, and not be picky (like me?):
- X-org runs (by default) as user=root (it is bad!), allows key-press shared (= spy!) between apps.
- Some apps use different versions of the shared library (lib-poppler?).
- Some library written in rust (not C), like librsvg becoming 3x bigger in time.
- Security of packages checked by md5 (weeker than sha256), in year 2024.
- Only few apps use FLTK, the rest 99% as size/number of tcz from total repo, use GTK* or QT as GUI.
I mean ... I could continue the list, but the intention is not to criticize;
If someone wants to spend time to compile from source (for percevied security) there are other distros (Gento) which provide even the scripts for EACH package to do it (Archlinux, Alpine). There are not demanding distro (DSL, Puppy) for lower resources; for modern hardware are the big boys (Fedora, OpenSUSE, Ubuntu, Debian).
If the sources and instructions to compile them are for free everywhere, even the compiled binaries provided for free; standard linux kernels, standard linux file herarchy, file systems etc. The theory is known: busybox + run from RAM, mounting squashfs files.. done!
So what could be improved? maybe re-check/change the compresion algorithms or block size;
But as long as "compatibility" with low resources (unchanged for 10-20 years) is the goal, limitations of CPU/RAM/HDD of that era do not allow for too much improvement. Maybe tune-up here and there, for some better user confort.
Summary: OK GNUser, you are right, TC is good as it is now, for its intended audience.
-
So we have yet to establish a core upon which everything else can be built!
If we had it, I think it would explode in adoption and contributions, and we would see more interesting projects than useless new distros.
ftr fwiw
from this comment https://github.com/raygard/wak/issues/7#issuecomment-2118782901 ( this issue gets my vote for issue with most interesting tangents)
i discovered this
Bootstrappable, self-hosting POSIX shell @ https://github.com/davidar/bootsh
... perhaps this or some derivative could meet the criteria of the above quote ?...
-
Necromancy of an old topic. Time is passing by and our goals and priorities are changing.
to answer the title , hypothetically of core's it can ;)
and *arguably* has (since the date of the op )
future plans regarding libc implementation and init software @ https://forum.tinycorelinux.net/index.php/topic,23835.msg149692.html#msg149692
Sources and Build Scripts x86/x64 @ https://forum.tinycorelinux.net/index.php/topic,27205.0.html
8)
Q)any other examples spring to mind?..
-
TCL bucks the trend of most other distros, which become increasingly complex over time.
could the core(scripts) be made "more" modular without increasing complexity ?
eg could (any?) of the existing logic be reduced & moved to script-file or function , while keeping the same functionality of the core ?
and would there be any advantages and/or disadvantages to such an endeavour ?
-
Demo vesion of TINY CORE PLUS
===========================
If we add Firefox + gstreamer codecs + alsa to TinyCorePlus.iso we will get fully usable desktop demo of TC capabilities. This iso could be downloaded from TC website as concept of proofe that you can have fully usable system on 700 MB CD-ROM iso.
Tiny Core HDD installation from hard disk IMG
------------------------------------------------------------------
Imagine I have new hard disk and want to instal TC very fast using dd command. It can be done using tinycorelinux.img just like RPi version is distributed as SD image.
The image will have 20 MB and it will have only one partition with GUI based Tiny Core Linux.
1. I don't have to create partiton in my new HDD to install standard TCL, but If I want space for extensions, I will create another EXT3 partition with journaling using gparted.
2. The first partition will be NTFS, and won't be mounted during boot. It protect this partition from newbies that can erase files by accident or error.
3. If first partition can't be accesed easily, it creates problem with editing boot codes. We can assume that second partition will be EXT3 with journaling and put this info to bootloader config file.
4. I can add swap partition using gparted if I need it, and don't have to modify boot codes.
5. Just like Android ROM has many partition that protects smartphone from malfunction, tinycorelinux.img will have simmilar structure.
-
Does TC have function to install extensions on local NAS server and load theme every time computer is booted?
-
If your NAS support nfs yes.
Here you have some thing to look at first and then you can ask the forum if that is not enough for you.
https://wiki.tinycorelinux.net/doku.php?id=wiki:netbooting#nfs_for_a_tce_directory (https://wiki.tinycorelinux.net/doku.php?id=wiki:netbooting#nfs_for_a_tce_directory)
And here are I, doing this with picore and uboot and tftp server nfs server.
Before you raspberry pi support tftp in "bios" (firmware)
You could use some of my lines in these scripts to see how i do it:
https://forum.tinycorelinux.net/index.php/topic,21356.msg133578.html#msg133578 (https://forum.tinycorelinux.net/index.php/topic,21356.msg133578.html#msg133578)
-
There should be few variants of Tiny Core.
* Micro Core with minimum 2 or more files.
* Tiny Core with only 2 files + mc + Dillo web browser 8MB (easy to boot through iPXE, PXE, pendrive)
- Xvesa variant with menu in boot loader 640x480, 800x600, 1024x768
- Xfbdev variant with menu in boot loader 640x480, 800x600, 1024x768
- Xorg variant (vesa)
- Xorg variant (autoconfig with dedicated driver)
* Core Plus iso with modern web browser + audio support + codecs
* TC recovery with only 2 files + Xvesa 32bit + Xfbdev 64bit + mc + gparted + testdisk + ddrescue + ntfs
* TC server with only 2 files (LiveCD with all files in RAM) configuration only by bootcodes or cloud configuration file
-
...
Knock yourself out.
...
ditto x2
(disclaimer: no disrespect and/or sarcasm intended to anyone regardless of any/and/or/all interpreter/language/translator difficulties/issues/etc)
-
> The base LIB is musl (not libc) because is smaller (means more secured).
>
A smaller one (speaking of linuxes: uclibc vs musl vs glibc) doesn't mean "more secured" automatically. Mostly it means one needs to implement that extra functionality (provided with bigger libs) in user software. If there's no need in that, a smaller is better, otherwise it's the opposite case.
-
Taken into account that TC focuses on compatibility to older CPU (ex:i486)...
@nick65go: Your comment has been stirring with me for a few thus begs to ask... how many TCL users are in fact using i386/486 equipment anymore?
. . o O ( Can I get a show of hands, please?? )
Non-retired admins: consider a sticky post with a survey -- the outcome may in fact alter future TCL builds.
There should be few variants of Tiny Core...
I agree... but I also have to disagree.
Most anyone who is going to use TCL is going to boot the downloaded ISO and either burn it to CD-ROM (640MB), DVD or FLASH. That said, there's a minimum of 640MB or so that we have as a foundation of the BOOT IMAGE. IN MY OPINION this image does not have to be as small as possible as we're completely wasting the remainder of that blank CD otherwise. Let's leave "variants" alone for the moment and move on. (See below.)
Does TC have function to install extensions on local NAS server and load theme every time computer is booted?
@neonix: Yes. As @partikg pointed out, you can use network shares via NFS, SMB/CIFS, AOE, iSCSI, etc. and simply load extensions remotely. If you're booting a device via PXE this is almost vital as there's usually no local storage. You can also create your own mini-repository on your NAS and simply edit /opt/tcemirror to point at your NAS. (Options exist in numerous flavors!)
could the core(scripts) be made "more" modular without increasing complexity ?
@mocore: The TCE foundation (scripts) are being rewritten outside of Tiny Core's crew and may someday become a replacement - with caveats.
- The existing TCE foundation is already a tiny bit complicated due to the stringent repository structure
- Making it more modular... I don't personally see much if any advantage to justify the amount of work entailed
- Functionality... somewhere around v4.x the current TCE/Repo foundation was solidified (and thereafter became stagnated/limited.)
In order to simplify and expand upon TCE would require an entire rewrite, which is on the books on my end for first quarter 2025 as we require repository functionality that doesn't exist and that the existing foundation cannot support, but I cannot promise backward compatibility thus why we're doing this initially outside of the existing Tiny Core Linux name so there's no confusion, conflict, etc. If the project is successful AND backward compatible, we'll send an offer up the chain of command and see if the TCL brass wants to convert :) It's far from effortless, thus why we're doing this solo right now.
@everyone: try to be patient! The entire TCL methodology is getting a conceptual refit based on what drove the TinyCore founder @roberts to start this project in the first place and the evolution necessary for it to step into the 21st century allowing more flexibility of what gets packaged under the hood and hopefully a lot less people quoting "if you don't like it the way it is, go somewhere else!" Tiny Core Linux is already, in my opinion, a reasonably unique variant to the Linux world. When we're finished, I assure you, this methodology and the tech we're implementing is going to create a class of its own!
Could be [tiny]core improved?
LOL... virtually anything can be improved upon - that's what society does... they point out flaws! (especially petty ones, it seems!) which leads to change when appropriate.
A decade later, you're still an active member of this forum. You, and everyone similar has spent their membership time offering ideas, bug reports, complaints and/or compliments... so of course it not only CAN be improved upon, but has been and will continue to be for as long as there are Admins willing to carry the torch and Users willing to make it worthwhile for them to do so.
Happy holidays everyone!
-
The entire TCL methodology is getting a conceptual refit
Is this true? Can you please clarify what's being refitted?
IMHO these are TCL's main strengths:
1. It's methods/concepts (e.g., frugal install, tcz system, known pristine state after boot)
2. Diminutive size
The above strengths more than make up for TCL's weaknesses:
1. Small repo (cf. Debian)
2. Patchy official documentation (cf. Arch, Gentoo)
3. Few online how-tos (cf. Ubuntu)
I really hope TCL isn't getting a radical conceptual overhaul. At least for me, TCL's concepts (as they currently exist) are what make me want to continue using the distro and contributing to it.
-
There are a Linux dist called Alpine Linux, that may fit your needs.
You can use miniature libs there, like musl.
-
Thanks, patrikg. Alpine is definitely my backup option if TCL were to become something very different from what it is now. But nothing fits my needs better than TCL as it exists today.
It would be nice if CentralWare or one of the other administrators could clarify this somewhat alarming statement:
The entire TCL methodology is getting a conceptual refit
-
The entire TCL methodology is getting a conceptual refit
Is this true? Can you please clarify what's being refitted?
IMHO these are TCL's main strengths:
1. It's methods/concepts (e.g., frugal install, tcz system, known pristine state after boot)
2. Diminutive size
The above strengths more than make up for TCL's weaknesses:
1. Small repo (cf. Debian)
2. Patchy official documentation (cf. Arch, Gentoo)
3. Few online how-tos (cf. Ubuntu)
I really hope TCL isn't getting a radical conceptual overhaul. At least for me, TCL's concepts (as they currently exist) are what make me want to continue using the distro and contributing to it.
I very much agree with this and GNUser's replay #19 as well.
-
> IMHO these are TCL's main strengths:
> 1. It's methods/concepts (e.g., frugal install, tcz system, known pristine state after boot)
>
at the same time tcz/squashfs is the reason (I suppose) of so slow TC booting (comparing to boot of uncompressed files)
-
...@nick65go: Your comment has been stirring with me for a few thus begs to ask... how many TCL users are in fact using i386/486 equipment anymore?. . o O ( Can I get a show of hands, please?? )
Non-retired admins: consider a sticky post with a survey -- the outcome may in fact alter future TCL builds.
Haven't we already left 386 behind right from the get-go? And I personally don't have any 386 nor 486 equipment.
There should be few variants of Tiny Core...
I agree... but I also have to disagree.
Most anyone who is going to use TCL is going to boot the downloaded ISO and either burn it to CD-ROM (640MB), DVD or FLASH. That said, there's a minimum of 640MB or so that we have as a foundation of the BOOT IMAGE. IN MY OPINION this image does not have to be as small as possible as we're completely wasting the remainder of that blank CD otherwise. Let's leave "variants" alone for the moment and move on. (See below.)
I'll freely admit that I might be an edge case but I never boot from an ISO, but always use the kernel+modules.gz+rootfs.gz. I'd be curious to see a poll of regarding who uses the ISO vs who does it the right way. ;)
Does TC have function to install extensions on local NAS server and load theme every time computer is booted?
@neonix: Yes. As @partikg pointed out, you can use network shares via NFS, SMB/CIFS, AOE, iSCSI, etc. and simply load extensions remotely. If you're booting a device via PXE this is almost vital as there's usually no local storage. You can also create your own mini-repository on your NAS and simply edit /opt/tcemirror to point at your NAS. (Options exist in numerous flavors!)
could the core(scripts) be made "more" modular without increasing complexity ?
@mocore: The TCE foundation (scripts) are being rewritten outside of Tiny Core's crew and may someday become a replacement - with caveats.
- The existing TCE foundation is already a tiny bit complicated due to the stringent repository structure
- Making it more modular... I don't personally see much if any advantage to justify the amount of work entailed
- Functionality... somewhere around v4.x the current TCE/Repo foundation was solidified (and thereafter became stagnated/limited.)
In order to simplify and expand upon TCE would require an entire rewrite, which is on the books on my end for first quarter 2025 as we require repository functionality that doesn't exist and that the existing foundation cannot support, but I cannot promise backward compatibility thus why we're doing this initially outside of the existing Tiny Core Linux name so there's no confusion, conflict, etc. If the project is successful AND backward compatible, we'll send an offer up the chain of command and see if the TCL brass wants to convert :) It's far from effortless, thus why we're doing this solo right now.
I haven't gone over them with a fine-toothed comb but I have taken a look at the Tiny Core scripts, primarily tc-config, and haven't found much of anything that I would change -as part of the base-. There are a few tweaks I would make for -my own purposes- and have determined that I can make whatever changes I want by placing slightly modified files in a third ".gz" file and loading modules.gz, rootfs.gz and my_own.gz - "remastering light".
@everyone: try to be patient! The entire TCL methodology is getting a conceptual refit based on what drove the TinyCore founder @roberts to start this project in the first place and the evolution necessary for it to step into the 21st century allowing more flexibility of what gets packaged under the hood and hopefully a lot less people quoting "if you don't like it the way it is, go somewhere else!" Tiny Core Linux is already, in my opinion, a reasonably unique variant to the Linux world. When we're finished, I assure you, this methodology and the tech we're implementing is going to create a class of its own!
I'm thinking that would be a popular thread on the forums?
Could be [tiny]core improved?
LOL... virtually anything can be improved upon - that's what society does... they point out flaws! (especially petty ones, it seems!) which leads to change when appropriate.
A decade later, you're still an active member of this forum. You, and everyone similar has spent their membership time offering ideas, bug reports, complaints and/or compliments... so of course it not only CAN be improved upon, but has been and will continue to be for as long as there are Admins willing to carry the torch and Users willing to make it worthwhile for them to do so.
Happy holidays everyone!
A sincere "Thank you" to all of the torch carriers, whether or not you are "officially" part of the "team". To you and the Tiny Core community at large, I hope you had a merry Christmas and will have a happy new year (and whatever other holidays you might celebrate).
-
Hi yvs
... at the same time tcz/squashfs is the reason (I suppose) of so slow TC booting (comparing to boot of uncompressed files)
The squashfs packages is one of the cornerstones of Tinycore.
Like all things in life, nothing is free. Every feature comes with a price.
It takes longer to boot:
That may be, but booting is not an activity I perform very often. I spend
most of my time performing useful tasks on my computer, not booting.
-
Your comment has been stirring with me for a few thus begs to ask... how many TCL users are in fact using i386/486 equipment anymore?
. . o O ( Can I get a show of hands, please?? )
Hand.
OK, it's more practical to run older Linux which uses less RAM/CPU, but I like that the option exists for my i486 PCs. i386 isn't supported as it is.
People wanting performance will probably have x86_64 systems these days, so why push dropping i486 compatibility in binaries now (presumably in hope for slightly faster performance)? Such people can use the x86_64 kernel/extensions.
Most anyone who is going to use TCL is going to boot the downloaded ISO and either burn it to CD-ROM (640MB), DVD or FLASH. That said, there's a minimum of 640MB or so that we have as a foundation of the BOOT IMAGE. IN MY OPINION this image does not have to be as small as possible as we're completely wasting the remainder of that blank CD otherwise.
Actually on my limited internet data I really like that I can download the smaller ISOs. But like Leee I usually download kernel+modules.gz+rootfs.gz directly for upgrades from home, and leave the ISO download for some time I can leech off someone else's internet.
Functionality... somewhere around v4.x the current TCE/Repo foundation was solidified (and thereafter became stagnated/limited.)
But this is a big advantage of Tiny Core! Simplicity to me means it's easy to understand everything, and not changing things all the time like most other distros is a big part of that. I don't even like how PiCore swapped out some TCL shell scripts for Python (I changed them back for my own use). The only annoying thing about extensions is that I have to build lots of them myself because the repos are small. I gather you're working on a system to port software build scripts from other distro packaging systems, which is great. I played with this myself but don't have the motivation to work through debugging and maintenance of such a system. But I can't see how it would be impossible to make that "backward compatible" with the current extension system. It might be easier to change TCL to match parts of the other distro you're porting build scripts from, but then that's already been done with dCore where existing Debian packages can be converted directly without compiling them separately.
-
Thanks, patrikg. Alpine is definitely my backup option if TCL were to become something very different from what it is now. But nothing fits my needs better than TCL as it exists today.
It would be nice if CentralWare or one of the other administrators could clarify this somewhat alarming statement:
The entire TCL methodology is getting a conceptual refit
CentralWare is trying out different changes, which we will evaluate then. Nothing has been decided yet.
-
with reference to i486 i would relate this prior thread:
https://forum.tinycorelinux.net/index.php/topic,25098.0.html
as per a post in that thread, had been using the latest tcl iso as a cut-off of what to keep
(at least before the purge: https://forum.tinycorelinux.net/index.php/topic,25098.msg165728.html#msg165728 )
currently the oldest units are an amd athlon x2 7750 dual-core and a couple of core2quads(q6600 & q8200)
---
and with reference to the size of the iso, it is Tiny Core Linux and it is definitely unique and most cherished for that quality.
i understand the size reference regarding the CD optical media and my thoughts go immediately back to the differences in size of Damn Small Linux and Puppy Linux
i wonder what the size of Tiny Core Linux would be if we fine forum folks used DSL as a template to come up with a TCL with near identical functionality as DSL right from the iso?
please note that i am NOT saying to change what is being done/offered/produced/etc because the current offerings cover the vast majority of common usage.
perhaps with other forum folks input we might contemplate a potential template? i have a dsl-4.4.10 that i started to pick apart a couple years ago but then life got in the way(sad but true for many)
-
But this is a big advantage of Tiny Core! Simplicity to me means it's easy to understand everything, and not changing things all the time like most other distros is a big part of that.
@CNK: Your version of "Simplicity" is based on your existing level of expertise. Someone without the knowledge of how shell scripts operate, for example, will be dumbfounded.
"...so why push dropping i486 compatibility..."
Not interested in dropping anything at all...
However, we (CentralWare) and TCL's Admins (TinyCoreLinux) are likely to be in the same boat.
We cannot "support" a hardware platform which we cannot replicate its environment.
I tossed my last 486 many years ago - though I think I still have an old DX chip in the archive just for grins.
In fact, I think there's even a Fire Starter (Blue Lightning Cyrix) in a shadow-box alongside a mini fire extinguisher.
That, along with a framed Gates 'n Crew photo after the IBM-DOS agreement/purchase.
Example 1: A few months ago User wants TCL to compile an extension to be used on old hardware. (486 if I'm not mistaken.) TCL Admin gladly accommodates the User; compilation goes through without a hitch... User comes back claiming extension throws an error (Illegal Op / Seg Fault if I'm not mistaken) - Admin can't replicate user's hardware environment, all support here-after becomes theoretical at best. Hours are wasted trying to guess what the problem might be, advising User "Try This" and "Try That" to no avail. This is where trying to "support" Users on old hardware becomes daunting. If the TOS were to claim "...may work on i486... but not directly supported..." or something of that nature and IF peeps were to actually read it, hopefully fewer bruised emotions would exist if something took place similar to the story above. (QEMU is not a viable testing grounds. Too many false-negatives. Teaching someone to source/compile/package an extension with zero or very little experience goes a bit beyond "supporting" Users.)
Example 2: We had a project handed to us during the COVID outbreak after Raspberry Pi boards became scalper fodder. The Client wanted us to replicate a Linux based operating system "stripped down to the bare basics" similar to the TCL concept but on a board that's NOT a RasPi and thus TCL doesn't work on it "as-is." We have a dozen or so of these boards in the archive as part of the project's overhead as we cannot possibly "support" something we cannot replicate.
@everyone: @curaga is correct; I may not have been clear. Our project is completely separate from Tiny Core Linux Version 15.x and older and may or may not even become Tiny Core Linux related -- this is determined by the existing Admins along with the voice of its Users. We are building this project almost-completely-from-scratch (no sense re-inventing the wheel in some instances!) using notes gathered over the past decade along with a few ounces of common sense based on Tiny Core's Users, posts made in the past couple years and deducting what could have made it possible for many of the support related posts to not have been needed in the first place. Even if our project does not become associated with the Tiny Core repository, Tiny Core will still benefit from it in the long run.
@gadget42: I think our oldest boxes also date around athlon/opteron and Core/Core2 eras, many of which are about to be retired along with a few containers of AGP/PCI/etc. cards some time this upcoming year.
ISO: How about a web page made up like a pizza ordering menu? You pick the kernel/busybox/core features and versions, add your pepperoni, sausage, etc. (extensions) and out pops an email with a download link to the final package? (This entire concept is still on the drawing/white-board as there are debates over complexity for the end user.) The reason for this starting is due to Raspberry Pi user requests over problems of Internet access and the lack of WiFi extensions not already being a part of the downloaded image and other similar problems arising where the boot image only fits, say, 85% of the general population and the other 15% are instant support tickets or told "try Big Brother Distro." (TCL extensions are cloud based; if the boot image cannot gain access to the repo, the experience stalls.)
Puppy (Noble) (http://Puppy (Noble)): ISO = 361MB
DSL 2024 (https://www.damnsmalllinux.org/2024-download.html) ISO = 1.1GB and 685MB
The argument above is Internet/bandwidth challenged Users being unable to obtain boot images of that size
Regardless, we'll see what the future has in store when we get there!
Which isn't that far away! It's New Year's Eve! (Here, at least!)
-
re @CentralWare pizza parlor idea
see: https://forum.tinycorelinux.net/index.php/topic,24241.0.html
(core-user reports it doesn't work anymore)
https://forum.tinycorelinux.net/index.php/topic,24241.msg167320.html#msg167320
also your favorite search engine for terms slitaz pizza cooker
it worked...til it didn't...haven't tried it lately...sigh...all things come and go...shrug
also, re DSL...i was specifically referring to the "old dsl" that had a 50MB target...
20241231-0556am-cst-usa-modified: added dsl note
-
Hi curaga and CentralWare. Thank you for the additional information. I hope any upcoming changes preserve key TCL concepts.
-
But this is a big advantage of Tiny Core! Simplicity to me means it's easy to understand everything, and not changing things all the time like most other distros is a big part of that.
@CNK: Your version of "Simplicity" is based on your existing level of expertise. Someone without the knowledge of how shell scripts operate, for example, will be dumbfounded.
But once they've leant shell scripts, or picked TCL in the first place because they do already understand its shell scripts, they don't have the burden of things changing completely. Like PiCore introducing Python scripts as well.
"...so why push dropping i486 compatibility..."
Not interested in dropping anything at all...
However, we (CentralWare) and TCL's Admins (TinyCoreLinux) are likely to be in the same boat.
We cannot "support" a hardware platform which we cannot replicate its environment.
I tossed my last 486 many years ago
Since I became aware of that I have been aiming to test a beta version on my 486 before the stable release (not that I can guarantee to always have the time to do so before the stable release is done).
Other distros say unsupported to mean changing the compiler target architecture to a later minimum version, so it absolutely can't run on earlier CPUs. If it's just an issue with documentation, then I don't have a problem.
-
@CNK: In my opinion, there's no sense for anyone to do away with an entire platform just to... what... save a few bytes in the kernel? For as long as Kernel Foundation maintains value in 486-land, we're good... just not trying to be overwhelmingly supportive of those antiques if we have no means to replicate user issues.
piCore introducing Python... I'm going to make an educated guess that if the core is being written partially in Python it's likely due to whom ever wrote them most likely feels more familiar with Python than Ash, Bash, etc. to accomplish a given task. ME, personally, I try to avoid building something that requires installing additional software (none of our Pi or Pi-Like boards have Python installed by default - or any other translator for that matter) and in some cases we'll rewrite a PY script as a shell script if it's reasonably easy to follow just to avoid installing third party apps.
@gadget42:
also, re DSL...i was specifically referring to the "old dsl" that had a 50MB target...
I know. :)
Slitaz Pizza Cooker: Cute! Still doesn't work, though.
-
piCore introducing Python...
afair ... it's micro python
BTW: piCore comes with microPython installed. It is used during the boot process to load extensions I believe!
-
yes!
care to try ... "executable autocompleteable "tcz.info" extension files " https://forum.tinycorelinux.net/index.php/topic,27469.0.html
?
... It's only wafer thin.!
-
Hi neonix
There should be few variants of Tiny Core.
* Micro Core with minimum 2 or more files.
* Tiny Core with only 2 files + mc + Dillo web browser 8MB (easy to boot through iPXE, PXE, pendrive)
- Xvesa variant with menu in boot loader 640x480, 800x600, 1024x768
- Xfbdev variant with menu in boot loader 640x480, 800x600, 1024x768
- Xorg variant (vesa)
- Xorg variant (autoconfig with dedicated driver)
* Core Plus iso with modern web browser + audio support + codecs
* TC recovery with only 2 files + Xvesa 32bit + Xfbdev 64bit + mc + gparted + testdisk + ddrescue + ntfs
* TC server with only 2 files (LiveCD with all files in RAM) configuration only by bootcodes or cloud configuration file
Sure, we could could try to be all things to all people.
Or we could stick with the original philosophy:
Tiny Core is not a turnkey distribution. It is very different than most Linux distributions.
It is a minimal GUI environment that allows users to easily pick and choose their desired applications. ...
-
>Sure, we could could try to be all things to all people.
>Or we could stick with the original philosophy.
How about a compromise?
How about we create hard-coded releases that simply ensure the majority of the masses can
1) Boot tinyCore, piCore and/or dCore
2) Gain access to the network/internet
3a) have a bare minimum desktop (save for (micro)Core)
3b) have SSH embedded for headless scenarios
@neonix: If the above were true, which it already is for most x86/x64 users, you can build your custom flavor somewhat easily using the extension manager. Tiny Core Linux was originally developed to act like LEGOs. We GIVE you that big flat piece (kernel/core/basic necessities) and you as the end-user build onto that foundation one brick (extension) at a time. This way, you're always assured that ONLY the things you've chosen are installed - no fluff, no bloat.
@admins: A few basic "Meta" extensions could also come in handy in creating a FEW starting environments. (ie: Update TC.tcz, if necessary, to give the user a "basic" desktop in each of the platforms, create another for a generic Xorg based desktop, etc.) For ISO files, I'd recommend the list above -- just make sure we can BOOT, get ONLINE*, have INSTALL capabilities and preferably, which would be a huge time-saver for slightly more advanced users, allow a selection between ext/syslinux versus grub2. For users such as @neonix possibly a single Go To Meta Extension that contains GUI files, a mid-sized browser, typical alsa items, network and hard drive utilities, etc. WITH a notice that it's intended as a starting point, but not guaranteed to work in every possible environment.
For x86 and x86_64 ISO images - it would be very worthwhile to have an image suited with ALL firmware/driver modules that are HARDWARE related which would apply to or otherwise affect the above list. (For example, we have an Intel motherboard which has ETHERNET which requires titan, mdadm and ipv6 drivers and STORAGE which oddly requires i2c - an install is impossible using the basic ISO files as we cannot get online to download drivers. I've created a special set of boot flash drives which contain the entire firmware/driver module set, but that's only after being faced with a lot of oddities that forced their creation. For general users... they'd be lost trying to figure out what's missing and for admins... that's hours and hours of support posts that potentially would no longer exist. (Yes, we also have USB dongles for scenarios for unforeseen install situations - but having an ISO that supports as much hardware as possible would be a God-send.)
* Isn't there a text based database of hardware IDs somewhere (at kernel.org I'm guessing) which I'm guessing we could use lspci/lsusb/etc. to get a list of detected hardware and cross reference it with kernel.org and determine which hardware modules are needed for said items? This way were're only loading module TCZ files we actually may need.
-
* Isn't there a text based database of hardware IDs somewhere (at kernel.org I'm guessing) which I'm guessing we could use lspci/lsusb/etc. to get a list of detected hardware and cross reference it with kernel.org and determine which hardware modules are needed for said items? This way were're only loading module TCZ files we actually may need.
The PCI ID DB is here (http://pci-ids.ucw.cz/). This is the USB version (http://www.linux-usb.org/usb-ids.html). Matching device models to drivers might be trickier because I think that info is generally built into each driver.
-
Matching device models to drivers might be trickier because I think that info is generally built into each driver.
Eh... t'was wishfull thinking! :)
EDIT: My above post regarding Intel:Titan motherboard... "mdadm" wasn't for Ether - was for storage, of course. Read the notes wrong! (...and didn't allow the brain to process what I was typing)
-
Hi neonix
There should be few variants of Tiny Core.
* Micro Core with minimum 2 or more files.
* Tiny Core with only 2 files + mc + Dillo web browser 8MB (easy to boot through iPXE, PXE, pendrive)
- Xvesa variant with menu in boot loader 640x480, 800x600, 1024x768
- Xfbdev variant with menu in boot loader 640x480, 800x600, 1024x768
- Xorg variant (vesa)
- Xorg variant (autoconfig with dedicated driver)
* Core Plus iso with modern web browser + audio support + codecs
* TC recovery with only 2 files + Xvesa 32bit + Xfbdev 64bit + mc + gparted + testdisk + ddrescue + ntfs
* TC server with only 2 files (LiveCD with all files in RAM) configuration only by bootcodes or cloud configuration file
Sure, we could could try to be all things to all people.
Or we could stick with the original philosophy:
Tiny Core is not a turnkey distribution. It is very different than most Linux distributions.
It is a minimal GUI environment that allows users to easily pick and choose their desired applications. ...
All the goals of original philosophy was achieved, now it's time to go beyond new froniers.
-
Is it possible to rewrite Xorg in other to generate 16:9 aspect ration desktop screen inside 4:3 resolution? I'm talking about VESa driver. It will probable require some CPU power.
The widescreen monitor will stretch 4:3 signal into 16::9 aspect ratio.
It looks like many GPU brands will never have support in Linux open code environment, but some solutions can be done in area of software.
If I can convert video aspect ratio inside VLC form 4:3 to 16:9, without hardware acceleration, CPU power is used, why the same can be done in Xorg?
-
Can I set volume above 100%? HaikuOS has this feature.
-
Can I set volume above 100%? HaikuOS has this feature.
Hi neonix. Are you using pulseaudio or just alsa?
alsa
If using pure alsa (which is what I do), volume can be boosted using a software pre-amp. I got the idea from these two how-tos:
https://wiki.archlinux.org/title/Advanced_Linux_Sound_Architecture/Troubleshooting#Volume_is_too_low
https://alien.slackbook.org/blog/adding-an-alsa-software-pre-amp-to-fix-low-sound-levels/
This is my ~/.asoundrc:
pcm.!default {
type asym
playback.pcm "plug:softvol"
capture.pcm "plug:dsnoop"
}
pcm.softvol {
type softvol
slave.pcm "dmix"
control { name "Pre-Amp"; card 0; }
max_dB 32.0
}
And I use these two startup commands:
amixer -q set Master 100%; amixer -q set Pre-Amp 160
pulseaudio
Increasing volume beyond 100% with pulseaudio is more straight-forward. I think you can run this command several times and it will keep increasing the volume beyond 100%:
pactl set-sink-volume 0 +10%
-
In 2013, I posted how to add Polish keyboard layout to Xvesa (TiinyX).
If I give you some tips about what Polish diacritic are needed, could you implement this in TinyX?
https://forum.tinycorelinux.net/index.php/topic,15366.msg88981.html#msg88981
-
In puppulinux it's easy to change resolution and chose between Xvesa and Xorg. In TC when I install Xorg it's difficult to have Xorg and Xvesa at the same time in the system.
There could be something like command in text mode:
setXorg
setXvesa
setXfbdev
as default x11server.
-
On main page there should be mirrors section that allow to change server easlly.
The main sections could be separated in two rows.
Welcome Intro Screen Shots Installation Core Concepts Book
FAQ Forums Downloads Wiki Mirrors About Us
-
Main page could be redesigned to "responsive web design".
-
Search option in "local extensions" that are installed on demand. I have more than 30 extension in on-demand mode an it takes many time to find firefox.tcz inside.