Tiny Core v16.2

[Juanito]

Team Tiny Core is proud to announce the release of Core v16.2
http://www.tinycorelinux.net/16.x/x86/release
http://www.tinycorelinux.net/16.x/x86_64/release

Changelog for 16.2
* provides.sh: Add -f switch to show full paths from mbartlett21
* provides.sh: Remove extra \n from mbartlett21
* tce-load: Replace  find  with  [ -d DIR ]  for kernel module detection from Rich
* tc-functions: update from VaguinerG
* etc/profile: removed obsolete path for scm from aus9
* etc/skel/.profile: create /run/user/$(id -u "$USER") from aus9/bdantas
* etc/skel/.profile: export XDG_RUNTIME_DIR from Rich

Note that several wayland compositor extensions - gnome-session, labwc, sway, weston - create XDG_RUNTIME_DIR - this should not create problems, but should be removed from startup scripts in future

[GNUser]

Hi Juanito. I grabbed the new corepure64.gz (version 16.2) to test it. 

I tried the rootfs in CorePure64-16.2.iso, the rootfs in TinyCorePure64-16.2.iso, and the rootfs directly available in http://www.tinycorelinux.net/16.x/x86_64/release/distribution_files/

It seems /etc/skel/.profile does not contain the expected changes related to XDG_RUNTIME_DIR.

[Rich]

Hi Juanito
The XDG_RUNTIME_DIR changes are in github but missing in
rootfs.gz and rootfs64.gz in the release/distribution_files
directories.

[Juanito]

Hmm - I don't know what happened there, thanks for pointing that out.

Hopefully things are OK now?

[GNUser]

Hi Juanito. I tested corepure64.gz from the distribution_files directory and it looks good. Thanks!

[gadget42]

admins/mods: if this needs moved and/or titled appropriately/suitably then by all means please do.

To Juanito/curaga/Rich/Any/All, thoughts? opinions? continued advancement of _maximum_planned_obsolescence_ ?
(seems tcl people recognize and embrace _extend_recycle_repurpose_reuse_ and have a good track record of overall hardware support longevity)

subject/topic:
Introducing architecture variants: amd64v3 now available in Ubuntu 25.10

for reference see:
https://discourse.ubuntu.com/t/introducing-architecture-variants-amd64v3-now-available-in-ubuntu-25-10/71312

and:
https://en.wikipedia.org/wiki/X86-64#Microarchitecture_levels

found-via/hat-tip/kudos:
https://dev1galaxy.org/viewtopic.php?id=7496

quoting: https://dev1galaxy.org/viewtopic.php?pid=58863#p58863

Those levels were invented a few years ago by "bigtech" to obsolete older hardware and force people to upgrade to newer PCs now that the switch from 32 bit to 64 bit is no longer enough to obsolete additional older hardware. It's sort of the next step after stopping support for 32 bit cpus.

IBM (Redhat) and Suse have already gone down this road, their recent releases don't work on older 64 bit cpus any more.

I see it as a good reason to become more independent from the corporate Linux world (primarily IBM/Redhat, but also Suse and Ubuntu) and focus on pure community run distros that don't have agendas and profit motives.

That said the way Ubuntu is currently approaching this for now is sensible, as they are building packages for the different levels, so for now they aren't obsoleting older 64 bit cpus, but the cinic in me makes me think that this is just a "boiling the frog slowly" approach to avoid a shitstorm, i.e. in a few years they will likely be discontinuing support for older variants.

BTW, wikipedia lists who is behind this:

In 2020, through a collaboration between AMD, Intel, Red Hat, and SUSE, three microarchitecture levels (or feature levels) on top of the x86-64 baseline were defined: x86-64-v2, x86-64-v3, and x86-64-v4. These levels define specific features that can be targeted by programmers to provide compile-time optimizations.

https://en.wikipedia.org/wiki/X86-64

[nick65go]

Code: [Select]

❯ /lib/ld-linux-x86-64.so.2 --help | grep x86
Usage: /lib/ld-linux-x86-64.so.2 [OPTION]... EXECUTABLE-FILE [ARGS-FOR-PROGRAM...]
This program interpreter self-identifies as: /usr/lib/ld-linux-x86-64.so.2
  x86-64-v4
  x86-64-v3 (supported, searched)
  x86-64-v2 (supported, searched)not all x86-64-v* libs or apps will improve performance. But for a proper app (ex: ffmpeg) speed can be 10%-20% more. The SUSE approach is to have branches for specific basic libs (ex: libz) so the loader will auto-chose at run-time the proper version for your CPU. But hey, they have a lot of resources (servers, people, time) to keep/update their x86-64-v2 and normal x86 etc.

The big problem will start if/when main software (ex: firefox, mesa)  will be be only x86-64-v3/4 from upstream developers.For common users a degrade speed of 10% will not be initially noticed (slowly boil the frog) then CPU firmware (updates with clear intention of obsolete), lower kernel speed (to avoid spectre / meltdown), increased bloated software (see rust language). In the end users will be forced to upgrade the hardware. I guesstimate in 5-10 years no 486 CPU will run and will not be manufactured.