Ouais Godrik, c'est ce que je disais sur le sujet en question (et que je m'en vais répeter ici au cas où vous n'y retourniez plus). Deux de mes trois PC sont UEFI sans support souris/réseau/whatever, juste du pur BIOS classique qui, pourtant, gère le Secure Boot et les entrées EFI (ce nouveau "truc en plus" de l'UEFI) donc pour moi c'est très commun puisque 66% de mes ordinateurs ne vont pas dans le sens du gars qui peuple actuellement le /dev/null.

Perso mon UEFI ça ressemble à une fenêtre de Windows Vista/7 + le contenu est agencé comme un menu de réglage de Nvidia

La résolution est inférieure à celle de mon écran cela dit.

C'est moi qui ai lancé le débat involontairement en voulant vulgariser la procédure
Perso, l'UEFI de mon portable a la même interface qu'un bios sans gestion de la souris. Par contre il y a moyen que mon PC fixe ai un UEFI avec support de la souris vu que c'est une CM MSI mais j'ai du aller 2 fois dessus maximum donc ça m'a pas marqué et j'avoue ne pas voir l'intérêt d'un support souris ni d'une IHM trop travaillé pour ce genre de logiciel au vu du temps passé dessus et de la façon dont s'est utilisé.

Tu es surtout parti du principe que l'auteur dispose d'un PC récent, ce qui est généralement le cas ici (surtout que quand les gens viennent avec un ordinosaure en général ils le précisent dans le post initial histoire de pas se faire conseiller Gnome3 ou KDE en environnement de bureau ).

j'avoue ne pas voir l'intérêt d'un support souris ni d'une IHM trop travaillé pour ce genre de logiciel au vu du temps passé dessus et de la façon dont s'est utilisé.

Moi non-plus. Chez MSi on tombe carrément dans le gimmick, mais bon ça fait plaisir à certains j'imagine. Pour ma part je préfère un truc avec des fonctionnalités intéressantes (genre le Wake-On-LAN), avec une UI sobre mais efficace.

De toute façon, je crois que l'auteur du sujet en question est parti après le pavé d'Ilatnem

On verra bien, parfois les gens oublient leur topic sur le bord de l'autoroute et reviennent le chercher deux semaines plus tard

Bon sinon j'ai pas encore testé la sauce Debian 10, juste installée. Pour le moment la seule différence "notable" que je vois à l'installation, c'est la possibilité d'activer les mises à jour de sécurité automatiques (avec un avertissement honnête sur les risques encourus ).

C'est quoi l'intérêt des versions chez debian ? Je me doute pas que c'est pas le lts de Ubuntu mais pourquoi c'est pas en rolling release et ça marche comment d'ailleurs ? C'est quoi la différence par rapport au lts ?

je ne comprends pas la question. toute les versions de debian sont lts.

rolling release est une mauvaise idee sur des machines de production.

GOG se fout-il de notre gueule en Europe ? Qui se souvient, il y a quelques années, de GOG qui se vantait qu'1 € ne valait pas 1 $ ?

Je regarde le prix de Cyberpunk. 59,99 € sur notre GOG français. Je me dis que si je change la monnaie en dollar, je devrais bien gagner un bon 7 € sur le prix et... Non, sur GOG de chez nous, le prix en dollar est à 66 $ et quelques... WTF ? QUI payerait un jeu 66 $ en vivant en Europe ?

Un petit détour par un proxy U.S. et là, le prix tombe bien à 59,99 $ soit 53 € et quelques... Putain de merde quoi... Et puis c'est pas illégal d'acheter sur GOG en étant connecté sur un proxy U.S., si ? Au final, on a les mêmes fichiers, absolument identique pour littéralement moins cher, c'est absurde !! GOG est-il revenu sur un argument de vente qui a fait sa notoriété ?

Ils ont du revenir dessus il y a plusieurs mois car il se faisait pas assez de bénéfice. Et perso, sa notoriété c'est plutôt le DRM free que de prendre en coût la valeur de la monnaie qui était certes intéressant mais pas le principal comparé à des jeux sans DRM.
https://www.jeuxvideo.com/news/1008384/gog-com-va-cesser-de-couvrir-les-differences-de-prix-regionales.htm
https://gamergen.com/actualites/gog-com-licencie-douzaine-employes-distributeur-est-grande-forme-financiere-299903-1

Et avec GOG 2.0, il y va y avoir d'autres atouts comme une bibliothèque unifiée.

C'était pas le principal mais c'était constamment affiché sur toutes les pages parmi les trois avantages à acheter sur GOG qu'ailleurs

Le 23 juillet 2019 à 23:43:03 godrik a écrit :
je ne comprends pas la question. toute les versions de debian sont lts.

rolling release est une mauvaise idee sur des machines de production.

