rogo a écrit 282 commentaires

Oui, Unstable et Testing sont des étapes vers Stable, mais je ça me semble franchement abusif de réduire Debian à ses releases stables.

D'abord, contrairement à ce qui est écrit ci-dessus, les rolling releases sont bien mentionnées sur le site officiel : Les versions de Debian. Cette page recommande d'installer généralement "Stable", mais envisage l'installation des deux autres.

La FAQ est encore plus claire quand elle répond à la question « Quelle version de Debian (stable/testing/unstable) me convient le mieux ? » Ce qui confirme que "testing/unstable" ne sont pas juste des étapes pour la prochaine release stable mais sont explicitement envisagées pour une utilisation directe.

Donc Debian est aussi une distribution rolling release. Une preuve supplémentaire : comme pour "Stable", il y a une équipe dédiée à la sécurité de "Testing", avec un dépôt APT spécifique.

L'histoire des peuples avant la colonisation est difficile à cerner précisément parce qu'ils n'ont pas laissé d'écrits, parce qu'il y avait pas mal de peuples nomades et sans doute moins d'états au sens classique. […]

Même difficulté pour l'Afrique (en dehors de l'Afrique du Nord et du monde arabo-musulman).

J'ai pourtant entendu le contraire il y a peu. Les royaumes éthiopiens avaient leur propre écriture, et on a retrouvé des inscriptions du IIIème siècle AD, si j'en crois Histoire de l'Éthiopie sur Wikipedia.

Par ailleurs, ces civilisations ne vivaient pas dans un monde fermé, et on a par exemple beaucoup d'écrits exogènes sur l'empire du Mali. Lequel n'est pas plus nomade qu'en Éthiopie, et certainement un « État au sens classique ».

En plus, la logique de l'argument me paraît douteuse. Les Celtes n'avaient pas d'écriture, et ils apparaissent pourtant dans tous les atlas historiques d'Europe. Je crois aussi me souvenir que les Mycéniens avaient deux écritures, mais l'étude de leur civilisation s'est faite avant tout sur des vestiges non-écrits (poteries, constructions, etc).

J'ai plus de plaisir à jouer sur les mots qu'au tarot !

Certes, distribuer a exactement le sens qu'il faut pour répartir les cartes entre les joueurs. Mais une langue se construit par l'usage plus que par la pertinence théorique, et la distribution des cartes se dit traditionnellement donner. Le terme distribuer étant plus rare en ce sens, c'est tout naturellement que donneur est devenu le terme d'usage, quand distributeur est compréhensible mais plutôt déroutant, surtout depuis l'apparition de machines ainsi nommées.

Au XVIème siècle déjà, on écrivait :

Je donrois quinze à l'Aretin, Et si gaignerois la partie, [Marot, II, 140]

Le Littré atteste de ce sens au XIXème siècle, qu'il illustre aussi par une citation de Molière dans donner. Par contre distribuer est défini sans référence au jeu de cartes.

En maths, je pense que le terme réseau serait plus logique que graphe (pourquoi appelle-t-on ces nœuds connectés par des arêtes des écrits ?) mais je me conforme à l'usage.

Je pense que c'est la dénomination « Styles » qui induit en erreur : le mécanisme est surtout prévu pour avoir un balisage sémantique des documents, et simultanément pour assigner une présentation à ce balisage. Un document utilisant des styles, même des styles créés sur mesure, pourra être visuellement identique à un document qui n'en utilise pas.

Par exemple, dans un document contenant des titres sur 3 niveaux, du code source, des noms de personnes, des chemins vers des fichiers et des citations, je veux que chacun de ces éléments soit balisé par un style indiquant sa nature. Ce qui me permettra ensuite de modifier la présentation des blocs de code source de façon uniforme.

Autre exemple, on fournit un modèle de document pour les rapports de stage avec des styles pour "membre du jury", "encadrant", etc. Ça garantit que la présentation sera relativement uniforme d'un rapport à l'autre. Et en plus on pourra extraire automatiquement tous ces champs stylés du fichier ods.

Le simple fait que beaucoup d'utilisateurs de traitements de texte — la majorité ? — ne connaissent pas le principe des styles donne une idée de la piètre qualité des documents généralement produits. Pour un compte-rendu d'une page, peu importe, mais pour un rapport de 50 pages, c'est navrant.

