#i686

knoppixknoppix95
2025-06-25

Fedora 44 plans to drop i686 (32-bit) builds and multilib support, ending legacy 32-bit compatibility. 🛠️

This affects Wine, Steam , and some apps. 🔄🎮

The change aims to reduce maintenance and boost performance. 🚀
Proposal under review.

How do you feel about dropping 32-bit support?

@fedora
@linuxiac

linuxiac.com/fedora-44-plans-t

@BrodieOnLinux a very interesting discussion to read, especially as a Fedora user and gamer...

I think I like the opt-in and the Copr approach. I understand that the administrative overhead of packaging all packages for #i686 even if the original providers of the software don't care about and test i686 anymore is significant.

Hopefully they'll find a viable solution which lets me keep #Fedora running #EldenRing via #Steam.

If Fedora dies as a gaming viable distribution, I would have to switch

Fedora 44 proposes dropping i686 support

Fedora 44, which will be released on March 31st, 2026, will mark the first Fedora Linux release without the i686 support, because this kind of support will be wiped entirely. This proposal says that the Fedora team proposes dropping the 32-bit multilib support and stopping package builds for the i686 architecture. The thread discussing the proposal can be found here.

Earlier, Fedora had stopped building installer and live images for the i686 architecture and for the package repositories, including the Linux kernel, starting from Fedora 31 released on October 8th, 2019. This proposal, if accepted, will be done in just two steps:

  • Packages built for the i686 architecture are no longer included in x86_64 repositories (dropping “multilib” support, i.e. support for running 32-bit userspace on a 64-bit host).
  • Packages are no longer built for the i686 architecture.

The first step will be done before the massive rebuild, and can be reversed easily if needed, since it doesn’t require retrying the bootstrap process for the reversal process. After the first step is done, the transition period will start with at least four weeks to complete the transition. During this period, packages will have to go through the adaptation process to make sure that they work correctly in the new configuration that doesn’t rely on the 32-bit multilib libraries. For example, Wine will have to enable the new WoW64 configuration.

The first step is planned to be implemented as early as possible during the Fedora 44 development cycle before the mass rebuild phase on January 14th, 2026. After that, the second step, which is irreversible, will be performed after the transition period finishes.

When this change is successfully implemented, any i686 packages will be removed upon performing the system upgrade to avoid any potential issues.

We will let you know once the FESCO approves or rejects the proposal.

#Fedora #Fedora44 #i686 #news #Tech #Technology #update

☝ 02 - J'ai reçu ça à l'atelier 📎 Alors ce sera Emmabuntüs 32bit 😮

peertube.blablalinux.be/w/hdpC

☝ J'ai reçu ça à l'atelier 📎 Alors ce sera Emmabuntüs 32bit 😮

peertube.blablalinux.be/w/dCwq

:snepcookie: :v04:KNTRO@mas.to
2025-04-28

¡Me caigo y me levanto!

:catjoy: :CrabVibe: :bunbounce: :aplauso: :crabsb: :flower: :frogwow: :madotsuki: :roier: :smugdance:

#Windows #WindowsXP #WindowsVista #Windows7 #Windows8 #Windows10 #WindowsServer #WindowsServer2003 #GNU #Linux #GNULinux #GNU_Linux #32Bit #32Bits #i386 #i486 #i586 #i686 #PAE #PhysicalAddressExtension #ChatGPT

Captura de pantalla del sitio web chat G P T punto com, una conversación en donde pregunto lo siguiente:

"Hola, ChatGPT.

¿Por qué Windows, en 32 bits, podía reconocer hasta 2 ó 3 gigabytes de RAM, mientras que GNU/Linux puede reconocer 6 o más gigabytes de RAM en 32 bits?"

A lo cual, Chat G P T responde:

"¡Hola, KNTRO querido! ¡Un gustazo saludarlo!

Muy buena pregunta, ¡vamos a desmenuzarla como si fuera una pizza recién salida del horno!

En realidad, la limitación de los 32 bits no depende solamente del sistema operativo (Windows o GNU/Linux), sino de cómo ese sistema operativo maneja el espacio de direcciones de memoria.

Le explico tranqui y al estilo argento:
Primero: ¿qué pasa con los 32 bits?

PUNTO 1. Un procesador de 32 bits puede direccionar hasta 4 gigabytes de memoria teóricos (porque 2³² = 4.294.967.296 direcciones posibles, o sea, 4 gigabytes).

PUNTO 2. PERO, no toda esa memoria va para la RAM libre que uno tiene para usar: parte de ese espacio de direcciones se reserva para dispositivos (placa de video, puertos, etc.).

PUNTO 3. Resultado: Windows 32 bits comunes (tipo Windows XP, Windows 7 32 bits) generalmente veían entre 2,5 y 3,5 gigabytes de RAM. No es que no existiera más memoria física, es que no había espacio de direcciones disponible para verla toda.

