Is Tier 2 i386 at the end of the road already?

V

vmb

My personal experience of being unable to continue using a 32-bit intel laptop occurred this weekend. I have had a Samsung N140 netbook since 2009. It was originally supplied with a cut-down version of Windows 7, but Samsung were deluded to think that Windows was usable on the Atom N270 processor. However, the netbook ran just fine with various Unix like OS over the years, but for the last five it has been running Gnome3 on FreeBSD and ZFS with just 2GB of RAM. Last week I was happy using it on 13.4-RELEASE but the trouble started after upgrading to 13.5-RELEASE. I don't use the netbook much, it was just a handy extra tool when I had to work on network switches with a battery that lasted most of the day.

I am aware that X86 support will be gone by 15-RELEASE, so it's not a surprise that old kit will eventually become unsupported. I have found this weekend that the intel i915 kernel module is not available for some 32-bit systems in 13.5-RELEASE or 14.3-RELEASE. I also had some problems with losing wireless networking, but since rebuilding for text mode only, wireless works fine now. Using ZFS to rollback proved that there was not a hardware problem.

Over the course of this weekend, I tried installing and running the 32-bit versions of FreeBSD 13.5, 14.3, Alpine Linux 3.22, and OpenBSD 7.7 with any desktop environment or any window manager. I tried Gnome3, KDE, Mate, XFCE, NsCDE, FVWM. There was only one that I could get running on the N140 netbook and that was OpenBSD 7.7 . Could that be because OpenBSD forked Xorg? I am not going to keep it on OpenBSD because in November when my Windows 10 machines are retired, I have a ZFS only rule that I am sticking to.

My conclusion is that the Samsung N140 netbook can still be used with FreeBSD 13.5, 14.3, and Alpine Linux 3.22 in text modes only, but there is no chance of getting a GUI running on these current versions. For me, this makes it a lot less useful particularly for configuring switches with only web based management interfaces. I am retiring this machine today and will have a clear out of the other 32-bit laptops that have out of date Kali installs.

It has made me worried that my daily use Lenovo X260 laptop, which isn't new, will similarly stop functioning when someone else decides it is too old.
 
What are the security risks from using an unmaintained OS "to work on network switches"? If you only use the device occasionally mostly for that purpose, how much attack surface is exposed?

In other words, if you can no longer upgrade it, will it matter?

Unfortunately, every device will age and at some point support might stop (unless there are vintage kit enthusiasts determined to find ways to keep them going, as with Veteran and vintage cars).

If quantum computing takes off, all the OSes we currently know could become redundant, again, unless enthusiasts keep them going for nostalgia's sake. We have to get used to change.
 
At some point you have to be realistic about time, effort and reliability, Atom N270 is a potato by todays standards. To put in perspective, Amazon's Fire HD 10 Tablet is at least 3 times faster and costs less than 100$. Anything as for software remotely new in terms will run dog slow on that hardware, the other option is to stop development for anything remotely new hardware which for obvious reasons isn't an option. I'm not say that we should promote e-waste but there's going to be a tradeoff at some point and very few developers are still on i386 only hardware.

As for your X260, it'll be fine for years however it's EOL and starting to show its age so desktop tasks will get slower over time as applications evolve, get more features and gets optimized for newer instruction sets etc. I imagine that gets pushed quite hard even viewing AV1 1080p content etc. Spectre and Meltdown mitigations also doesn't help performance on legacy hardware.
 
I have kept an old laptop running with Java applets for configuring older switch firmware without a command line interface just in case, but I would rather not use an unsupported OS on a live network.

I appreciate that old kit cannot be supported forever, it just would be nice if the upgrade process warned the operator that the device will no longer have feature X or Y after upgrade and do you want to continue. I am glad that ZFS snapshot rollback and boot environments are a thing.
 
