Obsidian a écrit 5288 commentaires

  • [^] # Re: Possibilité d'éditer ses propres contenus

    Posté par  . En réponse à la dépêche Améliorons l’expérience utilisateur de LinuxFr.org !. Évalué à 5.

    C'est une solution qui ajoute de la complexité : je n'ai pas envie d'être obligé de vérifier l'historique des messages avant d'y répondre, c'est ingérable.

    À l'usage, pour utiliser cela sur les autres sites aussi, je confirme que c'est très utile. La variable d'ajustement pourrait aussi être le délai de grâce. Sur certains sites, ce délai est de trois jours. C'est très pratique pour relire ses commentaires à tête reposée et sous un autre angle. Je pense que ce n'est qu'après 24 heures de délai au moins (et une bonne nuit de sommeil) qu'on peut vraiment reconsidérer ses propos avec l'œil d'un « lecteur » et non d'un « relecteur ».

    Quel pourcentage de messages ont "besoin" d'être édités ? A comparer avec la complexité engendrée.

    Paradoxalement, c'est justement le fait que ce pourcentage soit faible qui va rendre la chose gérable (et d'un autre côté, si tout le monde sollicitait en permanence les modérateurs pour modifier tous les messages du site, alors ça justifierait aussi la mise en place de cette facilité).

    Personnellement, j'ai aussi implémenté cette fonction dans le micro site web que j'ai fait pour l'association de mon quartier (avec les messages privés dont je parle dans un autre commentaire). Je fais cela « à la Git », c'est-à-dire que je remplace entièrement un commentaire par un autre même si la modification est minime, ce qui veut dire qu'en ce sens, l'opération n'est pas différente de poster un nouveau commentaire. Et comme mon éditeur est naturellement fait pour faire une prévisualisation (qui elle, n'est pas remise en cause), alors je n'ai besoin de pratiquement aucun code supplémentaire pour reprendre un commentaire existant.

    Dans un premier lieu, seule la date de dernière édition est discrètement signalée dans une note en bas du commentaire, et le fait que l'opération soit courante mais pas fréquente fait que cela attire automatiquement l'œil du lecteur quand c'est le cas. Ensuite, les anciens commentaires sont toujours dans la base. Ils sont juste déréférencés parce que le dernier en date remplace toujours le précédent. Donc, au point de vue code, ça ne pose aucun problème.

    Ensuite, il me suffit d'une simple table à deux colonnes pour faire un chaînage parent→enfant pour remonter l'historique des modifications. Ça resterait déjà tout-à-fait exploitable si la totalité des commentaires des 15 dernières années avaient un CV long comme le bras (cas des pages Wikipédia, par exemple), mais sur un forum des discussions. Ça va effectivement concerner peut-être 3 à 5 pourcent des commentaires, dont la majorité n'auront qu'une seule modification.

    Donc en résumé — POUR l'AVOIR FAIT — je confirme que c'est relativement facile. :)

    Un argument que j'aime bien : ne pas avoir de possibilité d'édition incite à réfléchir correctement. Je trouve que ça donne des discussions qui sont de meilleur niveau.

    Mouais mais non. Ça, ça n'est vrai que jusqu'à un certain niveau. Ensuite, au bout d'un moment, ça fatigue l'utilisateur, surtout quand il s'agit d'une régression. Prévenir les gens pour qu'ils ne fassent pas de faux pas, c'est une bonne chose, s'arranger pour que, techniquement, ils ne puissent pas en faire, c'est encore mieux.

  • [^] # Re: Un coup de polish sur le design ?

    Posté par  . En réponse à la dépêche Améliorons l’expérience utilisateur de LinuxFr.org !. Évalué à 3.

    Oui mais quand on soumet une CSS, on peut en fait ajouter le fichier de la fonte elle-même aux ressources, au même titre que les images associées. On peut donc, a priori, utiliser n'importe quelle fonte, même si elle très exotique. En principe, elle n'est chargée qu'une seule fois par le navigateur. Si, en plus, elle est déjà sur la distrib', c'est tout bénéf' pour le lecteur.

  • [^] # Re: Un coup de polish sur le design ?

    Posté par  . En réponse à la dépêche Améliorons l’expérience utilisateur de LinuxFr.org !. Évalué à 2.

    C'est vrai qu'il y a beaucoup de choses sympa dans les Google Fonts et que ça permet de décorer un peu le web. Celle-ci est belle, en effet, et je crois que je vais la garder sous le coude. Cela dit, elle est assez proche (au moins sur un rendu papier) de Libération, qui est déjà largement répandue sur les distribs. J'ai aussi un faible pour Linux Libertine, que j'avais impliquée dans Springtime sous Templeet, juste avant le passage à Ruby.

  • [^] # Re: Un coup de polish sur le design ?

    Posté par  . En réponse à la dépêche Améliorons l’expérience utilisateur de LinuxFr.org !. Évalué à 2.

    C'est noté. Merci pour les indications !

  • [^] # Re: Possibilité d'éditer ses propres contenus

    Posté par  . En réponse à la dépêche Améliorons l’expérience utilisateur de LinuxFr.org !. Évalué à 5.

    (Et on n'a pas besoin de révéler une "adresse personnelle", on donne l'adresse qu'on veut. Je peux me créer une boîte mail 'gasche-linuxfr@…' chez n'importe quel fournisseur email et l'utiliser.

    C'est exactement cela qui est rédhibitoire pour moi. Je gère déjà sept adresses e-mail un peu partout et même avec un client dédié, aller créer une adresse PAR forum pour bénéficier des MP, ce n'est pas acceptable. Surtout à la volée !

    Je ne comprends pas que tout le monde trouve normal de s'exprimer publiquement mais à une personne donnée dans un fil de discussion (via les réponses) et de ne pas pouvoir faire un aparté quand on a une information confidentielle à transmettre.

    Surtout que ce n'est pas du tout mutuellement exclusif : quand il y a des MP, il y généralement moyen d'être également prévenu par e-mail – si on le souhaite – et il y a un bouton pour les exporter. Même moi qui ait écrit un serveur complètement from scratch (sur du PHP/PostgreSQL) parce que notre hébergement est trop petit pour y coller quoi que ce soit de sérieux, j'ai mis en place cette fonctionnalité. Pour une population de 60 personnes environ.

    Ça existe absolument partout et ça fonctionnait très bien ici aussi.

  • [^] # Re: Un coup de polish sur le design ?

    Posté par  . En réponse à la dépêche Améliorons l’expérience utilisateur de LinuxFr.org !. Évalué à 2.

    D'ailleurs, puisqu'on en parle, est-ce qu'il y a possibilité de joindre des ressources annexes aux CSS alternatives que l'on soumettrait (images, fontes…) et si oui, dans quel dossier faudrait-il les mettre du côté du code (pour ceux qui passent par les pull requests) et via quelle URL seraient-elle accessibles ensuite ? (nécessaire pour la CSS elle-même).

  • [^] # Re: Il y a un autre truc "chiant"...

    Posté par  . En réponse à la dépêche Améliorons l’expérience utilisateur de LinuxFr.org !. Évalué à 4.

    Je n'ai pas de début de solution, mais je trouve ça vraiment "chiant"…

    Et pourtant, il y a une : c'est le bouton [^] qu'il y a dans le titre de chaque commentaire et qui sert à remonter au commentaire parent (tu peux ensuite utiliser le bouton Back pour revenir à ce que tu lisais). C'est d'ailleurs une suggestion faite dans le suivi il doit y avoir presque une dizaine d'années et qui avait déjà été implémentée du temps de Templeet.

    Par contre, la CSS mériterait d'être retravaillée parce que la simple barre verticale à gauche du paragraphe cité est un peu faiblarde. Personnellement, et pas plus tard que ce soir, j'ai ajouté ce qui suit dans « ~/.mozilla/firefox//chrome/userContent.css » :

    @-moz-document url-prefix(https://linuxfr.org/)
    {
    
    div#comments div.content blockquote
    {
        background-color:       #d0d0d0;
        border:                 solid 0px transparent;
        border-left:            solid 2px #b0b0b0;
        color:                  #303030;
        font-size:              90%;
        padding:                0.8em !important;
        margin:                 1em 5em 1em 0 !important;
        box-shadow:             0.5em 0.5em 0.5em #a0a0a0;
    }
    
    div#comments div.content blockquote p:first-child
    {
        margin-top:     0 !important;
        padding-top:    0 !important;
    }
    
    div#comments div.content code
    {
        color:              #e0e0e0;
        background-color:   black;
        font-family:        "Monospace Regular","monospace","fixed";
        font-size:          100% !important;
    }
    
    div#comments div.content blockquote p:last-child
    {
        margin-bottom:  0 !important;
        padding-bottom: 0 !important;
    }
    
    }
    

    Ça met un fond gris au bloc cité, ça lui ajoute une ombre et ça réduit légèrement la taille relative de la fonte. Rien que ça, ça facilite beaucoup la lecture des dialogues.

  • [^] # Re: LinuxFR.org semble développé par ~1 personne, des impacts ?

    Posté par  . En réponse à la dépêche Améliorons l’expérience utilisateur de LinuxFr.org !. Évalué à 5.

    La question ne se pose pas vraiment en ces termes. Quand on a voulu se débarrasser de templeet, j'ai pris la décision de partir sur un développement spécifique plutôt que des logiciels libres existants en 2008 et je pense que c'était le bon choix. J'avais également l'espoir à l'époque que cette base de code spécifique puisse être utilisée par d'autres sites, mais ça ne s'est pas concrétisé.

    C'est-à-dire que c'était également les motivations de Templeet, lorsque DLFP a abandonné DaCode. Et Templeet était lui aussi un logiciel libre (et même documenté !), pour les mêmes raisons.

    De l'autre côté, vouloir migrer même vers des outils existants demande un travail très conséquent pour juste arriver au même niveau. Je ne pense pas que l'on ait les ressources pour réussir un tel chantier. Et si on les avait, ça serait sûrement plus efficace de faire évoluer progressivement l'existant que de se lancer dans un gros chantier qui va forcément prendre du temps et dont l'issue est plus incertaine.

    Ça c'est vrai aussi, c'est un plan de migration, et c'est intéressant entre autre pour éviter les régressions […] à condition d'arriver à le faire admettre aux décideurs et aux développeurs de l'équipe au moment où c'est nécessaire.

    Mais bon. C'est un peu comme refaire sa maison. C'est très excitant au départ, arrivé à mi-chantier, on se demande pourquoi on s'est embarqué là-dedans et à la fin, il est presque temps de recommencer. En général, on le fait une fois, rarement une deuxième.

    Du coup, les années passant, il est probable que si tu transmets à ton tour, un jour, le bébé à une autre équipe, cela marque le début d'un nouveau cycle et que celle-ci en profite pour réécrire une nouvelle fois DLFP en exploitant les technologies du moment.

  • [^] # Re: Possibilité d'éditer ses propres contenus

    Posté par  . En réponse à la dépêche Améliorons l’expérience utilisateur de LinuxFr.org !. Évalué à 2.

    Ce serait donc un « minimum », si l'on peut dire, surtout dans la mesure où cela existait ici avant et que ça existe également partout ailleurs.

    Et à partir du moment où on a un formulaire permettant de relayer instantanément un message vers l'adresse e-mail (conservée confidentielle) d'un membre, et que d'autre part, on a tout un système de conservation des messages publics (les commentaires des discussions), alors il ne manque vraiment pas grand chose pour implémenter un vrai système de messages privés.

    Surtout que les MP basés sur l'e-mail déclarée d'un membre implique que l'expéditeur ait lui aussi une adresse valide qui sera automatiquement utilisée comme adresse expéditrice, ou à tout le moins en tant que Reply-To.

    Et justement, comme cela implique d'utiliser le nom de domaine de l'hébergeur de l'adresse e-mail, cela nécessite en fait d'envoyer le premier mail en tant que noreply@linuxfr.org ou quelque chose d'assimilé. Il est largement plus sympa d'avoir des MP pour communiquer des infos confidentielles entre membres d'un même site sans avoir à révéler son adresse personnelle.

  • # Pour quelles applications ?

    Posté par  . En réponse au message quand et pourquoi implementer un pilote?. Évalué à 9.

    Salut,

    Voila, j'aimerai vos avis du coup, quand et pourquoi implementer des pilotes,

    Concevoir puis implémenter des pilotes de périphériques est en soi une chose assez stimulante. C'est aussi une bonne occasion de plonger dans le code de bas niveau, voire carrément la programmation noyau et, en plus, les objectifs à atteindre sont relativement bien délimités : il s'agit en gros d'honorer une API (généralement déjà existante) dans sa totalité, pour permettre ensuite à des applications non spécifiquement écrites pour de pouvoir exploiter ton matériel à travers lesdits pilotes.

    La première question est donc : qu'est-ce que tu pilotes, fût-ce via une liaison RS/232 ou 485 ? Il y des chances pour que ce soit en atelier, donc peut-être des machines outils… Et là encore, ça n'a d'intérêt que si ton pilote permet d'adapter l'utilisation du matériel à quelque chose de générique, ou à la limite à un niveau d'utilisation simplifié. Ça peut être intéressant également si tu as une grande gamme de matériels différents mais censés être, in fine, exploités de la même façon par l'utilisateur.

    Par contre, si tu exploites du matériel spécifique dans un seul cas d'utilisation avec un logiciel dédié exclusivement, ça ne sert à rien d'intercaler un pilote entre les deux.

    et user-space ou kernel-space?

    À priori user space quand même, surtout si c'est au travers d'une liaison RS/232 qui, elle, est déjà bien prise en charge par le kernel. Non seulement la programmation peut être un cauchemar à déboguer (si ton pilote plante, c'est tout le système qui s'écrase. Ça ne se finira pas en simple segfault…) mais en plus, il faudra faire des appels internes pour aller revendiquer temporairement l'interface qui est faite pour être appelée via des appels système utilisateur normaux. Ça compliquerait un développement qui est censé être facilité quand il fait en user space.

  • [^] # Re: Possibilité d'éditer ses propres contenus

    Posté par  . En réponse à la dépêche Améliorons l’expérience utilisateur de LinuxFr.org !. Évalué à 4.

    En fait on peut modifier ses messages, mais le délai de grâce est un peu être un peu trop court :

    Autre chose qui existait jadis et qu'il serait agréable de récupérer : les messages privés.

  • [^] # Re: Bugs Firefox

    Posté par  . En réponse au message Perte des mots de passe firefox.. Évalué à 2.

    C'est-à-dire qu'ils partagent beaucoup de technologies sous la forme de bibliothèques communes, et le dépôt des profils utilisateurs est plus ou moins organisé de la même façon dans les deux cas.

    Jette-y quand même un œil pour voir si tu vois des fichiers « *.corrupt ». Tu devrais déjà y récupérer pas mal d'informations sans trop de difficulté.

  • # Bugs Firefox

    Posté par  . En réponse au message Perte des mots de passe firefox.. Évalué à 2.

    D'une manière générale, j'ai connu ces deux dernières années un certain nombre de bugs avec Firefox dont qui ont toujours été très difficiles à isoler, jusqu'à ce que je m'aperçoive qu'ils étaient parfois carrément structurels. Il semble que quand un profil utilisateur commence à être vraiment vieux et que l'on fasse un gros usage des ressources, par exemple quand on a beaucoup de bookmarks, ce profil finisse par se corrompre. Voici les principaux bugs que j'ai personnellement observés :

    • Corruption des bases SQLite : Firefox a décidé de s'appuyer dessus depuis un moment et c'est une très bonne idée en soi, sauf qu'à intervalles aléatoires mais globalement réguliers quand même, tous mes bookmarks disparaissaient ! Un tour dans ~/.mozilla/firefox/ me montre que j'obtenais alors trois fichiers :

    • places.sqlite

    • places.sqlite.corrupt

    • places.sqlite.bak

    Donc, autrement dit, la base avait crashé à l'ouverture et sqlite a eu le bon goût de la copier quand même dans « corrupt » avant d'en reconstruire une autre. Le fait de fermer Firefox, de supprimer le *.bak et le fichier normal, de renommer la base « corrupt » vers la base originale et de relancer le navigateur faisait rentrer les choses dans l'ordre, si bien que le crash à l'ouverture était totalement aléatoire. J'ai même fini par m'écrire un script « mozbook » exprès pour archiver proprement chaque base plantée et faire l'opération ci-dessus à chaque fois.

    J'ai une fois essayé d'exporter puis réimporter mes bookmarks en soupçonnant une corruption de données quelque part, mais le problème était réapparu quelque temps plus tard. Ça a fini par s'arranger au bout de quelques versions, mais je mets ça également sur le fait d'une mise à jour de SQLite proprement dit.

    • Disparition des cookies : beaucoup plus rare, mais exactement le même problème.

    Plus récemment : impossibilité de saisir des accents circonflexes ainsi qu'un ou deux autres caractères spéciaux. Cela n'affectait que Firefox. Une recherche sur le web m'avait renvoyé vers quelques billets épars, qui signalaient la même chose, mais qui étaient parfois vieux de six ans. Ça semble être un bug latent que personne n'a réussi à identifier : le fait de détruire mon profil, d'en reconstruire un autre et d'y réimporter mes données personnelles (dont mes bookmarks) a fait disparaître le problème.

  • # L.I.N.U.X

    Posté par  . En réponse au journal Un morceau de punk sur L.I.N.U.X. Évalué à 5.

    C'est autre chose que la Free Software Song !

  • [^] # Re: Gnome...

    Posté par  . En réponse à la dépêche Des nouvelles de GNOME à l’occasion de la 3.26. Évalué à 3.

    Indubitablement disruptif, en effet.

  • [^] # Re: C-l

    Posté par  . En réponse au journal Bash et les raccourcis clavier. Évalué à 3.

    L'avantage de la commande clear est quand qu'on peut la mettre dans un script…

  • [^] # Re: ASCII

    Posté par  . En réponse au journal Bash et les raccourcis clavier. Évalué à 8. Dernière modification le 21 septembre 2017 à 09:47.

    Tout-à-fait :) Et cela a même deux autres avantages supplémentaires :

    — Ça permet de saisir une tabulation dans une chaîne, utile par exemple pour les regexps filtrant les blancs et ne disposant pas de classes dédiés : grep "[^V^I ]\+ (ou ^V^I correspond à la saisie de Ctrl+V Ctrl+I et est traduit à l'écran par une belle tabulation (un blanc de plusieurs caractères), suivi d'un(e) vrai(e) espace ;
    – En faisant Ctrl+V Ctrl+O; ça permet de récupérer le jeu de caractères normal quand on a fait un cat d'un fichier binaire à l'écran et que l'affichage est sans dessus dessous. Bien sûr, il existe reset mais ça permet d'éviter de lancer une commande rien que pour ça et également de s'en sortir quand celle-ci n'est pas disponible (et en plus, c'est plus rapide).

    Là encore, pour l'anecdote, Ctrl+N et Ctrl+O correspondent aux codes 14 et 15 (0x0e et 0x0ef), soit respectivement « SO: Shift Out » et « SI : Shift In ». Et ces codes servaient à décaler le ruban d'impression, comme sur les machines à écrire, pour changer de couleur.

    Sur les terminaux à écran, c'est devenu « C0 » et » C1 » (Zero et Un) mais c'est sympa parce que les glyphes correspondent : SO↔C0 et SI↔C1.

    Au passage, C1 est censé contenir des caractères spéciaux et notamment graphiques (principalement pour faire des bordures), donc le Vidéotex a eu la bonne idée d'utiliser les mêmes codes pour passer du jeu alphanumérique au semi-graphique (les gros pixels sur le Minitel) et réciproquement. Et Ctrl+V servait aussi à introduire un caractère, mais qui servait à accentuer la minuscule qui suivait (ce qui donnait des séquences de 3 caractères pour les caractères spéciaux contre 1 en temps normal, un peu comme en UTF-8).

    Et par conséquent, pour les masochistes, Ctrl+V Ctrl+N permet donc de faire volontairement foirer son terminal. :)

    Bon, ÉVIDEMMENT, ça ne marche plus non plus sous gnome-shell, que ce soit avec le Xterm ou le gnome-terminal (je suppose qu'ils en ont profité pour empêcher également les terminaux de passer accidentellement dans l'autre jeu) mais l'insertion d'une tabulation fonctionne toujours et le tout est toujours valables avec les consoles virtuelles Linux en mode texte.

  • [^] # Re: Et l'indispensable C-o (ou Ctrl+o)

    Posté par  . En réponse au journal Bash et les raccourcis clavier. Évalué à 2.

    T'es sûr que c'est pas plutôt Ctrl+\ (qui se trouve sur la même touche que _ sur un clavier AZERTY) et qui permet par défaut d'envoyer un SIGQUIT ?

  • # ASCII

    Posté par  . En réponse au journal Bash et les raccourcis clavier. Évalué à 10. Dernière modification le 20 septembre 2017 à 17:32.

    Pour exécuter une commande que vous venez de taper, pressez: C-m: Retour charriot

    Il existe un raccourci pour envoyer le caractère EOF (End Of File): C-d.

    Il est possible de supprimer un caractère avant ou après le curseur avec les raccourcis:
    C-d: Supprimer le caractère qui se trouve après le curseur

    On note que ça fait double-emploi…

    Faire appel à l'auto-complétion de Bash peut se faire avec le raccourci: C-i: Équivalant à la touche TAB

    Il est possible de manipuler ce que montre Bash à l'écran avec ces trois raccourcis:

    C-l: Nettoie l'écran, pour ne montrer qu'une invite de commande vide. Similaire à la commande clear.
    C-s: Stop l'affichage. Très utile quand un programme très verbeux s'exécute.
    C-q Reprend l'affichage stoppé avec C-s.

    Ça vaut le coup de rappeler que tous les « raccourcis » ci-dessus, même si certains d'entre eux restent interceptés par le shell, ne sont pas des combinaisons choisies arbitrairement par lui, mais font partie à la base du code ASCII.

    Il est utile de rappeler également que la touche « Ctrl » n'est pas une simple meta-key comme Alt, mais sert en principe à émettre les codes de contrôle de la table ASCII (soit les codes 0 à 31 en début de table), codes qui étaient le seul moyen de piloter les appareils et terminaux lorsqu'il étaient reliés à leur hôte à l'aide d'une ligne série. Donc saisir Ctrl+A, Ctrl+B, Ctrl+C… jusqu'à Ctrl+Z, permet d'émettre les codes 1 à 26.

    C'est aussi pour cela que Escape est placé juste après cette gamme, sur le code 27. ESC étant justement le code permettant de s'échapper du flux ASCII standard et d'annoncer une séquence hors-protocole, ce qui permet de passer la main à n'importe quel standard.

    Et c'est pour cela encore qu'on trouve la touche sur pratiquement tous les ordinateurs et terminaux depuis les années 1960. Elle est donc réellement censée émettre un caractère à chaque fois qu'on la combine avec une lettre, et pas n'importe lequel : le code de 1 à 26, soit 0x01 à 0x1a en hexadécimal. Donc, on doit pouvoir capter la saisie de ce caractère avec un simple fgetc() ou équivalent (sauf s'il est intercepté entre les deux par une sous-fonction du shell ou autre). Essayez avec stty -icanon ; od -tx1 -vw1, par exemple. C'est totalement différent de « Alt » par exemple, qui à ma connaissance est spécifique à l'IBM PC (même si d'autres machines ont des meta-key similaires depuis longtemps) et qui n'est pas du tout tenue d'émettre quoi que ce soit (ce qui rendait d'ailleurs son exploitation compliqué quand on écrivait ses premiers programmes en BASIC).

    Du coup :
    - Ctrl+I : Neuvième lettre, 09 ou 0x09 → « HT Horizontal tabulation », donc le code ASCII d'une tabulation. C'est donc normal qu'elles émettent le même code. Essayez avec la commande ci-dessus pour vous en convaincre…

    • Ctrl+M : Treizième lettre, 13 ou 0x0d → « CR Carriage Return », code de retour en début de ligne.

    • Ctrl+L : Douzième lettre, 12 ou 0x0c → « FF Form Feed », soit littéralement : « alimentation en papier (ou même "en formulaire") ». C'est en principe à l'usage des imprimantes et cela sert à leur commander d'aspirer une feuille et de présenter le haut de la page devant la tête d'impression pour commencer à écrire dessus. Et évidemment, s'il y a déjà une feuille en cours de traitement, celle-ci est éjectée (laissant donc le reste vide) pour avancer directement à la suivante, ce qui correspond donc à un saut de page. Et sur les terminaux dont le système d'impression a été remplacé par un écran, ça revient donc à effacer la page et à replacer le curseur en haut à gauche.

    Ça marche normalement sur toute imprimante qui se respecte, mais à condition que ce soit une matricielle (continue ou feuille à feuille) ou à la limite une jet d'encre, qui peuvent encore fonctionner en mode texte même si les pilotes le font de moins en moins, mais pas les laser dont le mode de fonctionnement (dépôt de poudre sur la feuille puis passage au four) leur impose de traiter toute la feuille en une seule opération, sauf si elles peuvent bufferiser le texte jusqu'au moment où il faut éjecter la page, soit une page pleine ou justement un code 12 «FF».

    Côté écrans, ça marchait sur de nombreux huit bits, et notamment sur tout ce qui était Vidéotex, donc sur les Minitel et sur les 8 bits Thomson (MO6, TO8, etc.). C'était aussi plus pratique qu'un « CLS » pour avoir un écran vraiment propre et éviter le « OK » associé à la commande. Évidemment, l'une des exceptions est justement les DEC ANSI :-( Standard suivi par la console des PC, que ce soit DOS ou les consoles virtuelles de Linux, et par les XTerm. Par contre, le shell a conservé cette fonctionnalité et l'émule proprement (même si c'est lui qui le fait) et c'est pour cela qu'il en profite pour ré-afficher l'invite de commande.

    • Ctrl+S Ctrl+Q : Ce sont en fait directement les codes de XON et XOFF qui sont les codes dédiés au contrôle de flux lorsque la ligne n'est pas équipé de signaux physique pour le faire (comme RTS et CTS sur RS/232). Ce n'était pas directement ASCII mais presque : la page wikipédia indique que ça a été introduit par le Teletype Model 33 en 1963, c'est-à-dire l'année de publication de la première version du standard ASCII, et ces codes sont mappés sur DC1 et DC3, sachant qu'il y a quatre code DC1 à DC4 dans ASCII et que DC signifie « Device Control ». Ce sont donc des codes génériques permettant de piloter des fonctionnalités spécifiques à chaque appareil.

    Là encore, les terminaux et les premiers ordinateurs personnels fonctionnaient uniquement en mode texte, donc interrompre le flux en provenance du serveur permettait de suspendre le défilement à l'écran (c'était aussi pratique pour les imprimantes qui n'arrivaient pas forcément à suivre) et Linux mappe ça en principe, sur ses consoles virtuelles (pas sous X-Window) avec la touche Pause du PC et sa LED associée, touche qui sert initialement à ça même sur PC (apparu en 1981, pas dans les années 60). Bon, évidemment, je viens d'essayer avec une Fedora 25. Ctrl+S Ctrl-Q fonctionnent toujours mais plus la touche Pause. Bon.

    • Ctrl+D enfin, correspond à « EOT End of Transmission », ce qui est bien pratique pour dire « j'ai fini de parler », surtout sur les lignes half duplex. Du coup, sur un terminal, ça sert surtout à envoyer ce que l'on vient de saisir SANS appuyer sur Return et donc embarquer un retour chariot avec le reste. Ce n'est pas, à la base, directement un raccourci pour « exit », mais saisir Ctrl+D seul permet d'envoyer une charge utile de zéro caractère, ce qui est en soi reconnu par read() comme le signal d'une fin de connexion et de la refermeture du canal. Cela va donc provoquer un EOF exactement comme la fin d'un fichier qui aurait été atteinte si ce fichier avait été redirigé vers l'entrée standard du processus avec « < ». Le shell se termine donc normalement (en le détectant) mais ça fonctionne en fait avec tout processus à l'avant plan et fait pour gérer normalement l'entrée standard. Essayez avec cat par exemple.
  • [^] # Re: Raccourcis bash = raccourcis emacs ou vi

    Posté par  . En réponse au journal Bash et les raccourcis clavier. Évalué à 10.

    Purée, il y avait déjà des touches Like et Dislike à droite du clavier :)

  • # Mailings lists

    Posté par  . En réponse au message serveur et mailing list. Évalué à 4. Dernière modification le 03 septembre 2017 à 17:36.

    Bonjour,

    Ce n'est pas forcément très compliqué mais, comme dit ci-dessus, c'est un peu surdimensionné pour tes besoins et surtout, ça demande de mettre en place toute l'infrastructure sous-jacente, c'est-à-dire s'assurer d'avoir une liaison permanente à Internet, prévoir les backups et l'alimentation électrique (qui revient cher quand on la rapporte à une année) et administrer le serveur proprement dit au quotidien (ou presque).

    Donc, beaucoup de boulot pour pas grand chose si ce n'est pas par volonté personnelle. Et le problème serait identique avec n'importe quel autre système (à commencer par Windows).

    A contrario, si c'est pour toi un bon prétexte pour pratiquer le système et te lancer dans l'administration Linux, tu peux jeter un œil à GNU Mailman ou à Sympa.

    On voit souvent aussi le (vieux) Majordomo, mais il semblerait qu'il ne soit pas libre et je n'arrive pas à trouver sa licence.

  • [^] # Re: Lien utile

    Posté par  . En réponse au journal Linky et filtre cpl. Évalué à 3.

    Et s’il invoquait Belzébuth ?

    Rien que pour ça, je suis sûr que plein de gens serait prêts à l'adopter. :-)

  • [^] # Re: Lien utile

    Posté par  . En réponse au journal Linky et filtre cpl. Évalué à 8.

    Stoppez les rotatives ! dark_star aime s'occuper quand il s'ennuie en regardant l'intensité consommée chez lui, des fois qu'un truc ait décidé subitement de tirer 10A alors qu'avant c'était 100mA.

    Et bien ça, tu vois, tu devrais le faire de temps en temps. Je me suis aperçu un jour, comme ça, qu'après le passage d'électriciens dans un appartement dans lequel je venais d'emménager, j'avais une consommation en continu de 8 ampères. Ces branques avaient bypassé le contacteur jour-nuit de mon ballon d'eau chaude de 1800 W, qui fonctionnait alors 24h/24.

    Après m'être plaint et avoir reçu un coup de fil de l'entreprise concernée, resté depuis sans suite, j'ai fini par refaire le câblage moi-même.

  • # Re : Récuperer un Mot de passe Root

    Posté par  . En réponse au message Récuperer un Mot de passe Root. Évalué à 2.

    Bonjour et bienvenue,

    1) Impossible à dire de manière universelle : ça dépend du snapshot, qui va par nature remettre en place le système tel qu'il a été installé par le précédent stagiaire.

    2) Oui, c'est possible. J'ose tout de même espérer que si la machine « s'éteint pour une raison ou un autre », alors son comportement lorsque tu la rallumeras sera le même que la première fois que tu l'as mise en service.

    Malgré cela, avec Linux comme avec tous les autres systèmes, pour réinitialiser un mot de passe root, on accède au disque et/ou à la partition qui recèle les comptes utilisateurs depuis UN AUTRE système fonctionnel, qui lui exploite ce disque comme un volume ordinaire et peut donc le modifier à loisir.

    Il arrive assez fréquemment qu'on trimballe une distribution de Linux en LiveCD (ex: Knoppix) pour aller dépanner une machine Windows, par exemple.

  • [^] # Re: Faut dire qu'il n'a pas rédigé grand chose

    Posté par  . En réponse au message Linux est en santé!. Évalué à 3.

    Blague à part, merci à tous parce qu'il serait vraiment important de faire un papier solide sur cette version. Linus indique que c'est la plus grosse release qui soit après la 4.9, et la 4.9 l'est en partie parce que c'est une LTS.

    J'ai pris l'initiative d'entamer la dépêche juste après la rc2, il y a un mois et demi, pour éviter de faire comme avec la dépêche du 4.10 publiée exactement le jour de la sortie du 4.11, et parce qu'apparemment, ça manquait de traducteurs. D'habitude, je me contente de traduire les annonces des RC parce qu'elles restent souvent en plan (et que parfois, on y lit des âneries). Mais là, ça va faire deux mois et on n'a pas encore une ligne sur le contenu proprement dit.

    Pourtant il y a beaucoup à en dire : l'AMD Vega, l'intel IPU l'annonce sur les diff générés automatiquement par kernel.org et qui ne seront plus signés de la clé de Linus, le pilote de l'Image Processing Unit des Intel Atom, etc et les gros headers splités dans la dernière version du noyau (qui empêchent entre autre le pilote proprio nVidia de compiler).