Recent Posts

11

Programming & Scripting - Unofficial / Re: busybox fork, micro self-extracting payload, micro qemu

« Last post by nick65go on Today at 11:17:09 AM »

You are quite confused but it is ok. It is not supposed you do business with uzpexec.

For me is like instead of 7zip-archive I will have a 7z-self-extracting. The stub offer some comfort in automation. I just evaluate the "return" (in speed, lower resources, etc) if I "invest" (time, skills, etc) to use it.
Maybe I am a little confused because I try to see its practical value for me, with my "narrow" vision and focus on efficiency, instead of the larger audience goal. For me 7z-self-extracting add "bloat" stub of 200KB but can compress LZMA-solid type (re-gain size here more than 200KB for a big "package"). Or just use xz form busy-box.
Please carry-on, I am just a guy on internet after all, curious about innovation not often seen/shared. That is the motive I use TC forum 

12

Final Releases / Tiny Core v17.1

« Last post by Juanito on Today at 10:39:43 AM »

Team Tiny Core is proud to announce the release of Core v17.1
http://www.tinycorelinux.net/17.x/x86/release
http://www.tinycorelinux.net/17.x/x86_64/release

Changelog for 17.1 beta1:
* update kernel to 6.18.35
* update zsync - thanks to @GNUser

Note that you will need the updated kernel module extensions from the appropriate repo - it is probably better to download the ones you need prior to updating rootfs*gz, modules*gz and vmlinuz* and rebooting.

13

Programming & Scripting - Unofficial / Re: busybox fork, micro self-extracting payload, micro qemu

« Last post by Roberto A. Foglietta on Today at 10:02:21 AM »

I may have one idea for your stub.
In my opinion the main use of your program is that decompress in RAM (an ELF64, a sh-script etc). But for big RAM should not matter: someone could mount a TempFS -- hm, needs root rights -- on a folder and decompress there (aka in RAM, not touch the HDD) with the same useful busbox-applets (zcat, guzip etc). Ex: 10MB UPZ will expand in RAM as (lets say) 20 MB. so you need 30 MB free RAM before run the original gzipp-ed program.
When the RAM is low, then one possible/future option/advantage could be decompress + replace in place, overriding the already used chunk of what was executed. (technique from viruses). For sh / python script works OK. for ELF they need to be modular designed from scratch (not applicable to TC compiled tcz as now).

PS: Any program could be build in small pieces, each chunk compressed with different algorithms, etc. If ever your stub grows too big you can apply this to itself as ASM can load chunks of it code in any memory place even previously used code pointers, but NX (not execute) flag in CPU (not present in 486 cpus?) could be a problem sometimes.

You are quite confused but it is ok. It is not supposed you do business with uzpexec.

14

Programming & Scripting - Unofficial / Re: busybox fork, micro self-extracting payload, micro qemu

« Last post by nick65go on Today at 08:28:37 AM »

I may have one idea for your stub.
In my opinion the main use of your program is that decompress in RAM (an ELF64, a sh-script etc). But for big RAM should not matter: someone could mount a TempFS -- hm, needs root rights -- on a folder and decompress there (aka in RAM, not touch the HDD) with the same useful busbox-applets (zcat, guzip etc). Ex: 10MB UPZ will expand in RAM as (lets say) 20 MB. so you need 30 MB free RAM before run the original gzipp-ed program.
When the RAM is low, then one possible/future option/advantage could be decompress + replace in place, overriding the already used chunk of what was executed. (technique from viruses). For sh / python script works OK. for ELF they need to be modular designed from scratch (not applicable to TC compiled tcz as now).

PS: Any program could be build in small pieces, each chunk compressed with different algorithms, etc. If ever your stub grows too big you can apply this to itself as ASM can load chunks of it code in any memory place even previously used code pointers, but NX (not execute) flag in CPU (not present in 486 cpus?) could be a problem sometimes.

15

Programming & Scripting - Unofficial / Re: busybox fork, micro self-extracting payload, micro qemu

« Last post by Roberto A. Foglietta on Today at 06:55:36 AM »

...This destabilises a lot of people who were used to live on prehistoric narratives.

And if you felt that my comments were against you then please accept my sincerely apologies.

My humor tends to be sarcastic, not necessarly it means that I see antagonists everywhere.

- https://github.com/robang74/uzpexec#quick-arm64-view

I think that it is owrth to tell you that python support and 512-byte ARM64 are already available. Useless to say that because the great sucessful adoption of python and about the dominance of ARM64 on edge/mobile devices, the uzpexed v0.95 and the current HEAD on master branch is the most impactful release, so far (citing Homer Simpson)

About "sharing", pythong is valuable because universally adopted not because deposited and secured in a bank vault. This explains pretty well because I adopted the MIT+1 licensing terms: MIT the source and MIT the binary, because disassembling the binary the source are 1:1 retrieved back, label name apart. So, I leveraged the uzpexec extreme nature to extend the MIT licensing terms to the binary and spread the original github link/author.

Adoption is the key, sharing is the mean. ;-)

16

Programming & Scripting - Unofficial / Re: busybox fork, micro self-extracting payload, micro qemu

« Last post by nick65go on Today at 06:44:32 AM »

...This destabilises a lot of people who were used to live on prehistoric narratives.

I am like a "prehistoric"/dinosaurs but not yet destabilized. Once again: congratulations for your achievements and especially for SHARING them. Some nudges like those should not be lost in the big noise.
And if you felt that my comments were against you then please accept my sincerely apologies.

17

TCB Talk / Re: mount tool not reading drive!

« Last post by StelaHong on July 15, 2026, 04:29:48 AM »

I'd also check the boot messages with dmesg to see if there's a more specific error before changing too many things. On Tiny Core it's often something simple like a missing extension, firmware, or a boot parameter. Posting the exact error output usually makes it much easier for others to pinpoint the cause.

18

piCore Test Releases / Re: piCore 17 Beta Releases

« Last post by meo on July 14, 2026, 07:59:24 AM »

Hi Juanito!

I downloaded firefox-ESR to on demand and now it works. It works perfect with the exception that it does not play YouTube videos right out of the box.

Kind regards,
meo

19

Corepure64 / Re: [Solved] problems with v17 x64

« Last post by neonix on July 14, 2026, 05:09:27 AM »

 ASCII characters are ussualy a sign of corruption. Maybe you could reinstall all packages.

I noticed that when I use slow mobile internet connection, the risk of loosing connection, freez  connetion or packet lost is higer than in broadband LAN connection.   

20

Corepure64 / Re: [Solved] problems with v17 x64

« Last post by Rich on July 13, 2026, 08:45:07 PM »

Hi tektonikos
By close I guess you mean marking it as solved.
Once a post is 30 minutes old, you can no longer edit it.
If you need a thread marked as solved, mention it and I'll take care of it.