Attends quoi, je pensais que LTS c'était une invention d'Ubuntu ?

Ben du rolling release t'es pas obligé de tout update donc y a moyen de configurer un "lts" dessus

Je savais pas pour le prix chez GOG, que pour le drum-free. Mais ça a l'avantage de permettre aux pays pauvres d'avoir de meilleurs prix.

Le 24 juillet 2019 à 15:55:13 Raskolnik a écrit :

Le 23 juillet 2019 à 23:43:03 godrik a écrit :
je ne comprends pas la question. toute les versions de debian sont lts.

rolling release est une mauvaise idee sur des machines de production.

Attends quoi, je pensais que LTS c'était une invention d'Ubuntu ?

LTS, ca veut dire Long Term Support. Toutes les version de Debian sont supporte par le grope securite pendant un an apres la release de la version d'apres, par le groupe LTS cinq ans ares la release de la version, et commercialement par freexian plus longtemps si tu veux payer.

Ben du rolling release t'es pas obligé de tout update donc y a moyen de configurer un "lts" dessus

Donc ta solution est de faire le travail de la distro toi meme? Est ce que tu peux garantir que tu peux faire ca sans jamais perdre de fonctionalite, sans cause de downtime consequent, qui corrige toutes les failles de securite, et qui ne prends pas plus de temps que de faire "apt update; apt upgrade"?

En pratique la reponse est non, c'est un travail super complique. Frequement une faille de securite est decouverte, et upstream patch la faille dans la version la plus recente du logiciel. Si tu fais tourner une version plus ancienne et pas compatible, tu as trois choix:
1/ Tu ne patch pas la faille et tu la laisse tourne en production.
2/ Tu met le logiciel a jour, ce qui veut souvent dire qu'il faut mettre a jour les dependances. Et apres il faut migrer les fichiers de configurations qui ne sont plus compatible. Et tout ca, c'est en supposant qu'il n'y a pas de perte de fonctionnalite pure et simple entre la version que tu fais tourne et celle qui est upstream. Sinon, il faut forward-porter une fonctionnalite que upstream a probablement retirer parceque c'etait chiant a maintenir et tu ne connais pas le code base. En supposant que tu ne depend pas d'un binaire qui vient d'un vendeur tier et qui demande cette version la en particulier, auquel cas, soit tu es assez fute pour ecrire le stub qui va mimer l'interface correctement, ou alors, c'est juste pas possible.
3/ Tu backportes le patch toi meme vers une version plus ancienne du logiciel. Ca peut prendre des jours ou des semaines de faire ca, surtout si tu le fais sur des code base que tu n'as jamais touche avant.

Ou alors, tu fais ce que font les gens raisonnable et tu laisse la distribution faire le travail parceque c'est LEUR travail. Et toi, tu fais TON travail.

Du coup les maj sécurités des LTS, ça se passe comment ? Si une faille est découverte, ils (les responsables de la distroà mettent tout à jour pour avoir le correctif ou ils corrigent la faille eux-mêmes ? Si c'est la deuxième solution, ils font comment pour corriger un logiciel propriétaire ?

Ca depend, dans certains cas upstream fournit un patch et donc ils l'appliquent. Dans certains cas, ils backporte le patch. Mais quand tu as des mainteneurs pour les differents paquets, le patche est relativement facile parceque tu as un mainteneur expert sous la main.

Tu ne change jamais de version en LTS, tu ne change pas de majeure, et tu ne change pas de mineure, JAMAIS. Tu ne change JAMAIS les fonctionnalites d'un paquet en LTS. Parcequ'il y a toujours une regression imprevue quelques part. Le contrat est: si ca marche avant la mise a jour, apres mise a jour ca doit toujours marcher. L'admin ne devrait avoir RIEN a faire dans le cas ideal, et si ca ce n'est pas possible, on doit pouvoir dire a l'admin EXACTEMENT ce qui doit etre fait.

Aussi, ils ne gardent pas 200 versions LTS, du coup l'effort est relativement simple. En ce moment il y a 3 debian qui sont LTS, jessie, stretch, et buster. Buster est la version courante, donc c'est l'equipe securite qui s'en occupe. stretch vient juste de devenir oldstable, donc l'equipe securite s'en occupe encore pendant un an. Donc l'equipe LTS ne s'occupe que de jessie et ce encore pendant un an. (Apres, je les presente comme des equipes differentes, mais il y a des mainteneurs commun entre les differentes equipe dans Debian.)

Prenons le cas de deux gros bout:

1. python. Les trois LTS distribuent python 2.7 pour python2, et pour python3, jessie supporte 3.4, stretch supporte 3.5 et buster 3.7. Donc jamais ils ne vont backporter un patch pour python 3.6.
2. apache2, jessie est sur la branche 2.4.10, stretch est sur la branche 2.4.25, et buster est sur la branche 2.4.38: donc sur un span de 28 mineures, ils ne regardent que 3 mineures en particulier.

Si le bug est dans un paquet tier binaire, c'est pas le probleme de la distro. Le probleme de la distro stable est de ne pas casse la compatibilite avec les logiciels tiers. Mais comme ils ne mettent pas a jour le logiciels de facon majeur (ils appliquent seulement les patches de securite), ils ne cassent pas les interfaces binaires. Et donc si tu utilises un plug-in binaire tier, il y a de bonne chance que ca marche sauf si le patch est pile a l'interface.

Donc ta solution est de faire le travail de la distro toi meme?

Non mais je comprends pas pourquoi c'est aussi distinctivement séparé par les dévs du rolling release (avec des noms genre Debian 10 et tout) m'enfin debian unstable c'est pas du LTS si ?

Je parlais pas de faire un LTS soi-même hein je vois très bien le boulot que ça demande (et Ubuntu est une preuve que ça marche pas)

Mais y avait pas un truc spécifique à Ubuntu, qui est pourri justement ? C'est la durée des 6 mois ?

le mois dernier debian 9 etait ce que debian appellais "debian stable"
aujourd'hui, debian 10 est "debian stable" et debian 9 est "debian oldstable". (Et debian 8 est debian "oldoldstable", et non, il n'y a pas de "oldoldoldstable" )