Lets be real here. Even 12 year old BayTrail Atom DRM graphics are spotty. That was after D25xx Atom 64-bit which was after N2xx Atoms.
I have no reasonable expectation of running Xorg on 32Bit. Accelerated video that is.
Intel DRM driver is the ruling factor here correct? I am surprised Sandy Bridge HD3000 video is still supported on amd64. I can see that falling off soon.
That is at least a 15 year old platform.
Intel is downsizing. Do you think that means better DRM driver support?
 
I had Samsung N130, 2 years ago tried Haiku and NetBSD on it. Haiku: no success, NetBSD: could watch YouSlideShow and everything was slow.

Windows XP, HMM II, presented it to my friend retro fan. For working its too old.
 
The Atom N270 was slow, but still usable even under Gnome3 on FreeBSD 14.3 . I wouldn't try to watch a YouTube video on it, but it was fine with web interfaces on switches. I liked it because the battery lasted a long time and I didn't have to worry about finding a spare power outlet near a switch to keep it charged.

Up until recently, I would repair old kit. Replacing capacitors and fans, keeping things useable for longer, but now the cost of electricity is my main concern. I look at power consumption first before deciding to repair or repurpose.
 
I am thinking about doing exactly that, keeping it locked on 13.4 . However, I am going to have one last go with it running a supported OS by trying out Devuan Daedalus 5.0 desktop-live. If that runs XFCE, I can install it properly with ZFS and OpenWebStart for the Java applets.

I think that at the end of 2025, early 2026 there will be a bonanza in used 64-bit laptops, so I will likely find something suitable that can run 64-bit FreeBSD 14.3 and use Bhyve for the ancient tools that I occasionally use.

My personal journey with FreeBSD on X86 has come to an end. I started out with the first release of the Walnut Creek CD-ROM on a 386DX-20 with a whopping 4 Megabytes of RAM! I remember creating an install disk set on floppy disks from files on the CD-ROM and being relieved when the last floppy installed without a problem. Time to let go and move on.
 
Can I ask how you were running Xorg on x86? With Intel DRM driver or were you using VESA driver? I am not sure if the 915DRM driver works on i386.
No EFI on x86 so I know it was not scfb driver.
 
I think I swapped out the HDD for an SSD sometime when FreeBSD 11 was current. It has been upgraded using 'freebsd-update upgrade -r' ever since. Last week when I powered it up it was running FreeBSD 13.4 and I am certain the first line of rc.conf was loading the i915kms module. I remember having problems upgrading previously and having to use an older DRM version. The notebook has a weird 1024x600 display and I think it was one of my first FreeBSD hosts to be configured for the i915kms as it greatly improved the text mode on the odd sized display.

I installed Devuan 5.0 with XFCE on it earlier today, so presumably using the same Linux intel GPU driver. I started a custom reinstall a few hours ago and it has just finished compiling the Linux kernel for ZFS.

I would like to thank all of the FreeBSD developers that have maintained and contributed to FreeBSD X86 over the last 32 years that I have been using it. It is a tremendous achievement to keep an OS operational on hardware produced over such a long period and something to be proud of. Well done to all!
 
Look at it this way. Manufacturers are no longer producing 32-bit X86 systems. Many others don't even support CSM (legacy BIOS mode). My Framework laptop doesn't support it and my HP 840's CSM is buggy. HPE just announced that GEN11 servers will only support UEFI.

And, look at Microsoft desupporting 32-bit. The major Linux vendors don't support 32-bit kernels either.

As a developer, mixed 32- and 64-bit code contains a lot of gotchas. One needs to be extra careful in order to support both modes in each line of code. Mistakes happen often causing builds and boot to fail.
 
You can literally find cheap quad-core 64-bit devices on eBay for cheap. You're doing yourself a disservice clinging onto old, antiquated hardware. The Project has an obligation to keep up with current hardware/architectures, and certainly won't nerf itself over stubborn users.
 
I agree with all the points made about 64-bit, most of my kit runs 64-bit FreeBSD.

Last week I had an old 'tool' that was used occasionally, that stopped working after a software update. Today it is fixed, albeit in a different guise and better than it was last week. Eventually, that tool will no longer be usable and I will replace it. I don't throw away useful tools just because they are old. They get disposed of when they no longer work, cost too much to use, or I when I no longer have a need for them.