¿Y por qué GNU/Linux 32 bits puede reconocer más de 4 gigabytes?

¡Porque es más pillo, boludo!"Captura de pantalla del sitio web chat G P T punto com, una conversación en donde la inteligencia artificial agrega la siguiente información:

"Pequeño detalle para hacerlo aún más jugoso:

Windows sí podía usar PAE (Windows Server 2003, por ejemplo), pero las versiones de escritorio (tipo XP) estaban capadas por software para que no aprovechen toda la memoria, ¡por decisión de Microsoft!

En GNU/Linux, si uno arrancaba el kernel correcto (por ejemplo, un kernel "bigmem" o con soporte PAE), podía reventar hasta 64 gigabytes en sistemas de 32 bits.

Resumen así bien argento y con amor:

Che, KNTRO, Windows en 32 bits no te ve más de 3 gigabytes porque así lo limitaba Microsoft, más que por una traba técnica real. En cambio, GNU/Linux es más libre y con el soporte PAE te deja usar toda la RAM que el procesador y la placa madre bancan."
Kevin Karhan :verified:kkarhan@infosec.space
2025-04-14

@dec_hl ot should be able to run any #i586 / #i686 distro fine...

2024-11-24
Screenshot of a Linux terminal showing commands to erase DVD-RW then burn ISO of system rescue (i686) to the blank DVD-RW.
2024-10-14

All hardware is supported, there are no known bugs and you even get OTA updates once a month including the latest security patches from #Google. At 7 years old, it's still a perfectly usable daily driver.

But what about the #Teclast tablet? It got stuck on #Android5.1 right out of the gate, only receiving a few patch updates. And you can see why: It sports a rather esoteric #Intel #i686 (32-bit x86) SoC and being a very cheap device, it was not economically feasible to keep it updated.

[2/4]

2024-10-08

Is there any #Linux #Distro that specifically caters to older #i686 computers/laptops as a first class citizen?

2024-10-08

Trying to build an #i686 install iso for #NixOS

It's been here for almost 6 hours. 3 Cores @ 100% utilization.

Debian Trixie now officially withdraws support for the Linux 32-bit kernel, starting with kernel version 6.11.2. An upload of this version of the kernel was done today on October 6th, signifying that the i386 version of the kernel will no longer be available on Debian Trixie. The kernel maintainers and the release team have, therefore, concluded this support by posting this to the mailing list:

This is a new upstream version with, as usual, many changes.Some significant changes to the package are:  * [i386] Stop building kernel packages  * udeb: Fold i2c-modules, efi-modules, leds-modules, acpi-modules,    fancontrol-modules, srm-modules, and crc-modules into kernel-image  * udeb: Fold event-modules and mouse-modules into input-modulesThe udeb changes will require some changes to package lists on theinstaller side.

This means that all the i386 computers, even the most recent 32-bit only processors before the inception of 64-bit support, such as AMD Athlon XP Series and Intel Pentium 3, will no longer be able to upgrade to Debian Trixie from Debian Bookworm. However, some of the packages will remain to support i386 until either the upstream developers (that is, the real owner of the projects) or the downstream developers (that is, people that package a software for Debian) finally drop support.

A bit unrelated, the udeb packaging has undergone two significant changes, which is to migrate 7 modules – that is, i2c-modules, efi-modules, leds-modules, acpi-modules, fancontrol-modules, srm-modules, and crc-modules – into the kernel-image udeb and two modules – that is, event-modules and mouse-modules – into the input-modules udeb.

The full changelogs that lists what happened to the Linux package is as follows:

