Removing 32-bit support

Blog
1

As the world moves forward, some earlier technologies are gradually replaced and eventually phased out, as keeping them around requires more and more work for less and less gain. One such technology is 32-bit processors and 32-bit applications.

ThinLinc stopped supporting 32-bit servers in 2022 with ThinLinc 4.14.0, and later dropped support for 32-bit Linux x86 clients in 2023 with ThinLinc 4.15.0. The time is now here that we are removing support for the remaining 32-bit systems. This is happening not just in ThinLinc, but also in the Linux distributions themselves.

Specifically, the following things will no longer be fully supported in upcoming versions of ThinLinc:

  1. 32-bit Windows clients

  2. 32-bit Linux ARM clients

  3. 32-bit Linux applications

What this means for you

If you are still using 32-bit Windows clients, or 32-bit Linux ARM clients, then those machines would need to be upgraded to a 64-bit operating system to continue getting the latest ThinLinc bug fixes and features. If the machines are too old to support a new operating system, then they will be forced to continue running an older version of the ThinLinc client until they can be replaced. Such machines should be exceedingly rare these days, though.

Note that running an older version of the ThinLinc client is rarely an issue, as ThinLinc maintains good compatibility between servers and clients of different versions.

For Windows, a 64-bit version of the ThinLinc client is already available. A 64-bit Linux ARM client is not yet available, but will be released at the same time as the 32-bit version is removed. Until then, the 32-bit Linux ARM client should work fine on a 64-bit operating system if you also install the 32-bit support libraries for the operating system.

If you still have some older 32-bit applications running in your ThinLinc sessions, then some ThinLinc features may stop working for those specific applications. An upgrade to 64-bit versions of such applications is recommended, or finding alternatives if such an upgrade isn’t available.

We will not be actively blocking 32-bit applications, but support for them will be on a “best-effort” basis. That means that we’ll keep supporting them where they can use the same infrastructure as 64-bit applications, but not where extra work is required for just the 32-bit applications.

Short term, the only affected feature we’re aware of is smart card redirection, which will no longer be available for 32-bit applications. Long term, more features may also be removed as new technical restrictions appear.

When will this happen

We have not set a fixed schedule for this, but it will happen in the upcoming releases. You should be prepared for at least some changes already in the next release.

Feedback welcome

Please let us know if these changes cause any issues for you. We hope that 32-bit systems and applications are barely in use these days, and that this is a non-issue. But we want to make sure the transition is as easy as possible in cases where they are still used. Get in touch with us here in the community, or directly via our support email.

2 Likes
2

So ARM64 support in a few years then?

3

It should be a lot closer than that. :slight_smile:

1 Like
4

Please also finally consider making the whole ThinLinc Client source code / build environment open source at the same time. I see zero benefit in keeping the client closed source these days, since as soon as the client source code and build environment would exists on GitHub, third party developers like me could then easily build own customized client interfaces or even a pure command-line client for integration into other products and such. And if the whole client would have been open source right from the beginning others would have potentially created a ARM64 binary version of the ThinLinc Client already. This could easily pave the way for more potential customers…

So please finally consider taking the few bits to finally make the whole Client source code and build environment open source and public!

P.S: And also please stop using any python code obfuscater in your ThinLinc server by trying to protect your IP. :slight_smile: Please also consider potentially going open source on the ThinLinc server environment since your product anyway stands on the foundation of other open source software!

5

Hi @j.maus,

Open-sourcing any of the proprietary parts of the product is unfortunately off the table. The biggest driving factor behind this is prioritization and having a finite amount of resources available. Migrating a software and business model that has been in development for over 20 years is a multi-year undertaking that would consume an immense amount of our engineering and commercial resources.

Every hour spent on that transition would be an hour not spent on creating direct value for our customers. When contrasting the monumental internal effort of open-sourcing against spending that time actually solving our customers’ needs, the choice is clear.

I think I speak for everyone at Cendio when I say that an open-source model would have a ton of benefits and feel wonderful from an ethical standpoint. Unfortunately, we also have to make sound commercial decisions to pay our bills in the end.

6

Thanks @wilsj for your kind response and thoughts. I do of course understand the commercial bindings your are in and my P.S: about making the whole ThinLinc technology (incl. server) open source was of course meant to be the optimal case from my personal point of view only :slight_smile: as there are IMHO tons of success stories out there where companies still produce revenue and can pay their employees thought their product is fully open source But I also understand your reservations of course.

However, coming back to the ThinLinc client, I still feel that this could be a complete different story here. While of course the server components are a bit more critical and perhaps way to much work to release them under open source, I still think that especially having the client released as open source could open up completely new ways of attracting certain new customers or interested parties. Just imaging the client and its build environment would have been open source right from the beginning. Others would have probably already done the job in creating an ARM64/aarch64 version of the client or even integrating the client technology into other general remote connection clients like "remmina” or similar., which would have provided you and the great ThinLinc technology way more visibility. And besides, it would have helped certain customers (like us) to create an own command-line client only which could then be directly integrated in a ThinClient environment like thinRoot, which we are developing and using ourself. And it would probably also helped to better fix certain still existing bugs and shortcomings in the client ourself instead of just being able to open bug reports and simply reverting to a previous client version in case some problems appear (e.g. like we have had when we moved to the 4.19.0 client recently - see https://bugzilla.cendio.com/show_bug.cgi?id=8686 or https://community.thinlinc.com/t/thinlinc-client-4-19-0-and-fullscreen-multi-monitor-session-re-connect-issue/1742 )

And while I can understand that the server components might still be better kept closed source from a commercial POV, I still feel that especially opening the client could in return provide you even more potential customers, visibility and benefirts if it would be open source while at the same time not threatening your main IP, which mostly is probably located in the server components…