I think Apertium's support model is a very good balance of bleeding edge and long term support, but as the packager I am also the one who basically decided it so I'll admit I am biased. Still, I think it's objectively good, and I'll try to argue my point.
First of all, security. Distros and vendors drop support for old platforms when they no longer make economic sense to backport security fixes for. Ubuntu LTS has 5 years of security support, which I think is a completely reasonable limit. That means customers have to upgrade every 5 years, though ideally they would do so every 2 years when new LTSs come out. But if someone continues to use a distro for which there are no longer security updates? In this day and age of automated bot networks that actively hunt for vulnerable systems and inject exploits into websites? That's beyond my sympathy limit. Secondly, Unicode. We are in the language technology business, and we need to process Unicode and handle locales. New versions of Unicode and CLDR some out regularly, with ICU being the official support library. So distros with ancient Unicode/CLDR versions will potentially misbehave. Again, I think 5 years of support is reasonable here. Thirdly, language and tool features available in distros. As the packager, I have pushed for everything to be buildable and testable with only distro-provided packages - no 3rd party repos (pip, cargo, etc). Currently only 2 packages don't build on older distros: apertium-apy and lexd. APy because distros' versions of Python 3 simply got too old, and lexd because of a g++ bug. This is an area where I actively hold back Apertium code, to some consternation of developers including myself. Us developers want to use latest language features because they are better and cleaner, but the packager in me says we must support oldest Ubuntu LTS which means we have to hold back on writing bleeding edge code. The set of supported distros at any given time comes out to roughly 5 years of support. If a distro is at most 5 years old (not counting point releases), it will almost certainly work. As both packager and developer, I think this is a good balance. And given how both end-users and developers grumble equally about it (it's too new AND too old at the same time!), I feel confident we've objectively found a good balance. Fourthly, Docker, et al. Most of the above quickly becoming a moot point, because anyone can run any version of anything they want in various kinds of containers / snaps / appimage / etc. That's not to say we will drop the 5 year support, but it's something to think about. -- Tino Didriksen On Sun, 9 May 2021 at 23:05, Bernard Chardonneau <b...@tuxfamily.org> wrote: > > Date: Wed, 21 Apr 2021 13:38:56 +0200 > > From: Tino Didriksen <m...@tinodidriksen.com> > > To: "[apertium-stuff]" <apertium-stuff@lists.sourceforge.net> > > Reply-To: apertium-stuff@lists.sourceforge.net > > Subject: [Apertium-stuff] Ubuntu 16.04 (Xenial) going EOL > > Pièce(s) jointes(s) probable(s)> > > Reminder that Ubuntu 16.04 Xenial will reach end-of-life in a few days. > If > > you're still on Xenial, upgrade. > > > > Similarly, Debian 9 Stretch is becoming long in the tooth. > > > > -- Tino Didriksen > > > > Well, I was waiting a message of that kind to do a suggestion. > > I am of a generation who find it normal to use a camera to take pictures, > a phone to make phone calls, a watch to get the exact time, and a hammer > to hit something. > > But a computer stays a multi-use device. If somebody uses a computer ONLY > to work with Apertium, there should not be a problem changing distribution > every 6 months. In fact, even then, it is not entirely true as a text > editor > is needed, and the behavior of the favorite text editor (especially if it > is graphical) may change from one distribution to the next one. > > When something exists and works fine, it should never disappear to be > replaced by something worse. > But for things we can buy as for software, including free software, it > sometimes happens. > > When I discovered Apertium, I had Mandriva 2009 installed on my computer. > Apertium didn't work with it. So, I also installed Debian 6. On Mandriva > 2009, there were 2 things that I liked and never found again: a gadget > displaying a color world map with the areas where it's daylight called > kworldclock and a file explorer on which, when clicking on an picture file, > the picture was displayed into a tab, instead of opening a new window which > was often too small from the first photo and quickly always too small when > using arrows to see other ones, some portrait oriented, others landscape > oriented. > So, even if Debian 6 has extra possibilities, I still used Mandriva 2009 > for a few more years for image processing with Gimp. > > A few years later, I needed Debian 7 to make Apertium work. I did a copy > of Debian 6 with all the tools installed and upgraded it to Debian 7. But > the gnome 3 GUI works differently as the previous one and I didn't find it > easy to configure. This was a reason to continue using Debian 6 as much > as possible. I found the solution to compile Apertium with Debian 7 and > continue using it on Debian 6 without cg which was replaced by the cat > command for pairs using it. > > Then, more and more websites stopped working with Firefox 31 which is the > last, or one of the very last versions to work with Debian 6 without > crashing quickly. I ended up reinstalling Debian 7 with xfce4. The GUI > is less confusing and the video editor I use with Debian 6 but whose the > most interesting features for me are disabled with gnome 3 worked again. > > On the other hand, when starting gedit and asking to open a file from it, > a lot of mp4, mp3, ogg, jpg, png, etc ... files are shown. These are files > from different directories I accessed during the 2 last weeks but NOT with > gedit! > I couldn't find a way to disable this stupid spying system and that > did me hating xfce4. > > Last year in spring I had for work to use Discord software which now > requires a 64 bit OS. I prepared a Devuan 2 on a separate disc to use it. > But I also noticed a change in the design of gedit whose top menu and > some icons disappeared. I found the last version less convenient to use > and lost several new files and several changes as it was less easy to save > data. > > Finally, at the beginning of this year, I discovered that Debian 10 with > Mute has a GUI similar to gnome 2. The version of gedit that I like is > present and now called pluma. A problem I find with gedit is that it only > proposes the last 5 edited files (I would prefer 10 or rather 20). Pluma > does not propose more. I will have to ask them how to change that. > On Debian 6, I found a pity that the video editor only allow very few > couples of values for width and height for saving files in ogg format. > The new one working on Debian 10 normally allows MP4 to be encoded (it > is better), but as long as some possibilities of the software are > displayed in white on a white background, it is unusable. > > But despite these problems that need to be corrected plus some blockages > with a color zebra skin kind of display from which using the reset button > is the only way to get out (problem also observed on Devuan 2), I think I > will use Debian 10 for the next 5 years instead of Debian 7. > > For Apertium, I work on it as a hobby and since at least 2 years I also > have also other activities to do on my computer during my free time. This > is the main reason why I did not worked much on language pairs recently. > But the need to update regularly the operating system is an extra reason > and during last summer, after discussing with Hector Alos about change in > paradigms for generation when the analysis of the word gives mf or sp tag, > I finally did nothing because my computer was not ready to compile the > language. > > Normally for the operating system, Apertium is not something complicated : > reading files, processing data. For Apertium C++ programs, you use several > libraries. I understand you prefer using then for decoding XML instead of > rewriting this part. But after more than 10 years Apertium exists, I am > surprised you still need things that did not exists in system libraries > few years ago. > > So, a recent version of Apertium tools does not compile on a less recent > operating system. And you recently said somebody who use MAC OS that his > version is not supported. > > Now you ask to upgrade a version of Ubuntu and also Debian 9. Before few > years, that will be the same for Debian 10 and after Debian 11 ... > At that time, several changes done on Apertium programs may prevent them > to compile. > > So, permanent changes may be needed to continue using Apertium that worked > fine earlier. > > I think for the operating system versions on which Apertium can be compiled > now, Apertium can be broadcast as it is. > > But for any other operating system compatible with C++ language and pipe > processing, a solution could be to give both source code of Apertium tools > ans source code of system libraries it uses. These libraries would be > compiled with Apertium tools using them and object files stored outside > /usr/lib . So, there would not be compatibility problems with other version > of the same library in the distribution. > > That may do big executables, a long time to compile the whole, but if that > allows to use Apertium on any Windows, Mac OS, GNU/Linux and others with > the > same source files, it will be better than the present solution. > > > -------------------------------- > Bernard Chardonneau (France) > >
_______________________________________________ Apertium-stuff mailing list Apertium-stuff@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/apertium-stuff
