C'est une question qui peut paraître idiote, mais je pose quand même la question.
Quand on voit les gros projets comme le noyau Linux, les librairies systèmes, GCC etc .. ils sont de plus en plus complexes, existent depuis des décennies, on patch, on fait bugué, on repatch, en s'adaptant aux nouvelles architectures, c'est de plus en plus compliqués d'attirer des jeunes à contribuer, car le code est ultra complexe à appréhender. On refuse de deprecié certaines choses, car ça doit continuer à fonctionner sur des vieilles machines obscures.

Est-ce qu'à cause de tout ça, on fonce pas droit dans un mur ?

Sans parler qu'à chaque tentative de fork ou changement importants, on a droit à des mini révolutions (cf Wayland, Systemd) , pour au final ce retrouver avec un écosystème coupé en deux, où ni Xorg et ni Wayland arriveront à avoir un niveau équivalent à Windows ou Mac au niveau de l'intégration, d'évoluté et de stabilité du code.

Je pense aussi aux langages eux mêmes, combien de temps va t-on pouvoir transporter du code C, compris des fois par juste une personne, avec des vieilles méthodologies, alors que certains nouveaux langage comme Rust amènent une couche beaucoup plus sûr.

Bah le probleme de base est exactement le meme dans l'industrie logicielle "proprietaire". Que le logiciels soit libre ou pas, tu as exactement le meme probleme: les codes deviennent plus complexe et plus gros.

Ce qu'apporte justement le logiciel libre c'est que les codes sont accessibles et reutilisable. Ca veut dire que tu te retrouve avec une grosse usine a gaz (apache par exemple) que toute l'industrie utilise. Du fait, il y a beaucoup de gens qui regarde le code et qui ont interet a ce que le logiciel continue a fonctionner.