je n'ai jamais compris comment PHP l'avait détrôné pour le CGI, si quelqu'un a un pointeur ou une explication, je suis preneur

Il y avait une mauvaise raison : PHP peut nativement servir de langage de template, donc il était facile de transformer une page HTML en page PHP. En Perl, c'est possible (Mason, etc), mais ce n'est ni facile ni usuel.

L'autre raison est plus acceptable : la facilité de déploiement. Jusqu'à récemment, la norme pour installer un environnement web PHP était d'installer Apache + mod_php, et la configuration par défaut était tout de suite suffisante.

Par comparaison, le CGI est plus lourd à configurer, plus dangereux, et terriblement lent. Perl propose bien mod_perl mais c'est très différent du mode "chaque requête est autonome", et c'est difficile à utiliser, surtout que mod_perl2 est très peu documenté.

Aujourd'hui, tout converge vers une architecture de type FASTCGI où le serveur web (Nginx, Apache, etc) joue le rôle de proxy sur les applications. Les frameworks Perl récents (Dancer, Mojolicious) utilisent PSGI (Plack) sur le modèle du WSGI de Python, tout comme PHP promeut php-fpm en remplacement de son module Apache.

Des personnes qui sont une source d'inspiration pour transformer le monde vers plus de justice, de paix et de diversité.

Il suffit de rassembler les biographies des lauréats du prix Nobel de la paix. Après tout leurs critères sont les mêmes. Non, je plaisante ; la proportion d'affabulateurs, de criminels, d'incompétents et d'égoïstes sans cœur est visiblement la même chez ces nobélisés que dans les autres cercles du pouvoir.

Le principe est tout de même identique à celui du Nobel : quelques personnes qui décident, pour des raisons obscures et sans contre-expertise, que d'autres sont des modèles. Comme pour le Nobel, les enjeux politiques et commerciaux vont influencer les choix. Ici, c'est même pire, puisque l'auto-promotion semble inévitable, et que la religion y ajoute son influence.

Comme pour le Nobel, on découvrira ensuite qu'une lauréate idéale avait tout inventé (Rigoberta Menchu), qu'une autre idole n'a rien contre les pogroms dans son pays (Aung San Suu Kyi) et qu'un jeune prometteur est en fait devenu criminel de guerre (Obama).

S'il y a des gens que cette activité réjouit, tant mieux pour eux. Pour ma part, le projet a beau être poisseux de bons sentiments, il me semble aussi ridicule que malsain.

Je doute que ce soit spécifique à mes machines. Ça se reproduit sur plusieurs Debian Jessie, LO 4.3.3.2, écrans 1920x1080 à 2560x1440, texte justifié, police variable, par exemple Dejavu Sans 11. L'installation dans un compte utilisateur vide n'y change rien. Aucune autre application sur ces machines n'a des symptômes ressemblant à ça.

L'échantillon avait été sélectionné pour sa laideur extrême, la déformation est rarement aussi forte, et généralement peu gênante pour la lecture. Le mode aperçu semble aggraver le phénomène, même en restant au zoom 100%. J'utilise peu LO, donc je n'ai pas creusé.

