Is 32Bit development to continue (long term)?

Development OS
1

I’ve been following, and testing Haiku, for years. One thing that is very interesting, is the compatibility with BEOS binaries. It seems, for now, that the 32bit edition has been kept, partially for this reason.

In the rest of the OS world (NetBSD, Minux, ReactOS, and KolibiOS aside) 32bit is being heavily dropped. Among several reasons for Linux Distros dropping 32bit (x86) support, is the progress with Wine’s WOW64 (no 32bit userspace library dependency ) and the Linux Kernel’s announcement to slowly phase out x86. Amongst the BSDs, NetBSD is the only one “potentially” holding on.

I imagine there may be plans to eventually support BEOS applications, in the 64bit edition of Haiku. If this is the case, would 32bit development still continue?

Is there a philosophy in this, or will it mainly depend on developer interest and time?

2

Probably the latter-most statement. It would depend on developer interest and time.

I see no need to stop supporting it. Still using on my 32-bit only Thinkpad. Linux isn’t as fast as Haiku, so no point in supporting processors that are old enough to not be 64-bit (I guess it their thought). Linux also doesn’t run BeOS applications, so no need to maintain compatibility there.

2 Likes
3

Why remove something that works perfectly fine and takes few work to maintain?
Sure,keeping it working in the long run needs someone who cares and checks that nothing breaks,but I can’t imagine anyone wanting to break and remove 32bit on purpose.
Haiku is one of the very few lightweight operating systems that can still work good on that old hardware - Why do it like M$ and turn them into e-waste when they don’t need to be yet?

5 Likes
4

Often the reasoning is due to divergent complexities, between ports. I can understand this. Linux has a lot of “Corporate” developers. Linux is less of a hobbyist OS, these days. The whole thing flies in the face of the kernel’s origin story. But, that is just where things are. When money is involved, forced forward ( commercial ) thinking comes with it.

The kernel source will still be a valuable reference, for low-level developers.

5

Where did you get that information from? Several Haiku developers have presented data that suggests otherwise here on the forum a few times. Just use the search function.

1 Like
6

I’m guessing from a “casual” Linux user P.O.V., Haiku might be faster.

Many default distro configurations throw the kitchen sink at you. Pure performance is what the developer(s)/advanced users will note.

7

FreeBSD it’s tier 2 and openbsd it’s just supported as normal… did I miss something?

Plenty of Linux distros still support x86 too… debian, void, alpine, antix, slackware, gentoo, bodhi…

It is being dropped in places but the distinction I see is that distros that drop support are often commercially funded and dont want to support it any more because they view it as a wasted expense. Otherwise it seems to be kept as long as users are still interested and developers still want to support it. This is just an observation though, of course some non-commercial systems have dropped it (and vice versa probably).

8

Yes, I was speaking a bit broadly ( for the BSDs ). Both Open and Free are lowering the focus on it ( officially, for FreeBSD ).

As far as Debian/Devaun goes, 32bit kernels/installers are out. Any distro dependent on Debian, will have to follow, or do a lot of legwork. However, this doesn’t change LTS, for 32bit releases.

I truly hope Alpine continues to support 32bit, until the Linux kernel has phased it out too far (note that the kernel will retain some arm 32bit support). I use Alpine, on some of my old systems. Even on 64bit systems I use a 32bit installation, with a 64bit kernel.

As for Slackware, Gentoo, and everyone else, they depend on the Linux kernel. Unless someone makes a fork, they won’t have much choice.

Keep in mind, the kernel isn’t dropping 32bit support “immediately”. But they are officially “phasing out” x86 32bit support.

With that aside, you can expect to see less and less support for full video support. Initially, not so much with the actual drivers. But as an example, WINE has for sometime needed you to modify the registry; if you want to get correct 2D/3D accel. You have to tell WINE not to use 3D acceleration for doing the 2D acceleration. It is fine on newer GPUs and drivers; but some older drivers can’t render correctly, that way.

Void Linux is a good example of this kind of progress. I’m seeing more and more video devices getting reduced functionality, with Void. This isn’t directly related to 32bit hardware, as it also affects older 64bit hardware. This has to do with Wayland/Xorg and Mesa moving forward, and Void’s Mesa configuration (less inclusion of older Mesa models [Amber and Crocus?]).

Now, if someone still produces fairly complete 32bit binaries, you can likely use the last 32bit kernel ( what/when ever that may be) with them.

Also, you’ll probably see the Pentium I drop, before Pentium 2/3/4 and dual core 32bit CPUs. It is a phase out.

9

I’ll be the devil’s advocate here, Linux is probably faster in a bunch of things devs really appreciate, like write speeds or speed of compilation, but from a user’s standpoint Linux does feel slower overall, from the interface not being as snappy to the system still weak to being slowed down (if not frozen) by single app instances going rogue after all these years. And the Flatpak craze sure ain’t solving any of that.

On the latest Mint I often see, while idle, Cinnamon suddenly eating up an entire CPU core to… do nothing? For like half a minute! That sure isn’t making me feel like Linux is “fast”.

On top of that just think of all those big, chunky DEs like Gnome, KDE and Cinnamon (and even XFCE to some extent), they may be pretty but they sure don’t feel as responsive as Haiku’s native UI.
And yes, of course you could go for more basic UIs like iceWM, fluxbox or LXDE to get a more responsive Linux at the cost of an half-baked desktop experience where half your apps’ styles clash with the rest. (Thanks again, Gnome 3!)

Tl;dr: What the devs and what the standard users look at when talking about “fast” systems are very different, and rightfully so, as they are very different use-cases.

5 Likes
10