Du fait que les codes sont disponible ca veut dire qu'il ets auss plus facil de les documenter et la barriere d'entree a reconstruire une parti du logiciel est generalement plus facile. Parceque les codes ont tendance a etre plus modulaire. (Ils sont plus modulaire parceque il y a tellement de gens qui bossent dessus que si c'etait pas modulaire ca ne serait pas constructible du tout.)

Au niveau des langages, le C et le C++ ne sont pas pret de disparaitre. Oui il y a des efforts comme rust, go, D, et ce genre de truc. Mais ils ne prennent quasiment pas de part de marche parcequ'ils ne reglent pas de probleme fondamentallement important. Les erreurs contre lesquels ils protegent sont des erreurs de debuttant qui la plupart du temps sont decouvert immediatement par de l'analyse statique du code (genre splint et outil du genre), ou par un verificateur d'execution (genre valgrind et outil du genre).

Bon, j'enseigne pthreads dans 10 minutes, il faut que j'y aille

Le 14 février 2018 à 16:50:07 godrik a écrit :
Bah le probleme de base est exactement le meme dans l'industrie logicielle "proprietaire". Que le logiciels soit libre ou pas, tu as exactement le meme probleme: les codes deviennent plus complexe et plus gros.

Ce qu'apporte justement le logiciel libre c'est que les codes sont accessibles et reutilisable. Ca veut dire que tu te retrouve avec une grosse usine a gaz (apache par exemple) que toute l'industrie utilise. Du fait, il y a beaucoup de gens qui regarde le code et qui ont interet a ce que le logiciel continue a fonctionner.

Du fait que les codes sont disponible ca veut dire qu'il ets auss plus facil de les documenter et la barriere d'entree a reconstruire une parti du logiciel est generalement plus facile. Parceque les codes ont tendance a etre plus modulaire. (Ils sont plus modulaire parceque il y a tellement de gens qui bossent dessus que si c'etait pas modulaire ca ne serait pas constructible du tout.)

Au niveau des langages, le C et le C++ ne sont pas pret de disparaitre. Oui il y a des efforts comme rust, go, D, et ce genre de truc. Mais ils ne prennent quasiment pas de part de marche parcequ'ils ne reglent pas de probleme fondamentallement important. Les erreurs contre lesquels ils protegent sont des erreurs de debuttant qui la plupart du temps sont decouvert immediatement par de l'analyse statique du code (genre splint et outil du genre), ou par un verificateur d'execution (genre valgrind et outil du genre).

Bon, j'enseigne pthreads dans 10 minutes, il faut que j'y aille

pthread_mutex_unlock(&enseignement);

Oué mais une boîte privée peut prendre des mesures fortes, faire réecrire une partie de son code, voir repartir de zero. Elle a les moyens financiers et les moyens humains pour le faire, et le risque est mesuré. De plus ils sont maître de tout ce qui a autour, je veux dire si demain Microsoft veut reécrire toute la partie audio de windows, elle prend 100 dev qui vont travailler 6 mois dessus et ce sera régler, en adaptant surement très peu l'API et donc en gardant une compatibilité avec les logiciels existants, et sans rien casser. Alors que dans le libre, ça cassera sûrement tout Alsa, Pulse Audio, Jack etc ... et il y aura surement très peu de dev qui pourront faire le boulot, et mettront 2ans à 10 pour avoir quelque chose de satisfaisant. Sans parler des distributions qui mettront 5ans avant de mettre cette nouveauté dans leur dépôt stable.

prendre des mesures fortes, faire réecrire une partie de son code, voir repartir de zero.

C'est littéralement ce que fait le petit monde de GNU-Linux tous les 2 ou 3 ans lol.

C'est même l'un des gros défauts du libre pour ordi personnels : Jean-nerd a l'idée d'un logiciel, il va se lancer en solo dans le développement à partir de zéro et aboutir à un logiciel partiellement fonctionnel, tandis que le même logiciel partiellement fonctionnel qui avait déjà été fait il y a 10 ans tombe dans l'oubli et disparaît des dépôts faute de maintenance. Donc au final on a 2 logiciels mal finis, l'un est inconnu et l'autre est mort.

Je te dis ça à l'échelle des applications desktop (les lecteurs de musique, les front-end de lecture vidéo, les éditeurs de texte plus ou moins avancés, même les navigateurs web, ...) mais c'est vrai pour les outils pour serveurs, et même à l'échelle des environnements de bureau tout entiers.

D'ailleurs les trucs les plus durables et les moins réécrits, c'est le noyau, qui est sans doute le monstre de code le plus "corporate" d'une distro, et les outils système de bas niveau (RIP btrfs) qui n'ont rien de bien lisible non plus pour le débutant.

si demain Microsoft veut reécrire toute la partie audio de windows

Ils ne le feront pas car c'est beaucoup trop risqué étant donné la variété de matériel et les garanties juridiques livrées avec leurs licences. Windows 10 n'a encore aucun problème à faire tourner la plupart des programmes Windows XP, ce n'est pas par hasard.

À l'inverse il y a 3 mois j'ai pour la première fois entendu parler de Pipewire, un projet pour réécrire la manière dont le screencast et le partage d'écran se ferait sous GNU-Linux de manière sécurisé, performante et compatible avec Wayland. Des versions alpha fonctionnelles existent déjà, parce que : Redhat, SUSE, Canonical, ...
Le libre n'est pas fait uniquement par de gentils barbus bénévoles, il y a des boîtes, et elles ont des moyens. Pas assez pour pondre un OS mobile sérieux apparemment, mais assez pour réinventer tous les 2 mois un bout de la distro que l'utilisateur lambda ne pensait même pas problématique.

Alors que dans le libre, ça cassera sûrement tout Alsa, Pulse Audio, Jack

PulseAudio, c'était justement RedHat qui a reécrit toute la partie audio de GNU-Linux, les 2 ou 3 autres vieilleries de niche qui ont survécu, c'est principalement car PulseAudio est une usine à gaz qui ne les comprenait pas, et ils survivraient pareil sur Windows hein (pulseaudio existe théoriquement sur Windows d'ailleurs).
Au final c'est satisfaisant pour 99,9% des utilisateurs.

Sans parler des distributions qui mettront 5ans avant de mettre cette nouveauté dans leur dépôt stable.

Si demain Microsoft réécrit tout l'audio de son système, ça n'arrivera tout simplement jamais jusqu'aux serveurs d'updates de Windows 7, ni 8, ni 8.1, ni les versions tablettes à chier qu'ils ont abandonné. Donc quand tu sors "gneugneu Debian ils mettent 2 ans et demi à pondre une version stable" (pas 5, mais bien 2 et demi) c'est une remarque du plus bas niveau intellectuel imaginable, et au moins ils fournissent un système, et même un système stable (pas comme Windows 10 ).

Microsoft veut reécrire toute la partie audio de windows, elle prend 100 dev qui vont travailler 6 mois dessus et ce sera régler, en adaptant surement très peu l'API et donc en gardant une compatibilité avec les logiciels existants, et sans rien casser

Sauf que microsoft Fera jamais ça parce qu'ils ont pas la motivation de le faire parce que ça coûterait beaucoup trop d'argent par rapport à ce que ça rapporterai.

Les dev libre sont généralement un peu plus intéressé d'éviter de casser le user space que microsoft par exemple

Et j'ai tendance à penser (peut être à tort) que les gens qui écrivent du code qui est lisible par tout le monde sont généralement plus soucieux d'écrire du "bon code" tant en terme d’implémentation que de propreté que le code écrit par une entreprise.
Suffit de voir le code leaké de microsoft 2000 http://atdt.freeshell.org/k5/story_2004_2_15_71552_7795.html

Le 14 février 2018 à 23:02:51 Le-Respect a écrit :

prendre des mesures fortes, faire réecrire une partie de son code, voir repartir de zero.

C'est littéralement ce que fait le petit monde de GNU-Linux tous les 2 ou 3 ans lol.

C'est même l'un des gros défauts du libre pour ordi personnels : Jean-nerd a l'idée d'un logiciel, il va se lancer en solo dans le développement à partir de zéro et aboutir à un logiciel partiellement fonctionnel, tandis que le même logiciel partiellement fonctionnel qui avait déjà été fait il y a 10 ans tombe dans l'oubli et disparaît des dépôts faute de maintenance. Donc au final on a 2 logiciels mal finis, l'un est inconnu et l'autre est mort.

Je te dis ça à l'échelle des applications desktop (les lecteurs de musique, les front-end de lecture vidéo, les éditeurs de texte plus ou moins avancés, même les navigateurs web, ...) mais c'est vrai pour les outils pour serveurs, et même à l'échelle des environnements de bureau tout entiers.

D'ailleurs les trucs les plus durables et les moins réécrits, c'est le noyau, qui est sans doute le monstre de code le plus "corporate" d'une distro, et les outils système de bas niveau (RIP btrfs) qui n'ont rien de bien lisible non plus pour le débutant.

si demain Microsoft veut reécrire toute la partie audio de windows

Ils ne le feront pas car c'est beaucoup trop risqué étant donné la variété de matériel et les garanties juridiques livrées avec leurs licences. Windows 10 n'a encore aucun problème à faire tourner la plupart des programmes Windows XP, ce n'est pas par hasard.

À l'inverse il y a 3 mois j'ai pour la première fois entendu parler de Pipewire, un projet pour réécrire la manière dont le screencast et le partage d'écran se ferait sous GNU-Linux de manière sécurisé, performante et compatible avec Wayland. Des versions alpha fonctionnelles existent déjà, parce que : Redhat, SUSE, Canonical, ...
Le libre n'est pas fait uniquement par de gentils barbus bénévoles, il y a des boîtes, et elles ont des moyens. Pas assez pour pondre un OS mobile sérieux apparemment, mais assez pour réinventer tous les 2 mois un bout de la distro que l'utilisateur lambda ne pensait même pas problématique.

Alors que dans le libre, ça cassera sûrement tout Alsa, Pulse Audio, Jack

PulseAudio, c'était justement RedHat qui a reécrit toute la partie audio de GNU-Linux, les 2 ou 3 autres vieilleries de niche qui ont survécu, c'est principalement car PulseAudio est une usine à gaz qui ne les comprenait pas, et ils survivraient pareil sur Windows hein (pulseaudio existe théoriquement sur Windows d'ailleurs).
Au final c'est satisfaisant pour 99,9% des utilisateurs.

Sans parler des distributions qui mettront 5ans avant de mettre cette nouveauté dans leur dépôt stable.

Si demain Microsoft réécrit tout l'audio de son système, ça n'arrivera tout simplement jamais jusqu'aux serveurs d'updates de Windows 7, ni 8, ni 8.1, ni les versions tablettes à chier qu'ils ont abandonné. Donc quand tu sors "gneugneu Debian ils mettent 2 ans et demi à pondre une version stable" (pas 5, mais bien 2 et demi) c'est une remarque du plus bas niveau intellectuel imaginable, et au moins ils fournissent un système, et même un système stable (pas comme Windows 10 ).

Windows 10 est quand même très stable, surtout quand on prends en compte le nombre énorme de logiciel supporté, et avec un système admin/utilisateur moins cloisonné que Linux pour l'utilisateur lambda (et donc plus apte à faire n'importe quoi avec son système).
Et même si bien entendu aucune partie n'a été réécrite complétement, il faut que Windows a su évoluer avec le temps.
Un exemple simple, le démarrage de linux, c'est l'épilepsie assuré (avec Xorg qui fait clignoter l'écran), l'audio qui grésille etc ... Ca fait des années que le "problème" est connu, mais ça demande tellement de toucher à beaucoup de librairie différente, que c'est impossible à coordonner pour changer ça.
De plus même si des grosses boites comme RedHat ou Google travaille sur des projets open-source, elles peuvent pas s'occuper de tout et favorise ce qui a un intérêt pour eux. (Sans parler des cas, où bien qu'ils participent à Linux, ils refont certaines parties de leur côté et la mette sous licence propriétaire).
Pour en revenir à Pulse, Alsa etc ... Le résultat c'est que même aujourd'hui on a des systèmes "bâtard" qui doivent supporter les deux pour avoir tout qui fonctionne, l'absence d'une ABI est un problème. Je trouve (c'est que mon avis !!), qu'il peut pas y avoir un ecosystème viable, quand il y a autant de dépendance entre chaque brique logicielle.

Après faut pas voir mon post comme un troll, ou une critique hein...

Un exemple simple, le démarrage de linux, c'est l'épilepsie assuré (avec Xorg qui fait clignoter l'écran), l'audio qui grésille etc.

• quelques lignes de systemd
• écran noir 10 secondes
• écran gris 2 secondes
• interface lancée

Quantité de grésillement audio : zéro.
Clignotements : zéro.

Bref, rien d'apocalyptique, ni même de gênant, si je voulais un truc parfait la seule chose en jeu serait plymouth.

Pour en revenir à Pulse, Alsa etc ... Le résultat c'est que même aujourd'hui on a des systèmes "bâtard"

C'est "bâtard" si tu t'amuses à installer des vieilleries dont tout le monde connaît la faible compatibilité avec PulseAudio hein. T'es vraiment en train de reprocher à GNU-Linux le fait que tu ne saches pas gérer ton installation ?

Je trouve (c'est que mon avis !!), qu'il peut pas y avoir un ecosystème viable, quand il y a autant de dépendance entre chaque brique logicielle.

En fait t'as pas approché GNU-Linux depuis 5 ou 6 ans c'est ça ? Les snaps, les flatpak, les appimages, etc. ça ne te dit vraiment rien ? Et quand bien même toutes ces technologies n'auraient pas été inventées, ça fait 20 ans que GNU-Linux est un écosystème viable avec "autant de dépendances entre chaque brique logicielle", prouvant par sa simple existence que ta critique se base sur du rien.

Le 15 février 2018 à 00:59:09 Le-Respect a écrit :

Un exemple simple, le démarrage de linux, c'est l'épilepsie assuré (avec Xorg qui fait clignoter l'écran), l'audio qui grésille etc.

• quelques lignes de systemd
• écran noir 10 secondes
• écran gris 2 secondes
• interface lancée

Quantité de grésillement audio : zéro.
Clignotements : zéro.

Bref, rien d'apocalyptique, ni même de gênant, si je voulais un truc parfait la seule chose en jeu serait plymouth.

Pour en revenir à Pulse, Alsa etc ... Le résultat c'est que même aujourd'hui on a des systèmes "bâtard"

C'est "bâtard" si tu t'amuses à installer des vieilleries dont tout le monde connaît la faible compatibilité avec PulseAudio hein. T'es vraiment en train de reprocher à GNU-Linux le fait que tu ne saches pas gérer ton installation ?

Je trouve (c'est que mon avis !!), qu'il peut pas y avoir un ecosystème viable, quand il y a autant de dépendance entre chaque brique logicielle.

En fait t'as pas approché GNU-Linux depuis 5 ou 6 ans c'est ça ? Les snaps, les flatpak, les appimages, etc. ça ne te dit vraiment rien ? Et quand bien même toutes ces technologies n'auraient pas été inventées, ça fait 20 ans que GNU-Linux est un écosystème viable avec "autant de dépendances entre chaque brique logicielle", prouvant par sa simple existence que ta critique se base sur du rien.

Bah écoute si elle se base sur du rien, comment t'expliques que plein de distro soient obligés de forcer l'option --enable-alsa pour Firefox qui l'a deprecated depuis un petit moment ?
Les snaps, les flatpack, rien que le fait qu'il y en ai deux pour faire la même c'est un non sens, et à cause de ça, ça risque pas de devenir la manière "mainstream" d'installer un logiciel.
Il y a que les Appimages qui soit vraiment cool, mais mise à part Molotov, j'ai jamais vu des programmes tiers l'utiliser.

Ca veut pas dire que j'émet des interrogations sur le monde libre actuel qu'il faut transformer ça en guerre des OS hein. Et pour participer un peu au packaging de logiciel sur Solus, je peux te dire que non, c'est pas aussi stable que ça. Avoir des logiciels qui compile pas d'une version à l'autre ça arrive plus souvent que ce que l'on croit.

l'option --enable-alsa pour Firefox

ALSA c'est bien le pilote noyau dont PulseAudio est usuellement le serveur audio ? c'est pas un crime de l'utiliser non plus hein, et si c'est pas élégant de l'utiliser directement, la faute en reviendrait à la gestion du son de Firefox, pas à l'écosystème GNU-Linux...

Les snaps, les flatpack, rien que le fait qu'il y en ai deux pour faire la même c'est un non sens

Ils n'ont pas du tout le même fonctionnement, ne font donc pas la même chose. L'un d'eux est là pour faciliter le développement d'applications de bureau, l'autre est premièrement adapté aux serveurs et l'internet des objets de Canonical.
L'un demande les droits root, l'autre non. L'un est pensé pour être décentralisé, l'autre n'a été décentralisé que plus tard. Ils ne gèrent pas leurs dépendances pareil non plus.

Mais bon, RegleGraduee a dit que la liberté de choisir la technologie qu'on préfère est un non-sens, donc ça doit être un non-sens hein

et à cause de ça, ça risque pas de devenir la manière "mainstream" d'installer un logiciel.

C'est bien ce que je disais, tu n'as jamais approché une distro récente. La logithèque Ubuntu regorge de snaps depuis des années, et les développeurs tiers produisent des quantités improbables de logiciels en flatpak, étant de fait des formats tout à fait mainstream.

Il y a que les Appimages qui soit vraiment cool

Si tu participes au packaging de quoi que ce soit et tu estimes que le seule format de paquet cool, ce soit celui qui embarque toutes ses dépendances (quitte à avoir des doublons), sans possibilité de mises à jour, c'est inquiétant.

mise à part Molotov, j'ai jamais vu des programmes tiers l'utiliser.

Openshot, Popcorn time, Etcher, Subsurface, Kdenlive, ...

(hum... mon message n'etait pas parti hier, je le reposte.)

Oué mais une boîte privée peut prendre des mesures fortes, faire réecrire une partie de son code, voir repartir de zero. Elle a les moyens financiers et les moyens humains pour le faire, et le risque est mesuré.

Si tu as une puissance de developpement infini, tu peux faire en gros ce que tu veux. Mais ce n'est pas forcement intelligent de le faire. Google en a fait les frais avec els extension du noyau qu'ils ont pousse. Quand ils ont voulu merger els apport dnas le noyaux, les chagements ont ete refuse parceque le code etait de mauvaise qualite. Du coup ils ont perdu beaucoup de temps a refusionner leurs changement avec le noyau.
Note que google a ete capable de faire ca a relativement pas cher PARCEQUE le noyau est open source. Ils n'ont pas eu a developper un noyau entier ce qui serait debilement cher.

De plus ils sont maître de tout ce qui a autour, je veux dire si demain Microsoft veut reécrire toute la partie audio de windows, elle prend 100 dev qui vont travailler 6 mois dessus et ce sera régler, en adaptant surement très peu l'API et donc en gardant une compatibilité avec les logiciels existants, et sans rien casser. Alors que dans le libre, ça cassera sûrement tout Alsa, Pulse Audio, Jack etc ... et il y aura surement très peu de dev qui pourront faire le boulot, et mettront 2ans à 10 pour avoir quelque chose de satisfaisant.

C'est pas forcement grave de tout casser. Si tu casses tout et que ca fait chier les gens, ah personne n'utilisera ta contribution. Mai les API sont relativement bien defini donc c'est relativement facil de ne pas tout casser quand tu change un module.

Sans parler des distributions qui mettront 5ans avant de mettre cette nouveauté dans leur dépôt stable.

Logiciel libre, ca ne veut pas dire distribution linux.

Windows 10 est quand même très stable, surtout quand on prends en compte le nombre énorme de logiciel supporté

OK pour le nombre de logiciel supporté mais on parle quand même d'un OS qui bouffe 80% des ressources d'un ordi bureautique, alors qu'aucun programme n'est ouvert part l'utilisateur.
Quand sur une fresh install, le menu démarrer met 1 minute pour apparaître j'appelle pas ça de la stabilité.

Le logiciel libre supporte au contraire presque tous les soubassements techniques des logiciels qu'on utilise. Serveurs, smartphones, objets connectés, etc.

Seul le monde du PC (en relatif déclin chez le grand public, pas le gaming), de Microsoft et de sa Xbox font exception. Les playstation, les macintosh, c'est du Unix

Merci c'est super intéressant de vous lire!

Super intéressant mais vachement compliqué à comprendre quand on connait que dalle en dev, en système linux et que beaucoup ont des avis différents :o

En meme temps, c'etait une discussion sur la viabilite du mode de devleoppement des logiciels libres. Tu t'attends a ce que ca devienne complique.

Sans avoir la prétention de m'intégrer totalement dans cette discussion (c'est intéressant mais je manque de temps comme... tout le temps), j'avais un petit commentaire à ajouter:

C'est même l'un des gros défauts du libre pour ordi personnels : Jean-nerd a l'idée d'un logiciel, il va se lancer en solo dans le développement à partir de zéro et aboutir à un logiciel partiellement fonctionnel, tandis que le même logiciel partiellement fonctionnel qui avait déjà été fait il y a 10 ans tombe dans l'oubli et disparaît des dépôts faute de maintenance. Donc au final on a 2 logiciels mal finis, l'un est inconnu et l'autre est mort.

Je vais faire l'avocat du Jean-Nerd ici, mais j'ai personnellement besoin de refaire (au moins partiellement, au moins dans les grandes lignes) ce qui a déjà été fait pour bien le comprendre. Comprendre les problèmes auxquels se sont heurtés les gens qui ont conçu "l'ancien truc", comprendre leurs solutions... je suis pas trop du genre à écouter une présentation de 60 minutes sur une solution existante et en ressortir tout confiant, prêt à faire mes premières pull-request dessus
De même, j'aime bien lire du code mais encore une fois se cogner toutes les sources d'un logiciel existant qui répond à une problématique, ça n'est pas l'unique façon d'aborder cette problématique. Je comprends les gens qui ont besoin de tenter leur truc dans leur coin, quand c'est pour des questions d'apprentissage. Après quand ça consiste à forker Ubuntu pour changer le pack d'icônes et appeler ça une distrib pour mettre sur son CV "fondateur de Ubuntu Feng Shui Edition, 8 utilisateurs incluant ma mère et ma soeur", je cautionne moins.

Bref my work is done here, je stack ce topic dans un coin de la to-read-list (jvais faire un addon qui me redirige vers cette liste à chaque fois que je veux glander sur netflix...). Intéressant ceci-dit!

Oué mais une boîte privée peut prendre des mesures fortes, faire réecrire une partie de son code, voir repartir de zero. Elle a les moyens financiers et les moyens humains pour le faire, et le risque est mesuré.

Pour avoir bossé dans une seule boite côté ingénierie au milieu de ma carrière dans la recherche publique, je peux te dire que bien souvent, dès que la boite est un tant soit peu grosse, qu'il y a des investisseurs à séduire ou une action en bourse à maintenir, il est hors de question de ré-écrire quoi que ce soit. Ils (ceux qui décident, qui veulent de la thune) veulent empiler les features mal développées et bugués mais qu'ils vont pouvoir vendre, plutôt que de rendre le code plus beau, avec de plus belles abstractions, et plus simple à maintenir.

Notre code était un monstre, qui devait être compatible muti plateformes, dont certaines complétement obsolètes... Mais comme un ou deux pauvres clients continuaient à s'en servir, on devait continuer à les supporter. On passait juste notre temps à faire les bitchs honnêtement...