In the world of software development, a distinction is made between various stages of software during its production process. A piece of code that has just been made up may be referred to as pre-alpha, and should really be considered as no more than work-in-progress. Once the application or library has evolved to the point that an end-user could potentially use it more-or-less as it is supposed to work, then it goes into alpha status. This does not mean it is finished, but needs some level of user interaction with the software and its developers to detect and eliminate bugs. It then goes on to beta status, where more user testing and bug detection goes on. The actual difference between alpha and beta depends a little on how things are organized for that particular project, but, in general terms, alpha is usually tested in-house by members of the business or organization that is producing the application, while beta testing is performed by a larger community. There is also a question of feature freeze, which is the point in time at which no further features will be added to the software before final release – all modifications being limited to just making sure the features already incorporated into the product actually work. Alpha software does not usually have any freezing applied to it, and some features may morph as development goes on. Beta software usually is frozen to some extent, in the sense that major modifications should —in theory— no longer be considered until the time comes for the next release. Finally, a further stage called a Release Candidate may be distributed as a final check before the production-ready version of the software is made public, though not all organizations actually do so.
Dans le monde du développement des logiciels, on distingue diverses étapes du logiciel au cours de son processus de production. Un élément de code qui vient d’être créé peut être nommé pré-alpha et devrait être vraiment considéré comme un travail en cours et rien d'autre. Une fois que l’application ou la bibliothèque a évolué au point qu’un utilisateur final pourrait éventuellement l’utiliser plus ou moins comme elle est censée fonctionner, elle progresse au stade alpha. Cela ne veut pas dire que c’est achevé, mais que le logiciel a besoin d’un certain niveau d’interaction avec un utilisateur pour que ses développeurs puissent déceler et éliminer des bogues. Ensuite, il atteint le stade bêta, où davantage de tests d’utilisateur et de détection de bogues ont lieu. La vraie différence entre l'alpha et le bêta dépend en partie de l’organisation des choses pour le projet précis, mais, généralement, un logiciel alpha est testé en interne par des membres de l’entreprise ou de l’organisme qui produit l’application, alors que les tests d’une bêta sont faits par une plus grande communauté. S’ajoute aussi la question du gel des fonctionnalités, ce qui est le stade auquel aucune autre fonctionnalité ne sera ajoutée au logiciel avant sa sortie finale ; toutes les modifications sont alors limitées à s’assurer que les fonctionnalités déjà incorporées au produit fonctionnent bel et bien. Habituellement aucun gel n’est appliqué aux logiciels en stade alpha et certaines fonctionnalités peuvent changer au fur et à mesure que le développement avance. En général, les logiciels au stade bêta sont gelés jusqu’à un certain point, dans le sens où des modifications importantes devraient théoriquement ne pas être envisagées jusqu’au moment de la préparation d’une nouvelle version. Enfin, une étape appelée Release Candidate (RC ou pré-publication) peut être distribuée comme dernière vérification avant que la version du logiciel soit rendue publique, bien que toutes les organisations ne le fassent, en fait, pas.
How does this work for Ubuntu distributions? In actual fact, each team (Ubuntu, Xubuntu, Ubuntu Budgie…) has different philosophies and ways of implementing the software release model described above. To complicate facts further, specifics have also been known to change between versions. To take an example, at the time of writing, both Ubuntu 20.04 and Ubuntu 20.10 have been made public as production-ready distributions, the first as a long-term-support (LTS) version to be supported for five years or more, and the second as a standard version with support of nine months or until July of 2021. While these are being used in production by users, the next version of Ubuntu —called Hirsute Hippo, or Ubuntu 21.04— is being prepared. Slated for final release at the end of April of 2021, a beta version should appear on or about April 1st 2021. Features will have been frozen a week earlier. The complete release schedule can be seen through the following link: https://discourse.ubuntu.com/t/hirsute-hippo-release-schedule/18539
Comment cela fonctionne-t-il pour les distributions Ubuntu ? En fait, chaque équipe (Ubuntu, Xubuntu, Ubuntu Budgie…) a sa propre philosophie et ses propres façons d’implémenter le modèle de publication des logiciels décrits ci-dessus. Pour compliquer davantage les faits, l’on sait que des spécifications peuvent changer entre les versions. Par exemple, au moment où j’écris cet article, les distributions finalisées Ubuntu 20.04 et Ubuntu 20.10 sont disponibles au public, la première comme une version à support à long terme (LTS) qui sera supporté pendant cinq ans ou plus et la seconde comme une version standard avec un support pendant neuf mois, jusqu’en juillet 2021.
Pendant que celles-là servent quotidiennement pour le travail des utilisateurs, la prochaine version d’Ubuntu – appelée Hirsute Hippo, ou Ubuntu 21.04 – est en préparation. Sa publication finale est prévue fin avril 2021 et une version bêta devrait être disponible aux environs du 1er avril 2021. Les fonctionnalités auront été gelées une semaine auparavant. Le calendrier complet de sa diffusion peut être consulté à : https://discourse.ubuntu.com/t/hirsute-hippo-release-schedule/18539
So, what about earlier development releases of Hirsute, those that are made available between this project’s inception at the end of October 2020 and the beta version of April 2021? Previous versions of Ubuntu have, at times, been released in an alpha version. This is no longer the case. Instead, a kind of rolling development version is made available on a daily basis, with the ISO files to be found here: http://cdimage.ubuntu.com/daily-live/current/ The first of the two links should be considered specific for Hirsute Hippo, and will need to be updated as future versions roll around. However, the second link —to daily images— has been stable for some years and, in time, will probably point towards future development versions of Ubuntu – whatever they may be called. (“Irritated Ibis”? Just guessing at this point.)
Alors, quid des versions de développement antérieures de Hirsute, celles qui ont été rendues disponibles entre le démarrage du projet à la fin d’octobre 2020 et la version bêta d’avril 2021. Des versions antérieures d’Ubuntu ont parfois été sorties en version alpha. Ce n’est plus le cas. À la place, un type de version de développement mise à jour en continu est disponible quotidiennement ; les fichiers ISO se trouvent ici : http://cdimage.ubuntu.com/daily-live/current/
Le premier des deux liens est spécifique à Hirsute Hippo et devra être mis à jour au fur et à mesure de la publication de versions futures. Cependant, le deuxième lien – vers des images quotidiennes – est stable depuis plusieurs années et, à la longue, pointera sans doute vers des versions futures de développement d’Ubuntu – quel que soit leur nom (« Irritated Ibis » ? Ce n’est qu’une supposition à ce stade.)
For all practical intents and purposes, these daily builds can be considered as alpha software. The only departures from standard software development are the fact that new versions are being published on a day-to-day basis (not just at a single point in time), and that the testing process is being extended to all potential users of the system (not just in-house staff or developers).
À toutes fins utiles, on peut considérer ces compilations quotidiennes comme des logiciels alpha. Ce qui varie d'un développement standard de logiciel est le fait que de nouvelles versions soient publiées quotidiennement (et pas seulement à un moment donné) et que le processus des tests soit étendu à tous les utilisateurs potentiels du système (pas uniquement au personnel interne ou aux développeurs).
On to the main question: should you consider downloading, trying out and eventually installing this pre-production software? Well, perhaps, but do it knowing precisely what purpose it has, and which caveats to take into account. Let us start with the latter: • Be aware that things may not work as expected, or even break themselves and other parts of the software stack. The system may fail catastrophically, with no warning, and has the potential to wipe any and all data on your drives. In short, any version of a Ubuntu distribution that is not published specifically as a final, production-ready version should NOT (emphatically NOT) be used on your daily computer, or on any machine that holds data you care about. Period. • Some aspects of the system —which software is present, and how it is configured— may change as it goes through daily builds and beta. So, do not take an alpha version as the final product. Do not bet your money or your time on it. It is just the best you can hope for at the time being, if you need to plan ahead on how you will use this version of Ubuntu when it comes out in its final form.
Parlons maintenant de la question principale : devriez-vous envisager de télécharger, essayer et peut-être même installer ce logiciel de pré-production ? Peut-être, mais en connaissant précisément ses objectifs et les mises en garde à prendre en compte. Commençons par ces dernières : ••Soyez conscient que des choses peuvent ne pas fonctionner comme attendu, ou peuvent même se casser elles-mêmes ainsi que d’autres éléments de la pile du logiciel. Le système peut échouer de façon catastrophique, sans préavis, et peut supprimer toutes les données sur vos disques, le cas échéant. Bref, toute version d’une distribution Ubuntu qui n’est pas publiée spécifiquement en tant que version finale prête à l’emploi ne devrait PAS (surtout PAS) être utilisée sur votre ordinateur quotidien ou sur quelque machine que ce soit qui contient des données qui vous sont importantes. Point barre. ••Certains aspects du système – quels logiciels y sont installés et sa configuration – peuvent changer pendant que vous utilisez les compilations quotidiennes et la version bêta. Ainsi, il ne faut pas considérer une version alpha comme un produit final. Ne pariez ni votre argent, ni votre temps dessus. Ce n’est que ce qui est le mieux à un instant T, si vous devez prévoir à l’avance votre utilisation de cette version d’Ubuntu lors de sa sortie finale.
With that out of the way, you should be considering testing an alpha or daily build version of Ubuntu in the following cases: • If you are developing a piece of software that will need to work seamlessly on the next version of Ubuntu. Testing it on daily builds of the distribution is a great way of ensuring compatibility. Do so frequently, as different versions of the new distributions appear, and also on beta when that comes out. If all goes well, then you can have some confidence your software will work fine on the definitive version on release. Naturally, this is relevant mostly for software developers. • If you have a specific piece of hardware that is known to cause issues under Linux in general, or Ubuntu specifically, being able to test that hardware with daily builds is a great way of ensuring that compatibility is maintained. This may be the case even with consumer-grade hardware, with some graphics chipsets and wifi cards being the most typical offenders. This will be relevant for organizations with specific hardware needs, or even individual users that have problematic equipment.
Cela étant dit, vous devriez envisager de tester une version alpha ou une version quotidienne d’Ubuntu dans les cas suivants : ••Si vous développez un logiciel qui doit fonctionner sans aucun problème sur la prochaine version d’Ubuntu. Le tester sur les compilations quotidiennes de la distribution est une excellente façon d'être sûr de sa compatibilité. Faites-le fréquemment, au fur et à mesure que les différentes versions des nouvelles distributions paraissent, ainsi que sur la bêta quand elle sort. Si tout se passe bien, vous pouvez être assez confiant que le logiciel fonctionnera très bien sur la version définitive, dès sa publication. Bien entendu, c'est, principalement, pertinent pour les développeurs de logiciels. ••Si vous avez du matériel précis qui est connu pour ses problèmes sous Linux en général, ou sous Ubuntu en particulier, pouvoir tester ce matériel avec les compilations quotidiennes est une excellente façon de vous assurer que la compatibilité continue. Cela peut être le cas même avec du matériel du marché, certaines cartes graphiques et cartes WiFi étant les délinquants les plus typiques. Ce sera pertinent pour des organismes avec des besoins spécifiques en matériel, ou même pour des utilisateurs lambda qui ont des équipements problématiques.
So, once you have decided you need to try out a daily build, how to do so without putting your computers or data at risk? The first way is actually recommended for software developers, and consists of using a virtual environment such as VirtualBox to boot the ISO file. Anything that goes on within the alpha distribution does so within the tightly controlled virtual environment, and cannot affect files on your computer proper. The distribution to be tested can be reviewed merely as a live distribution, or installed to a (virtual) disk and updated periodically there for more testing. In the case of Hirsute Hippo, we can see that the daily build I downloaded actually works quite well within the virtual environment. As a side-note, we can see that specific backgrounds for this version have not yet been incorporated as of late January 2021, but will be done later on in the process — one would suppose, with a hippo-inspired theme in substitution of the gorilla.
Bon, une fois que vous aurez décidé qu’il faudrait essayer une des compilations quotidiennes, comment le faire sans compromettre vos ordinateurs ou vos données ? La première méthode est en fait recommandée pour les développeurs de logiciels : il s’agit de l’utilisation d’un environnement virtuel tel que VirtualBox pour démarrer le fichier ISO. Tout ce qui se passe dans la distribution alpha, se passe dans l’environnement virtuel, qui est strictement contrôlé, et ne peut pas affecter les fichiers sur votre ordinateur. La distribution à tester peut l’être tout simplement comme une distribution Live, ou elle peut être installée sur un disque (virtuel) et mise à jour de temps en temps pour davantage de tests.
Dans le cas de Hirsute Hippo, nous voyons que la compilation quotidienne que j’ai téléchargée fonctionne en fait très bien dans l’environnement virtuel. Soit dit en passant, nous voyons que des arrière-plans spécifiques de cette version n’ont pas encore été incorporés à la fin de janvier 2021, mais cela se fera un peu plus tard dans le processus – on pourrait supposer que le thème est inspiré par un hippopotame à la place du gorille.
However, neofetch does confirm we are actually working on the new version of Ubuntu 21.04, and not ye olde gorilla version 20.10: The second way to test daily builds is on actual physical hardware. This is what you need to do if ensuring hardware compatibility is an issue. Here, there is no way around the fact we need to try out the daily build on an actual computer. Ideally, this computer would be a test machine equipped with the hardware we are nervous about compatibility that is dedicated to testing. Naturally, most individuals can scarcely afford to have such a dedicated computer, though the practice is more relevant in organizations with a large number of similar machines. If your park consists of 60 PC-type desktop computers used by members of your organization for daily work, then having computer number 61 of a similar type in the IT department just to test out new software before putting it on staffers’ machines is something of a must. See it as an insurance policy of sorts.
Cependant, neofetch confirme que nous travaillons bel et bien sur la nouvelle version d’Ubuntu 21.04 et pas sur l’antique version du gorille, la 20.10.
La seconde façon de tester des compilations quotidiennes est d'utiliser du vrai matériel physique. C’est ce dont vous avez besoin si la compatibilité du matériel est un problème. Dans ce cas, il n’y a pas d’autre solution, il faut essayer la compilation quotidienne sur un vrai ordinateur. Idéalement, cet ordinateur serait une machine de test – possédant le matériel qui nous concerne, quant à sa compatibilité, dédiée aux tests. Bien entendu, la plupart des individus ne peuvent pas se payer un tel ordinateur dédié, bien que la pratique soit plus pertinente dans des organisations avec un grand nombre de machines similaires. Si vous avez une soixantaine d'ordinateurs de bureau de type PC utilisée quotidiennement dans votre organisation, alors avoir l’ordinateur numéro 61 de type similaire est presque obligatoire. Pensez-y comme à une sorte de police d’assurance.
But even private individuals may have an old laptop lying around unused that, in the worst case, can be reformatted with no loss of data. This is our best option to try out alpha grade software in general, and Ubuntu daily builds in particular. The photo is of an old Acer Aspire 11” laptop I use for these purposes. This is actually the only use I have for it, since both the battery and the internal hard drive connector on the motherboard (SATA connector) are long out of commission.
Toutefois, même des individus privés peuvent avoir un vieux portable inutilisé à portée de main qui, dans le pire des cas, peut être reformaté sans perte de données. C’est notre meilleure option pour essayer des logiciels alpha en général et les compilations quotidiennes d’Ubuntu en particulier. La photo est celle d’un vieux portable Acer Aspire de 11 pouces que j’utilise pour cela. C’est en fait la seule utilisation que j’en fais, puisque la batterie et le connecteur SATA du disque dur interne sur la carte mère sont morts depuis longtemps.
A more compromised situation arises when you have no other choice but to run alpha-grade software on your daily computer. This is really not ideal. At the very least, make a backup of your data —or several backups— before messing around. Even better: it is good practice to actually physically disconnect your hard drive before proceeding, just to ensure your working environment is not affected. Swapping out your hard drive for another drive that will be used only for testing purposes makes sense, since you will be able to come back to your regular operating system and files by just swapping drives back again. However, it should be stressed that running alpha software on a production computer is never a great idea, and should be avoided if you are not a rather experienced system administrator (and experienced systems administrators will avoid doing so at all costs… which is, actually, all you need to know to avoid making a bad decision).
Une situation plus compromise se présente quand vous n’avez d’autre choix que de faire tourner un logiciel alpha sur votre ordinateur quotidien. Ce n’est vraiment pas l’idéal. À tout le moins, faites une sauvegarde de vos données – ou plusieurs sauvegardes – avant de commencer à bricoler. Encore mieux : une bonne pratique est de déconnecter votre disque dur physiquement avant d'aller plus loin, pour tout simplement vous assurer que votre environnement de travail ne sera pas affecté. L’échange de votre disque dur pour un autre disque qui ne sera utilisé que pour des tests est logique, puisque vous pourrez revenir à votre système d’exploitation et vos fichiers normaux en faisant l’échange à nouveau. Cependant, je dois surligner que faire tourner un logiciel alpha sur un ordinateur de production n’est jamais une bonne idée ; évitez de le faire si vous n’êtes pas un administrateur système plutôt expérimenté (et des administrateurs système expérimentés éviteront à tout prix de le faire… ce qui est, en fait, tout ce que vous devez savoir pour éviter de prendre une mauvaise décision).
So, coming back to the main question: should you consider downloading, trying out and eventually installing this pre-production software? By all means, do so — but do it knowing precisely what purpose it has, on an appropriate platform (Virtualbox or a dedicated computer), and making sure there is no danger for your data. Any feedback you can give the developers —by filing bug reports— may be of help to make the distribution better and safer for regular users. But, if you are at all uncomfortable with what has been laid out in these lines, just stick to regular production releases. It will be good to know that daily builds and beta releases are done, and our favorite distribution is widely tested by a variety of people in different situations and on a diversity of platforms before software gets to your hands. Some would in fact argue that this is precisely the main strength of open-source software in the first place.
Bon, revenons à la question principale : devriez-vous envisager de télécharger, d’essayer et finalement d’installer ces logiciels en pré-production ? Faites-le bien sûr, mais faites-le en sachant précisément ses objectifs, sur une plateforme appropriée (VirtualBox ou un ordinateur dédié) et en vous assurant que vos données ne risquent rien. Tout commentaire que vous pouvez communiquer aux développeurs, en soumettant des rapports de bogue, peut aider à rendre la distribution meilleure et plus sûre pour des utilisateurs normaux.
Mais, si ce qui a été écrit ici vous met mal à l’aise, il vaut tout simplement mieux rester avec les publications finales. Vous serez content de savoir que des compilations quotidiennes et des versions bêta sont faites et que notre distribution préférée est testée par toutes sortes de personnes dans des situations différentes et sur différents matériels avant que le logiciel vous soit destiné. Certains diraient en fait que la force principale des logiciels Open Source est précisément cela.