En effet les dernières versions de LibreOffice sont stables, fonctionnelles et agréables à utiliser (les versions précédentes n'étaient pas prêtes pour une utilisation professionnelle selon moi, et oui, je suis exigeant :-)

On n'a pas la même expérience… ou alors je suis encore plus exigeant !

D'aussi loin qu'il me souvienne, l'affichage du texte à l'écran dans LibreOffice est très mauvais. Il faut monter à de grands niveaux de zoom pour obtenir un résultat acceptable. Voici ce que peut donner une fonte taille 11 au zoom 100% : 
Les lettres qui se grimpent dessus, ça n'est pas à mon goût.

J'ai beau virer ma config LO, activer/désactiver le lissage et le kerning, changer de fonte, rien ni change, ça reste moche et pénible à lire.

C'est vrai que le mainteneur Debian est laxiste. Il devrait se soucier des utilisateurs qui vont :
- désactiver Network Manager ou équivalent,
- désactiver le système ifupdown de Debian,
- activer systemd-networkd,
- activer systemd-resolved et lier /etc/resolv.conf dessus,
- utiliser un DHCP qui ne fournit pas de DNS, ou utiliser une config statique sans DNS,
- garder la configuration par défaut de systemd-resolved.

Google va pouvoir surveiller les millions d'utilisateurs qui rentrent dans ce cadre !

Plus sérieusement, si on utilise un système de configuration automatique du réseau comme networkd+resolved, ça ne me choque pas qu'il se débrouille pour que ça marche, quitte à extrapoler. Si ça déplaît, alors on assume et on va modifier les fichiers de configuration.

Si on veut vraiment bidouiller son réseau, on passe plutôt par des outils comme ip (voire ipconfig et route), et dans ce cas là, pas de DNS automatique.

Puisqu'apparemment les Finances publiques détiennent tous les droits sur le logiciel, la CADA décide qu'ils doivent en diffuser le code source selon l'article 12 de la loi du 17 juillet 1978. Lequel stipule simplement que :

Sauf accord de l'administration, la réutilisation des informations publiques est soumise à la condition que ces dernières ne soient pas altérées, que leur sens ne soit pas dénaturé et que leurs sources et la date de leur dernière mise à jour soient mentionnées.

Très bien, il suffit juste de respecter l'esprit du code. Sauf que l'article 15 de la même loi indique :

La réutilisation d'informations publiques peut donner lieu au versement de redevances. […] L'administration peut aussi tenir compte des coûts de collecte et de production des informations et inclure dans l'assiette de la redevance une rémunération raisonnable de ses investissements comprenant, le cas échéant, une part au titre des droits de propriété intellectuelle.

Vu leurs réticences à publier ce code, ils peuvent très bien demander quelques centaines de milliers d'euros pour ce faire. Pour ce chercheur, la partie n'est pas encore gagnée.

Merci pour la réponse, même si elle ne répond pas du tout à la question ;-)

Du coup, j'ai fait l'effort d'aller lire la doc, laquelle semble vraiment bien fichue. Je ne connais pas Django, je n'aurais pas parié un kopeck sur mes chances, et pourtant j'ai trouvé et compris en 10 minutes.

La nouvelle méthode citée dans la dépêche est documentée dans ce paragraphe et mon interrogation fait l'objet du paragraphe suivant.

En bref, quand on ne se satisfait pas de l'objet QuerySetManager renvoyé automatiquement par as_manager(), il faut utiliser from_queryset() qui va renvoyer une sous-classe de QuerySetManager que l'on peut alors enrichir. Un exemple de code est donné dans la doc, cf lien ci-dessus. Le mécanisme de portage automatique de l'API de QuerySet à QuerySetManager est aussi expliqué et illustré.

De mémoire, Debian recommande le paquet unattended-upgrades à la place de cron-apt. La config par défaut de unattended-upgrades est généralement suffisante.

Le paquet unattended-upgrades installe notamment un fichier /etc/apt/apt.conf.d/20auto-upgrades :

APT::Periodic::Update-Package-Lists "1";
APT::Periodic::Unattended-Upgrade "1";

Le paramétrage des mises à jour automatiques est dans /etc/apt/apt.conf.d/50unattended-upgrades. La config par défaut installe automatiquement les nouveautés venant des dépôts de sécurité de stable et oldstable. Le fichier est très documenté, facile à modifier.

On peut compléter avec le paquet apt-listchanges pour se faire envoyer par email le détail des modifications.

Je ne connais pas Django, mais ça m'intéresse de savoir se qui se fait ailleurs, et je n'ai pas compris le passage sur QuerySetManager.

La dépêche dit que si l'on voulait créer son propre QuerySetManager, il était alors pénible de l'interfacer avec le QuerySet associé. La solution proposée est de ne pas créer son propre QuerySetManager, mais d'en générer un à la volée. Stricto senso, ça ne répond pas au problème initial, à moins que les classes -SetManager soient toujours des surcouches neutres sur les -Set.

À première vue, ça semble surtout très mal ficelé : dès qu'on voudra enrichir ce SetManager, il faudra changer la structure du code et se taper l'ancienne syntaxe ? Mais j'ai sans doute mal compris.