The major change that has occurred for me in the last week is that I now only use FreeBSD on 64-bit hardware like the majority. For me at least, FreeBSD has already reached the end of the road on X86.
 
cy@ said:
Manufacturers are no longer producing 32-bit X86 systems.
Click to expand...
Intel at some point even contemplated removing the 32 bit instruction set from their x86 based CPUs. Which means you can't run 32 bit code anymore without some form of emulation. It's probably a little too early to do this, but I'm sure it'll happen some time in the future.
 
Beastie7 said:
You can literally find cheap quad-core 64-bit devices on eBay for cheap. You're doing yourself a disservice clinging onto old, antiquated hardware. The Project has an obligation to keep up with current hardware/architectures, and certainly won't nerf itself over stubborn users.
Click to expand...
I kind of agree. But what we see as antiquated is quite different to those from a poorer country. Open-source projects are "for everyone".

That said, x86_64 has been out a while and much of the i686 (and below) hardware is starting to physically break anyway. For those who do maintain their old stuff in fully working order (i.e as a hobby), it is likely that we prefer to run older operating systems on it anyway.

Basically, once Wine's instruction translation (i.e WoW64) matures further, then I think x86 will retire much faster in the open-source world.
(As for Wine, I know it will be "technically" more complex; but as a user, it will be so much easier rather than fiddle with 32-bit jails or mixed userlands).
 
well, I tried 14.2 on a Allwinner H3 board (arm v7/nanopi something) and it bombed pretty fast. 13.[45] worked well.
kind of sad because there still are some interesting 32 bit armv7 on the market, and won't go away that fast as i386.
 
This reminds me of the steamroller scene in Austin Powers. Getting run over by the steamroller is going to label 32-bit "retrocomputing" and you'll be like the SPARC aficionados. Sorry, time is a one-way arrow.
 
I have two customers whose business apps REQUIRE a down level operating system.
I built them fresh hardware, installed the downlevel OS, and they will probably be good for another 10 years.

The simple solution for security: No internet connection.
 
kpedersen said:
Basically, once Wine's instruction translation (i.e WoW64) matures further, then I think x86 will retire much faster in the open-source world.
(As for Wine, I know it will be "technically" more complex; but as a user, it will be so much easier rather than fiddle with 32-bit jails or mixed userlands).
Click to expand...
There is an ongoing work on having the new wow64 mode, but it is not yet in the port tree.
And given the work done for it, I doubt that anyone will accept the patches to land in FreeBSD ports tree. So we will have to wait for it to be merged upstream which could take a lot of times when we look the current state of this merge request that was started over one year ago:
gitlab.winehq.org

Fix Cyberpunk 2077 spawning only one dispatcher thread in FreeBSD (!5213) · Merge requests · wine / wine · GitLab

Normally Cyberpunk 2077 spawns #cpu_threads of dispatcher threads. However with Freebsd, since create_logical_proc_info was a stub, the game would instead spawn a single dispatcher thread, causing the game...
gitlab.winehq.org gitlab.winehq.org
That had been reworked into this
gitlab.winehq.org

ntdll: implement create_logical_proc_info on FreeBSD. (!7339) · Merge requests · wine / wine · GitLab

Add Expat as a dependency, and use it to parse the XML returned from FreeBSD's kern.sched.topology_spec sysctl.
gitlab.winehq.org gitlab.winehq.org
Which is awaiting approval/instruction for 4 month now.

The 3 current version of wine available in the port tree won't work if there is no pkg repository with the 32bit parts. Which means that if 15-release is really the end of i386, that would also mean the end of wine gaming on FreeBSD for the 15-release.

Given that 15-release is expected for December, I cannot see how the necessary patches for the new wow64 mode will be ready and merged upstream in order to have wine in port working.
 
Cost of doing business? I mean, sure, you're solving their problem temporarily, but eventually that's not gonna work and then it's time to spend money.
 
You must log in or register to reply here.
Back
Top