[akoster]

It is a shame that many major Linux distributions are dropping 32-bit x86 support. I used to be able to say with confidence that the old laptop or PC in your garage can run any major Linux distribution, breathing new life into aging hardware. For example, I have an old ThinkPad T42, which I use to test out new Linux distros, which incidentally, is currently running Arch. Using older hardware increases the chances that stable drivers will be available. I put in the CD (or flash drive), boot up, and everything seems to just work(tm). Its no speed demon, but its usable. But now with Arch dropping support for a significant amount of commonly available and being a major, top-level distribution, I feel I now must make specific recommendations for Linux newcomers to try rather then have them waste time downloading a large ISO, transferring it to a flash drive or disc, to find they are unable to boot up with it. This may cause users to give up before even giving Linux or open source software an honest try.

Also, I wonder what this means for the Intel Quark SoC (found in Intel Edison and Intel Galileo boards). Does this mean Arch Linux wont be an option for these devices?

Despite RHEL 7/CentOS 7 not supporting 32-bit x86, there is now a community-led effort to port it to 32-bit x86. I wonder if Arch would consider doing the same (supporting 32-bit x86 as an alternative architecture).

[kogepathic]

tl;dr - due to a CPU bug, you can't run normal i686 distributions on the Quark anyway, and support in mainline Linux is still shit 3 years after release.

> Also, I wonder what this means for the Intel Quark SoC (found in Intel Edison and Intel Galileo boards). Does this mean Arch Linux wont be an option for these devices?

I have a device based on the Quark SoC. Support is abysmal for this SoC, especially considering it's been on the market for 3 years (2014). Intel has clearly abandoned this market segment since their repeated headlines of new Quark SoCs has totalled exactly 0 new product launches since 2014.

In mainline Linux I can't use the onboard Ethernet because of some modifications Intel made to the stmmaceth module that weren't pushed upstream. The internet is full of people trying to run newer versions of Linux on their Quark hardware and Intel telling them to use old Yocto Linux BSPs [0] because they can't be bothered to clean up and push their code upstream (or upstream refused to merge it, I don't know and haven't checked).

Also the Quark is affected by the F0 0F bug, so you can't run normal distributions on it because processes will segfault. [1]

> It might solve this issue for Intel Quark, but it would break for any multicore processors. This is not something acceptable.

Honestly I'm not sure why anyone would want to buy a Quark based system. Support is bad, performance is terribad, and power consumption is also terrible (my Quark system idles at 7W, and consumes 2W when in S5 "off" state). You would be very wise to look for an ARM instead of choosing this dumpster fire of a CPU.

[0] https://communities.intel.com/thread/105047

[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=738575

[akoster]

Thanks for your post (and tl;dr comment too - I need to work on being more concise :-). I own no Quark powered boards but have some friends who do. It's a shame that they fall into the category of boards with poor software support (and even more of a shame since they are based off the Intel architecture). I own a few raspberry pi's and have been extremely pleased that even my rPi model B+ from 2012 still gets support and updates (and hopefully will for a while longer now that the rPi zero exists with similar hardware). Friends would brag about the faster or cheaper O-droid, Pine-64 or Banana-pi, but with dismal software support, I couldn't justify even a descent performance boost. This reminds me of the little I know of the Android ecosystem, where a tablet I bought in 2013 is still stuck on Jelly Bean, while my 2012 iPhone 5 still gets updates. I wish there was some sort of regulatory label put on these devices (or boards) that would clearly state how many years of support they would commit to.

[kogepathic]

> I wish there was some sort of regulatory label put on these devices (or boards) that would clearly state how many years of support they would commit to.

As someone who owns a Raspberry Pi, PandaBoard, BananaPi, Orange Pi, and Intel DK200 I've learned this important life lesson:

Always assume that the most support you'll ever receive for the board is on the day you buy it.

Apart from the Raspberry Pi, no one else gives half a shit to fix bugs or even provide distro updates for their hardware.

Cheap Chinese boards are even worse for this. They'll typically take the SoC kernel (an ancient version several years out of date with the worst patches you've ever seen) and roll some shitty old distro around it (e.g. Ubuntu 14.04, Android 4.4).

A good recommendation for people looking to buy a board is to look at the Armbian [0] or Arch Linux ARM [1] supported hardware (read the notices!!!) and buy that.

[0] http://armbian.com

[1] https://archlinuxarm.org/

[scandox]

Supporting this view. Got given a Quark SoC based box by someone at Intel. Tried to get something going with it, only to realise I had to use WindRiver Linux. Tried to obtain toolchain for building even simple software for it online, couldn't find it. Asked contacts at Intel: radio silence.

[kogepathic]

If it's a DK200, then I've built grub to bypass secure boot.

You can boot other Linuxes on it (e.g. Yocto) but as per my parent comment, not much will work.

I have an SPI image and instructions to flash if you're interested. You'll need an SPI programmer like the ch341a.

I think Intel is violating the GPL by not providing sources, since they include a written offer and GPL requires source availability for 3 years.

I tried to download the WindRiver SDK using the code in the box, and Intel told me the product was no longer receiving support...

[scandox]

Honestly this all occurred over a year ago and I just ditched it

[kogepathic]

Smart choice. Bypassing signature verification in grub was an interesting challenge, but I'll be binning mine soon. Can't be bothered to keep something without mainline support and crap performance.

[jonathonf]

> I wonder if Arch would consider doing the same (supporting 32-bit x86 as an alternative architecture).

Yes: https://lists.archlinux.org/pipermail/arch-ports/2017-Januar...

(Also https://lists.archlinux.org/pipermail/arch-ports/2017-Januar...)

[akoster]

This is great news! Thanks for posting! I will definately keep an eye on this.

[rlpb]

> It is a shame that many major Linux distributions are dropping 32-bit x86 support.

Really it's that nobody who is interested in 32-bit x86 support is prepared to maintain it. In Free Software land, that's almost always the reason that stuff gets dropped. If it's enough of a shame, those interested would step up and make it happen. They haven't.

[cannam]

> I have an old ThinkPad T42

I have a T40p running Arch which I still occasionally use, even for development, because it's just such a pleasing machine ergonomically. So I'm a bit concerned about this as well -- but then, I've been happily using Arch for years and it's not like I've ever contributed anything to the effort of maintaining it.

[akoster]

I completely agree with you on the pleasure of using such a well-crafted machine. From the keyboard, to the connectivity, to the overall build-quality and the way in which the designers thought out so many things so well, it makes me sad that that I cannot just swap out its socketed (yes socketed!) single-core processor for something more modern.

You make a good point- I too have been an open-source consumer. Yea I have filed a few bug reports, helped some people experience Linux or switch from IE6 to Firefox, but have not contributed much to these projects time- or money-wise. With things like the Linux kernel, that are suported by the likes of Red Hat and SUSE (which are in turn supported by big businesses), I am not too concerned about their survival. But after reading about the GPG maintainer and now the GNU Octave maintainer being forced to stop their their generous contributions, I realize perhaps I need to be doing more as a user for open-source things I care about being around in the future.

[swiley]

It's increadibly easy (although the computer will spend hours crunching) to make a boot disk for pretty much anything using buildroot. That honestly sounds like a better plan for underpowered hardware than expecting a major distro to support it.

[akoster]

This is definately something I need to look into. Not only would I be able to produce install images but also would have the chance to learn more about what goes into making that ISO file I take for granted. Thanks for posting!