C'est aussi très lent. Ton shell calcule la liste de fichiers, puis il lance la commande, alors que find peut lancer la commande au fur et à mesure.

Je coinche.

D'abord cette lenteur ne s'applique pas sur le second exemple, celui où on utilise la complétion shell pour ouvrir un fichier avec vim.

Ensuite, pour le premier exemple, je doute que la différence soit notable entre un seul appel à rm suivi d'une liste de fichiers et plein d'appels consécutifs. Je me risquerais même à prédire que find serait plus lent (plus de processus lancés).

Enfin, pour de la recherche dans les sous-répertoires d'un projet, qui était le cadre où mes exemples se plaçaient, je n'ai jamais de problème de lenteur (merci aux SSD et à la RAM à bas prix).

En pratique, je trouve que le globbing shell est souvent plus fiable que find quand on traite le résultat. Par exemple, ls -1shS **/*.zip(LM+100) pour lister et trier les fichiers zip de plus de 100Mo sous le répertoire courant : avec find, ça planterait parfois, notamment s'il y a un espace dans un nom de fichier.

Moi, je m'en fous je cherche en ligne de commande avec find sais ou je range mes fichiers.

Juste au cas où tu aurais un trou de mémoire et que tu envisages vraiment d'utiliser find, je suggère de recourir à "mlocate" (ou toute autre déclinaison de "locate") :

locate Tezuka
locate -ib nausicaa
locate -i --regex 'ima.+soko'

Mon utilisation de find a aussi diminué en parallèle de mes progrès en shell : rm src/**/*.o est plus pratique que d'utiliser $(). En plus, on peut compléter : vim **/config.php<TAB>.

Je sais, tout ça est un peu hors-sujet, j'ai juste profité de l'appel d'air. J'ai de la sympathie pour XFCE, mais je ne le pratique plus ; j'ai adopté Xmonad avec délice.

Le probleme de wayland c'est que ca fait des annees que c'est cense arriver et que cela n'arrive pas

Source ? Parce que je lis les annonces Wayland, et je n'ai jamais vu la moindre promesse de livraison rapide. Même lors de l'annonce de la version 1.0, fin 2012, il y avait plutôt des mises en garde sur le sujet. Cf la dépêche LinuxFr de l'époque.

Idem pour l'intégration dans les toolkits graphiques, ça c'est toujours inscrit dans une perspective longue. Par exemple, Gnome, en 2012, ne prévoyait pas de compatibilité totale avant 2014.

Aujourd'hui, Wayland et Weston ne sont pas encore prêts pour la prod, mais c'est aussi parce que chacun préfère peaufiner plutôt que de se presser. Fedora 20 propose déjà Wayland, l'imminente Fedora 21 l'utilisera au moins pour la page de login, et peut-être que F22 ou 23 l'adoptera par défaut. Ça avance comme prévu, tranquillement.

Quelle est ta métrique de complexité ? Pour moi runit est globalement beaucoup plus simple que systemd (et portable OS/libc/compilateur :)).

Runit est plus simple que systemd. Trop simple, d'ailleurs, puisque, bien qu'étant prévu pour servir d'init, personne ne l'envisage sérieusement. En tout cas, je ne l'ai jamais vu apparaître dans les discussions sur le passage à systemd, upstart, ou openrc.

Donc on se retrouve à utiliser runit comme un complément au système d'init. Avec ses propres commandes, comme sv, ses propres répertoires et fichiers de configuration, son système de log intégré, son espace utilisateur configurable séparément, etc. Tout ça en parallèle de service, de /etc/init.d/, de rsyslog, etc. Bref, le terme de complexité me semble justifié.

Personnellement, j'avais pataugé plusieurs heures pour installer runit comme "monitoring & respawn system". La doc succincte, le peu d'utilisation, et les messages minimaux n'ont pas aidé. Et je n'aurais pas osé y toucher ensuite sans mon mémo perso. Une fois passé à systemd et désinstallé runit, j'ai lu une doc, et en un quart d'heure la migration était faite.

Les cgroups permettent de coller une balise sur un processus. C'est particulièrement utile parce que cela permet notamment :

