Recent Posts

61

TCE Talk / Re: Firefox

« Last post by gadget42 on February 25, 2026, 05:03:49 AM »

daily driver librewolf 147.0.4-1 has about:config setting dom.ipc.forkserver.enable and it is set to true(default)

62

General TC Talk / Re: Bulding the kernel from source and making an ISO?

« Last post by Juanito on February 25, 2026, 04:41:55 AM »

You would perhaps be better off compiling the kernel natively on tinycore.

Core is comprised of rootfs.gz, modules.gz and vmlinuz (core.gz = rootfs.gz + modules.gz)
CorePure64 is comprised of rootfs64.gz, modules64.gz and vmlinuz64 (corepure64.gz = rootfs64.gz + modules64.gz)

You don't need to touch rootfs.gz/rootfs64.gz
You can replace vmlinuz/vmlinuz64 with the bzImage you compiled
You would probably need to replace the contents of modules.gz/modules64.gz with the modules you compiled

63

Off-Topic - Tiny Core Lounge / Re: XLibre - a fork of Xorg

« Last post by Juanito on February 25, 2026, 04:33:42 AM »

The silence is eloquent. I hear "status quo is preferable" loud and clear. Works for me

Perhaps it's worth detailing where we are now with x11 and wayland:

x86 (TinyCore)
Xvesa, Xfbdev and xorg-server are all available
mesa is not compiled for wayland in the interests of keeping things small
fltk-1.3 does not support wayland

x86_64 (TinyCorePure64)
Xfbdev and xorg-server are available
mesa is compiled for x11 and wayland
fltk-1.4 supports wayland so the tinycore applets are available in a wayland compositor

armhf (piCore)
xorg-server is available
mesa is compiled for x11 and wayland
fltk-1.4 supports wayland so the tinycore applets are available in a wayland compositor

aarch64 (piCore64)
xorg-server is available
mesa is compiled for x11 and wayland
fltk-1.4 supports wayland so the tinycore applets are available in a wayland compositor

x11 is becoming increasingly unsupported, particularly for x86 (xorg-server will not start with my intel hd4400 graphics using the modesetting driver, but will start with the obsolete xf86-video-intel driver)

wayland is becoming increasingly supported, wayland-only test versions of x86_64 and aarch64 work well (firefox works noticeably better on an RPi3 with wayland as compared to x11). All gtk3 and gtk4 apps work with wayland.

