Debian officially takes out i686 disk images!

Debian 13 “Trixie” has just been released today to bring many improvements and new versions of packages, such as GNOME 48, KDE Plasma 6.3, and Linux 6.15 LTS. As we have speculated earlier back last year that the i686 support was declining, further evidenced by Debian taking out the i686 kernels, our speculations made last October were made right.

Debian has joined the majority of the distros that no longer provided the i686 architecture support for kernel and for installation disks. Starting from Debian 13 “Trixie”, you can no longer use the Debian installer disks made for the i686 processors. Anyone who still uses the i686 version of Debian 12 “Bookworm” won’t be able to upgrade to Trixie.

If you’re looking into upgrading to Trixie, consider one of the following options:

• If your computer’s processor supports the 64-bit instructions (the oldest processors that support them are AMD Athlon 64 and Intel Pentium 4 Prescott, Cedar Mill, or higher), you’ll need to back up your crucial data and re-install Debian with the 64-bit installers.
• If your computer’s processor only supports 32-bit (older Intel Pentium 4, Pentium 3 or older, and AMD Athlon XP or older), you have one of the two options.
  • Stay on Debian 12 “Bookworm”
  • Find another Linux distribution that supports 32-bit, such as Arch Linux 32

Thanks to @geerlingguy for addressing the elephant in the room.

@RaspberryPi dominates the #SBC market because they know how to write #documentation and build #drivers that get accepted into #mainline #Linux kernel.

• The best specs and hardware is useless if it needs intimate knowledge on how to roll one's own kernel. And oftentimes one doesn't even get proper drivers and reproduceable build instructions but just some "vomited" out bootable images to dd onto a microSD!

That's why my #BananPi Zero M2 is still unused to this day: It's way too inconvenient and whilst I do want to support it someday, it's just not a good start when the 1st #RasperryPi's documentation to this day is still the bare minimum and vendors can't be assed to do that.

• The only reason #amd64-based #SBC|s don't have the same issues as #arm64 is because #BIOS & #UEFI-boot alongside the way #hardware is initialized make it trivial to make it "go brrrr..."

Funnily enough, it takes more than 5 minutes to bump the char limits on Mastodon's toots

It's been compiling for ages (I'm just bumping to 1000) and doesn't seem to get anywhere, almost as if it was stuck for the arm64 target

On the other hand, the amd64 target is working like a charm, so I guess it has to do with architecture emulation ?

@jbqueru OFC and in terms of #RISCv vs. #ARM it won't be competitive for quite some time as ARM includes a lot of #proprietary and #patented #PowerSaving technologies that are just not available outside of said closed ISA.

• I do thus treat #ARM64 like #amd64: A "black box" that I cannot audit, verify or control beyond what it allows me to.

@jbqueru Also I hope for #RISCv to be the #ISA of the future for long-term #OpenSourceHardware and support.

#ARM64 - just like #amd64 - is yet another proprietary ISA and almost all devices with it in terms of #Laptops have #AntiRepairDesign like #Apple's #MacBook|s that self-destroy their #SSD|s which also contains it's #EFI / "#BridgeOS", making machines with fried SSDs 'braindead'…

And yes, #RAM to also fails and making it not fully replaceable and upgradeable is inherently bad and I'm still mad at @frameworkcomputer for their botched #FrameworkDesktop #PC!

• Cuz it's neither necessary nor beneficial for a #Desktop PC, unlike with the #Framework12 where the #SoC used only supports single channel and a single SODIMM so it makes sense for them to take that into account.

@JessTheUnstill @bohwaz @punkfairie @ajsadauskas @tomiahonen @fuchsiii Exactly...

Coincidentially, that's why #Android (and #iOS) doesn't let users have #root access because billions of devices owned by mostly "#TechIlliterates" that hardly get #SecurityUpdates would be an even bigger risk if they didn't boot a locked-down #ROM image, thus only allowing for #malware in user-privilegued userspace!

• I'd even go so far that I'd wish for @torproject to basically merge fmr. #FirefoxOS / #KaiOS & @tails_live / @tails / #Tails to build a #privacy-focussed #ROM for #Smartphones and #Tablets i.e. "#TailsMobile" or sth.

Cuz having a mobile OS that shoves everything through #Tor and only allows #userspace-Apps in the form modern web technologies would be a big #security and #privacy gain.

• Not to mention #amd64 is on it's way out and inevitably they gotta have to transition to supporting #arm64 and eventually #RISCv-#64bit at some point.

Release is coming - help us with testing!

https://www.armbian.com/newsflash/release-is-coming-3/

We've just published the first multi-arch Bluefin-LTS builds! Bluefin-LTS has been an amazing place to test new things and this worked amazingly well with the new Github runners!

Armbian weekly news: https://www.armbian.com/newsflash/armbian-weekly-highlights-8/