1. d'affecter des ressources à ce cgroup ;
2. d'en contrôler l'exécution ;
3. de garder toujours trace de ce processus et de ses descendants.

 

Le 1 est tout simple : on peut limiter le volume de mémoire, la quantité de processeur ou d'entrée/sortie auquel le cgroup aura accès.

Le 2 rend possible de suspendre une application pour la redémarrer plus tard. Une sorte d'hibernation partielle.

Le 3 est à mes yeux fondamental, c'est le seul moyen que je connaisse pour surveiller totalement un processus, et c'est ce que fait systemd, cf systemd for Administrators, Part II. Sinon, à coup de forks et autres astuces, une application peut fausser compagnie à son moniteur.
D'ailleurs, le besoin tout simple de lancer une appli en mode démon avec redémarrage automatique en cas d'arrêt, ce besoin naturel était très dur à satisfaire avec sysvinit. start-stop-demon ne suffit pas, et si le processus n'écrit pas son pid, monit non plus. Il fallait bidouiller ou recourir à runit et toute sa complexité. Désormais, ça se fait en 5 lignes évidentes.

Me semble que sysVinit sera toujours supporté, juste, pas par défaut. S'il n'y a pas de citation confirmant la quote, je continuerai de penser que Debian 8 supportera sysVinit.

C'est aussi ce qu'il me semble. J'avais laissé un commentaire pendant la phase de rédaction pour pointer ce passage qui me semblait fallacieux, pour ne pas dire mensonger. Mais je n'avais pas voulu corriger moi-même, échaudé par quelques mauvaises expériences dans Wikipedia sur les sujets polémiques.

Incroyable, dans le Littré

|2| Par exagération, qui passe la croyance, excessif, extraordinaire.

Qui pourrait exprimer par quels faits incroyables Son bras se signalant pour la dernière fois…. [Racine, Mithridate V, 4]

Donc au XVIIe siècle, Racine utilisait déjà incroyable au sens d'extraordinaire.

le manque d’opérations triviales (formatage de dates par exemple)

En XSLT1, rien n'est prévu pour gérer les dates. Mais ce n'est pas le cas en XSLT2. Ceci dit, c'est extrêmement pénible à utiliser. Par exemple, s'il faut convertir "02-23-2015" en "23 février 2015", il faut commencer par bricoler en découpant la chaîne par position avant d'appliquer les fonctions de date : plusieurs dizaines de lignes de code en tout, soit un facteur 10 par rapport à un langage généraliste.

À mes yeux, le principal défaut de XSLT est que c'est un carcan plutôt étroit. Pour un besoin simple, tout va bien. Quand on commence à manipuler le texte des attributs, on commence à suer. Mais le jour où l'on décide de normaliser certaines valeurs XML en croisant avec une base de données, alors la feuille XSL devient un boulet. On peut paraît-il y greffer des modules pour lancer des requêtes SQL en cours de transformation, mais ça semble aussi productif que de remplacer systemd par emacs.

J'ai arrêté de lire dès la section sur l'AMI, en 2.4.4.1. Si cette auto-défense passe par la manipulation, l'insinuation et l'amalgame, alors je m'en passerai.

Déjà, dans les pages précédentes, j'ai été plutôt agacé que l'auteur cite des chiffres sans mentionner les études qui les auraient produits. Il colle aussi un sens plus que douteux sur un écart de 2 % qui relève très certainement de l'intervalle d'incertitude (p. 5, qui plus est sur un sous-échantillon).

La forme du texte me donne la nausée. D'un côté : « comme Dracula », le « projet des Maîtres », « cet AMI qui nous voulait du mal », la « servilité des médias, propriétés des puissants ». Et le pendant manichéen : « fulgurantes analyses de l'AMI », « légitimes inquiétudes chez les citoyens », « qui se mobilisent de manière exemplaire ». Les grands méchants contre le gentil peuple uni.

Le reste est pour le moins maladroit, et à mon avis manipulateur.

