Debian GNU/Linux 9, nom de code Stretch (en référence à la pieuvre violette de Toy Story 3) est sortie le 17 juin 2017.
(
Alors que la version 8 intégrait systemd, cette version intègre pour sa part quelques autres nouveautés technologiques de taille comme Wayland (cela concernera surtout les utilisateurs du bureau GNOME), Flatpak ou encore le pilote noyau unifié AMDGPU pour les puces graphiques AMD les plus récentes…
Les choses sont également plus claires maintenant que Firefox et Thunderbird sont présents dans les dépôts sous leurs noms officiels, grâce notamment aux efforts de Sylvestre Ledru (compte Twitter). So long Iceweasel et Icedove !
Sommaire
Considérations générales
Stretch est disponible sur dix architectures matérielles différentes : AMD64, ARM64, ARMel, ARMhf, i386, MIPS, MIPS64el, MIPSel, PowerPC64el et s390x.
Elle repose sur le compilateur GCC 6 exclusivement (voir l’annonce sur la liste de diffusion). LLVM/Clang/LLDB est proposé par défaut en version 3.8 (et embarque aussi la version 3.9).
Il est à noter que la version pour i386 nécessite un processeur prenant en charge l’option de compilation i686, et que Stretch ne sera pas disponible sur PowerPC.
Des statistiques sur le nombre de paquets (environ 54 000 paquets produits à partir de 25 000 paquets source), de fichiers source, leur taille, le nombre de lignes de code et la répartition par langage de programmation sont disponibles (parmi plein d’autres statistiques du projet Debian), ainsi que la production reproductible de paquets (94 % des paquets pour stretch/amd64).
L’installation peut se faire en 75 langues (et le site Debian est disponible en 37 langues).
Cette version est dédiée à Ian Murdock, le fondateur du projet Debian, mort en décembre 2015.
Installateur
En grande partie grâce au travail de Cyril Brulebois (comptes Twitter et Mastodon, #DebianInstaller), l’installateur a été revu :
- installation en mode graphique par défaut, si disponible ;
- choix de l’environnement graphique possible via tasksel ;
- prise en charge de 75 langues (certaines uniquement en mode graphique) ;
- meilleure gestion de l’UEFI (mais pas encore Secure Boot au moment de la sortie de Stretch 9.0).
Nouveautés logicielles
Nouvelles versions de logiciels :
- GNOME 3.14 → 3.22 (proposé par défaut en version X.Org et sur option en version Wayland ; et avec, pour la première fois dans Debian, GNOME Logiciels : ça tombe bien vu que Synaptic est incompatible avec Wayland — bon, sinon, il y a apt aussi) ;
- XFCE 4.10 → 4.12 ;
- KDE 4.14 → KDE Plasma 5.8 ;
- MATE 1.8 → 1.16 ;
- Vim 7 → 8 ;
- GnuPG 1.4 → 2.1 ;
- LibreOffice 4.3 → 5.2 (parmi les nouveautés, citons le port vers GTK3 et Wayland) ;
- Gimp 2.8 → 2.8 (non, ce n’est pas une erreur ! À noter : d’une part que dans l’intervalle GIMP a fêté ses 20 ans et, d’autre part, que la version 2.10 qui devrait sortir cette année pourra être installée via Flatpak — voir ci‐après) ;
- Firefox ESR 52, incluse à la sortie de Stretch, est la première version ESR compilée pour GTK 3 (ce qui n’est pas encore le cas de Thunderbird — ici en version 45) (à noter qu’il faudra encore attendre pour voir ces logiciels fonctionner nativement sous Wayland, d’ici là ils fonctionnent parfaitement et de manière transparente avec la surcouche XWayland) ;
- NetworkManager 0.9 → 1.6 ;
- le pilote X.Org xf86-video-intel pour toutes les puces graphiques Intel Gen 4 ou supérieures (puces arrivées en 2007) est retiré au profit du pilote générique xf86-video-modesetting qui repose sur Glamor, un procédé d’accélération 2D général basé sur OpenGL, et qui est déjà utilisé pour les puces AMD les plus récentes (cela ne change rien pour le pilote 3D).
Nouveauté de taille : Flatpak débarque, en version 0.8 : à vous les applications dans leur dernière version sans risque d’altérer la stabilité de votre Debian Stable ! Autrement dit : vous n’aurez plus à choisir entre nouveauté et stabilité.
Parmi les nouveautés en termes de logiciel, Stretch embarque notamment :
- la première version du « Debian Pure Blend » Astro (une solution pour des groupes aux besoins particuliers, ici l’astronomie). Il rejoint ceux sur la chimie, les jeux, l’éducation, les SIG, pour les enfants, le médical, le multimédia ou la science) ;
- le logiciel de mathématiques Sagemath de sagemath.org ;
- la forge logicielle GitLab ;
- la possibilité d’installer les paquets MELPA (Emacs Lisp) par apt (comme Flycheck, Projectile, Evil et Helm) ;
- la pile LIO SCSI, avec les modules FC, FCoE, iSCSI, iSER, tcm_loop, etc.
Côté serveur :
- MariaDB 10.1 devient la version par défaut de MySQL (il s’agissait précédemment d’Oracle MySQL) et des méta‐paquets ont été ajoutés pour faciliter les changements futurs ;
- nginx 1.6 → 1.10 ;
- OpenJDK 1.7 → 1.8 ;
- OpenSSH 6.7 → 7.4 (les vieux algorithmes de chiffrement et le protocole SSH 1 sont maintenant désactivés par défaut dans OpenSSH) ;
- PHP passe de la version 5.6 à la version 7.0 et l’empaquetage a été retravaillé pour faciliter l’installation de multiples versions en parallèle ;
- OpenSSL (1.0.1t → 1.1.0e) (les chiffrements 3DES et RC4 ne sont plus disponibles, ce qui casse de vieux outils, tels que la prise en charge de TLS sous Windows XP) ;
- Perl (5.20.2 → 5.24.1) (certains modules retirés du cœur sont livrés via des paquets séparés).
Pour les nouvelles installations, une nouvelle méthode de nommage des interfaces réseau sera utilisée (du type ens0 ou enp1s1 (Ethernet) ou wlp3s0 (sans fil) au lieu de eth0 ou eth1).
Parmi les retraits de logiciels :
- OwnCloud, jugé trop difficile à maintenir ;
- VirtualBox, du fait qu’Oracle refuse de partager les vulnérabilités à travers le CVE, cela rend difficile la gestion de la sécurité des paquets dans la branche stable ;
- les interfaces réseau ne sont plus nommées de la même manière. Pour les nouvelles installations, les informations matérielles et l’adresse MAC sont utilisées pour le nommage et la numérotation ; les installations existantes ne sont pas touchées ;
- le paquet
net-toolsest déclaré obsolète au profit deiproute2(apt install net-toolspour récupérerifconfiget ses copains) ; - le montage de
/usrdoit se faire au niveau de l’initramfs. Pas de souci avec les noyaux fournis par Debian ; -
/binet/sbinfusionnés dans/usr/binet/usr/sbinà l’installation du paquetusrmerge(par défaut lors de l’installation). - les gestionnaires de mots de passe
fpm2etkedpmqui ne sont plus maintenus en amont (voir plutôt du côté depass,keepassxoukeepass2) ; - l'outil de surveillance
nagios3qui peut être remplacé paricinga.
Améliorations d’apt :
- téléchargement via utilisateur apt (ce n’est plus root) ;
- information intéressante pour les administrateurs de miroirs : l’
aptde Stretch peut utiliser des enregistrements DNS (SRV) pour localiser une ressource HTTP (back‐end) ; - nouveau miroir au nom « ultra simple à retenir » : deb.debian.org ;
- interface en ligne de commande stabilisée (plus d’avertissement lors d’un tube — pipe —, par exemple) ;
- disparition des serveurs FTP pour les paquets.
Nouveaux paquets de débogage :
Les paquets contenant les symboles de débogages étaient auparavant de la forme paquet-dbg, ceux‐ci se nomment maintenant paquet-dbgsym, sont générés automatiquement et se trouvent dans un nouveau dépôt et non plus dans le dépôt principal. Ces modifications permettront aux dépôts miroirs de ne plus avoir à récupérer ces paquets qui étaient utilisés par peu de gens, permettant ainsi d’économiser bande passante et espace disque.
Stretch avait été légèrement retardé pour faire place au noyau Linux 4.10 : en effet, ce noyau devait être une version à support étendu (long‐term support ou LTS), version que les développeurs en amont (upstream) s’engagent à maintenir plus longtemps. Ceci facilite en retour le travail de l’équipe noyau de Debian, lire ce journal pour plus d’explications. La version finalement choisie par le responsable des LTS Greg Kroah‐Hartman est la 4.9, l’équipe noyau de Debian l’a donc aussi choisie pour être le noyau de Stretch.
Après un vote public (ouvert à tous), c’est le thème graphique nommé softWaves qui a été choisi pour Stretch. Il a été réalisé par Juliette Taka‐Belin, créatrice du thème de la version précédente de Debian.
Futur
La version testing se nomme désormais Buster (le chien dans les films d’animation Toy Story).
Aller plus loin
- Debian (1442 clics)
- Debian Stretch sur Debian Wiki (642 clics)
- Dépêche de la version 8 Jessie (199 clics)
- Debian : Notes de version (292 clics)
- Debian 9 sans se prendre la tête (1390 clics)
- Debian 9 Stretch pour les très grands débutants (1045 clics)
- Annonce officielle de la sortie (253 clics)
# Mise à jour d'URL
Posté par Cyril Brulebois (site web personnel) . Évalué à 3.
Merci à tous pour l'article. Une petite édition serait la bienvenue, mon compte Twitter est (du moins pour l'instant) celui où toutes les infos relatives à l'installateur sont publiées : cf. @CyrilBrulebois & #DebianInstaller.
Debian Consultant @ DEBAMAX
[^] # Re: Mise à jour d'URL
Posté par Benoît Sibaud (site web personnel) . Évalué à 3.
Infos ajoutées dans la dépêche, merci.
[^] # Re: Mise à jour d'URL
Posté par antistress (site web personnel) . Évalué à 2. Dernière modification le 18 juin 2017 à 18:35.
Du coup on pourrait mettre le compte LinuxFr de Cyril sous son nom dans la dépêche, comme pour Sylvestre (vu qu'on a des stars ici :)
[^] # Re: Mise à jour d'URL
Posté par Benoît Sibaud (site web personnel) . Évalué à 3.
Ajouté, merci.
# KDE 5.8 !
Posté par Eiffel . Évalué à 5.
Sacré bond en avant ! Ça fait plaisir de voir Plasma dans Debian, qui sait Debian pourrait potentiellement remplacer ma Kubuntu ?
[^] # LXQt aussi !
Posté par Anonyme . Évalué à 3.
En plus de KDE 5, on a enfin LXQt pour du desktop sur des machines nomades. :)
# Ouais...
Posté par antistress (site web personnel) . Évalué à 4. Dernière modification le 18 juin 2017 à 18:38.
…land !!!
Et ça c'est cool :)
À part ça, si quelqu'un a une astuce sous GNOME Wayland pour que le pavé numérique reste activé au démarrage, je suis preneur. C'est censé être réglé upstream, mais ça ne l'est pas dans mes Debian…
[^] # Re: Ouais...
Posté par gnumdk (site web personnel) . Évalué à 1.
C'est vraiment une mauvaise idée d'utiliser wayland pour l'instant, encore plus avec Gnome 3.22.
Le support est loin d'être complet et certaines fonctions de base de GTK ne sont pas implémentées: gtk_window_present() par exemple.
[^] # Re: Ouais...
Posté par Renault (site web personnel) . Évalué à 6.
Je ne suis pas de ton avis.
Même s'il manque des choses, j'utilise Wayland depuis un an au quotidien sous GNOME sans avoir de soucis particuliers.
[^] # Re: Ouais...
Posté par gnumdk (site web personnel) . Évalué à 7.
Si pour toi une fonctionnalité de base à savoir afficher une fenêtre à l'écran n'est pas un problème… Clic sur une notification de geary ou autre, sous Wayland, il ne se passe rien, sous Xorg, la fenêtre devient la fenêtre active.
[^] # Re: Ouais...
Posté par Renault (site web personnel) . Évalué à 5.
La fonctionnalité que tu cites ne sert pas à tout le monde (typiquement, je clique rarement sur les notifications, je la lis et c'est tout).
De plus cela reste une fonctionnalité de confort, elle n'est pas indispensable à un usage du bureau. GNOME reste utilisable dans ces conditions.
À chacun de mettre le curseur suivant ses besoins et attentes, il y a des personnes qui ne peuvent pas utiliser Wayland encore (notamment ceux qui ont besoin d'outils d'accessibilité) mais de là à dire qu'il faut le déconseiller à tout le monde me semble aberrant. Comme je le dis, je l'utilise sans soucis depuis longtemps, et je ne suis pas le seul.
Et il est bien que plein de gens testent Wayland par ailleurs, pour avoir des retours et l'améliorer plus vite.
[^] # Re: Ouais...
Posté par Romeo . Évalué à 5.
Heu, non ?
C'est le comportement de base sur tout les autres OS desktop/mobile …
Cela n’empêche peut-être pas d'utiliser Wayland, mais ça reste une regression forte à mes yeux.
[^] # Re: Ouais...
Posté par Renault (site web personnel) . Évalué à 5.
C'est bien ce que je dis, ce n'est pas avec cette seule régression que tu déconseille tout le monde d'utiliser Wayland.
Je n'ai pas dis que ce n'était pas gênant, voire pénible pour certains, juste que de déconseiller Wayland sur cette seule régression était exagéré.
[^] # Re: Ouais...
Posté par ff9097 . Évalué à 3.
Ça marche très bien depuis plus d'un an.
[^] # Re: Ouais...
Posté par antistress (site web personnel) . Évalué à 3. Dernière modification le 19 juin 2017 à 12:10.
Ça marche très bien chez mon père en stable et chez moi en Unstable, si ce n'est la mémorisation de l'état du pavé numérique.
Bon, nos besoins sont simples : un seul écran, pas de tablette wacom etc.
[^] # Re: Ouais...
Posté par Bigon . Évalué à 1.
Le problème de NumLock est en fait un bug dans le paquet debian (Bug: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=649587)
Je viens de le fixer dans unstable et je vais le fixer dans stable aussi.
[^] # Re: Ouais...
Posté par antistress (site web personnel) . Évalué à 2.
Mon héros !
[^] # Re: Ouais...
Posté par Cyril Brulebois (site web personnel) . Évalué à 1.
Heureusement qu'on a des clous pour fixer tous ces bogues, hein ! ;)
Debian Consultant @ DEBAMAX
# libreoffice avec wayland ?
Posté par Jarvis . Évalué à 2.
Jamais entendu parlé d'une prise en charge native de Libreoffice avec Wayland. Vous êtes surs?
[^] # Re: libreoffice avec wayland ?
Posté par Renault (site web personnel) . Évalué à 4.
En tout cas sous Fedora, sous Wayland, Libreoffice est bien lancé par défaut avec la compatibilité Wayland. Pas de X11 / XWayland requis donc.
[^] # Re: libreoffice avec wayland ?
Posté par Okki (site web personnel, Mastodon) . Évalué à 8.
À mon avis, c'est juste le portage GTK+ 3 qui apporte de facto la compatibilité Wayland.
# Vivement la suivante
Posté par louiz’ (site web personnel) . Évalué à -10.
Vivement debian 10, dans 2-3 ans, qu’on puisse enfin publier des logiciels écrits en C++17 ou en Python 3.6.
C’est toujours un plaisir d’être coincé dans le passé à cause de cette distro.
[^] # Re: Vivement la suivante
Posté par claudex . Évalué à 10.
Ben, be l'utilise pas…
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Vivement la suivante
Posté par louiz’ (site web personnel) . Évalué à 2.
Je l’utilise pas. Je veux juste que les gens qui veulent utiliser mes logiciels puissent les utiliser.
Donc je dois me conformer à ce que les gens utilisent, malheureusement. Et le plus petit dénominateur c’est Debian stable.
[^] # Re: Vivement la suivante
Posté par barmic . Évalué à 9.
Il y a des RHEL toujours maintenues largement plus vielle.
Mais C++17 à changer d'ABI ? Je pensais que ces langages sans runtime avait justement pas ce genre de problème (modulo la disponibilité des bibliothèques dynamiques que tu utilise).
Après on le dit à chaque fois Debian Stable est fait pour les serveurs. C'est prévu pour être véritablement stable au détriment des mises à jour (hors sécurité). Un serveur est géré par admin qui lui saura sans difficulté installer une application dans un environnement précis.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Vivement la suivante
Posté par whity . Évalué à 5.
Je suppose qu’il utilise des fonctionnalités de la bibliothèque standard C++17 qui ne sont donc pas disponibles (le standard C++17 n’est même pas finalisé…). Il pourrait cela dit compiler son application en liant la libstdc++ en statique (-static-libstdc++ si mes souvenirs sont bons) si c’est juste ça le soucis, et ça marcherait vraisemblablement.
Cela dit : les gens qui veulent une version « stable » ne veulent probablement pas d’une application compilée avec un support expérimental (il y a une grosse contradiction là-dessus).
Sinon, si, l’ABI change grosso merdo à chaque release majeure de GCC (donc entre la 4 et la 5, la 5 et la 6, etc.). C’est cela dit surtout au niveau de la libstdc++ que cela joue, pas du langage lui-même.
Mes commentaires sont en wtfpl. Une licence sur les commentaires, sérieux ? o_0
[^] # Re: Vivement la suivante
Posté par louiz’ (site web personnel) . Évalué à 1.
Non, le but c’est que ça puisse etre compilé sous debian, pas de fournir un binaire qui pourrait se lancer sous debian.
Je pense qu’il y a des gens qui veulent un OS stable (dans le sens « j’ai plus besoin d’y toucher quand je mets à jour, rien ne va casser/bouger, je suis tranquille »), tout en ayant la possibilité d’installer quelques rares logiciels « à jour » manuellement. Sinon le repository « backport » n’existerait pas.
En effet. Et je n’ai pas dit « je veux release mon truc aujourd’hui », mais « j’aurais bien aimé avoir la possibilité de release un truc utilisant C++17 avant 2-3 ans ». D’ici là C++17 sera bien finalisé.
[^] # Re: Vivement la suivante
Posté par Zenitram (site web personnel) . Évalué à 9.
Es-tu conscient que ce que tu dis, si on le reformule de manière plus directe, c'est "je veux qu le truc qui sort maintenant supporte un truc qui n'a pas encore été défini"?
IPoT?
Personne n'est capable de faire ça, sauf à parier sur l'idée que C++17 beta sera le même que C++ release, ce qui est dans tous les cas dangereux.
Si tu as besoin d'une truc "hype", tu ne peux compiler par défaut que sur du "hype", normal.
Mais rien ne t’empêche de :
- Compiler sur ta machine hype et livrer les .deb pour les non hypes
- Arrêter de te la péter "j'ai absolument besoin de C++17", et faire du C++ compatible avec le non hype.
Pour l’anecdote, je maintien un fork d'un projet que je compile pour des vieux macOS que certains utilisent encore, et mes patchs pour faire du C++03 (à la place de C++11, non supporté par les libs par défaut et embarquer en statique est assez galère sous macOS ou je n'ai pas trouvé) ont été refusé, alors que ça change rien (c'est de la typo, et parfois même les conversions auto ralentissent plus qu'autre chose, rien de "killer-feature"), et l'argument est juste "non mais C++11 c'est assez vieux arrête de me faire chier nous on est hype".
Alors, perso je trollerai en te demandant en quoi ton super-logiciel a absolument besoin de C++17 qui va "enlarge your productivity".
[^] # Re: Vivement la suivante
Posté par louiz’ (site web personnel) . Évalué à -4.
Le problème c’est pas que ça soit pas disponible maintenant. C’est que les versions de debian sortent tous les 1000 ans, du coup on reste sur ces versions pendant 1000 ans. cf mon autre réponse où je parle de fedora, etc.
C’est aussi une question de malchance. Si le freeze avait eu lieu, disons, 8 ou 9 mois plus tard, et bien peut-etre que gcc 7 aurait été dedans, et donc on aurait pu l’avoir à disposition 2 ou 3 ans plus tot.
lol ;)
C’est juste qu’on n’a pas la meme notions de ce qui est « à jour » ou non. Je suppose que tu ne voudrais pas coder en C++98 avec un gcc qui a 20 ans (enfin, peut-etre que si, mais c’est juste pour la démo), parce que c’est vieux et qu’il te manque des trucs. Ben moi pareil, sauf que c’est pas au bout de 20 ans que ça me gène, c’est au bout de 2. Alors oui, techniquement je peux toujours coder avec des hyper vieux langages qui existaient avant que je sois né, mais bof.
Ils n’en ont pas besoin. Ils n’ont même pas besoin d’être en C++ tout court. Ils n’ont même pas besoin d’exister. C’est juste que je préfère. Parce que ça me passionne, m’intéresse et me fait plaisir.
(t’arrives quand même à deviner des intentions un peu comme tu veux, dans les messages des autres. « Te la péter », « ton super-logiciel »)
[^] # Re: Vivement la suivante
Posté par Psychofox (Mastodon) . Évalué à 3.
Saut que au final tu es de très mauvaise foi car on parle de 2ans entre chaque release debian et pas 1000ans.
[^] # Re: Vivement la suivante
Posté par louiz’ (site web personnel) . Évalué à 0.
https://en.wikipedia.org/wiki/Hyperbole
J’ai supposé qu’en mettant un nombre irréaliste (ici 1000 ans), ça semblerait évident que c’est pas vraiment le nombre d’années entre deux release debian, et que c’était juste une éxagération pour dire « super longtemps ».
Mais désolé, tu as raison, ouais, c’est SEULEMENT 2 ans. Ouf.
[^] # Re: Vivement la suivante
Posté par Psychofox (Mastodon) . Évalué à 7. Dernière modification le 20 juin 2017 à 12:01.
Mais 2 ans c'est pas énorme au final.
J'ajouterai que ton problème n'a rien de spécifique à debian et s'efforcer à toujours utiliser ce qui est le plus bleeding edge possible, c'est un peu une forme d'asociabilité. Tu fermes la porte à la plupart des gens qui utilisent du BSD, et même la plupart des distros.
Si on check le nombre de distros packageant gcc > 7 dans leur dernière release on se rend compte qu'il n'y a pas beaucoup de candidates et encore moins de distributions "majeures": en gros Fedora, Arch et Gentoo. C'est peu.
[^] # Re: Vivement la suivante
Posté par eingousef . Évalué à 4.
Ben te plains pas alors
*splash!*
[^] # Re: Vivement la suivante
Posté par Zenitram (site web personnel) . Évalué à 9. Dernière modification le 20 juin 2017 à 14:40.
Tu es dans la mauvaise foi la plus complète, alors soyons clair, tu as 2 options :
- Tu as rien à foutre des autres, dans ce cas tu as rien à foutre que Debian a GCC 1000 ou 1001,
- Les autres t’intéresse, tu dois gérer l'historique, qui en gros est de 5-7 ans (ce qui n'est pas énorme au passage) suivant les pas de chance, avec du CentOS, du Mac, du Ubuntu en plus de Debian. Debian n'est pas le pire en fait, c'est le cadet de tes soucis (perso j'avais toujours des utilisateurs en Ubuntu 12.04 jusqu'au mois dernier). Et tu as le choix, entre filer les binaires que tu as compilé toi-même sur du moderne avec un backport possible sur veille distro ou utiliser du C++ de plus de 5 ans (ce qui n'est pas bien méchant) pour que tout le monde puisse compiler sans se prendre la tête
Dans les 2 cas, il n'y a aucune raison à ta complainte sur Debian, qui est la que pour te complaire.
Disons qu'avec des arguments type "C’est juste que je préfère", c'est la seule conclusion qu'on peut avoir, c'est tout. Niveau d'argumentation sur ton besoin que les autres devrait assouvir : 0.
[^] # Re: Vivement la suivante
Posté par louiz’ (site web personnel) . Évalué à -1.
Les autres m’intéressent, mais 5-7 ans c’est énorme pour moi.
[^] # Re: Vivement la suivante
Posté par whity . Évalué à 7.
En effet. Et rien ne t’interdit d’installer gcc 7 sur ta debian. Mais je comprends que les mainteneurs ne fassent pas d’effort en ce sens : ce n’est pas ce que fait le public visé, ce n’est pas ce que souhaitent la plupart des utilisateurs.
Si ton logiciel devient :
- important d’être mis à jour régulièrement, aussi bien en terme de technos que de sécurité
- indispensable au quotidien des utilisateurs
- avec une bonne réputation de qualité sur les mises à jour, notamment en terme de non-régression
Alors tu pourras discuter avec les mainteneurs debian pour une exception. Le seul logiciel que je connais dans ce cas est firefox (pour les définitions d’anti-virus et similaires, pour qui c’est aussi le cas, il y a un canal dédié). Pour les autres, il y a les backports si ton logiciel peut supporter d’être compilé sur un environnement d’il y a x ans où x < 3. S’il ne peut pas, il te reste d’autres canaux de distribution (par exemple : fournir un .deb sur ton propre repository).
Il y a je pense suffisamment de solutions alternatives pour que tes critiques sur le choix de stabilité fait par debian ne soient guère entendues.
Mes commentaires sont en wtfpl. Une licence sur les commentaires, sérieux ? o_0
[^] # Re: Vivement la suivante
Posté par Sébastien Wilmet . Évalué à 4.
Ça dépend du contexte dans lequel tu développes tes logiciels, mais tu pourrais peut-être adopter une approche comme font la plupart des modules GNOME:
- sortir une nouvelle version à intervalle régulière.
- ne pas hésiter à utiliser les dernières technologies et versions des bibliothèques, sans garder la compatibilité avec les anciennes versions (donc pas de
#if/#elsesuivant la version d'une bibliothèque, par exemple).- pour une certaine version d'une certaine distrib, prendre la dernière version du logiciel qui est compatible.
Donc ceux qui sont en Debian stable pourraient installer la version N-1 ou N-2 de tes logiciels. Tout comme Debian stable a actuellement GNOME 3.22 alors que GNOME 3.24 est déjà sorti en amont.
[^] # Re: Vivement la suivante
Posté par louiz’ (site web personnel) . Évalué à 0.
Ouais, mais bof, après tu te retrouves avec des bugs du type:
Je m’imagine très bien tomber dans une telle situation : https://www.jwz.org/blog/2016/04/i-would-like-debian-to-stop-shipping-xscreensaver/
[^] # Re: Vivement la suivante
Posté par claudex . Évalué à 10.
Donc tu veux fournir à des utilisateurs qui privilégie une distrib avec des paquets stables (sinon ils n'utilisent pas Debian stable) un truc qui bouge tout le temps et dépend de la dernière version des bibliothèque. J'ai l'impression que tu as un problème de cible.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Vivement la suivante
Posté par louiz’ (site web personnel) . Évalué à -9. Dernière modification le 19 juin 2017 à 19:56.
Ça dépend si une release tous les ans c’est « qui bouge tout le temps » pour toi, alors ouais.
Et c’est surtout que j’ai eu des utilisateurs debian qui sont venus demander pourquoi ça marchait pas. Du coup j’ai dû faire une image docker debian pour tester le machin, trouver pourquoi ça marchait pas spécifiquement sur debian, et maintenant j’essaye de m’assurer que ça fonctionne sur debian, parce que je suis sympa.
Et puis « des utilisateurs qui privilégie une distrib avec des paquets stables (sinon ils n'utilisent pas Debian stable) », laisse moi rire. Je parie qu’il y a un très très grand nombre d’utilisateurs de debian qui le sont uniquement parce que « c’est la distribution pour les serveurs, et moi j’ai un serveur, donc c’est ce qu’il me faut, non ? » et qui se retrouvent à installer des backports à tour de bras.
Mais bon, je vais peut-être envoyer chier tous les utilisateurs debian qui viendront demander comment utiliser mes logiciels, vu que c’est ça que je suis censé faire si je comprends bien ce qu’on me raconte ici. Parce que ce que je retiens de cette discussion c’est un peu « non mais on en veut pas de ton truc ». C’est triste.
[^] # Re: Vivement la suivante
Posté par claudex . Évalué à 7.
Ben, c'est toi qui vient cracher sur Debian à la base du thread. Il ne faut pas s'étonner d'avoir des retour négatifs après.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Vivement la suivante
Posté par louiz’ (site web personnel) . Évalué à -9.
Oui, et c’est très bien, ça confirme ce que je pensais.
Je vais pouvoir utiliser tranquillement des trucs à jour la conscience tranquille.
Je suis passé de « oui mais les pauvres utilisateurs ?? Je peux pas les abandonner :(( » à « Barf, vu qu’apparemment ils s’en foutent, c’est bon ».
Je vous remercie donc.
[^] # Re: Vivement la suivante
Posté par Psychofox (Mastodon) . Évalué à 4.
Ben voilà tout le monde est content.
[^] # Re: Vivement la suivante
Posté par ylsul . Évalué à 2.
Tu pourrais en discuter avec les mainteneurs Debian et leur dire que ton logiciel n'est pas maintenu à long terme et qu'ils ne devraient pas le distribuer. Proposer juste des versions exécutables directement sur ton site par exemple (pour python je suppose que ça nécessite un emballage particulier…).
Parce que le principe de Debian c'est qu'ils ont une version stable maintenue longtemps, avec des logiciels qui n'ont pas subi d'ajouts de fonctionnalités depuis un moment, dans le but d'améliorer leur stabilité. C'est en contradiction avec l'objectif "je ne veux pas rétro-porter mes corrections de bugs sur les anciennes versions". Soit tu maintiens certaines versions de ton logiciel à long terme, soit ce n'est pas compatible avec Debian stable (je ne sais pas s'ils peuvent maintenir le logiciel dans les versions de test / instable seulement).
D'ailleurs c'est même dangereux que dans la Debian stable il traîne une telle version d'un de tes logiciels, il faudrait le voir avec eux.
[^] # Re: Vivement la suivante
Posté par louiz’ (site web personnel) . Évalué à 2.
Ils backportent apparemment sur la version 4.0 (la version packagée) certains correctifs que je fais sur master.
Je sais pas comment ils sélectionnent quels patchs sont importants et lesquels ne le sont pas (j’ai vu qu’ils en ont pris un qui parlait d’un “null pointer dereference etc”), et je n’ai pas vraiment de retour de la part du packager, ni aucun dialogue (c’est quelqu’un d’autre qui m’a informé que c’était packagé dans debian).
À mon avis c’est pas une bonne idée (ils passent vraiment en revu tous mes commits pour décider lesquels sont dignes de la version stable, lesquels sont importants et lesquels ne le sont pas ?!), mais bon, c’est pas vraiment mon problème.
[^] # Re: Vivement la suivante
Posté par Anonyme . Évalué à 3.
On parle de biboumi ?
Si c’est le cas alors le paquet n’est même pas dans stable et « ils », c’est surtout Jonas Smedegaard.
Les packagers prennent souvent contact avec l’upstream, si ça n’est pas le cas ici, est-ce que toi tu les as contacté ? Sinon, alors tu es au mauvais endroit, c’est vers lui/eux que tu dois te retourner.
[^] # Re: Vivement la suivante
Posté par louiz’ (site web personnel) . Évalué à 2.
Oui, on parle de biboumi, et oui effectivement il n’est pas dans stable (mais il reste quand meme en version 4.x, je ne sais pas trop pourquoi du coup, vu que la version 5.0 est sortie et est vachement mieux).
Et non, il ne m’a pas contacté, alors qu’il a patché certains trucs qui auraient pu m’intéresser, par exemple
https://anonscm.debian.org/cgit/pkg-voip/biboumi.git/commit/debian?id=111e446d1d57ccc47b35f7c6fbf8bd5575d5a0a1
https://anonscm.debian.org/cgit/pkg-voip/biboumi.git/commit/debian?id=176a1fcdf53f54c92fbc57f49f610bb7c91ec8f4
Je regrette un peu ce manque de communication (j’aurais bien aimé un petit « au fait, pourquoi tu n’as pas appliqué cette modification à ta dernière release, parce qu’elle rencontre aussi ce problème, pas juste la branche master ? »), mais ce n’est pas dramatique, et ce n’est pas le sujet de ce thread. Le travail fait par le packager est correct, et je n’ai pas non-plus pris la peine de le contacter pour lui dire que j’aimerais plus de communication, donc je suis pas vraiment en position pour lui raler dessus.
[^] # Re: Vivement la suivante
Posté par Anonyme . Évalué à 3. Dernière modification le 20 juin 2017 à 14:25.
Peut-être que le mainteneur n’a pas eu le temps de s’en occuper, y a qu’en prenant contact avec lui que tu sauras.
Concernant le second patch : « Add some bugfix patches cherry-picked upstream. », donc c’est qq chose qui est déjà présent chez toi.
Au final, j’ai quand même l’impression que tu en fais des tas, mais que non seulement tu es de mauvaise fois mais en plus tu ne fais rien de concret pour résoudre ces « problèmes »
[^] # Re: Vivement la suivante
Posté par louiz’ (site web personnel) . Évalué à 2.
Oui, cherry-picked de ma branch master, pour etre appliquée à la release 4.0 (la dernière à l’époque). Je ne l’avais pas fait moi-meme parce que je ne savais pas que le problème se trouvait aussi dans la 4.0. C’est de ça dont je parle dans mon « j’aurais bien aimé un petit “au fait, pourquoi tu n’as pas appliqué cette modification à ta dernière release, parce qu’elle rencontre aussi ce problème, pas juste la branche master” »
J’ai dit que c’était « un peu dommage » mais que c’était pas grave. Et t’en conclues « tu en fais des tas ».
Non, j’en fais pas des tas, je m’en fous. Qu’il le package comme il veut. Mon souci à la base c’était juste que je voulais que biboumi soit compilable sous debian stable, sans devoir m’interdire d’utiliser des technos que j’aime pendant les 3 prochaines années. C’est tout.
Et je suis pas de mauvaise foi, c’est un fait : y’aura pas de gcc 7 dans debian stable avant la prochaine release. Après par contre j’ai de nouvelles solutions qui s’offrent à moi : dire aux gens d’utiliser les backports, ou ne plus me soucier de debian et continuer à faire ce que je veux quand je veux vu qu’apparemment mon logiciel n’est pas adapté à Debian stable (si j’ai mal compris ce thread, tu peux m’aider).
[^] # Re: Vivement la suivante
Posté par barmic . Évalué à 10.
Une petite trentaine de commentaires… Ça doit être violent quand tu t'intéresse à quelque chose :)
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Vivement la suivante
Posté par louiz’ (site web personnel) . Évalué à -2.
Tu confonds. Je m’en fous du package 4.3 qu’on peut trouver à l’adresse suivante : https://anonscm.debian.org/cgit/pkg-voip/biboumi.git/log/
S’il est utile à des gens, tant mieux.
(Il n’est de toute façon pas compilé avec le support de la base de données, ni de TLS, donc quasiment sans intéret selon moi)
Mais je m’en fous pas de ne pas avoir gcc 7 dans debian pour les 2-3 prochaines années.
[^] # Re: Vivement la suivante
Posté par wismerhill . Évalué à 2.
Ces derniers mois, l'objectif de debian était de corriger les problèmes pour sortir debian 9 justement.
Ça implique que sid était gelé et que les mainteneurs ne mettaient à jour les paquets que pour corriger des problèmes connus.
Donc, forcément un paquet qui n'est pas destiné à être inclus dans la stable en préparation ne va recevoir beaucoup d'attentions.
[^] # Re: Vivement la suivante
Posté par Anthony Jaguenaud . Évalué à 10.
Salut,
depuis le début de la discussion, je me pose la question de pourquoi c++17 ?
En développement, il y a plusieurs façon de voir les choses : avancer tout le temps et si tu as un bug sur une ancienne version répondre prend la nouvelle !
Cette philosophie (courante en LL par manque de temps sur certains projet) ne me convient pas. Parce que oui, certains bug n’existe plus, mais d’autre sont apparus, et il n’y a jamais de version sans bug (même si je ne suis pas sûr que ça existe).
On peut aussi : maintenir des versions stables. Sur lesquelles on reporte les bug fix si nécessaires jusqu’à la sortie d’une nouvelle stable. Ça oblige à faire 2 versions, ce n’est pas la cata non plus.
J’ai vu que tu t’agaces ensuite, demande toi si tes utilisateurs tu veux les garder ou non. En fonction de ça, tu t’adapte. Soit tu fais du support debian, et donc, tu utilises des techno en accord (c++14) soit tu ne supportes pas, tes utilisateurs n’ont cas aller débuguer arch/Linux ;-)
On ne fait pas de LL pour nuire à sa santé, donc pose toi honnêtement la question de ce que tu veux faire. Fais tu le logiciel avant tout pour toi ou pour tes utilisateurs ? Peux-tu te contraindre au c++14 ou serait-se trop complexe ?
Avec ces réponses, tu trouveras ce qu’il faut faire.
[^] # Re: Vivement la suivante
Posté par louiz’ (site web personnel) . Évalué à 2.
Ça ne fonctionne que si on release moins vite que les versions stables de debian (si par exemple je sors 3 versions en 1 an, ben la version 1, packagée dans debian, ne sera plus prise en charge par mes backports, quand je vais sortir la 3).
Oui, débuguer archlinux, ou trouver des workaround pour les bugs connus (mais non-corrigés) dans debian. Chacun choisit les bugs qu’il veut rencontrer, et perso j’aurais préféré que les deux types de personnes puissent quand meme utiliser mes logiciels. Mais bon tant pis.
Parce que c’est amusant, et ça m’évite de recoder std::optional<>
[^] # Re: Vivement la suivante
Posté par Anthony Jaguenaud . Évalué à 3.
Non, regarde les versions du kernel ou de firefox, on ne maintient pas la version n-1 et n, firefox maintient une version pendant 18mois, soit 5-6 versions standard.
De plus tu as répondu au dessus qu’il y a un mainteneur qui suit ton travail et backport les bugfix sur la version debian. Ça a toujours été comme ça, si tes utilisateurs ont un bug sur debian tu les renvoies sur le bug tracker debian. Si le mainteneur pense que le bug vient de chez toi et non des adaptations qu’ils a réalisées, il te fera un bug report.
Donc avec « c’est amusant » j’en déduis que tu codes pour toi, alors fait fi de tes utilisateurs. Sinon, ne peux-tu pas utiliser boost::optional ? et attendre patienment que le standard c++17 soit finalisé voir même réellement utilisable en production ?
[^] # Re: Vivement la suivante
Posté par louiz’ (site web personnel) . Évalué à 4.
Ah oui, tu parles de maintenir seulement une version LTS, et la toute dernière release, mais pas entre. Ok.
Principalement pour moi, oui. Mais comme y’a des utilisateurs debian que ça intéresse, j’aurais bien aimé pouvoir leur dire « oui, et mon logiciel qui m’amuse, il peut aussi vous servir ». Maintenant je dois choisir entre les deux : m’amuser à 100%, ou pouvoir fournir quelque chose aux utilisateurs de debian (parce qu’avoir des utilisateurs aussi ça me fait plaisir). C’est ça qui me rend triste.
Oui, mais ça sera le cas bien avant la sortie de la prochaine debian.
[^] # Re: Vivement la suivante
Posté par Antoine . Évalué à 6.
J'ai l'impression que tu n'interagis pas beaucoup avec des utilisateurs, car souvent ce sont les utilisateurs eux-mêmes qui ont un problème de cible. Pour ma part, il n'est pas rare de voir des utilisateurs de Debian stable (voire une version encore plus ancienne, ou bien une vieille CentOS) vouloir utiliser la dernière version de certains logiciels et se plaindre que ça bugue (dernier exemple en date : un utilisateur de Debian avec Python 2.7.3—ça doit être Debian 7—manque de bol, un bug corrigé dans Python 2.7.4 empêche le logiciel de tourner).
C'est particulièrement courant, bien sûr, en entreprise, où c'est un département séparé qui choisit les versions des systèmes installés…
[^] # Re: Vivement la suivante
Posté par sebas . Évalué à 2.
Tu n'as jamais entendu parler de debian testing ?
[^] # Re: Vivement la suivante
Posté par louiz’ (site web personnel) . Évalué à 5.
Oui, (et c’est pas mieux en testing actuellement, ni meme en unstable, https://packages.debian.org/sid/gcc).
Mais le problème c’est pas ce que moi j’utilise, c’est ce que les gens utilisent. Et je veux (si possible) que mes logiciels puissent fonctionner sur ce que les gens utilisent, et malheureusement debian stable en fait partie. Je pourrais dire « oui, ben faut utiliser debian unstable pour pouvoir utiliser mon logiciel », mais j’aime pas trop l’idée (meme si parfois j’hésite), et je suis sur que je recevrais plein de bug report de gens mécontents.
[^] # Re: Vivement la suivante
Posté par patrick_g (site web personnel) . Évalué à 5.
Pourquoi ne pas faire une version AppImage de ton logiciel ?
[^] # Re: Vivement la suivante
Posté par louiz’ (site web personnel) . Évalué à 1.
Voir ma réponse https://linuxfr.org/news/debian-9-stretch-deploie-ses-tentacules#comment-1705206
[^] # Re: Vivement la suivante
Posté par Psychofox (Mastodon) . Évalué à 2.
De toute façon tu fais du logiciel libre non ? Si tu fournis les sources tout le monde peut compiler et installer ton appli.
[^] # Re: Vivement la suivante
Posté par louiz’ (site web personnel) . Évalué à 3.
Oui mais pour compiler sous debian, faudra installer gcc 7 depuis les backports et autres emmerdes.
Alors oui, techniquement on peut tout faire, suffit juste d’y passer du temps. On peut même recoder tous les trucs qui nécessitent du C++11 pour que ça compile sous debian wheezie ou j’sais plus quel vieux machin. Le souci c’est le travail que ça demande.
[^] # Re: Vivement la suivante
Posté par Anonyme . Évalué à -1.
C’est quand la dernière fois que tu as utilisé Debian ?
[^] # Re: Vivement la suivante
Posté par louiz’ (site web personnel) . Évalué à 2.
Je suis dessus au boulot, par contrainte.
Et c’est quoi la solution pour installer gcc 7, autre que les backports ?
Ou alors tu fais référence à mon « et autres emmerdes », parce que tu considères que c’est simple ?
[^] # Re: Vivement la suivante
Posté par Psychofox (Mastodon) . Évalué à 2.
Honnêtement, qu'est-ce qui est compliqué à utiliser un package des backports ?
[^] # Re: Vivement la suivante
Posté par louiz’ (site web personnel) . Évalué à -2.
Moi je n’aime pas. Mais si les gens qui utilisent debian n’ont pas de souci avec l’installation de GCC depuis les backports (et d’après ce topic, ils n’en ont pas), alors c’est peut-etre la solution que je vais retenir, oui.
[^] # Re: Vivement la suivante
Posté par Anonyme . Évalué à 2.
Quel argumentaire…
[^] # Re: Vivement la suivante
Posté par louiz’ (site web personnel) . Évalué à -2.
J’ai pas vraiment besoin d’argumenter, je cherche pas à convaincre. Et c’est une question de gout. Lors de mes utilisations précédentes, le fait de devoir configurer les backports et d’installer des paquets depuis ces dépots m’a parru plus agaçant que de les avoir directement.
Si d’autres gens aiment, tant mieux, je vais pouvoir me servir de « t’as qu’à utiliser les backports » sans souci.
[^] # Re: Vivement la suivante
Posté par lolop (site web personnel) . Évalué à 2.
Sur n'importe quel Linux, sans avoir besoin des droits d'admin:
(et après tu recompiles tout ce dont dépend ton application :-)
Votez les 30 juin et 7 juillet, en connaissance de cause. http://www.pointal.net/VotesDeputesRN
[^] # Re: Vivement la suivante
Posté par Antoine . Évalué à 2.
Heu, ouais… sauf que gcc est dépendant de la version disponible de la glibc (et de la libstdc++ pour g++) : je ne suis pas sûr que ça marche aussi facilement que ça, sauf si on parle de versions très proches.
En C++, mon expérience est qu'il vaut largement mieux utiliser les backports fournis par la distribution, que ce soit sous Debian, CentOS ou RHEL, sous peine de s'arracher les cheveux.
[^] # Re: Vivement la suivante
Posté par Psychofox (Mastodon) . Évalué à 2. Dernière modification le 27 juin 2017 à 09:17.
Tu peux préciser ce que tu entends par "dépendant" ?
[^] # Re: Vivement la suivante
Posté par Zenitram (site web personnel) . Évalué à 5.
error: dependency not found.
[^] # Re: Vivement la suivante
Posté par Psychofox (Mastodon) . Évalué à 1.
tu regardes la doc et tu t'aperçois qu'il faut juste mettre les sources de mpfr, mpc, gmp et isl dans des répertoires du même nom avant de compiler.
Mais c'est pas comme si c'était pas marqué en toutes lettres dans le prerequisites.html du tarball de gcc.
[^] # Re: Vivement la suivante
Posté par Psychofox (Mastodon) . Évalué à 3.
Les gens qui utilisent debian stable sont conscients de ça, donc je serais tenté de dire que ce n'est pas vraiment ton problème.
On ne peut pas dire qu'utiliser les backports soient une grosse emmerde c'est relativement simple d'autant plus si la seule contrainte est la version de gcc.
[^] # Re: Vivement la suivante
Posté par Vincent Bernat (site web personnel) . Évalué à 7.
Debian unstable a toujours été à jour pour gcc. Ce n'est juste pas forcément la dernière version qui est installée par défaut. https://tracker.debian.org/pkg/gcc-7.
Si les "gens" utilisent Debian stable, c'est qu'ils accordent de l'importance à ce côté "stable". Sinon, ils seraient sous unstable ou Arch. Debian ne force pas les "gens" à utiliser stable.
[^] # Re: Vivement la suivante
Posté par LaBienPensanceMaTuer . Évalué à 6.
Il est écrit dans la dépêche que cette nouvelle mouture intégrait Flatpack…
Cela n'est il pas sensé répondre à ta problématique ?
[^] # Re: Vivement la suivante
Posté par louiz’ (site web personnel) . Évalué à 6.
« Flatpak is the next-generation technology for building and installing desktop applications. »
Je fais pas de « Desktop applications ». Je développe un serveur XMPP (un component, en fait : https://biboumi.louiz.org). Je suis pas sûr que ce soit le meilleur outil pour packager ce genre de logiciel. Idem pour AppImage.
[^] # Re: Vivement la suivante
Posté par dj_ (site web personnel) . Évalué à 1.
Faut utiliser Snap alors
[^] # Re: Vivement la suivante
Posté par trancheX . Évalué à 1.
Pour c++17 n'est il pas possible de linker statiquement toute les lib utilisées notamment la libc++ (avec un petit -static-libstdc++) ? Ok ça a l'inconvénient de ne plus avoir les maj de sécurité de la libstdc++ et toutes celles utilisé … peut être pas idéal.
Et effectivement flatpak n'a pas été pensé pour les serveurs, dommage.
Il reste snap ou docker et peut être appimage mais faut demander à l'utilisateur de l'installer.
Donc effectivement pas de solution parfaite, snap/docker est peut être la moins pire mais pas directement clé en main pour les utilisateurs (je sais pas trop j'ai jamais vraiment utilisé).
Sinon faut tout recoder en Go qui n'as pas de dépendance ni même à la libc (je plaisante hein). Sérieusement, je compati : c'est vrai que le vieux GCC de debian c'est vraiment pas pratique. Mais il arrive et je crois avoir lu que debian allait faire des efforts sur ce point (mais je retrouve pas où).
[^] # Re: Vivement la suivante
Posté par louiz’ (site web personnel) . Évalué à 5.
Je ne fournis pas de paquet binaires (à part un .deb et .rpm qui sont juste l’output de mes tests d’integration, pour vérifier que ça build correctement et que j’ai pas merdé mes “Makefiles”. Ce n’est pas censé etre utilisé par l’utilisateur final non-dev).
Alors oui, j’ai bien une image docker qui utilise alpine https://hub.docker.com/r/louiz/biboumi/ mais dans l’idée c’était plus pour faire plaisir aux fans de dockers, qui aiment bien utiliser ça et qui trouvent que c’est pratique. Idéalement je voudrais pas avoir à répondre « t’as qu’à utiliser docker » quand on me demande comment installer biboumi sous debian.
[^] # Re: Vivement la suivante
Posté par Adrien Dorsaz (site web personnel, Mastodon) . Évalué à 10. Dernière modification le 20 juin 2017 à 07:12.
Pour la version longue de "ben, ne l'utilise pas", je voudrais faire remarquer quelques dates:
Donc, la communauté Debian a décidé d'arrêter les intégrations de nouveaux développements / fonctionnalités en janvier. La communauté a dès lors demandé à tous ses membres et utilisateurs de tester les versions packagées dans le freeze des logiciels qu'ils utilisent afin de remonter tous les bugs possible. Après 6 mois de tests, la communauté Debian a enfin décidé que les paquets disponible durant le gel ont suffisamment été testé pour sortir une version officielle en juin 2017.
Durant cette période de gel, il aurait été impossible d'intégrer Python 3.6.0, puisque Python est un langage fournissant énormément de paquets dépendants et car il venait juste de sortir officiellement de la communauté Python.
Pour c++17, comment dire… Le dernier brouillon n'était même pas à disposition….
Pour en remettre une couche, non ce n'est pas "cette distro" qui te bloque, mais "cette communauté de membres et d'utilisateurs qui ont pris la peine pendant 2 ans d'empaqueter des centaines de logiciels et de les tester pendant 6 mois avant de décider qu'une nouvelle version de leur distribution pouvait être distribué".
Maintenant, il n'y a pas de honte d'avertir tes utilisateurs que tu ne leur fournis aucun support et que s'ils souhaitent utiliser ton logiciel, il faut avoir une installation identique à la tienne. Ça ne change rien au fait que ton application sera toujours open-source/libre et appréciée, mais ça a le mérite de mettre directement les choses au claire avec tes utilisateurs: il n'y a pas de support et le logiciel utilise des technologies très récente (moins de 3 mois d'existence quand même).
Il n'y a pas de honte non plus à poser des questions du style "Savez-vous pourquoi la communauté Debian n'intègre pas le support de c++ 17 ?" au lieu de rager et de critiquer directement le travail effectué par des centaines de membres et utilisateurs…
[^] # Re: Vivement la suivante
Posté par xcomcmdr . Évalué à -1.
Ce que j'en retire :
Utilisez Arch.
Arch c'est le bien. :p
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: Vivement la suivante
Posté par xcomcmdr . Évalué à -5.
Le sens de l'humour se perd sur DLFP. Triste.
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: Vivement la suivante
Posté par LaBienPensanceMaTuer . Évalué à -3.
Ce n'est pas parce qu'une réponse est à côté de la plaque et peu pertinente qu'il s'agit d'humour…
C'est bien parce qu'une réponse est à côté de la plaque et peu pertinente qu'elle se prend, à la fin, une note négative …
Bisous, coeur avec les doigts !
[^] # Re: Vivement la suivante
Posté par louiz’ (site web personnel) . Évalué à 1.
Le problème c’est pas que je peux pas utiliser python 3.6 ou gcc 7 dès aujourd’hui. Le problème c’est que, comme c’est debian stable, et que c’est figé jusqu’à la prochaine version, je ne pourrai pas utiliser ces versions de logiciels avant 2-3 ans.
Le problème c’est pas que, en juin 2017, y’ait pas python 3.6 dans les dépots. Mon problème c’est qu’ils n’y seront pas avant très très très longtemps. Parce que oui, meme dans fedora (distro que j’utilise) y’a pas gcc 7, et c’est pas dramatique, parce que je sais que bientot ça sera corrigé.
Non mais je connais ces raisons. Ça ne m’empèche pas de « rager et de critiquer », parce que je les aime pas.
[^] # Re: Vivement la suivante
Posté par LaBienPensanceMaTuer . Évalué à 4.
Tu connais visiblement pas les backports ….
En passant, ce n'est plus un truc de bidouilleurs, c'est supporté nativement par Debian: https://backports.debian.org/
Donc il est tout à fait possible que d'ici 5/6 mois tu ais également accès à gcc 7 ou python 3.6 via les backports… mais bon, à lire ce fil, j'ai l'impression que ton unique objectif est de râler sans aucun volonté constructive…
Je trouve d'ailleurs ta logique, vu le soft que tu développes, particulièrement foireuse….
Es tu au courant que les gens qui font du hosting sérieux vont généralement préférer déployer du Debian stable pour des raisons évidentes: avoir un système stable, robuste, qui ne changera pas d'un point de vue fonctionnel entre deux mises à jour, qui ne te cassera pas tes fichiers de configuration entre deux mises à jour, etc…
Pour un mec qui développe un serveur, je te trouve un peu déconnecté de la réalité du monde de l'hébergement et de la fourniture de service …
Si pour toi, il est plus important d'avoir accès à un langage dont le draft n'a pas encore été publié plutôt qu'avoir un système qui te donne toutes les chances d'avoir un taux de disponibilité excellent, peu d'interruption de service, un suivi de sécurité sans modification du fonctionnel, alors je pense que tu devrais plutôt te mettre à coder des applis desktop ….
[^] # Re: Vivement la suivante
Posté par louiz’ (site web personnel) . Évalué à 1.
Et je n’ai pas de problème avec les gens qui font du hosting sérieux et qui veulent continuer à utiliser la version 4.0 du serveur. J’oblige personne à upgrade. Mais je sais que y’a des gens qui sont intéressés par les nouvelles fonctionnalités.
C’est faux. J’ai toujours considéré qu’utiliser les backports était chiant. Mais si j’apprends qu’en fait 99% des utilisateurs de debian stable n’ont pas de souci avec le fait d’installer gcc depuis les backports, parce qu’en fait les backports c’est pas chiant (et que y’a donc que moi qui suis nul), alors ça peut etre la solution que je vais retenir : rajouter « pour installer sous debian, utilisez GCC 7 depuis les backports » dans les instructions d’installation. C’est peut-etre un meilleur compromis que de leur dire « non c’est pas supporté, @+ ».
[^] # Re: Vivement la suivante
Posté par LaBienPensanceMaTuer . Évalué à 2.
Maintenant, c'est juste rajouter 1 ligne dans le /etc/apt/sources.list puis installer ton paquet à coup de:
apt-get install -t stretch-backports gcc
(voir : https://backports.debian.org/Instructions/ )
Et terminé. Donc oui, c'est plus aussi chiant que ça a pu l'être à une époque et je pense que, de ce coup, c'est tout à fait envisageable de dire à tes utilisateurs d'utiliser les backports pour compiler ton soft.
Après, peut être aurais tu tout intérêt à faire un travail de packaging (quand le gcc kivabien et le python kivabien sortiront) toi même car beaucoup d'admin ne sont pas toujours motivé pour:
Si tu veux aider l'adoption de ton soft, je pense que tu as tout intérêt à le packager pour qu'il soit simple à déployer.
[^] # Re: Vivement la suivante
Posté par louiz’ (site web personnel) . Évalué à 1.
Merci pour l’info, je vais réfléchir à ça.
[^] # Re: Vivement la suivante
Posté par barmic . Évalué à 2.
Joli troll ;)
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Vivement la suivante
Posté par barmic . Évalué à 3.
Pour celui qui n'a pas compris : quelqu'un qui vient poser un problème aussi vieux sans apporter d'arguments nouveau et qui alimente le débat stérile c'est la définition d'un troll. D'autres exemples possibles :
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Vivement la suivante
Posté par Antoine . Évalué à -1.
Si pour toi un débat est « stérile », tu as le droit de ne pas participer et d'aller voir ailleurs. Je ne crois pas que tu aies été mandaté pour faire la police des commentaires, et désigner ce qui est un troll ou ne l'est pas…
[^] # Re: Vivement la suivante
Posté par barmic . Évalué à 0.
J'ai dis que c'est du troll, pas qu'il ne faudrait pas le faire.
J'ai même à mon actif plusieurs troll de ce genre et tu dois pouvoir trouver un de mes journaux qui parle d'une des raisons qui peuvent le rendre intéressant.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
# Pour les très grands débutants, DFLinux-Stretch est en ligne !
Posté par idéefixe . Évalué à 8.
Pour les très grands débutants, DFLinux-Stretch est en ligne !
# GNOME 3.14 et 3.22 dans RHEL aussi
Posté par Sébastien Wilmet . Évalué à 9.
Red Hat Enterprise Linux (RHEL) 7.2 et 7.3 sont sur GNOME 3.14, et pour RHEL 7.4 ce sera GNOME 3.22. Ça tombe bien que Debian ait les mêmes versions, il y a des chances que ce soit plus stable (étant donné que Red Hat fait plus ou moins les 3/4 du boulot dans GNOME).
Aussi, GTK+ 3.22 est et sera la dernière version de GTK+ 3, c'est donc une version LTS.
Bon il faut que les mises à jour arrivent dans Debian, pour la version stable j'ai déjà vu pas mal de paquets GNOME qui n'étaient pas à jour (genre un certain module GNOME en était à la 3.14.4 et Debian stable était toujours à la 3.14.0).
[^] # Re: GNOME 3.14 et 3.22 dans RHEL aussi
Posté par Okki (site web personnel, Mastodon) . Évalué à 7.
J'ai l'impression que leur vision de la stabilité diffère de celle des utilisateurs. Je peux me tromper, mais je vois plus une recherche de la stabilité dans le sens où une application qui ne proviendrait pas forcément de leurs dépôts (du style, une application propriétaire) aurait la garantie de pouvoir fonctionner à l'identique du début à la fin, sans surprise.
À l'inverse d'utilisateurs qui aimeraient bien voir corriger des bugs (qu'on trouvera toujours, y compris chez Debian) pour obtenir un système toujours plus stable. La logique voudrait que si un développeur sort 36 versions correctives de son application ou de sa bibliothèque, sans ajouter de nouvelles fonctionnalités, elles soient toujours intégrées dans Debian. Mais ça ne semble pas être le cas, puisque j'imagine qu'ils ont trop peur qu'un correctif puisse avoir des effets de bords inattendus, qui iraient à l'encontre de leur vision de la stabilité.
Donc pour moi, non, une Debian stable n'est pas stable. Y compris sur un serveur, puisque sur le miens, j'ai déjà rencontré un certain nombre de problèmes (allant jusqu'aux plantages) avec lftp, screen, rtorrent… Problèmes qui avaient été corrigés dans les versions plus récentes fournies par Ubuntu Server.
Dans certains domaines qui peuvent partager cette vision de la stabilité, Debian est sans doute effectivement le meilleur choix possible. Mais je ne pense pas qu'il faille dire aux particuliers qu'avec une Debian ils auront un système bien plus stable et plus fiable qu'avec d'autres distributions.
[^] # Re: GNOME 3.14 et 3.22 dans RHEL aussi
Posté par claudex . Évalué à 8.
Pour moi, c'est plus un système qui fonctionne pendant la durée de vie de la version sans nécessiter de changement de configuration. Contrairement, par exemple, à une rolling release qui nécessite de modifier la configuration des logiciels quand ceux-ci le demande. Tu configure tes logiciels et ils fonctionnent pour deux ans sans plus y toucher.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: GNOME 3.14 et 3.22 dans RHEL aussi
Posté par louiz’ (site web personnel) . Évalué à -7.
Oui, stable c’est dans le sens « ça change pas », pas dans le sens « ça fonctionne correctement ».
Ils préfèrent avoir des trucs avec des bugs connus, plutôt que d’avoir un truc avec ces bugs connus corrigés mais avec peut-être de nouveaux bugs inconnus.
[^] # Re: GNOME 3.14 et 3.22 dans RHEL aussi
Posté par Cyril Brulebois (site web personnel) . Évalué à 10.
Vu le nombre de corrections qui passent par
stable-proposed-updates(en plus des correctifs de sécurité qui passent par un canal dédié), je pense qu'il y a un certain a priori, ou une certaine méconnaissance du fonctionnement de la distribution, ou bien un peu de mauvaise foi.Debian Consultant @ DEBAMAX
[^] # Re: GNOME 3.14 et 3.22 dans RHEL aussi
Posté par microlinux (site web personnel) . Évalué à 6.
"Ils préfèrent avoir des trucs avec des bugs connus, plutôt que d’avoir un truc avec ces bugs connus corrigés mais avec peut-être de nouveaux bugs inconnus."
Il existe une troisième solution à cela, c'est d'avoir un truc où les bugs connus sont corrigés sans toutefois introduire de nouvelles fonctionnalités avec de nouveaux bugs inconnus. C'est la mise à jour à faible risque, et c'est ce que pratiquent les distributions de qualité entreprise comme RHEL/CentOS, SLES, Ubuntu LTS, etc.
J'explique ça en détail dans le chapitre 1 de mon bouquin sur Linux. L'extrait est en ligne ici.
http://www.editions-eyrolles.com/Livre/9782212137934/debuter-avec-linux
Un gentil bonjour de la garrigue gardoise.
Dyslexics have more fnu.
[^] # Re: GNOME 3.14 et 3.22 dans RHEL aussi
Posté par Anonyme . Évalué à -2.
Un troll dans le troll. Bien joué.
[^] # Re: GNOME 3.14 et 3.22 dans RHEL aussi
Posté par microlinux (site web personnel) . Évalué à 4.
Par "qualité entreprise", on entend le support longue durée pour un cycle d'au moins cinq ans, les avis sur la durée pouvant varier. RHEL/CentOS c'est dix ans par version, Ubuntu LTS c'est cinq ans. Voir à ce sujet l'excellent chapitre "What is Enterprise Linux?" dans "The Definitive Guide to CentOS", publié chez Apress. "Enterprise Linux" est un concept, pas un jugement de valeur sur telle ou telle distribution.
Dyslexics have more fnu.
[^] # Re: GNOME 3.14 et 3.22 dans RHEL aussi
Posté par claudex . Évalué à 2.
Et Debian LTS, ça sent le pâté ? https://wiki.debian.org/fr/LTS
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: GNOME 3.14 et 3.22 dans RHEL aussi
Posté par microlinux (site web personnel) . Évalué à 6.
Je lis régulièrement les dépêches de Raphael Hertzog sur Debian LTS. Apparemment le projet manque de finances pour décoller sérieusement.
Dyslexics have more fnu.
# De mieux en mieux
Posté par Narann (site web personnel) . Évalué à 7.
J'utilise Debian depuis 7 et j'ai l'impression que les dist-upgrade se passe de mieux en mieux. Avant il y avait toujours un pet de travers. La, la 9: Aucun soucis. Je me demande si le fait que Debian testing soit utilise par Ubuntu et Mint n'aide pas a avoir une meilleur stabilité de la branche stable.
[^] # Re: De mieux en mieux
Posté par Anonyme . Évalué à 4.
j'ai trois ordi qui ont commencé avec Debian Squeeze (6 ?) et jamais eu un seul problème de dist-upgrade que ce soit avec apt ou aptitude.
Après, j'essaie toujours d'attendre quelques semaines que les bugs soient résolus.
J'ai toujours pensé que Canonical utilisait sid comme base de travail, ce qui expliquait une partie de l'aversion pour Ubuntu.
# systeme de fichier
Posté par tuxicoman (site web personnel) . Évalué à 6.
Et sinon, pour une installation sur SSD (ordinateur personnel) ,c'est toujours ext4 qu'il faut privilegier?
[^] # Re: systeme de fichier
Posté par antistress (site web personnel) . Évalué à 5.
questions performances, oui si l'on en croit les mesures de phoronix
par contre tu peux tweaker ext4 : http://libre-ouvert.toile-libre.org/?article72/ssd-crucial-m4-64-go-linux-trim-ext4-noatime
[^] # Re: systeme de fichier
Posté par Anonyme . Évalué à 3.
Sympa ton article, je n'étais pas tombé dessus à l'époque mais je le garde désormais en favoris. En plus tu le mets à jour, c'est sympa :)
Il fonctionne toujours aussi bien ton Crucial M4 ? J'ai le modèle 64Go depuis cinq ans et pas de soucis. Pas pressé d'en changer quand je vois que les modèles à mémoire MLC ont quasiment tous disparu du marché.
[^] # Re: systeme de fichier
Posté par antistress (site web personnel) . Évalué à 4.
oui, toujours aussi bien :)
# Fusion des usr (usrmerge) pour plus tard.
Posté par vialibre . Évalué à 4.
Il semble que la fusion des arborescences /usr a été repoussée à la prochaine version depuis la RC1 de l’installeur.
[^] # Re: Fusion des usr (usrmerge) pour plus tard.
Posté par Cyril Brulebois (site web personnel) . Évalué à 1.
Yes, spot on! Désolé, ça m'a échappé quand j'ai survolé la dépêche initialement.
Debian Consultant @ DEBAMAX
[^] # Re: Fusion des usr (usrmerge) pour plus tard.
Posté par Benoît Sibaud (site web personnel) . Évalué à 3.
Corrigé, merci.
# Une image stretch ?
Posté par Denis Dordoigne . Évalué à 3.
Quelqu'un a-t-il déjà tenté de construire une image de machine virtuelle pour debian stretch ? Je vais essayer de tenter le coup avec VMBuilder, mais si quelqu'un a déjà une méthode qui fonctionne je suis preneur !
Membre de l'april, et vous ? https://april.org/adherer -- Infini, l'internet libre et non commercial : https://infini.fr
[^] # Re: Une image stretch ?
Posté par Cyril Brulebois (site web personnel) . Évalué à 3.
J'ai aperçu des gens mentionner vagrant sur le canal IRC
#debian-cdmais je ne suis pas familier de la problématique des images cloud. Cela dit, il existe une liste debian-cloud@ où les derniers messages parlent justement de cela. Un début de réponse, peut-être ?Debian Consultant @ DEBAMAX
[^] # Re: Une image stretch ?
Posté par oau . Évalué à 3. Dernière modification le 19 juin 2017 à 17:51.
Perso j'installe à la main avec virt-manager ca me donne une image de base. J'installe ensuite mes petites affaire. Ma conf vim, exim, syslog, xymon etc. Ensuite je snapshot cette image de base pour créer de nouvelles vm. Au boot j'ai un rm -rf /var/log et une mise à jour du hostname et l'ajout dans xymon et c'est parti. J'ai commencé à tester avec stretch il y a quelques jours. Mise à part les interfaces réseau qui change de nom. Tout va bien.
[^] # Re: Une image stretch ?
Posté par Anonyme . Évalué à 5.
Et à la fin de le journée, tu te rends compte que t’as réinventé Puppet et vagrant…
[^] # Re: Une image stretch ?
Posté par Re_ . Évalué à 2.
J'utilise packer, qui va utiliser un fichier de preseed pour l'install + qq tâches ansible pour provisionner et basta !
Utilisé régulièrement sous Debian Jessie, j'ai testé dernièrement avec une Stretch, pas de problèmes rencontrés.
# GnuPG 1.4 → 2.1
Posté par gouttegd . Évalué à 10.
Le passage de la version par défaut de GnuPG de 1.4 à 2.1 est très important, et pourrait surprendre les utilisateurs de Debian Stable sur desktop (il y en a ?), alors quelques petites remarques sur ce qui change, pêle-mêle.
a) Là où GnuPG 1.x était monolithique (le binaire gpg faisait tout), GnuPG 2.1 a une architecture modulaire (déjà amorcée avec GnuPG 2.0, mais c’est vraiment la branche 2.1 qui a achevé cette transition), comprenant au minimum les composants suivants :
(On peut éventuellement y ajouter scdaemon, le démon d’accès aux cartes à puce, si vous utilisez ce genre d’outils.)
L’utilisation des démons auxiliaires est obligatoire (l’utilisation de gpg-agent était facultative avec GnuPG 1.x, ce n’est plus le cas avec GnuPG 2.x). Pas la peine de jouer avec l’option
--no-use-agent, elle est silencieusement ignorée.b) Les clefs privées sont désormais stockées dans le dossier
$GNUPGHOME/private-keys-v1.d. Le fichier$GNUPGHOME/secring.gpgn’est plus utilisé. À la première utilisation de GnuPG 2.1, les clefs privées présentes danssecring.gpgseront silencieusement migrées versprivate-keys-v1.d.c) Tous les démons auxiliaires (gpg-agent, dirmngr, scdaemon) sont démarrés automatiquement quand ils sont nécessaires. Cela peut éventuellement surprendre ceux qui utilisaient précédemment GnuPG 2.0 (que Debian fournissait dans le paquet gnupg2), où un script
/etc/X11/Xsession.d/90gpg-agentse chargeait de démarrer l’agent au démarrage d’une session.Similairement, la variable d’environnement
GPG_AGENT_INFO, précédemment utilisée pour localiser la socket de l’agent, n’a plus lieu d’être.La socket en question, d’ailleurs, n’est plus placé dans $GNUPGHOME, mais dans
/var/run/user/$(id -u)/gnupg, dossier qui est géré par Systemd. Vous n’avez normalement pas besoin de le savoir, mais ça peut occasionner des surprises voire des désagréments si vous aviez l’habitude de faire des choses un peu « exotiques » avec l’agent GnuPG (aeris devrait pouvoir vous en dire quelques mots — je crois qu’il s’est arraché quelques cheveux sur cette question).d) Les clefs OpenPGP au format v3 (qui datent de l’époque de PGP 2.6, au milieu des années 1990) ne sont plus du tout prises en charge. Si vous avez encore des données qui traînent chiffrées avec une clef v3, vous aurez besoin de GnuPG 1.x (que Debian fournit désormais sous le nom gnupg1) — auquel cas je vous invite instamment à déchiffrer ces données et à les re-chiffrer avec une clef plus récente.
e) GnuPG 2.1 a introduit un nouveau format de stockage des clefs publiques, le format keybox (fichier
$GNUPGHOME/pubring.kbx), plus efficace que l’ancien keyring (fichier$GNUPGHOME/pubring.gpg). Néanmoins, si vous avez déjà utilisé GnuPG ≤ 2.0 et que vous avez donc déjà un fichierpubring.gpg, GnuPG 2.1 continuera à utiliser le fichier existant. Pour migrer vers le nouveau format (ce qui n’est pas obligatoire, remarquez), l’approche recommandée est la suivante :f) La procédure de génération de clefs a été simplifiée : GnuPG génère par défaut des clefs « standard » sans plus demander à l’utilisateur de choisir lui-même l’algorithme, la taille, la date d’expiration (la seule chose demandée est l’identité à associer à la clef). Utilisez la commande
--full-gen-keyau lieu de--gen-keypour retrouver l’ancienne procédure où vous pouvez spécifier vous-même les caractéristiques de la clef.g) GnuPG 2.1 prend en charge la cryptographie elliptique, mais par défaut la création de clefs ECC n’est pas accessible, même en utilisant la commande
--full-gen-key. Il faut ajouter l’option--expertpour se voir offrir la possibilité de créer une clef ECC.[^] # Re: GnuPG 1.4 → 2.1
Posté par Anonyme . Évalué à 4.
Merci pour tes précisions. C’est quelque chose qui aurait pu être mis (en condensé) dans la dépêche.
Ce qui est cool c’est que peut-être que les serveurs de clefs vont se mettre à les gérer correctement maintenant :)
[^] # Re: GnuPG 1.4 → 2.1
Posté par jjl (site web personnel) . Évalué à 8.
Oui, oui, moi par exemple o/
Au boulot, je suis pas payé pour jouer avec mon bureau si il casse dans testing.
À la maison, pareil pour les PCs que je gère (femme et enfants)
Mes PCs perso (fixe et portable) sont sous testing par contre.
/mavie, vous pouvez passer à la suite :)
[^] # Re: GnuPG 1.4 → 2.1
Posté par Anonyme . Évalué à 5.
Un peu la même chose. Mon PC de travail est sous Debian stable parce que besoin d'une machine qui soit disponible, je n'ai pas toujours le temps de mettre les mains dans le moteur et qui plus est je ne suis pas informaticien de formation. Avec quelques rétroportages (et maintenant Flatpack) pour mes outils, ça roule bien et tous les trois ans j'ai de grosses améliorations.
Il faut aussi penser que DFlinux est basé sur stable et qu'il y a beaucoup de personnes ou de structures qui utilisent l'ordi pour de la gestion bureautique (compta, mailing, etc.) sans avoir de connaissances informatiques. Le passage d'un informaticien pour les dist-upgrade n'est quasiment plus indispensable, du moment que les protocoles de sauvegardes sont bien intégrés (dans les esprits et dans la machine).
[^] # Re: GnuPG 1.4 → 2.1
Posté par microlinux (site web personnel) . Évalué à 7.
"les utilisateurs de Debian Stable sur desktop (il y en a ?)"
Il y a même plus conservateur que ça. Sur mon portable aussi bien que sur ma station de travail, j'ai CentOS 7 avec KDE 4.14 et LibreOffice 5.0.6. Support officiel jusqu'en juin 2024, rétroportage de corrections de bugs et tout. J'ai une prédilection pour les systèmes "ennuyeux".
Dyslexics have more fnu.
# Vim config par défault
Posté par oau . Évalué à 3.
j'ai l'impression que la conf par défault de vim concernant la souris est en mode visual. C'est très perturbant. C'est que moi ?
[^] # Re: Vim config par défault
Posté par LaBienPensanceMaTuer . Évalué à 2.
Non non, c'est bien la config par défaut qui a changé.
Il faut updater ton ~/.vimrc (mais tu as l'air de gérer, je vais pas te faire l'insulte de te donner la ligne à ajouter :p).
# PHP 7.0 et non 7.1 ?
Posté par EauFroide . Évalué à 4. Dernière modification le 19 juin 2017 à 20:24.
Pourquoi la version de PHP intégrée est 7.0 et non 7.1 ?
Oracle, another crap :D
Donation Bitcoin : 1N8QGrhJGWdZNQNSspm3rSGjtXaXv9Ngat
[^] # Re: PHP 7.0 et non 7.1 ?
Posté par Anonyme . Évalué à 4.
Sûrement parce que 7.1 date de la toute fin 2016 et que le gel a eu lieu en janvier 2017. Cf le commentaire d’Adrien Dorsaz.
# Plus d'une façon d'utiliser Debian...
Posté par maxmasou . Évalué à 4.
Juste pour préciser que les versions de Debian peuvent être utilisé à partir du freeze sans réel problème et du coup on a automatiquement des logiciels plus récents sans réellement sacrifier la stabilité. La version téléchargeable de Firefox et Thunderbird se met à jour automatiquement en plus. Pour Chrome il y a un dépôt. Bref, pour une utilisation Desktop et aussi pour du développement web, je n'ai aucun problème à garder des logiciels vieux d'environ 1 ans (on peut déjà estimer que le "soft freeze" de Buster va être en novembre prochain)!
Et puis ça évite les ennuis de Unstable lorsque tu as oublié de prendre ton café le matin! Genre un changement de Sysvinit à systemd avec des dépendances non résolus que tu fais pareil avec le plus grand des plaisirs! Ensuite quand tu reviens finalement avec un café, ton ordinateur ne démarre plus!
Tant qu'a utiliser Unstable ou Testing en performance, il est préférable d'utiliser Arch qui est réellement une rolling-release…
Vivre Debian!
[^] # Re: Plus d'une façon d'utiliser Debian...
Posté par eingousef . Évalué à 4.
Parce qu'il y a une version "non-téléchargeable" ?
*splash!*
[^] # Re: Plus d'une façon d'utiliser Debian...
Posté par Thomas Douillard . Évalué à 3.
Accessible uniquement par les initiés. Si Vous voyez ce que je veux dire.
[^] # Re: Plus d'une façon d'utiliser Debian...
Posté par xcomcmdr . Évalué à 4.
:p
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: Plus d'une façon d'utiliser Debian...
Posté par eingousef . Évalué à 5.
Pas bête ! Il y avait aussi "la version qui n'existera jamais", "la version auto-générée par une intelligence artificielle (fireplop<)" et "la version qui existera mais qui ne sera jamais publiée pour whatever raison à la con". La partie continue !
*splash!*
[^] # Re: Plus d'une façon d'utiliser Debian...
Posté par Psychofox (Mastodon) . Évalué à 5.
La version de dans 2-3 ans pardi.
[^] # Re: Plus d'une façon d'utiliser Debian...
Posté par Anonyme . Évalué à 3.
Celle de Milan aussi.
[^] # Re: Plus d'une façon d'utiliser Debian...
Posté par maxmasou . Évalué à 2.
Je voulais dire la version que l'on récupère sur mozilla.org! La ESR, la release, la beta ou la developer edition…
Il y a tellement de choix qu'on ne sait plus laquelle choisir! lol
# Utilisation bureau.
Posté par Tanouky . Évalué à 7.
Bonjour,
Je vois beaucoup de monde dire que Debian stable n'est pas fait pour le bureau.
Pourtant, j'utilise KDE Debian (pour l'instant Jessie) sans problème (et c'est bien la première fois que je suis content de mon système d'exploitation…En 2 ans, il n'a jamais eu un problème de démarrage, j'ai toujours pu compter dessus, les bugs étaient toujours les mêmes…:D )…
Pourquoi donc Debian Stable est si "mal vue" pour le bureau ?
[^] # Re: Utilisation bureau.
Posté par gouttegd . Évalué à 4. Dernière modification le 20 juin 2017 à 20:19.
Bah l’idée « Debian stable = pas pour le bureau » est quand même pas mal répandue par les Debianneux eux-mêmes…
Par exemple, Raphaël Hertzog et Roland Mas, dans les Cahiers de l’admin – Debian Wheezy, écrivent :
N’étant pas moi-même utilisateur de Debian (quelque version que ce soit) sur le desktop, c’est ce passage qui m’a fait demander, mi-ironiquement mi-sérieusement, s’il y avait des utilisateurs de Stable sur bureau…
[^] # Re: Utilisation bureau.
Posté par Tanouky . Évalué à 10.
D'accord.
Pour tout t'avouer, en 10 ans, je suis passé par des tas de distributions et c'est bien Debian Stable à laquelle j'ai adhéré.
Comme je le dis, les bugs du début sont les mêmes maintenant et ne me gênent pas (par exemple, l'instabilité de kdenlive à certains moments).
Et pour le reste, je n'ai pas eu un seul démarrage foireux, une seule perte de connexion, un seul truc qui fonctionnait et qui ne fonctionnait plus ensuite (l'inverse est faux, puisque j'ai pu amélioré certaines fonctions).
Mes parents, ma femme, mes oncles et tantes, cousins et des tas d'amis sont sous Debian Stable, aussi : c'est bien simple, je n'ai rien à faire pendant 3 ans pour les aider, hormis en ce qui concerne "l'apprentissage" (ce qui me convient très bien…d'une, je n'aime pas résoudre les problèmes nouveaux apparus je ne sais comment ou à cause de l'utilisateur, de deux, s'ils apprennent, c'est une bonne chose).
Ainsi, la plupart savent se servir d'apt en ligne de commande, et c'est quand même pas rien ! :D
(Pour les mises à jour)
Voilà mon avis d'utilisateur "bureau", qui fait du Blender, libreoffice, du FTP, un peu de réseau, de l'Arduino, du jeu vidéo, de la vidéo tout court…:)
[^] # Re: Utilisation bureau.
Posté par maxmasou . Évalué à 10. Dernière modification le 20 juin 2017 à 20:22.
Parce que selon moi les gens aiment vivre avec l'utopie qu'un logiciel plus récent est nécessairement meilleur. L'exemple de Wayland est frappant! Les gens sont prêt a se séparer de plusieurs logiciels qui marchent bien pour quelque chose qui sera meilleur, mais qui n'est pas encore intégré parfaitement dans les distributions Linux. Une chose que j'ai comprit avec les années, c'est qu'un logiciel libre nouveau ou profondément modifié à toujours besoin de temps pour arriver à maturité et être utilisable et ce temps se compte parfois en années! Dans ce contexte Debian stable est parfaite!
[^] # Re: Utilisation bureau.
Posté par Renault (site web personnel) . Évalué à 8.
Tu portes un jugement de valeur sur la question, ce qui me semble dénué de sens.
Un logiciel nouveau, ou mis à jour, sert à corriger des soucis, ajouter des fonctionnalités, changer d'ergonomie… Peut être que tu t'en moques de la fonctionnalité X, mais pour certains ça vaut le coup.
Mais heureusement qu'il y a des gens comme ça (j'en fais parti), si tu veux avoir Wayland stable avant 2025, il faut des gens pour tester, faire des retours, rapporter des bogues, tester sur l'ensemble des configurations matérielles / logicielles existantes.
Personnellement j'aime quand ça bouge, je m'ennuie quand mon système n'a aucune modification pendant longtemps. Car oui, j'aime tester, j'aime profiter des nouvelles fonctionnalités qui apportent parfois un vrai confort.
Bref, ne juge pas les gens qui n'ont pas la même optique que toi, il faut de tout pour faire un monde, Debian évoluerait bien moins vite si tout le monde se calquait sur son modèle de développement.
[^] # Re: Utilisation bureau.
Posté par maxmasou . Évalué à 2. Dernière modification le 20 juin 2017 à 21:23.
C'est pas pour porter un jugement. J’admets que Wayland corrige plusieurs choses, notamment au niveau de la sécurité. Dans ce cas particulier, le problème ne vient pas tellement du logiciel, mais de tous l'écosystème qui repose dessus.
Je veux pas non plus insulter ceux qui essaie des nouveaux trucs, j'en fait partie moi aussi. J'essaie juste de dire que des personnes veulent avoir des logiciels "bleeding edge" seulement parce que c'est "bleeding edge" …
Je dois t'avouer qu'après 1 ans sur Stable, j'ai hâte à la nouvelle version. Je migre toujours au "soft freeze" et parfois un peu avant.
[^] # Re: Utilisation bureau.
Posté par xcomcmdr . Évalué à 2.
Y'a rien de mal à aimer la nouveauté, les nouvelles fonctionnalités, la sécurité …
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: Utilisation bureau.
Posté par eingousef . Évalué à 10.
Cas de figure 1 :
Entreprise Machin sort le nouveau format VP11 de vidéo pour le web. En 3 mois elle est incluse dans les nouvelles versions des principaux brouteurs et encodeurs. Au bout d'un an les 3/4 des vidéos sur le web sont en VP11. Et encore 1 an après la nouvelle Debian sort, et les utilisateurs de stable sur le desktop peuvent profiter des vidéos du web en VP11. Pas de pot, on est déjà passés à VP12.
Cas de figure 2 :
Des utilisateurs communiquent sur une ML qui rajoute un titre en début de sujet (par exemple:
[Râleurs]) si celui-ci n'existe pas déjà. Kévin envoie un e-mail en mettant pour sujetsainul sa marchent pa xD, toute la ML recevra un e-mail ayant pour sujet[Râleurs] sainul sa marchent pa xDencodé en UTF-8. Un utilisateur avec un client à jour répond, le sujet de la réponse estRe: [Râleurs] sainul sa marchent pa xD. Un utilisateur en Debian stable avec un vieux icedove qui ne gère pas les changements d'encoding dans les sujets répond, le sujet devientRe: [R�leurs] Re: [Râleurs] sainul sa marchent pa xD. Au bout de 5 échanges de réponses ça devient :Re: [R�leurs] Re: [Râleurs] Re: [R�leurs] Re: [Râleurs] Re: [R�leurs] Re: [Râleurs] sainul sa marchent pa xDDans l'affichage des threads d'un client mail c'est juste illisible. Déjà que le mail de Kévin à la base était tout pourri >:(
Cas de figure 3 :
Le nouveau jeu Battle For Bidule sort une nouvelle version stable. Un utilisateur de Debian stable veut jouer avec une bande de copains. Situation :
— On joue à Bidule, version X.Y.
— Ah mais j'ai pas la X.Y, elle est pas dans les dépôts.
— Ben utilise les backports.
— Elle est pas dans les backports
— Ben fais de l'apt-pinning alors
— Ok j'installe le paquet de testing. Ah zut il me demande de mettre à jour 250 paquets dont la libc.
— Ouch attends un peu tu risques de tout péter.
— T'inquiète, ça risque r
*user disconnected*Pour résumer, le problème auxquels sont confrontés les utilisateurs de stable c'est qu'aujourd'hui les standards évoluent plus vite que ne sortent les nouvelles versions de Debian. Pour une utilisation sur serveur, ce n'est généralement pas un problème, parce que quand on fait évoluer les protocoles implémentés sur les serveurs, c'est généralement par petites incrémentations en faisant gaffe à casser le moins souvent la compatibilité avec les versions précédentes. Et ces petites incrémentations sont généralement bien gérées par les mainteneurs des backports Debian. Pour une utilisation sur Desktop, c'est plus problématique, parce que les standards implémentés sur les clients évoluent beaucoup plus vite (en peu de temps tu peux avoir un nouveau codec vidéo pour le web qui se déploie, un nouveau codec audio pour la VoIP, un nouveau champ dans les header des e-mails, une nouvelle version d'un jeu multijoueur), ils évoluent de façon plus massive (pour les jeux d'une version à une autre t'auras des changements de gameplay, ça va forcément casser), et les backports debian ne peuvent pas suffire.
Donc mon conseil: n'utilisez pas stable sur votre desktop, sauf si vous n'allez jamais sur internet / n'interagissez jamais avec personne. Sinon, utilisez plutôt testing ou unstable. Personnellement à part quelques programmes que j'ai pas réussi à compiler parce qu'ils étaient écrits par des jeunots hyperactifs qui ont décidé que le C++11 c'était HaZBine et qu'ils étaient incapables de coder un hello world sans utiliser C++17, j'ai jamais eu de problèmes avec testing.
*splash!*
[^] # Re: Utilisation bureau.
Posté par whity . Évalué à 9.
Utilisez stable quand elle vient de sortir. Unstable juste après la sortie d’une stable, il faut aimer être joueur. Testing, c’est un bon choix à partir du feature freeze. Avant, c’est risqué (certains paquets peuvent être cassés dans testing pendant très longtemps, et les mises à jour de sécurité ne sont pas garanties).
Mes commentaires sont en wtfpl. Une licence sur les commentaires, sérieux ? o_0
[^] # Re: Utilisation bureau.
Posté par maxmasou . Évalué à 4.
Je ne sais pas quel navigateur que tu utilises, mais je n'ai jamais eu de problème de codec avec Firefox et encore moins avec Chrome et ce, depuis environ 4-5 ans. Tu peux facilement avoir les versions à jours de Firefox et Chrome sur Stable et s'il te manque réellement un codec, tu le télécharges à partir du dépôt de Unstable et ça finit là parce que 99% du temps un codec n'a pas de dépendance.
Pour Thunderbird je comprend pas plus ton point. Présentement j'utilise la 54 Beta… et elle se met à jour automatiquement…
Vraiment? La mémoire qui se remplit jusqu’à ce que ton ordinateur soit inutilisable. Plus capable d'aller sur internet parce que NetworkManager change de façon d'utiliser les adresse MAC. Personnellement c'est le genre de problème que j'ai déjà eu avec testing. Vraiment rien d'insurmontable, mais il faut savoir ou chercher quand sa arrive. Disons qu'un novice va se décourager et abandonner, un utilisateur intermédiaire va passer 1 semaines avant de trouver la solution et un utilisateur avancé va trouver le problème dans la même journée…
Les changements dans Testing seront majeurs dans les prochaines semaines. J'ai de la misère a croire que tu vas effectuer un dist-upgrade prochainement!
La je te donne 100% raison, Debian Stable n'est pas fait pour jouer a des jeux décents! Sauf l’excellent Supertuxkart(l'équipe de développement fait vraiment du super boulot)!
[^] # Re: Utilisation bureau.
Posté par eingousef . Évalué à 1.
Jamais eu ce problème, sauf bêtise de ma part.
Jamais eu ce problème. En même temps j'ai viré NetworkManager le jour où il a cessé d'être init-agnostique.
2 conseils : 1) utiliser apt-listbugs, 2) utiliser des logiciels simples et stupides le plus possible (le deuxième conseil ne conviendra pas forcément à ceux qui aiment les environnement de bureau tout intégrés où il n'y a rien à configurer).
Non, je vais attendre : https://linuxfr.org/nodes/111860/comments/1701524
*splash!*
[^] # Re: Utilisation bureau.
Posté par Psychofox (Mastodon) . Évalué à 10. Dernière modification le 22 juin 2017 à 08:43.
Tes exemples ne sont pas du tout convaincants.
L'histoire des codec vidéos, c'est pipotron, je n'ai jamais vu un format vidéo se généraliser aussi vite. C'est en général au contraire un des domaines où l'adoption a souvent pas mal d'inertie notemment à cause des encodeurs/décodeurs hardware qui mettent plus de temps à arriver que les solutions software.
L'histoire des mails est bien gentillette mais il y'a une tétrachiée de clients mails disponibles dans les repos donc là encore, c'est idiot.
Pour les jeux, la debian stable n'est pas la plus pertinente mais ce n'est pas vraiment ce que j'appelle une utilisation desktop. Le gaming sur pc c'est un truc marginal et encore plus sous linux.
[^] # Re: Utilisation bureau.
Posté par seb95 (site web personnel) . Évalué à 9.
Je n'ai jamais eu de soucis de codecs, de formats, de mails, de bugs, ect… sur mes stables.
Je m’ennuie souvent sur stable car j'aime bien les rollings et je suis souvent sous sid mais je dois admettre que stable est bien la seule distribution ou je peux fermer les yeux et être sur d’être tranquille.
Dans la famille je ne met que du debian stable et avant ça c’était du ubuntu lts mais depuis que l'ubuntu m'a foutu des pc HS suite a une suppression de pilote graphique j'ai tout misé sur debian.
De plus la stable n'est pas que prédisposé a être sur du serveur, mais bien sur du desktop comme des ordinateur de travail, ordinateur de personne qui veulent juste que ça marche, des gens comme moi qui n'ont plus le temps de passer des heures et des heures a faire de la maintenance, bref c'est une distribution universel.
[^] # Re: Utilisation bureau.
Posté par gpe . Évalué à 7.
Au boulot moi aussi j'utilise une debian stable/backports. Déjà parce que je n'ai pas toujours le temps de gérer quand quelque chose est cassé dans testing ou sid et aussi parce qu'on utilise des logiciels proprio qui n'évoluent pas au rythme de testing/sid lorsque des changements sur des lib importantes interviennent. Les éditeurs fournissent des paquets deb pour stable uniquement en général.
# Virtualbox ?
Posté par SPlissken . Évalué à 3.
J'ai pas compris cette histoire avec Virtualbox.
Est ce que ça veut dire que Virtualbox n'est plus présent dans les dépôts debian et donc plus installable sur debian ?
[^] # Re: Virtualbox ?
Posté par Zenitram (site web personnel) . Évalué à 1.
J'ai l'impression:
https://packages.debian.org/search?suite=default§ion=all&arch=any&searchon=names&keywords=virtualbox
Gni? pourquoi "donc"? Démontre moi le lien entre "pas dans les dépôts" et "plus installable". Perso je vois "plus installable à partir des repos" certes, mais rien à voir avec "plus installable" général.
J'ai survolé le rapport, le pb semble que Debian ne veut pas généraliser l'exception Firefox à prendre la dernière version aussi dans les versions stables (mais on y viendra à force à avoir plein de logiciels comme ça…), donc failles car Debian ne veut/peux pas faire comme des gens font avec le noyau Linux à regarder quel changement est pour un problème de sécurité et backporter.
Mais je ne vois pas ce que ça change pour installer de Debian, à part changer de source.
https://www.virtualbox.org/wiki/Linux_Downloads
"Debian 9 ("Stretch") i386 | AMD64"
Tu peux installer, certes avec quelques différences (faut faire confiance à oracle pour le binaire, pas repo…).
Aussi https://packages.debian.org/sid/virtualbox est à jour donc il "suffit" de récupérer sid pour au moins virtualbox.
Cette façon de faire à figer les versions pour une distro est de moins en moins tenable, de plus en plus de projet ne prennent pas le temps (qui est de l'argent, que personne ne veut mettre) de maintenir les vieilles versions ("Upgrade to a newer release" est une réponse valable quoiqu'en dise Debian, si personne ne veut payer pour autre chose), à force Linux en grandissant commence à ressembler à Windows, où on installe un OS de base et où on fait comme on peut (avec la sécurité en conséquence) pour avoir certains logiciels pas ou trop vieux dans les repos officiels. Pas facile de grandir et avoir du monde ;-). Ho souvenir de Linuxiens critiquant Windows, alors qu'en sortant un peu du 1% de part de marché les différences s'estompent :-D.
PS : par contre, je serai curieux qu'on m'explique la différence entre Firefox (qui reste et est MAJ dernière version) et VirtualBox (qui dégage), ai-je loupé quelque chose ou "ça dépend (à débattre suivant ton poids")?
[^] # Re: Virtualbox ?
Posté par whity . Évalué à 5.
VirtualBox n’est pas essentiel au quidam moyen, tandis qu’un navigateur web, si. Et, autre point, l’évolution des technos web impose une évolution rapide des navigateurs (quoique ça se soit un peu calmé ces derniers temps), avec un vieux navigateur certains sites n’étaient simplement plus utilisables. Côté virtualbox, il n’y a pas cette évolution fonctionnelle nécessaire qui justifie la montée de version.
En gros, firefox est une énorme exception, qui ne passe que parce qu’il n’y a aucune autre solution viable (ne pas fournir un navigateur web, c’est juste pas envisageable).
Mes commentaires sont en wtfpl. Une licence sur les commentaires, sérieux ? o_0
[^] # Re: Virtualbox ?
Posté par xcomcmdr . Évalué à 2.
Ouais sauf que sous Windows j'ai une vraie sécurité du serveur graphique (hein Xorg), et j'ai pas de lecteur vidéo qui me ferme la session quand il plante (hein SMPlayer), et je perds pas ma session graphique quand le pilote graphique plante (merci les évolutions de Vista).
Finalement, plus ça va, plus Windows est loin devant. :p
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: Virtualbox ?
Posté par maxmasou . Évalué à 0.
Tu as autant de sécurité que les choix que tu fais. Xorg c'est un cheveu dans la palette d'attaque possible sur ton ordinateur. De plus, pour faire une attaque relié à Xorg, le pirate est rentré par quelque part sur ton ordinateur. C'est ce "quelque part" qu'il faut que tu trouves. Il y a 2 possibilités qui se démarque des autres:
1)Tu as inconsciemment téléchargé quelque chose de farfelu avec un Navigateur Internet.
2)Ton port SSH est ouvert à tous, ce qui est très rare à moins d'avoir un serveur XYZ.
Je vis peut-être sur une autre planète, mais de mémoire je n'ai jamais vue d'article sur un particulier qui c'est fait attaquer par Xorg. Remarque que ne suis pas Edward Snowden non plus! Par contre j'ai déjà entendu ça plusieurs fois avec Windows. À commencer par mon père qui c'est fait vider sa carte de crédit à cause d'un Keylogger…
[^] # Re: Virtualbox ?
Posté par Antoine . Évalué à 5.
D'une manière générale, on ne voit jamais d'article sur un particulier qui se serait fait attaquer sous GNU/Linux. Ce n'est pas parce qu'un système GNU/Linux avec environnement graphique serait super sécurisé, mais simplement que ça n'a pas de sens pour un pirate de choisir une cible statistiquement si réduite par rapport aux utilisateurs Windows.
Ton père n'était probablement pas ciblé en particulier, il a été victime d'une attaque en masse. Et quand on effectue une attaque en masse pour vider la carte de crédit d'un grand nombre de gens, on choisit de cibler le système d'exploitation qui a les plus grosses parts de marché.
Eh oui. Or, utiliser Xorg est un choix, utiliser Windows en est un autre…
[^] # Re: Virtualbox ?
Posté par maxmasou . Évalué à -1.
Ouais je comprend tout cela. Mais par "choix", je voulais dire:
1)Utiliser un Firewall bien configuré (Firewalld, Iptable, etc)
2)Utiliser Firejail avec tout ce qui se connecte à internet si possible
3)Utiliser par défaut le mode de navigation privé de Firefox qui ne garde pas de donnée de navigation
4)Utiliser un gestionnaire de mot de passe indépendant comme KeepassX
etc!
Non il a eu le trip de télécharger tout plein de kit d'émoticônes un peu partout sur Internet. L'attaque est arrivé tout de suite après lorsqu'il a fait un achat…
Peut-importe le système d'exploitation, il y a pas grand chose qui protège contre ce que l'on installe soie-même!
[^] # Re: Virtualbox ?
Posté par groumly . Évalué à 5.
Si, les sandbox.
Linuxfr, le portail francais du logiciel libre et du neo nazisme.
[^] # Re: Virtualbox ?
Posté par maxmasou . Évalué à 0.
Imagine le scénario suivant:
1)Tu installes un programme tier frauduleux qui vient AUSSI modifier les fichiers de Firefox
2)Un programme frauduleux est actif en arrière plan dans chaque onglet de Firefox
3)Le programme frauduleux crée un log de tout les sites internet que tu visites et de tous les requêtes que tu envoies.
Tu es dans le trouble parce que Firefox a été corrompu! C'est un peu comme barrer tous les portes de la maison pendant que le voleur est à l'intérieur!
La seul chose qui peux te sauver c'est si Firefox exécute une mises à jour et restaure les fichiers originaux de Firefox. Mais si en plus le programme frauduleux a désactivé les mises à jour automatiques…
[^] # Re: Virtualbox ?
Posté par EauFroide . Évalué à 1. Dernière modification le 27 juin 2017 à 01:52.
Les sandbox ne bloquent pas tout à 100% (#sandboxEvasion).
N'installez pas n'importe nawak !
Donation Bitcoin : 1N8QGrhJGWdZNQNSspm3rSGjtXaXv9Ngat
[^] # Re: Virtualbox ?
Posté par Antoine . Évalué à 3.
Il faut surtout décider si on parle d'une situation où l'utilisateur est un expert en sécurité prêt à passer une journée entière ou plus à configurer sa machine aux petits oignons (configurer firejail ou apparmor, ce n'est pas à la portée de n'importe qui, hein…), ou si on parle du degré de sécurité offert par une installation par défaut.
[^] # Re: Virtualbox ?
Posté par ted (site web personnel) . Évalué à -4.
Pour répondre à propos de Xorg:
Le fait que chaque application sache ce que tu frappes au clavier, ce n'est pas forcément dérangeant (ça peut même être pratique). Les applications pouvant tirer parti de cela, c'est celles que tu as installées. Tu as donc confiance en elles. Sinon, il vaut mieux ne pas les utiliser.
Un LUG en Lorraine : https://enunclic-cappel.fr
# Base stable et application rolling
Posté par Wawet76 . Évalué à 6.
Le problème de Virtualbox est assez révélateur, et je suis content de la politique adoptée pour Firefox.
La Debian idéale pour moi aurait le fonctionnement actuel pour la base du système et tout ce que j'installe sur mes serveurs, et le fonctionnement actuel du paquet Firefox pour les applications utilisateurs. Avec la partie base/serveur supportée plus longtemps (support plus simple, car nombre de paquets limités).
On s'en approche avec le dépôt backport remarquez.
[^] # Re: Base stable et application rolling
Posté par j (site web personnel) . Évalué à 3.
Reste-t-il un intérêt à utiliser VirtualBox quand on peut utiliser KVM + Virtual Machine Manager ?
(C'est une question que je me pose et je la partage avec ceux qui veulent.)
[^] # Re: Base stable et application rolling
Posté par j (site web personnel) . Évalué à 2.
pour VMM je précise qu'il s'agit de https://virt-manager.org/
[^] # Re: Base stable et application rolling
Posté par whity . Évalué à 5. Dernière modification le 30 juin 2017 à 15:04.
Pour du serveur, probablement pas.
Pour du bureautique, pour pouvoir partager ses vms avec ses copains sous windows, pour la meilleure intégration du copier/coller partagé, du partage de fichiers, il y a pas mal de bonnes raisons. Tout un tas de petits détails qui font que c’est beaucoup plus confortable au quotidien.
Mes commentaires sont en wtfpl. Une licence sur les commentaires, sérieux ? o_0
# Debian Stable, c'est bien!
Posté par ted (site web personnel) . Évalué à 4.
Debian est mon système préféré quand je veux installer un ordinateur et ne pas avoir de surprises sur le long terme.
Sur Hacker News, le chef de projet actuel Chris Lamb demande ce que les gens veulent pour Debian 10, ça peut valoir le coup de se faire entendre ;)
https://news.ycombinator.com/item?id=14579080
Un LUG en Lorraine : https://enunclic-cappel.fr
# Le daemon Nagios
Posté par EchoPapaMike . Évalué à 1.
Le daemon Nagios a disparu !
Je ne parle pas de nrpe …
Merci de le rajouter dans la liste des logiciels disparu !
[^] # Re: Le daemon Nagios
Posté par Benoît Sibaud (site web personnel) . Évalué à 5. Dernière modification le 27 juin 2017 à 17:54.
https://www.debian.org/releases/stable/amd64/release-notes/ch-information.fr.html#noteworthy-obsolete-packages
« Les outils de surveillance nagios3 ont été supprimés de Stretch. Le paquet icinga en est le remplaçant le plus proche. Il est globalement compatible, mais lit les fichiers de configuration à un emplacement différent. »
Précision ajoutée à la dépêche, merci.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.