Replied inline, snipping a bunch... On Sun, 21 Nov 2021 at 16:11, Bernard Chardonneau <b...@tuxfamily.org> wrote:
> So, for Internet, I use more and more often Debian 10, but for the other > things, I am more often on Debian 6 which is more stable. > You can mix and match in several ways, if you really want to. You can run Debian 6 primary with Debian 10 tools in Docker or chroot, or the inverse. Including GUI apps. There's no need for dual-booting these days - containers work vastly better. And even virtual machines have a mere 1% CPU overhead. So that you prefer Debian 6 is not a big problem. There are ways to run exactly the versions you want. But any Debian older than Debian 9 is officially unsupported. > And for 32 or 64 bits as it is the topic of your message. > > ... > > So I found the most simple was to stay on 32 bits for the 3 GNU/Linux OS > installed on my hard disk. This does not exclude a 64 bits installation > on a separate hard disk for the time I would need to use a 64 bits only > software as Discord. > Again, see containers. Run a fully up to date 64 bit kernel and host, then put old distros and 32 bit in containers. > In addition, my notebook (the one I used during Apertium stage in July > 2016) is 32 bis only, I did the test today. And the laptop I got from > my father with a big screen, originally sold with Windows XP has a 32 > bits processor. I would find normal to continue using Apertium a long > time on the first one and to put it also on the other one. > Then you can still run the Debian Sid versions of the tools, either in a container or chroot. > ... I finally contacted OLPC France > and I may get soon one. I chose the model X4 with an ARM processor. > I don't know if it is a 32 or 64 bits architecture, Apertium is not > a requirement for this PC, but of course, if it works on it, it will > be better. > I will be adding various ARM builds, so there is hope for that. > As apertium work consists only in text files processing, and as character > and strings are supported in C++ since the beginning, more than 40 years > ago, I don't understand why apertium is dependent of so many libraries > and what developers do to make the new code not compatible with old > versions of these libraries up to not succeeding to compile it. > > So, as I wrote several months ago, even if apertium (including other > tools as cg) is available in a version needing to use particular versions > of external libraries working only on several distributions, and may be > now, only with 64 bits processors (to process bytes !), there should also > be separately a version of the same apertium tools with the code of any > external functions called (not up to iostream library which is a part of > the language, but quite all the rest). > > So, this version could be compiled on any OS and distribution supporting > C++ language and pipelines. Executables of the different apertium tools > (tools belonging to apertium core and other tools used in apertium > pipeline) > would be bigger with this version, but if it allows apertium to work on > a very larger number of computers, I consider it as a minor problem. > > To compare, I started developing my own mailer (libremail) in 2002, > it has been often improved, I still use it, but for the compatibility > between old and new OS, only 2 changes > 1) "only text file processing" is a really complex domain, because we want to process free form Unicode text in various formats. There is only one official Unicode library: ICU. This library is routinely updated with new Unicode versions, and new Unicode versions don't just add emojis - they also add languages and fix bugs and security issues. So this is why we depend on ICU. Now, ICU includes the whole of the CLDR, which we don't need yet. For Windows and macOS, I used to strip the CLDR part to reduce download size, but it's not really worth the bother these days. For Linux we just have the packages depend on the distro's ICU package, which is very likely already installed as many other things need it. So we don't just process text files. We process free form Unicode text files, and we want the processing power and correctness that ICU brings. 2) "only text file processing"? No, not only text files. Also files authored in Word, LibreOffice, HTML, etc. Some of those files are zip with XML, so we need a way to unzip the files and manipulate the HTML/XML in a way that won't break it. So that's 2 more libraries: libzip and libxml2. Again, they're likely already installed on most Linux desktops, and we just depend on the distro package. 3) "new code not compatible with old versions" I quite frankly dispute. The fact that the codebases all build against 5 year old compilers and library versions is evidence enough. We take some amount of pain in changing code to build on the older distros, but there are limits. E.g., we require at minimum C++14. Using newer versions of C++ cleans up the code quite a bit, and newer libraries have important bug and security fixes. 4) "only with 64 bits processors"? No. Debian Sid is always the newest versions of everything, and that's built as 32 bit. So we make sure everything builds as 32 bit. But I don't want to waste build time on archs that are unused, and 32 bit market share is vanishingly small. So if you really need 32 bit, the newest versions of everything can be installed in a 32 bit Debian Sid chroot or container. 5) "separately a version of the same apertium tools with the code of any external functions" - absolutely bloody not. That would be such a huge maintenance burden. There is no Standard C++ Unicode handler, so what replacement for ICU do you propose? Same for the other needed libraries. We don't use libraries for the fun of it or on a whim - we use them because they're the best at what they do, where best is a combination of "widely available in distros" and "quality output". E.g., libxml2 is very old and there are several newer shinier XML libraries, but they aren't as widely available nor can they handle HTML, so we use libxml2. Overall, for an open source project, I'd say we're doing very well. There's a good balance between wanting to use new shiny things, but also wanting to accommodate old distros (and Windows + macOS). We don't break backwards compat just because - we break it when distros go EOL upstream. -- Tino Didriksen
_______________________________________________ Apertium-stuff mailing list Apertium-stuff@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/apertium-stuff