debian unstable, c'est debian unstable. c'est evidement pas LTS. Et c'est en effet assez proche de ce que tu aurais avec une rolling release. Les paquets dans unstable sont a peine teste. En gros la barre, c'est "ca compile, et ca fait pas segfault quand je le lance". Le but d'unstable est de teste les paquet pour voir si ils sont assez stable pour aller dans "testing" (et testing c'est future stable).

la semantique change legerement pendant les periodes de freeze de debian ou la barre est releve pour testign et unstable afin d'arriver a une stable qui est relativement sans bug.

J'arrive pas à voir comment ils font pour maintenir tout les logiciels. Imaginons on découvre une faille au moment de la version 2.23 d'un logiciel qui était présente depuis un moment or la version sur Debian Stable est la 2.15. Ca se passe comment ? C'est les mecs de Debian qui font un patch (si oui ils font comment dans le cas d'un logiciel propriétaire ?) ?

Bah, Debian c'est 1400 contributeur et 80 mainteneurs. Donc, bon il y a de la force de frappe!

Dans le cas que tu donnes, si c'est du logiciel libre, ils backporte le patch qui resoud la faille. La plupart du temps, le patch s'applique tout seul: tu cherrypick le commit dans git et pan ca marche.

Les mainteneurs des paquets connaissent bien l'equipe de developpement upstream, voir ils font parti de l'equipe de developpement upstream. Aussi les mainteneurs de paquet de debian parlent aux mainteneurs de fedora et companie. Donc en pratique, ils ne font pas tout ca eux meme, probablement tu peux reutiliser le patch de redhat. Et quand il y a une grosse faille sur un logiciel complique, la communaute partagent leurs notes sur quel patch marche sur quelles versions.

Si c'est un logiciel proprietaire c'est complique. Mais il y a tres peu de logiciel proprietaire dans debian, il y a quelques firmware et drivers, et c'est tout.

Le 26 juillet 2019 à 20:43:46 godrik a écrit :
Bah, Debian c'est 1400 contributeur et 80 mainteneurs. Donc, bon il y a de la force de frappe!

Dans le cas que tu donnes, si c'est du logiciel libre, ils backporte le patch qui resoud la faille. La plupart du temps, le patch s'applique tout seul: tu cherrypick le commit dans git et pan ca marche.

Les mainteneurs des paquets connaissent bien l'equipe de developpement upstream, voir ils font parti de l'equipe de developpement upstream. Aussi les mainteneurs de paquet de debian parlent aux mainteneurs de fedora et companie. Donc en pratique, ils ne font pas tout ca eux meme, probablement tu peux reutiliser le patch de redhat. Et quand il y a une grosse faille sur un logiciel complique, la communaute partagent leurs notes sur quel patch marche sur quelles versions.

Si c'est un logiciel proprietaire c'est complique. Mais il y a tres peu de logiciel proprietaire dans debian, il y a quelques firmware et drivers, et c'est tout.

D'accord, je vois mieux et ça se passe à peu près comme j'imaginais. Le nombre de contributeur est donc vraiment essentiel surtout si c'est pas un logiciel qui propose des versions LTS.

Vous conseillerez quoi comme logiciel de gestion de projet sur Linux (de préférence libre ou au moins open source) ? Je dois faire des diagrammes de Gantt Je connais Gantt Project mais je me demande si il y a mieux.