XLibre might make sense for x86, particularly if it updates Xvesa and Xfbdev (I don't know if this is planned), but I'm not sure if it makes sense for x86_64, armhf or aarch64.

The decision to be taken is perhaps not deciding between x11 and XLibre, but rather deciding between x11/XLibre and wayland.

64

General TC Talk / Re: Bulding the kernel from source and making an ISO?

« Last post by edmazing on February 25, 2026, 02:36:09 AM »

Thanks for the warm welcome.

That does indeed create an ISO nicely.
I'm just not sure how to create core.gz and vmlinuz with the required P9 support. I can get a bzimage and vmlinux file. If I take the current kernel source and compile it.

Make isoimage in the kernel source doesn't seem to produce a file that works as expected. I think it'd be because my host is ubuntu.
Sorry if compiling from source has been asked before.

65

General TC Talk / Re: Bulding the kernel from source and making an ISO?

« Last post by Rich on February 24, 2026, 10:20:44 PM »

Hi edmazing
Welcome to the forum.

I take it you want to create a bootable ISO. This deals with making an ISO that
can boot multiple versions of Tinycore, but should provide sufficient information
for creating your own ISO:
https://forum.tinycorelinux.net/index.php/topic,27848.msg180072.html#msg180072

66

Off-Topic - Tiny Core Lounge / Re: XLibre - a fork of Xorg

« Last post by GNUser on February 24, 2026, 09:46:01 PM »

Outright replacement of Xorg with Xlibre runs the risk of unforeseen breakage.
I doubt there is any appetite for that.

Breakage is not my favorite dish, either

I naively thought XLibre was a drop-in replacement for Xorg, maintained by folks committed to its longevity. Real life is always more messy than theory.

I'm happy to kick this can down the road.

67

General TC Talk / Re: Serial Port

« Last post by Rich on February 24, 2026, 09:26:47 PM »

Hi MTCAT

... am I correct to say that the commands below create both a log file with the date and time as the title AND a "working" file (for the GUI), in this called "Temps.log"? ...

Temps.log is a "link" to the current YYMMDDHHMMSS.log file. Either name
can access it, but when the command gets run again, a file with a new
YYMMDDHHMMSS timestamp will be created and Temps.log will be pointing
at that instead.

... I think the "working file" as I'm calling it (Temps.log) would also always start out fresh in the sense that when the re-direct command from microcom is executed on power up (as contained in a script in ~/X.d lets say), it would overwrite the previous "Temps.log" and starts "fresh" with new readings? ...

Yes, and a new YYMMDDHHMMSS.log file.

... Ah, okay, and then adding the touch command basically creates an empty file ahead of time? ...

It's a good idea to include that. It makes it easy to spot a string of failures since
those files will show a size of zero bytes in a directory listing. The file names
will tell you when those failures occurred. If you copy them, their timestamp in
a directory listing may change, but the filename will still reflect when it was created.

68

Off-Topic - Tiny Core Lounge / Re: XLibre - a fork of Xorg

« Last post by Rich on February 24, 2026, 09:05:54 PM »

Hi GNUser
Maybe these warnings served as a deterrent:

Upgrade notice

    Module ABIs have changed - drivers MUST be recompiled against this Xserver version, otherwise the Xserver can crash
    or fail to start up correctly.

    If your console is locked up (no input possible, not even VT switch), then most likely the input driver couldn't be loaded due
    to a version mismatch. When unsure, it's best to be prepared to ssh into your machine from another one or set a timer
    that's calling chvt 1 after certain time, so you don't need a cold reboot. Or, make sure that you have magic SysRq key
    enabled (Alt+PrtSc) via sysctl (kernel.sysrq=1), then press following combination depending on keyboard layout to
    make kernel regain control over keyboard to make VT switching work:
        QWERTY/AZERTY keyboard layout: SysRq + R
        Dvorak/Colemak keyboard layout: SysRq + P

    Proprietary Nvidia drivers might break: they still haven't managed to do even simple cleanups to catch up with Xorg master
    for about a year. All attempts to get into direct mail contact have failed. We're trying to work around this, but cannot give
    any guarantees. But you can make it work by adding Option "IgnoreABI" "1" line to ServerFlags section in Xorg
    config.

    Most Xorg drivers should run as-is (once recompiled!), with some exceptions. See .gitlab-ci.yml for the versions/
    branches built along with Xlibre.

Found here:
https://github.com/X11Libre/xserver/tree/xlibre-xserver-25.0.0.0

Outright replacement of Xorg with Xlibre runs the risk of unforeseen breakage.
I doubt there is any appetite for that.

I also don't see any clean and simple way for Xlibre to co-exist with Xorg to
allow someone to switch back and forth between the two.

69

General TC Talk / Bulding the kernel from source and making an ISO?

« Last post by edmazing on February 24, 2026, 08:47:45 PM »

I'm looking to add P9 support to the kernel (So I can hopefully run gcc as a tiny C++ compiler on V86, ). Thus recompiling it from source.

I found the kernel source over at https://distro.ibiblio.org/tinycorelinux/17.x/x86/release/src/kernel/
Ran wget for the tar.gz and configure files.
Extracted the tar.gz and copied the configure file as a .config.
Then did make menuconfig, under network support added Plan 9 Sharing Support (9P2000)
Then Filesystems -> Network File Systems -> Plan 9 Resource sharing Support (9P2000) (Unsure if the access control or security labels are needed.)

Ran make. It took about two hours but it compiled just fine.
How exactly would I package the result into an ISO?
I think I should be able to manage to add gcc and the other bloat to make it into a tiny compiler environment.

70

TCE Talk / Re: Firefox

« Last post by CNK on February 24, 2026, 08:26:35 PM »

As today ( February 13, 2025) in Firefox 135.0, I enabled (set on true) dom.ipc.forkserver.enable and I noticed a faster web pages loading.

If the feature was added in 135.0 then it should be in any of the later versions which the script downloads, the latest stable version is 148, so 135 is old. Firefox Nightly builds are mainly for people helping to develop and debug the browser, I'm sure it's not really what you want. If the setting you're looking for isn't in the latest Firefox version the script downloads for you, it was probably changed/renamed later. I use the current ESR version, 140.8, and the dom.ipc.forkserver.enable setting is in about:config there.