Tiny Core Linux
Off-Topic => Off-Topic - Tiny Core Lounge => Topic started by: GNUser on June 23, 2025, 02:22:36 PM
-
I just saw this today:
https://www.phoronix.com/news/XLibre-25.0-Released
https://github.com/X11Libre/xserver/releases/tag/xlibre-xserver-25.0.0.0
I hope this extends the useful life of X into the distant future. But it's also possible that it peters out after an initial wave of enthusiasm. Time will tell. I wish I could help the initiative but I know too little about graphics.
-
If it would be a one-man orchestra then it will fail. I also hope it will not.
Maybe a better future will have if it will be split in two pieces (with maybe a common code/part):
1. XlibreX11 - for compatibility with ALL old GPU devices. The job will finish soon as no/few new devices /quirk/patches.
2. XlibreX12 - cut the old stuff compatibility, concentrate only on Actual + new GPU devices. Plus No xWayland etc.
Without a split like this, it is too much work, limit in API advances + extensions, to keep pass with innovations in GPU cores.
Anyway, for a long time from now, still will be apps using X11, but under Wayland. What matters, for users of an OS, are the applications. As long as speed is good enough, it should not matter the "insecurities" of Xorg in a container/VM, or isolated machine.
-
The Xlibre case brings out the worst in the open source community
https://en.ubunlog.com/The-XLibre-case-brings-out-the-worst-in-the-open-source-community./
-
+
https://forum.tinycorelinux.net/index.php/topic,27679.0.html - xlibre_new_xorg_fork
-
It took me a while to digest the basics of X* but here's what I've discovered so far, through http://tinycorelinux.net/16.x/x86_64/tcz/src/xorg/:
xorg-server_fbdev.patch
xorg-server-21.1.16-tearfree_backport-1.patch
These and, supposedly, many others are already included in XLibre.
The xlibre xserver only concerns Xorg, not X11, xlib, etc.
Compiling wasn't hard:
wget -qO- https://github.com/X11Libre/xserver/archive/refs/tags/xlibre-xserver-25.0.0.7.tar.gz | tar -xz
cd xserver-xlibre-xserver-25.0.0.7/
mkdir build
cd build
CC="gcc -flto -mtune=generic -Os -pipe -fcommon" CXX="g++ -flto -mtune=generic -Os -pipe -fno-exceptions -fno-rtti -fcommon" meson --prefix=/usr/local --sysconfdir=/etc --libexecdir=/usr/local/lib/xorg --buildtype=plain -Dsuid_wrapper=true -Dxkb_output_dir=/var/lib/xkb -Ddefault_font_path=/usr/local/lib/X11/fonts/misc,/usr/local/lib/X11/fonts/TTF,/usr/local/lib/X11/fonts/OTF,/usr/local/lib/X11/fonts/Type1,/usr/local/lib/X11/fonts/100pdi,/usr/local/lib/X11/fonts/75dpi -Dsha1=libcrypto -Dlog_dir=/var/log -Dsystemd_logind=false -Dglamor=true ../
sudo ninja install
However, I was unable to execute it successfully. It seems that it tries to run, the screen goes black, but nothing appears. Perhaps it is necessary to recompile the video drivers?
-
For future TC17, the stop of Xorg development/patches maybe will force use of Xlibre :P to avoid Xorg "vulnerabilities" which A.I. will discover. This will be a challenge (I guess) because many applications in TC were focused to run Xvesa/Xfbdev/Xorg for smaller size storage/RAM gain. But Xlibre is not yet large tested (is work in progress) and corporate money will push Wayland development and the crowd of developers will develop for future wayland type apps (firefox, libreoffice, mpv, KDE).
Compatibility with (very) old structure could have the fate that DSL / Slax distro suffered.
-
I wonder if it might make sense to keep Xvesa and Xfbdev, but drop the rest of x11 in favour of wayland.
With flwm-1.4 and labwc the tinycore flwm gui applets seems to work well in CorePure64.
-
...wayland.
It looks promising. Without an NVIDIA graphics card, Wayland has become easier on TinyCore.
(https://files.catbox.moe/0o5818.png)
However, I find all the dependencies that are loaded hellish, not to mention being forced to load everything related to Xorg, when I could have a Wayland environment without Xorg. I think the Wayland-related packages could be restructured.
-
Wayland without Xwayland (an extra layer to run X11 apps) is just a dream for now, because many applications still ask for X11 (ex: gnumeric). The difference between Xorg and X11 is that Xorg asks for all X11 dependencies PLUS its drivers (xf86* input/video) + its video firmware(<5-10MB). And some Xorg drivers (AMD/Nvidia) pull big size files (+ LLVM libs of 20-30MB).
Ex: if you just want a small distro (tinycore?) with only Firefox, then bad luck; it drags GTK3+deps, all X11 + video firmware + ffmpeg (for decode acceleration). Oh boy, the diff between TC/ AplineLinux and other (relative bloated) distro then becomes smaller and smaller; and if you then want some libreOffice or libreCAD or graphics/audio editing software then is game over.
-
Wayland-only test versions were made for aarch64 and x86_64, see http://tinycorelinux.net/15w.x/
Anything that used gtk3 or gtk4 should work without any x11 libs, but I seem to recall that one or two apps had direct deps rather than via gtk3/4.
-
"Anything that used gtk3 or gtk4 should work without any x11 libs".
Thanks Juanito! this is news for me, I am still learning (sometime bad/wrong things, it seams) using official docs (which is misleading if they are old).
-
Wayland-only test versions were made for aarch64 and x86_64, see http://tinycorelinux.net/15w.x/
Hello, Juanito. This is exactly what I need right now. Is there any chance of updating to 16.1? In addition, taking advantage of this shipment, please consider using -O2 -s instead of -Os, as it is extremely beneficial for x64.
-
"Anything that used gtk3 or gtk4 should work without any x11 libs".
Note that I’m referring to the Wayland-only versions of gtk3/4 in the test repos.
-
This is exactly what I need right now. Is there any chance of updating to 16.1? In addition, taking advantage of this shipment, please consider using -O2 -s instead of -Os, as it is extremely beneficial for x64.
Maybe you could try the 15w.x version first to see if you like it (labwc-config will set up the tinycore menus)?
-
This is exactly what I need right now. Is there any chance of updating to 16.1? In addition, taking advantage of this shipment, please consider using -O2 -s instead of -Os, as it is extremely beneficial for x64.
Maybe you could try the 15w.x version first to see if you like it (labwc-config will set up the tinycore menus)?
Worked: Firefox
I couldn't run any terminal.
Foot says: err: main.c:436: setlocale() failed
-
Foot says: err: main.c:436: setlocale() failed
Loaded mylocale, etc. But still:
locale -a
locale: Cannot set LC_CTYPE to default locale: No such file or directory
locale: Cannot set LC_MESSAGES to default locale: No such file or directory
locale: Cannot set LC_COLLATE to default locale: No such file or directory
C
POSIX
-
I couldn't run any terminal.
Did you try havoc?
-
Loaded mylocale, etc. But still:
locale -a
locale: Cannot set LC_CTYPE to default locale: No such file or directory
locale: Cannot set LC_MESSAGES to default locale: No such file or directory
locale: Cannot set LC_COLLATE to default locale: No such file or directory
C
POSIX
Hi Vaguiner. A UTF-8 locale is required for foot to work, as stated in its .info file. It seems your locale is not correctly configured. You need to see something along these lines:
$ locale -a
C
en_US.utf8
POSIX
$ locale
LANG=en_US.UTF-8
LC_CTYPE="en_US.UTF-8"
LC_NUMERIC="en_US.UTF-8"
LC_TIME="en_US.UTF-8"
LC_COLLATE="en_US.UTF-8"
LC_MONETARY="en_US.UTF-8"
LC_MESSAGES="en_US.UTF-8"
LC_PAPER="en_US.UTF-8"
LC_NAME="en_US.UTF-8"
LC_ADDRESS="en_US.UTF-8"
LC_TELEPHONE="en_US.UTF-8"
LC_MEASUREMENT="en_US.UTF-8"
LC_IDENTIFICATION="en_US.UTF-8"
LC_ALL=Once your locale is set correctly, foot should work. I use foot 1.21.0 in TCL16 x86_64 as my daily driver without issues.
-
Did you try havoc?
Got it
(https://files.catbox.moe/r813xa.png)
The whole thing feels more elegant, smooth, and responsive. Definitely a good thing.
-
Everything works as it should, so it's probably close to perfect. Heh, who would have thought that TinyCore, such a conservative and tinysystem, would now be one of the first to be able to run Wayland only?
(https://files.catbox.moe/t3rhaq.png)
Thanks, I'll keep that in mind. However, although very tempting, it's not feasible for me to stay on 15w.x with so many extensions that have already been updated on 16.x.
btw my onboot is like this:
mylocale.tcz
firmware-i915.tcz
havoc
labwc
firmware-atheros
firmware-iwlwifi
wireless_tools
wifi
nano
file
Xorg-fonts
Took me some time to realize that labwc was refusing to spawn because of missing extension Xorg-fonts
I also have no idea how to change the keyboard layout. In dwl, it's easier to do it through the source code.
"file" is missing by nano
-
I also have no idea how to change the keyboard layout.
In labwc it's done through environment variables, which you define in ~/.config/labwc/environment
I like US standard layout as default, with ability to switch to US international layout by pressing Shift+CapsLock. So, as an example, this is what my ~/.config/labwc/environment looks like:
$ cat ~/.config/labwc/environment
XKB_DEFAULT_LAYOUT=us,us(intl)
XKB_DEFAULT_OPTIONS=grp:shift_caps_toggle
XCURSOR_THEME=Bibata-Original-Ice
XCURSOR_SIZE=24
More details here:
https://github.com/labwc/labwc/blob/master/docs/environment
https://labwc.github.io/labwc-config.5.html#environment_variables
-
It will be nice if this will evolve in a TC wiki specifically dedicated to Wayland and its application.
Maybe short tips of what config to load, what options are for menu, terminal, keyboard, panel, taskbar etc.
They can be in each .info files, but centralized in a wiki page could be better (even if just concatenate of copy/paste *.info).
And maybe some links to developer source/docs for people who want to spend time to read the fine tune ups. (as GNUser already started listing few).
-
Hi nick65go
It will be nice if this will evolve in a TC wiki specifically dedicated to Wayland and its application. ...
Thank you for volunteering, and congratulations, you've been promoted to Wiki Author.
-
what options are for menu, terminal, keyboard, panel, taskbar etc.
Hi nick65go. If you are using a wlroots-based compositor such as sway or labwc, here is a helpful list of options:
https://github.com/solarkraft/awesome-wlroots
-
Hi nick65go
Thank you for volunteering, and congratulations, you've been promoted to Wiki Author.
@Rich: Thank you for your trust and your over-estimating of my skills :)
I am still on CachyOS with KDE (Kwin windows manager). But I will prepare something offline and message you when is suitable (after testing my findings) and when time will allow me to focus more on TC. Tiny-core still remains for me a nice project to promote and survive.
FYI: Until now, I never wrote any wiki articles and my English is not native. It could become embarrassing to me.
-
Hi Juanito, Rich, curaga, Paul_123. I'm pleasantly surprised to see that XLibre is taking off: Currently there are 535 contributors to its xserver, with a very active merge history. The XLibre developers seem seriously committed to maintaining and improving X.
Some OSes have no plans of abandoning X. Among those, some are moving from Xorg to XLibre (GhostBSD, for example: https://ericbsd.com/addressing-xlibre-change-and-ghostbsd-future.html).
What are your thoughts on TCL moving from Xorg to XLibre? Do you think such a move would add stability to TCL? I'd be interested in your thoughts on this. I'm willing to help with packaging and testing, of course.
EDIT: I'd also be happy with the status quo (Xorg) and a wait-and-see approach. Kindly let me know your thoughts--I've always been happy just going along with whatever TCL is doing :)
-
The silence is eloquent. I hear "status quo is preferable" loud and clear. Works for me :)
-
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.
-
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 ;D
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.
-
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.
-
The decision to be taken is perhaps not deciding between x11 and XLibre, but rather deciding between x11/XLibre and wayland.
Hi Juanito. Thank you very much for this detailed description of the state of affairs. While I am a bit surprised at your conclusion, I trust your judgment and experience. TCL will continue to shine in the future, with whatever extensions are available.
At the risk of digressing into an ode to TCL, TCL might be the only suckless distro that can actually be configured into a daily driver. Wherever TCL goes I will happily follow.
-
While I am a bit surprised at your conclusion
I'm not sure I made a conclusion :)
..but if I were to make a suggestion it would be:
x86: stick with x11 only
x86_64: not sure
armhf/aarch64: move to wayland only
-
I'm not sure I made a conclusion :)
Thanks for clarifying. Your suggestions make sense.
While I don't like the idea of moving any architecture to wayland only, I understand that there are many things that TCL as a distro--and I as a user--have to deal with that are outside our control.
P.S. Rant follows.
Pardon if I vent for just a second. Software such as systemd and wayland have caused a lot of fragmentation, uncertainty, and wasted precious resources (namely, human time and energy). I would know about wasted time and energy: I have invested well over 100 hours to make my TCL+labwc+sfwbar setup as productive as my TCL+fluxbox setup. I did that only to be prepared for the possibility of a future without Xorg. Truth be told, I was perfectly happy with fluxbox and actually prefer it over labwc+sfwbar.
TCL really does a tremendous job of creating beauty and order out of the chaos that is all-things-linux. For as long as I use linux, TCL is the distro for me. But on some days, the BSDs (which don't have systemd or wayland, and don't suffer from nearly the same degree of fragmentation as linux) sure look attractive. As long as TCL enables me to stay productive and relatively sane, I have no plans on ditching linux for one of the BSDs. Thank you for all you do, Juanito.
-
a humble thought.
can we move this thread to "General TC Talk" and make it a sticky(pinned to stay visible at the top)?
as always, huge kudos to everyone here for making this community(and TCL) such a pleasure to enjoy!
also i concur with @GNUser rant in reply number 32:
https://forum.tinycorelinux.net/index.php/topic,27701.msg181581.html#msg181581