Re: Fixing a mesh problem
On Sun, 2026-09-13 at 10:07 -0700, Jordan Brown via Discuss wrote:
OpenSCAD still basically works on Windows 10. I think dark mode has
problems. I just dug out a Windows 10 system, charged it up,
downloaded the most recent build, and fired it up. Smoke didn’t come
out; it appears to basically work.
But it is inevitable that there will eventually be something that
kills it. In addition to any dependency that we might accidentally
add, we depend on quite a number of external components that we need
to keep more or less current, and they might introduce a
dependency. At that point your only option will be to freeze on the
last working build.
Can you foresee a situation when a Linux Appimage will run into
problems like this?
Personally I will NEVER have a Windows 11 machine in my home, but I
have a Win 10 machine to run my printers.
Larry
On 13.09.26 23:47, larry via Discuss wrote:
Can you foresee a situation when a Linux Appimage will run
into problems like this?
Yes, keeping compatible with old system gets more complex and
time consuming with each release of any of the dependencies.
As for AppImage specifically, the definition is that it needs
to be built on the oldest system it can support. Right now
AppImages are based on Ubuntu 22.04, so the should work on
anything >= 22.04.
In the not too distant future, that likely needs to be bumped
to build on 24.04. At this point it may stop working on
older versions.
The general rule, I'm seeing is that support should be there
for the current and previous release of Debian/Ubuntu, plus
the one before as best effort. Anything more than that goes
into the "works by random luck" territory.
ciao,
Torsten.
On 9/13/26 18:26, Torsten Paul via Discuss wrote:
On 13.09.26 23:47, larry via Discuss wrote:
Can you foresee a situation when a Linux Appimage will run
into problems like this?
Yes, keeping compatible with old system gets more complex and
time consuming with each release of any of the dependencies.
As for AppImage specifically, the definition is that it needs
to be built on the oldest system it can support. Right now
AppImages are based on Ubuntu 22.04, so the should work on
anything >= 22.04.
In the not too distant future, that likely needs to be bumped
to build on 24.04. At this point it may stop working on
older versions.
The general rule, I'm seeing is that support should be there
for the current and previous release of Debian/Ubuntu, plus
the one before as best effort. Anything more than that goes
into the "works by random luck" territory.
ciao,
Torsten.
Thanks for the update, Torsten. That gives us a baseline.
Cheers, Gene.
On 9/13/2026 2:47 PM, larry via Discuss wrote:
Can you foresee a situation when a Linux Appimage will run into
problems like this?
I don't know enough about AppImage to really answer that question,
but... probably. (Side note: it would be nice if somebody added some
actual content to the AppImage Wikipedia page.)
The question here is whether a new AppImage, a new build of OpenSCAD,
can run on an old system. Running an old AppImage on a new system
is a related question but with different issues.
Looking at the AppImage documentation
https://docs.appimage.org/reference/best-practices.html:
3. The binaries contained in the AppImage need to be compiled on a
system not newer than the oldest base system that the AppImage is
intended to run on.
... so if you're running a ten-year-old system, you lose because nobody
is going to keep ten-year-old systems around to build on.
4. The AppImage should actually be tested on the base systems that it
is intended to run on
... and similarly, nobody is going to test on your ten-year-old system.
AppImage isn't magic. There is, ultimately, an interface between the
application and the system. If that interface changes incompatibly, the
application breaks. If the application starts using new system
interfaces, it won't run on an old system. A modern AppImage isn't
going to run on your 386-based system, and a 386-based AppImage probably
isn't going to run on a modern system. Once we've established that
there are breaking changes, we're just haggling
https://quoteinvestigator.com/2012/03/07/haggling/ over when they occur.
IMHO, from a security perspective AppImage can be succinctly described
as a Horrible Idea. It's basically reinventing static linking, and
there are excellent reasons why basically all systems moved away from
static linking: you can't update those libraries.
This was a huge headache for Microsoft a few years ago, when a critical
security bug was found in one of the libraries that they distribute, and
that application vendors are allowed to redistribute. It required an
update to pretty much every application that included the affected
library... which was a lot. Application developers were advised "If you
have redistributed gdiplus.dll with your application, you should issue
an updated version of your application to your customers with the
updated version of this file included in the download of this security
update for your development software.".
And it happened more than once, with that same library.
Check out the affected-software list, just for Microsoft, for one of the
vulnerabilities here:
https://learn.microsoft.com/en-us/security-updates/securitybulletins/2004/ms04-028
When you're a library developer, maintaining compatibility with existing
applications can be very hard. When you're an application developer,
strictly following library rules (to minimize compatibility breaks),
monitoring library updates, and updating when the library inevitably
breaks compatibility, is hard. But what's really hard is handling the
fallout when a ten-year-old application with ten-year-old libraries gets
a malicious JPEG image fed to it and the customer's system gets taken over.