Well, and most “casual” users have no clue how to disable Linux services, they don’t need.

Some of the lack of snappiness, is the graphical environment. Some hardware/driver configurations will see improvement, by disabling the compositor.

I’m so power hungry, the difference between loading 64bit and 32bit binaries bothers me (partially due to old IDE and LiveUSB setups).

1 Like
11

Both kinda, for the R1 release the goal still includes BeOS compatibility, and that requires the 32bit version.

But at the same time the 32bit version is already lacking behind the 64bit version, some problems become difficult to solve. We can’t build the 32bit webbrowser on 32bit anymore, and nobody made the cross compile work yet. That and devs testing 32bit less and less depending on the hardware devs actually use.

There are no concrete plans to eliminate 32bit support, but the way things are going I can imagine that it will bitrot further.

We are Open to maintaining it further, though having 1 or 2 devs interested in supporting such older machines would definetely help in the long run :slight_smile:

3 Likes
12

This is already fixed by the new memory allocator that will be released in beta6. The web browser will be updated again at that point.

If your only example is something that is, in fact, already fixed, maybe not?

4 Likes
13

While there is some truth to that, there’s no way around system performance data. If filesystem access or network transfer speeds are slow this will definitely be noticable for “normal users”. Yes I know the Haiku GUI feels quite snappy and I like that too. Would be interesting to have some actual GUI and application performance data on Haiku vs. Linux (and the most used DE’s ) instead of having to go by gut feeling.

And yes I freely admit I was triggered by the constant Linux badmouthing that some users here seem to have a need for. Yes, sometimes a comparison is helpful, but generally we should concentrate on making Haiku a better OS and a real alternative to Linux.

1 Like
14

There is an ongoing discussion on the debian mailing list right now about which platforms should see support going forwards. Armhf is a no brainer really because many commercial systems use it and lots of hardware is still produced using it too. Look at lower end allwinner and rockchip SoCs, for example, even microchip and NXP still make armhf SoCs. They are used a lot in appliances like dashcams, routers etc, so there are a lot of brand new armhf systems. We are launching a system where I work based on armhf running Linux in February. So 32 bit arm is fully supported in the kernel and very much mainstream and not going anywhere.

This isn’t really true either. The kernel is dropping i486 and i586 but there’s been no discussion about i686. It’s reasonable to expect they will eventually drop i686 too and for many distros to drop it (a lot already did) but there’s no planned phase out for it from the kernel and I suspect as long as it’s still used in industry and embedded spaces (and it is) it will probably remain maintained in the kernel for some significant number of years into the future.

You see this sort of thing with, for example, powerpc. Mesa support is quite bad and frequently breaks for old video cards on powerpc (and big endian in general) because no one is really using, testing, maintaining it. But IBM continue to support powerpc and develop the kernel for modern 64 bit power systems and they are very well supported, for the set of software generally used on those systems. In all these cases the rule is generally the same, the things that are supported and maintained tend to be the things people still use, most of the time stuff gets dropped because users stop using it and it has been broken accidentally and no one really complained.

15

For a fair comparison, you need indeed to have the same type of install and same things running in the background. That means disabling few things that are not supported on Haiku, like firewalls, real time antivirus or bluetooth services. Also, you need to keep systems in same state and only do updates to see performance on a long term. No “normal’ user” does that so it is never fair.

While I think 32 bits will stay supported on a long term, I guess that ability to run 32 bits apps on 64 bits systems is a different thing to maintain and will disappear where it is existing. It is becoming pointless as these apps are slowly disappearing and anyway emulation or VMs will still allow to run them.

16

The main problem with Linux these days is the fact that it is being/has been ‘commercialized’.

Systemd is a love it or hate it scenario, admins like it, seems it makes their lives easier, but lots of desktop users loath it, because it is taking over mainline Linux, & as a desktop user, it isn’t necessary.

Also, I’ve noticed more people thinking about using an alternative O/S, on a few Linux forums recently. So you may see your numbers of users growing soon….

2 Likes
17

At least until R1, seems very long time to me :wink:

18

That’s not the problem at all.

Linux gets contributions from where it found success: on servers and embedded devices. So of course it gets finetuned for these use cases. It was never succesful enough on the desktop for that part to get serious attention by the developers (or the funding to achieve that).

This may change, for example, with the newly annouced Steam Machine, maybe, if it is priced reasonably and they sell a lot of those. With the Windows 11 migration, the timing may be just right, and Valve/Steam had already been working on it for a few years (on the Steam Deck and by generally supporting Linux gaming), so they already did a lot of the work. Until now it was on a game console form factor, and so maybe they didn’t give as much attention to the proper “desktop” part of things, but it was quite close.

Commercialization is a good thing, it means you can pay developers to do the things and solve the problems. But if you’re selling servers or embedded devices, you won’t solve desktop Linux user’s problems.

2 Likes
19

Hard disagree on commercialization being a good thing.
It could theoretically be a good thing if you’re making money with the hardware,and only the hardware,then use that money to produce a good OS that pleases the users and makes them want to buy more great hardware.
But I haven’t seen that in practice.
Once companies get successful,they realize that they can earn even more money and make their investors happy by screwing their users.
Place ads in every menu,nag users with premium cloud subscription,collect user data without consent to train your AI stuff,…
Just have a look at Windows,MacOS,Android and iOS which are doing exactly that.
Linux is still far away from being that awful,but lets stop pretending commercialization would change anything for good there.
If a company finds a way to make money at the cost of their users,it will do.

3 Likes
20

You can’t really take an opensource product that works great and make it shit, it will just be forked.

1 Like