• Pour illustrer le traitement de l'AMI, il choisit un échantillon de journaux, sans les mentionner ni même les dénombrer, mais en excluant un grand journal. Comment justifier ce choix ?
• 10 articles sur le sujet, dans les 7 mois suivant juin 97, lui semblent trop peu, et preuve de servilité. Sur quel critère ?
• Pourquoi choisir une période commençant au 1er juin, plusieurs mois après les fuites sur le dossier AMI ?
• Il admet ne pas s'intéresser au contenu et à la taille des articles. Est-ce bien sérieux ?
• Il compare les articles médiatiques sur l'AMI et Céline Dion pour montrer que le premier est un sujet dissimulé. Ne faudrait-il pas comparer avec un sujet de la même catégorie (politique internationale ou économie) ?
• Si les journaux ont servilement publié surtout des articles favorables à l'AMI, pourquoi ont-ils publié des lettres ouvertes de citoyens qui y sont hostiles ?
• Et pour finir sur la forme, pourquoi qualifie-t-il les opposants de citoyens quand il appelle les partisans des gens ?

Comment répondre quand des propos publics sont déloyaux ? C'est simple : il n'y a pas de solution générale, et souvent pas de solution du tout.

Je suis plus souvent confronté à ce problème indirectement que directement, généralement en écoutant la radio ou dans la presse. Un bon exemple est l'affaire du rapport médical sur V. Bettencourt rédigé par une femme médecin proche d'un des magistrats instructeurs. J'ai entendu et lu plusieurs personnalités affirmer qu'elle avait ausculté la vieille dame. Cela semble la suite logique de la phrase précédente, alors que c'est une manipulation longue à réfuter. Cette femme a en fait rédigé le rapport qui synthétise les comptes-rendus de plusieurs spécialistes, lesquels ont validé cette synthèse. Elle-même est médecin légiste, et n'a donc pas de raison d'ausculter un vivant. Pour comprendre le mensonge, il faut expliquer la complexité de la situation. Pour des manipulations sur des sujets plus difficiles, comme les statistiques de l'immigration, exposer la tricherie demande encore plus de travail et d'argumentation raisonnée. Même un journaliste consciencieux n'a aucun espoir face à un hâbleur malhonnête.

L'agressivité des propos ou leur malhonnêteté ne sont pas les seuls facteurs. Bien souvent, il faut lutter contre le bon sens et les bonnes intentions. Le cas d'école est selon moi l'édito du Monde sur la mort de Mandela, intitulé « L'irrésistible force de la non-violence ». La directrice du journal, journaliste aguerrie, y faisait de Mandela un disciple zélé de Gandhi, un chantre de la non-violence en Afrique du Sud, où la lutte armée de l'ANC se serait faite malgré lui. Cela colle parfaitement à l'icône médiatique, à cette vague d'adoration qui a submergé le monde entier (sauf Israël), mais c'est complètement faux. Mandela abandonna la résistance civile de Gandhi qu'il jugeait inefficace. Il demanda à la direction de l'ANC la création d'une branche armée dont il devint le chef, et engagea une politique d'attaques armées et d'attentats. La première fois que je racontais cela, mon interlocuteur fut persuadé que j'affabulais, c'était trop incompatible avec le discours ambiant.

Qui utilise stable ?

Je ne connais pas de serveur qui soit en Debian testing ou unstable. J'ai vu des serveurs qui fonctionnaient sans évolution depuis des décennies, même si en général leur durée de vie est plus courte. Pour ces engins, il faut des systèmes d'exploitation stables.

Il n'y a aucune raison de geler sid une fois que les paquets ne passent plus automatiquement dans testing !

Aucune raison, vraiment ? J'en vois plusieurs. Imagine que tu maintiennes le paquet Foobar. Ta version 1.0 est dans testing, mais comme il n'y a pas eu de gel, tu sors une 1.1 en unstable. Sauf qu'on découvre un bug critique en 1.0. Comment s'en sortir en gardant un historique linéaire ?

Pour résumer, cette résolution veut interdire la dépendance unique à systemd en dehors des cas de force majeures (interface graphique sur systemd, etc) : tout paquet Debian devrait accepter plusieurs systèmes de démarrage.

Plusieurs amendements ont été ajoutés, chacun étant une possibilité de vote :

1. La compatibilité avec plusieurs init systems est recommandée, mais pas obligatoire.
2. Chaque mainteneur est libre de décider.
3. Ce vote est inutile et cette résolution générale est une perte de temps.