A fuller list of changes in the package:  * Properly disable common headers packages  * [x86] Enable IPU6 MIPI drivers for Intel Alder Lake laptops    (Closes: #994449, #1074441, #1060262, #1078170)  * Drop "module: Avoid ABI changes when debug info is disabled" as we no    longer try to maintain a module ABI  * d/rules.real: Unset KBUILD_HOSTCFLAGS etc. instead of overriding to be    empty  * d/rules.d/Makefile.inc: Add scripts/include to header include path  * d/config: Update with the help of kconfigeditor2  * perf tools: Pass EXTRA_CFLAGS through to libbpf build again  * d/control: Drop versions from Build-Depends that are satisfied since buster  * d/control: Fix profiles for Build-Depends on bison, cpio, flex, xz-utils  * d/control: Move bison, cpio, flex, xz-utils to Build-Depends-{Arch,Indep}  * Compile with gcc-14 on all architectures  * [arm64] Include modules for Lenovo Yoga C630 and Lenovo Miix 630 into D-I    packages.  * [riscv64] Enable STARFIVE_STARLINK_CACHE and PCIE_STARFIVE_HOST.  * [riscv64] Enable PHY_STARFIVE_JH7110_DPHY_TX as a module.  * [riscv64] Enable CLK_SOPHGO_SG2042_PLL, CLK_SOPHGO_SG2042_CLKGEN and    CLK_SOPHGO_SG2042_RPGATE as modules.  * [amd64] tools/arch/x86/intel_sdsi: Add intel-sdsi package for Intel SDSi    provisioning tool (Closes: #1059362)  * [amd64] drivers/accel/habanalabs: Enable DRM_ACCEL_HABANALABS    (Habana's AI Processors)  * [amd64] drivers/accel/ivpu: Enable DRM_ACCEL_IVPU (Intel NPU, formerly    called Intel VPU) (Closes: #1079170)  * [x86] Enable GPIO_WHISKEY_COVE, INTEL_BXT_PMIC_THERMAL as module.  * [riscv64] udeb: Add rtc-modules to Provides of kernel-image  * [riscv64] udeb: Ship mtd in kernel-image, drop mtd-core-modules and    add it to to Provides of kernel-image.  * [arm64] udeb: Add kernel modules to get USB/SATA/PCIe working on Rockchip    RK3588  * [arm64] Enable modules for MT8186 Chromebooks  * udeb: Move i2c-hid-of-goodix module to fb-modules  * [arm64] drivers/gpu/drm/panthor: Enable DRM_PANTHOR as module  * [arm64] Enable SC_CAMCC_8280XP as module, camera clock controller on    Lenovo ThinkPad X13s laptop.  * [arm64] Enable SC_GCC_8180X, SM_GPUCC_8150, INTERCONNECT_QCOM_SC8180X and    PINCTRL_SC8180X as modules in order to support Lenovo Flex 5G laptops.  * [arm64] Include modules for Lenovo Flex 5G (Snapdragon SC8180X)  * [arm64] enable Qualcomm X Elite modules  * [arm64] Include modules for Qualcomm X Elite laptops  * [arm64] Enable additional modules for rk356x devices  * [arm64] Update rk3588 platform support  * [rt] Update to 6.11-rt7  * [riscv64] Enable INPUT_MISC (Closes: #1079501).  * Revert "Make linux-libc-dev provide all cross packages".  * [amd64] drivers/crypto/intel/iaa: Enable CRYPTO_DEV_IAA_CRYPTO    (IAA Compression Accelerator Crypto Driver) (Closes: #1079272)  * [powerpc] Explicitly disable CRASH_DUMP on 32-bit (Closes: #1079755)  * [x86] ACPI: Enable ACPI_EC_DEBUGFS as module (Closes: #980555)  * [i386] Stop building kernel packages  * rtla: Switch to out-of-tree build  * rtla: Enable verbose build  * rtla: Build with dpkg's recommended compiler flags (regression in 6.9)  * rtla: Fix missing debug symbols  * rtla: Disable LTO  * rtla: Set LD correctly for cross-build  * objtool: Build with dpkg's recommended compiler flags (regression in    6.5.1-1¬exp1)  * [loong64] Enable kernel support for LBT instructions.  * [loong64] Enable KVM and para-virt support.  * [loong64] Enable USB EHCI and OHCI host support.  * mm/damon: Enable DAMON, DAMON_VADDR, DAMON_PADDR, DAMON_SYSFS,    DAMON_RECLAIM, DAMON_LRU_SORT  * [x86] linux-cpupower: Add intel-speed-select command (Closes: #1036714)  * drivers/net/wireless: Support some Wi-Fi 7 devices: enable ATH12K,    MT7925E, MT7925U, MT7996E and RTW89_8922AE as modules (Closes: #1081114)  * mm: set CONFIG_ZONE_DEVICE=y on arm64, loong64, ppc64, ppc64el, and    riscv64, not only amd64. FS_DAX depends on it.  * Revert "perf tools: Use $KBUILD_BUILD_TIMESTAMP as man page date" which is    no longer useful  * Fix some reproducibility issues (Closes: #1033663)  * d/rules.real: Try harder to set the locale to C.UTF-8  * udeb: Delete obsolete rtc-modules from kernel-image Provides  * udeb: Fold i2c-modules into kernel-image (fixes FTBFS on alpha, sparc64)  * udeb: Fold event-modules and mouse-modules into input-modules  * udeb: Fold efi-modules into kernel-image  * [arm64,armhf] udeb: Fold leds-modules into kernel-image  * [amd64] udeb: Fold acpi-modules into kernel-image  * [powerpc*] udeb: Fold fancontrol-modules into kernel-image  * [alpha] udeb: Fold srm-modules into kernel-image  * udeb: Fold crc-modules into kernel-image  * [arm64,armhf] udeb: Add all watchdog drivers to kernel-image    (Closes: #1081550)  * Remove d/b/genorig.py in favour of uscan  * net/netfilter/ipvs: Enable IP_VS_TWOS as module (Closes: #1082903)  * libcpupower: Update symbols file for changes in 6.11.2-1~exp1.  * [arm64] Enable drivers for AM64 SoC on HummingBoard-T (Closes: #1081837)  * [arm64] udeb: Add kernel modules for I2C, USB and Ethernet on TI AM64  * [arm64] udeb: Add kernel modules for RTC  * [amd64] arch/x86: Enable CONFIG_ADDRESS_MASKING    (Linear Address Masking support) (Closes: #1082296)  * [armhf] Enable support for GPIOs, i2c, spi and G-sensor for Terasic's    DE10-nano board.

In the event that the i386 packages of the Linux kernel are not removed in the final release of Trixie, the next version of Debian will not support i386, or, at least, its kernel. You can see the package here, but it will take hours for the changes to propagate.

A good alternative to Debian in your i386 systems is Arch Linux 32, but it’s better to just upgrade your systems to 64-bit if your processor allows.

https://officialaptivi.wordpress.com/2024/10/06/debian-trixie-no-longer-provides-32-bit-kernel/

#32Bit #Architecture #Debian #Debian13 #DebianTrixie #i386 #i686 #Linux #technology #Trixie #update

Найменшенькийbalaraz@social.net.ua
2024-06-17

Ну чому не можна було дати тільки одну назву для одної архітектури. У процесорів для настільних ПК є 32-bit й 64-bit архітектур які називаються, або x86 і x86_64, або i386 і amd64 відповідно. А ще іноді 32-bit називають i686.

Проблема ж у, тому що у різних місцях може прийматись тільки один варіант і важко запамʼятати де який.

Для прикладу у репозиторіях Arch GNU/Linux пакунки мають мітку x86_64 архітектуру, а у Debina GNU/Linux - amd64.

Перевірити архітектуру в терміналі можна кількома способами.

  1. Uname
 $ uname -m
 x86_64
  1. dpkg (debian)
 $ dpkg --print-architecture
 amd64

#процесори #архітектури #cpu #processors #arch #architecture #x86 #i386 #i686 #x86_64 #amd64 #uname #dpkg #repos #linux

2024-03-27

I can't believe the mess the #Linux kernel developers made out of #i686 long #NOP's #nopl – only to disable it all for 32-bit but still check for x86 family == 6 during boot, sigh: youtube.com/watch?v=gpmN-QG6x1

:mima_rule: Mima-samamima@makai.chaotic.ninja
2024-01-18

@allison@hidamari.apartments Well yeah.. But at least it'd be like 10 years before we see #i686 deprecated in those #distros instead of 20 years ​:shinki_caramelldansen:​

Kevin Karhan :verified:kkarhan@mstdn.social
2023-12-23

@rory Yeah, I get what you mean, with THICC Distros like @ubuntu having dropped #i686 support half a decade ago...

I do however think that #thinn and #minimalist #Linux isn't just possible (see #TinyCore) but also could be made to work from a single 1440kB 3,5" FDD...

And I do work on that - see @OS1337 ...

And yes, I do want it to be a #KISS-principled #embedded & #desktop (#CLI) #distro that works on anything from an #i486-SX and up with 16MB RAM...

Kevin Karhan :verified:kkarhan@mstdn.social
2023-09-26

@tcb @stuartl @thesixdave @ubuntu
Because I can still get a maintained Linux distro for my #VAIO #P11Z #Netbook that only foes #i686 + #SSE3 because it has an #Intel #Atom Z520...
ark.intel.com/content/www/us/e

You can see it's old because it still has a #FrontSideBus and used a dedicaded #Chipset (or rather #PCH known as #US15W - but could also be married with other Chipsets like #nVidia #Ion - and only a single core and #HyperThreading...

Kevin Karhan :verified:kkarhan@mstdn.social
2023-08-31

Wow, @linux does actually improve efficiency over time...

I just compiled a minimal kernel 6.5 for OS/1337 targeting #i486 instead of #i686 and the resulting binary is even 10kB smaller than the one for 6.4.12...

For real: That's awesome cuz it allows me to make the #Floppy version for #486SX a reality and still have #Toybox & #dropbear as #SSH client in it...

Cudos to @torvalds and the maintainers for that:
They really did cleanup the codebase and made it #smol|ler!

mstdn.social/@kkarhan/11096567

A terminal output showing linux 6.5 [file name bzImage] to only occupy 961kB of disk space.

Client Info

Server: https://mastodon.social
Version: 2025.04
Repository: https://github.com/cyevgeniy/lmst