Malheureusement, la prestation de code, ça ne marche que très rarement surtout qu'à moins d'être vraiment une toute petite structure, il y a toujours un geek quelque part qui est capable d'écrire ce genre de script dans le cadre de ses heures et qui est beaucoup plus au fait des nécessités de sa boîte (surtout que ce sont généralement les siennes aussi).
J'ai connu l'affaire aussi au début des années 2000. Je travaillais dans un centre de recherche semi-indépendant et qui avait besoin d'un depuis longtemps (une vraie arlésienne) et le patron avait confié la chose à une boîte canadienne pour le développer.
Moralité, un soft toujours pas sorti des années plus tard et une facture tenue confidentielle mais qu'un collègue avait réussi à estimer en millions de dollars. Au point ou on en était, on ne disposait que d'une interface (client Windows natif) qui permettait de nourrir une base de données… sans pouvoir la lire en retour. Celle-ci était formée d'une boîte de dialogue de taille fixe truffée de champs de saisie et de boîtes déroulantes. Entre autres tares, j'ai suggéré à un collège de faire [TAB]… [TAB]… [TAB]… pour voir comment on passait d'un champ à l'autre au clavier, sachant que cette interface devait être utilisée intensivement dans les laboratoires pour entrer les résultats de recherche. Et sans surprise, on voyait le focus partir dans tous les sens. L'interface proprement dite avait là encore dû être confiée à un stagiaire débutant (j'ai connu plusieurs stagiaires qui étaient plus compétents que les titulaires qu'ils épaulaient), qui avait dû utiliser l'interface de composition de Visual Basic et décorer bien gentiment son panneau avec ses contrôles, sans même être conscient de l'existence de la propriété « index ».
Toujours au même endroit, quelques années plus tard, un type qui faisait de la bioinfo devait reverse-complémenter une séquence de paires de bases génétiques (remplacer un A par T, un C par un G, et vice-versa, puis retourner la séquence en la lisant de droite à gauche) enregistrée en ASCII dans un fichier de 3Mo.
Le gars avait fini par me demander de l'aide parce que son programme n'avait toujours pas fini après… 2 heures de calcul ! Il avait écrit un script en Perl (encore à la mode à l'époque), il chargeait son fichier dans une grande chaîne de caractères et utilisait chomp pour grignoter le dernier caractère, le complémenter et l'ajouter à la chaîne de sortie.
Pour le fun, étant donné que la tâche à réaliser était excessivement simple, je me suis amusé à l'optimiser à outrance également, en y consacrant une petite heure. J'avais utilisé mmap() pour projeter son fichier en mémoire en laissant toute latitude au système pour charger tout cela de la façon la plus efficace possible et j'avais écrit le cœur de la boucle en utilisant xlat sur x86 (c'était surtout un prétexte pour le faire. En plus, je n'avais pas envie de me faire suer à savoir si et dans quelles conditions le compilateur aurait pu faire mieux).
On est passé de plus de 2 heures à… 2 dixièmes de secondes ! :-)
Certes, ce n'était pas très difficile, mais je pense que c'est le plus grand gain que j'obtiendrai jamais.
Il ne s'agit pas de se « restreindre », mais bien d'agir en connaissance de cause, surtout que LIMIT est aussi utile que répandu, mais que si l'on en croit ce tableau, cette fonctionnalité serait prise en charge sur un grand nombre de SGBD mais à l'exception notable de poids lourds comme Oracle ou MS SQL.
Du coup, si ça nous a toujours paru naturel de l'utiliser et qu'on a appris le SQL avec, on va vers certaines déconvenues.
À l'inverse, on n'est plus obligé non plus de s'en tenir à SQL92. On peut aujourd'hui choisir de reconnaître SQL 2003 (même s'il y a eu 2008, 2011 et 2016 depuis) et profiter des fenêtres WINDOW, et même des requêtes récursives qui sont définies depuis 1999 et avec lesquelles j'ai implémenté le forum du site de mon quartier.
Si l'importance du bug est bien relayée aux mainteneurs successifs, on a des chances de le voir arriver dans les prochaines rc. Peut-être pas la rc2 à venir demain soir mais encore que… les gens sont invités pendant cette période à tester intensivement le noyau et c'est le genre de correctif qu'on aime voir arriver assez vite. Surtout qu'étant très concis, il peut se permettre d'être examiné rapidement.
Donc, j'imagine qu'il va d'abord être publié avec le noyau 4.15, puis rétroporté. Les règles disent que le patch doit se trouver dans la branche de Linus pour pouvoir être ajouté à -stable, mais ne précisent pas si un noyau officiel doit être sorti ou si les -rc suffisent (sachant qu'elles servent à cela).
Autre ambiguïté : il y a aussi les règles de soumissions des patches à la branche -stable, mais impossible de savoir si cela doit être fait à l'initiative du développeur, si ces règles ne s'adressent qu'aux mainteneurs, ou si c'est ouvert aux deux. Elles précisent aussi que le patch concerné — ou un patch équivalent – doit se trouver dans la branche principale. C'est évidemment utile quand on veut rajouter un correctif au noyaux LTS et il se trouve que le dernier en date (4.14) en est un ! Mais évidemment, on peut faire des rétroportages sur de très anciens noyaux (branche 3.x par exemple) et dans ce cas, il se peut que les patches à appliquer pour corriger la même chose soient très différents.
Tout cela pour dire que c'est bon pour le noyau 4.15 à sortir le mois prochain, mais impossible de dire s'il va être automatiquement rétroporté.
Après un long git clone (le noyau, c'est beaucoup), on peut voir que le bug est toujours présent dans le dernier noyau.
On fait donc un patch de la ligne err = -EFAULT; pour la changer en return -EFAULT;… Et il n'y a plus qu'à préparer le tout.
Juste une petite précision, parce cette page est effectivement un point d'entrée mais qu'elle ne contient pas moins de 800 arborescences, chacune contenant au moins une branche, souvent plusieurs.
D'abord la branche de Linus, qui recèle le noyau tel qu'il sera effectivement publié à la fin est « kernel/git/torvalds/linux.git ». C'est utile de le savoir parce qu'elle n'arrive qu'en 693 position sur 800 et que de nombreuses autres arborescences, dans les répertoires de leurs propriétaires respectifs, s'appellent également linux.git.
Ensuite, toutes ces branches sont faites pour être mergées, donc in fine être intégrées dans l'arborescence principale, et elles-mêmes s'appuient sur l'existant, donc sont toujours un fork de cette même lignée au départ. Cela veut dire que si on suit une arborescence spécifique et que l'on remonte une de ses branches, on va toujours retomber tôt ou tard sur le noyau officiel. Donc, si on clone dans un dépôt local vide la branche citée ci-dessus, on télécharge en fait le noyau entier jusqu'au moment où la branche a forké pour la dernière fois, c'est-à-dire généralement à la dernière version du noyau, en gros. Et si on est sûr d'avoir la branche au complet, il nous manque justement les dernières modifications apportées au noyau officiel, alors qu'on a téléchargé le reste de l'historique jusqu'à 2005 pratiquement pour rien.
C'est important aussi parce que si on clone indépendamment plusieurs dépôts de la même façon, on va se retrouver à chaque fois avec un répertoire de 3 Go par arborescence. Et il se trouve que tous ces dépôts vont en fait contenir à 90% la même chose.
Ça va être le cas en particulier avec linux-next, qui est la branche de travail à suivre dès lors qu'on veut faire des contributions au noyau sur la durée. Ça l'est encore plus quand on débute avec Git et qu'on a l'habitude de faire git pull pour rapatrier le contenu d'une branche distante. Ça se passe toujours bien avec la branche de Linus, mais c'est une autre affaire avec linux-next qui est reconstruite à intervalles réguliers. Quand on a recloné le dépôt deux ou trois fois en re-téléchargeant à chaque fois 3 Go de données, on apprend vite à faire autrement. :)
Le mieux à faire est donc de cloner à la base la branche de Linus, et d'utiliser git remote add pour ajouter des références vers des dépôts distants à notre dépôt local. La base d'objet étant commune, seul ce qui n'a pas déjà été rapatrié le sera lors d'une mise à jour des branches. La bonne idée étant donc d'ajouter linux-next et les arborescences des sous-systèmes qui nous intéressent. Cela évite également de créer automatiquement une branche locale associée si ce n'est pas nécessaire (cas de linux-next).
Ensuite, il suffit de faire git remote update pour mettre à jour toutes les branches d'un coup et sans impacter les branches locale.
6755fd269d5c1 (Tudor-Dan Ambarus 2017-05-30 17:52:48 +0300 963) * This condition is met by the default RNG because it selects a favored
6755fd269d5c1 (Tudor-Dan Ambarus 2017-05-30 17:52:48 +0300 964) * DRBG with a security strength of 256.
6755fd269d5c1 (Tudor-Dan Ambarus 2017-05-30 17:52:48 +0300 965) */
6755fd269d5c1 (Tudor-Dan Ambarus 2017-05-30 17:52:48 +0300 966) if (crypto_get_default_rng())
6755fd269d5c1 (Tudor-Dan Ambarus 2017-05-30 17:52:48 +0300 967) err = -EFAULT;
6755fd269d5c1 (Tudor-Dan Ambarus 2017-05-30 17:52:48 +0300 968)
6755fd269d5c1 (Tudor-Dan Ambarus 2017-05-30 17:52:48 +0300 969) err = crypto_rng_get_bytes(crypto_default_rng, (u8 *)priv, nbytes);
6755fd269d5c1 (Tudor-Dan Ambarus 2017-05-30 17:52:48 +0300 970) crypto_put_default_rng();
6755fd269d5c1 (Tudor-Dan Ambarus 2017-05-30 17:52:48 +0300 971) if (err)
6755fd269d5c1 (Tudor-Dan Ambarus 2017-05-30 17:52:48 +0300 972) return err;
… et :
git log --format='%h %an %ad %s' ecc.c
6755fd269d5c Tudor-Dan Ambarus Tue May 30 17:52:48 2017 +0300 crypto: ecdh - add privkey generation support
7380c56d2fca Tudor-Dan Ambarus Tue May 30 15:37:56 2017 +0300 crypto: ecc - rename ecdh_make_pub_key()
ad269597107e Tudor-Dan Ambarus Thu May 25 10:18:05 2017 +0300 crypto: ecc - remove unnecessary casts
099054d735a5 Tudor-Dan Ambarus Thu May 25 10:18:04 2017 +0300 crypto: ecc - remove unused function arguments
8f44df154de7 Stephen Rothwell Fri Jun 24 16:20:22 2016 +1000 crypto: ecdh - make ecdh_shared_secret unique
3c4b23901a0c Salvatore Benedetto Wed Jun 22 17:49:15 2016 +0100 crypto: ecdh - Add ECDH software support
(END)
Donc, le fichier incriminé a été créé en 2016 et n'a fait l'objet que de six patches en tout, donc les quatre derniers au printemps dernier. La ligne fautive se trouve dans le tout dernier patch, qui lui même ne modifie pas l'existant mais déclare de nouvelles fonctions, qui n'ont donc encore jamais été amendées jusqu'ici.
C'est donc un authentique bug qui a passé tous les filtres jusqu'à présent.
Absolument, et cela est même très codifié. On peut lire tout cela dans le Kernel Development Process, que l'on trouve également au format texte (et maintenant *.rst) sous Documentation/process dans l'arborescence des sources du noyau.
Le texte commence à avoir de l'âge mais on y lit notamment :
Once a stable release is made, its ongoing maintenance is passed off to the
"stable team," currently consisting of Greg Kroah-Hartman. The stable team
will release occasional updates to the stable release using the 2.6.x.y
numbering scheme. To be considered for an update release, a patch must (1)
fix a significant bug, and (2) already be merged into the mainline for the
next development kernel.
Soit littéralement :
Une fois la version stable publiée, son entretien est transmis à l'équipe « stable », actuellement formée d'un [seul] membre : Greg Kroah-Hartman. L'équipe stable publiera des mises à jour occasionnelles de la branche stable en utilisant la numérotation 2.6.x.y [aujourd'hui 4.x.y]. Pour envisager son intégration dans une mise à jour, un patch doit (1) corriger un bug non négligeable, et (2) avoir déjà été intégré dans la branche principale du développement du prochain noyau.
Donc, concrètement, ça veut dire que quoi qu'il se passe, ton patch doit suivre la procédure normale, en passant par la branche de développement linux-next, pour vérifier entre autre qu'il compile bien et qu'il ne provoque pas d'autres régressions (ce qui serait un comble). Et cela signifie aussi qu'il doit d'abord inclus dans le noyau courant avant d'être backporté aux mises à jour des versions précédentes. On n'y pense pas mais ça tombe effectivement sous le sens une fois qu'on le dit : ce serait idiot de corriger un bug dans la version qui vient de sortir pour voir réapparaître le bug dans le noyau suivant…
Tout cela est important parce que la phase d'intégration (de nouveautés ou autres) ne dure que deux semaines à chaque fois, suivies de SEPT semaines environ de phase de stabilisation : les fameuses -rc1 à -rc7 (le plus souvent car pour 4.14, on a eu une -rc8), chaque rc (release candidate) étant publiée par Linus le dimanche soir. Et quand on regarde l'arbre Git ainsi que les notes de publication sur la LKML, que l'on peut retrouver par exemple dans l'actuelle dépêche sur la sortie du noyau 4.14 en cours de rédaction, on s'aperçoit que nombreux sont les gens à soumettre des patches, voire des lignées entières de soumissions « urgent-pour-linus » le vendredi soir de la dernière semaine, ce qui a généralement le don de mettre le chef de mauvaise humeur. :)
Tout cela pour dire que c'est cuit pour le 4.14 proprement dit, mais qu'on a de bonnes chances de le voir apparaître dans le 4.14.1 ou .2 dans les prochaines semaines, avant d'attendre la stabilisation du 4.15, sachant qu'un kernel panicdoit être considéré comme un bug non négligeable. :)
Je contribue beaucoup aussi et heureusement, je ne passe pas mon temps à reprendre les gens sur l'orthographe (et heureusement, parce que c'est un océan qui serait devant moi). Nous avons la chance d'être relativement bien lotis sur DLFP. Mais dans le cas présent, la faute réapparaît tout au long du fil, et est assez fréquente en règle générale.
C'est important aussi parce que « suffire » est l'un des rares (peut-être même le seul ?) verbes du TROISIÈME groupe (parce qu'il finit par un E) à se conjuguer au passé comme un verbe du deuxième.
Merci du partage (qui est un peu l'âme du site) mais juste pour info, ici, tu ne résous pas du tout ton problème initial. Au contraire, tu te limites ici à ce qui se trouve dans ton répertoire « source » SANS descendre dans ses sous-répertoires, ce qui est justement le problème qui t'amène ici.
Le problème principal est que, contrairement à d'autres commandes, « mv » ne va pas créer le sous-répertoire parent s'il n'existe pas à l'avance. Tu pourrais tout faire tenir en une seule commande find mais il faudrait pour cela tester l'existence du sous-répertoire (avec test ou avec les opérateurs de bash, le créer le cas échéant avec mkdir -p (-p pour créer les sous-répertoires parents si nécessaire) et enfin, y copier ton fichier.
Mais il y a plus rapide : « cp -R » permet de COPIER récursivement une ou plusieurs sources vers une destination donnée et par conséquent, les sous-répertoires et toute l'arborescence. Donc, si ton répertoire initial n'est pas trop lourd, je le copierais en entier avec cette commande puis j'utiliserais ensuite find pour supprimer toutes les copies des fichiers âgés de MOINS d'une semaine.
Plutôt que les supprimer directement, je les déplacerais dans un répertoire temporaire pour éviter tout accident puis, une fois m'être assuré de son contenu, je supprimerais le répertoire temporaire en question.
Enfin, si l'opération que tu comptes faire est régulière, alors tu peux te permettre de saisir directement la commande que tu cites sans même utiliser « maxdepth » puisque tu sais que les sous-répertoires de destination existeront déjà.
Et en bonus : si tu comptes mettre en place une copie de l'arborescence vide (c'est-à-dire juste les sous-répertoires sans les fichiers) justement pour l'exploiter de cette façon, tu peux utiliser l'option « -type d » de find pour lui demander de trouver tous les répertoires.
J'adorais le Linux Distribution Chooser de ZeGenieStudios qui était assez pertinent et qui avait le bon goût de poser des questions à la fois simples et en français mais, malheureusement, il semble qu'il n'existe plus. :-(
« Intel Premium » ? Je ne vois pas.
Sinon, avant toute chose, quel âge a ton PC et quelles sont ses caractéristiques ? Si c'est une machine contemporaine, tu pourras envisager toutes les distributions avant d'en choisir une, mais si c'est un ordinateur hors d'âge, il faudra t'orienter vers des distributions spécialement conçues pour.
Mais l'envie de jouer avec des pilotes est malgré tout assez forte :p
En fait, sans surprise, je me reconnais beaucoup de mon parcours de développeur dans tes propos, et effectivement, avoir un bon prétexte pour étudier une certaine partie d'une technologie, est généralement le meilleur moyen de s'y mettre, tant au niveau de la motivation que du support de travail.
Quant à la maintenance, le code à déjà au moins 2 ans, mais cumule à la fois les défauts de jeunesse et une dette technique impressionnante.
Pourtant, deux ans, ce n'est pas grand chose. :)
Faire du vrai nettoyage, voire du refactoring, et même in fine un plan de transition douce d'une techno à l'autre sans interruption de service sont des projets extrêmement intéressants en eux-mêmes, surtout avec des outils comme Git (une fois qu'on le maîtrise bien). À condition d'arriver à le faire admettre, comme on en parlait ailleurs. C'est toujours pénible quand on a un chef qui nous dit qu'on a pas le temps de tout ré-écrire quand on est face à une bouse infâme et qui donne ensuite l'ordre exact inverse une fois qu'on a fini d'appréhender la chose.
Enfin, on m'a un peu expliquer les antécédents donc je peux comprendre, mais je n'ai pas trop envie de travailler avec un code aussi inutilement complexe, sachant qu'en plus je vais être le seul à intervenir dessus, théoriquement.
Que tu le nettoies ou que tu le refasses entièrement, profites-en pour le documenter. C'est une bonne occasion de le faire parce que tu ne seras pas poussé aux fesses pour sortir en temps et en heure un produit qui n'existe pas encore. Et tant qu'à faire, essaie de faire quelque chose qui soit auto-généré, donc soit du Doxygen, soit une page de référence interactive à la manière de celle d'Apache.
Je le dis d'expérience parce que pour avoir travaillé sur un gros projet interne à une compagnie, il m'a fallu beaucoup de temps pour m'approprier la chose et une fois cela fait, je n'avais plus le temps de documenter mes propres contributions. Pourtant, le leader initial du projet a eu le bon goût (parce qu'on lui a demandé) d'écrire un gros document dans un traitement de texte (écrit comme un livre, donc) pour présenter la chose. C'était bien, mais c'était assez rébarbatif à lire, c'était un cours presque déjà obsolète étant donné la rapidité des cycles de développement, et surtout : ce n'était de fait pas un « manuel », quelque chose qu'on pourrait directement ouvrir à la bonne page quand on travaille sur un point particulier du projet.
Bon, comme on l'a dit, on développe un pilote pour un produit dès lors que ce produit réalise à sa manière une tâche qui est déjà connue et identifiée dans ses grandes lignes par l'utilisateur et/ou le système d'exploitation. Par exemple, si l'une de tes cartes était une imprimante, ça vaudrait le coup de l'associer à l'existant pour pouvoir automatiquement profiter des facilités de composition et de mise en page.
Accessoirement, toutes les fonctionnalités sont dans un seul binaire, très difficile à maintenir, raison pour laquelle je me suis dit que déplacer le code lié au hard dans des pilotes serait une piste intéressante, pour débloater un peu le bouzin (qui n'est, bien sûr, absolument pas documenté).
Ça reste une bonne idée en soi. C'est juste que ces modules ne seraient pas forcément des pilotes.
Tu peux déjà faire un distingo entre le côté matériel, de bas niveau, et le haut de la pile, c'est-à-dire son exploitation par l'utilisateur. Comment fonctionne globalement cette application à l'écran ? Est-ce qu'il y a juste un menu du style « 1. … 2. … 3. … 4. … 5. … » qui se contente de basculer vers une application distincte à chaque fois, ou est-ce que l'on a, par exemple, un tableau de bord qui serait toujours présent ?
Tu peux aussi t'inspirer d'OBD2 (le protocole de la prise diagnostic des voitures) qui, d'un côté, spécifie le protocole lui-même et, de l'autre, une quantité impressionnante de codes produits et des réponses qu'ils peuvent envoyer, sachant que chaque véhicule n'implémente qu'un petit sous-ensemble de cette liste (correspondant aux équipements réellement embarqués dans le véhicule). Et ensuite, tu regardes si, à chaque fois, tu peux inscrire une carte donnée dans ce cadre.
M'enfin cela ne reste que des pistes de réflexion. Il n'y a rien de pire qu'un standard écrit à l'arrache au départ et qu'il faut ensuite maintenir par compatibilité pendant des décennies (sans exagérer).
Normalement, le C doit reproduire fidèlement ce qui se trouve entre deux guillemets " " dans ton programme. Si ça ne fonctionne pas, c'est que soit tu utilises un compilateur VRAIMENT trop vieux, soit (ce qui est beaucoup plus probable) tu utilises un éditeur de texte qui ne travaille pas en UTF-8 par défaut, voire qui choisit de ne pas le faire pour le type de fichier que tu édites (ici un *.c) parce qu'il est configuré pour utiliser un autre charset par défaut pour ce type de listing.
Du coup, la séquence doit bien être encodée dans ton programme, mais pas en UTF-8, si bien que lorsque ton application la restitue dans un terminal qui, lui, en attend, ça ne donne plus rien.
En fait, l'avantage, c'est 99,9% de la chose passeraient par une simple CSS. Nul besoin de scripts ou d'extensions particulières. Donc aucun ralentissement. Et si l'on veut quand même des animations flashy, CSS3 permet déjà d'en faire énormément avec transition et transform.
Ce qui est bien, c'est que sur DLFP, les utilisateurs sont traditionnellement incités à le faire et il existe des facilités pour mettre facilement en place ses créations avec le lien changer de style, à gauche dans la boîte principale.
Ça se fait avec vBulletin aussi. Un commentaire rapidement modifié ne laisse aucune trace (je ne saurais dire si cela tient compte du fait qu'il y ait ou non des réponses), sinon la date de dernière modification est ajoutée, et cliquer dessus donne accès à l'historique et au différentiel des changements (à la Wikipédia).
Les journaux, ici, sont surtout des « journaux de bord » ou des « journaux intimes (sauf qu'ils ne sont pas intimes) » et se traduisent en anglais par « log », soit en fait « blog » puisqu'ils sont sur le web.
Les journaux sont donc en fait les blogs personnels des membres, sauf que les derniers billets sont référencés par un lien qui se trouve directement dans la barre de haut de page, et cela marche parce que le public de linuxfr.org est en grande partie composé d'habitués de longue date.
De la même façon, les dépêches seraient des « news », mais ici, on est bien sur linux fr.org ;)
Les principales différences sont que d'une part, tout le monde peut participer à la rédaction d'une dépêche, qui généralement rédigée à plusieurs dans l'espace de rédaction alors qu'un blog est privé par nature, et que d'autre part, un journal soumis est immédiatement publié (comme un commentaire), alors qu'une dépêche est soumise à approbation finale de la modération. De fait, les dépêches sont en fait publiées en page d'accueil au nom du site (même si elles sont quand même créditées à leur auteur), alors que les billets de blog, d'un point de vue moral, n'engagent que leur auteur.
Évidemment, d'un point de vue légal, les unes et les autres doivent être modérés de la même façon et, de toutes façons, on rend toujours crédit à l'auteur d'un papier, quel qu'il soit. Mais c'est comparable aux articles d'un journal papier écrits par les membres de sa rédaction, par rapport aux petites annonces qui sont publiées dans ses pages.
Enfin, dans cet esprit, une dépêche se soit d'avoir un intérêt pour tout le lectorat du site, alors qu'un billet de blog journal, lui, peut parler de tout ce qui intéresse son auteur, tant que cela ne devient pas du spam caractérisé et qu'il n'y a pas flood.
Comme il est très difficile de produire en continu des dépêches valides sur l'actualité sur un site communautaire et sans avoir de chroniqueur attitré, alors les journaux sont ici mis en évidence car on a la chance qu'ils soient de bonne qualité par rapport à certains autres sites (et ce, parce que les gens ont l'habitude de les utiliser de longue date). Un billet de blog particulièrement intéressant et bien écrit peut ensuite, éventuellement, être promue en dépêche.
J'ajoute également, comme dit plus haut (et parce que mon commentaire qui a HUIT minutes ne peut plus être édité) que j'ai écrit un site web entier en PHP (+ PostGreSQL) et implémentant un forum organisé en arbre (comme celui de DLFP) avec possibilité d'édition et messages privés.
Ce n'est pas un exploit en soi, mais ça répond à ta question, dans le sens où je l'ai déjà écrit. C'est juste que ce n'est pas en Ruby. :)
J'ai oublié de dire, pour ceux que cela intéresse, qu'on peut aussi soit mettre en ligne soit carrément uploader ce bout de CSS en bas de cette page : https://linuxfr.org/stylesheet/modifier
Il suffit de copier-coller le bloc présenté et de le faire précéder de la déclaration « @import url("//linuxfr.org/assets/application.css"); » présentée sur ladite page.
Mais après si toi tu tiens aux MPs et tu n'as absolument pas envie de montrer une adresse email que d'autres personnes risqueraient de connaître déjà, n'hésite pas à ouvrir un ticket de suivi et/ou à envoyer un patch.
Je fréquente linuxfr.org depuis 1999. J'ai déjà ouvert quelques tickets qui ont fini par être implémentés, dont le [^], évoqué dans un autre commentaire, et qui est en place depuis Templeet.
J'ai contribué en postant une ou deux dépêches, j'ai fait un certain nombre de traductions dans les dépêches noyau, et j'avais proposé les CSS Nightgrey et Springtime en leur temps, toujours sous Templeet (la dernière m'a demandé environ 80 heures de travail, à l'époque. Les CSS éponymes actuelles ne sont pas les mêmes et ont été écrites par d'autres personnes).
Pour le patch MP, tu as tout-à-fait raison en soi et la seule raison pour laquelle ce n'est pas encore proposé, c'est que je ne connais RIEN au Ruby. Il y a des moments où on ne peut plus courir tous les lièvres à la fois. Je suis principalement codeur C, et j'ai pourtant déjà fait pas mal de web.
Par contre, et c'est une vraie question, puisque tu utilises cet argument pour conclure ce fil, peux-tu nous indiquer si tu as déjà toi-même contribué au site (autrement que par les commentaires, ce qui est déjà beaucoup) et si oui, dans quelle mesure ?
# Vécu
Posté par Obsidian . En réponse au journal Optimisez votre code !. Évalué à 9.
Malheureusement, la prestation de code, ça ne marche que très rarement surtout qu'à moins d'être vraiment une toute petite structure, il y a toujours un geek quelque part qui est capable d'écrire ce genre de script dans le cadre de ses heures et qui est beaucoup plus au fait des nécessités de sa boîte (surtout que ce sont généralement les siennes aussi).
J'ai connu l'affaire aussi au début des années 2000. Je travaillais dans un centre de recherche semi-indépendant et qui avait besoin d'un
depuis longtemps (une vraie arlésienne) et le patron avait confié la chose à une boîte canadienne pour le développer.
Moralité, un soft toujours pas sorti des années plus tard et une facture tenue confidentielle mais qu'un collègue avait réussi à estimer en millions de dollars. Au point ou on en était, on ne disposait que d'une interface (client Windows natif) qui permettait de nourrir une base de données… sans pouvoir la lire en retour. Celle-ci était formée d'une boîte de dialogue de taille fixe truffée de champs de saisie et de boîtes déroulantes. Entre autres tares, j'ai suggéré à un collège de faire [TAB]… [TAB]… [TAB]… pour voir comment on passait d'un champ à l'autre au clavier, sachant que cette interface devait être utilisée intensivement dans les laboratoires pour entrer les résultats de recherche. Et sans surprise, on voyait le focus partir dans tous les sens. L'interface proprement dite avait là encore dû être confiée à un
stagiairedébutant (j'ai connu plusieurs stagiaires qui étaient plus compétents que les titulaires qu'ils épaulaient), qui avait dû utiliser l'interface de composition de Visual Basic et décorer bien gentiment son panneau avec ses contrôles, sans même être conscient de l'existence de la propriété « index ».Toujours au même endroit, quelques années plus tard, un type qui faisait de la bioinfo devait reverse-complémenter une séquence de paires de bases génétiques (remplacer un A par T, un C par un G, et vice-versa, puis retourner la séquence en la lisant de droite à gauche) enregistrée en ASCII dans un fichier de 3Mo.
Le gars avait fini par me demander de l'aide parce que son programme n'avait toujours pas fini après… 2 heures de calcul ! Il avait écrit un script en Perl (encore à la mode à l'époque), il chargeait son fichier dans une grande chaîne de caractères et utilisait
chomppour grignoter le dernier caractère, le complémenter et l'ajouter à la chaîne de sortie.Pour le fun, étant donné que la tâche à réaliser était excessivement simple, je me suis amusé à l'optimiser à outrance également, en y consacrant une petite heure. J'avais utilisé mmap() pour projeter son fichier en mémoire en laissant toute latitude au système pour charger tout cela de la façon la plus efficace possible et j'avais écrit le cœur de la boucle en utilisant xlat sur x86 (c'était surtout un prétexte pour le faire. En plus, je n'avais pas envie de me faire suer à savoir si et dans quelles conditions le compilateur aurait pu faire mieux).
On est passé de plus de 2 heures à… 2 dixièmes de secondes ! :-)
Certes, ce n'était pas très difficile, mais je pense que c'est le plus grand gain que j'obtiendrai jamais.
[^] # Re: Chacun cherche son film
Posté par Obsidian . En réponse au journal Optimisez votre code !. Évalué à 7.
Il ne s'agit pas de se « restreindre », mais bien d'agir en connaissance de cause, surtout que LIMIT est aussi utile que répandu, mais que si l'on en croit ce tableau, cette fonctionnalité serait prise en charge sur un grand nombre de SGBD mais à l'exception notable de poids lourds comme Oracle ou MS SQL.
Du coup, si ça nous a toujours paru naturel de l'utiliser et qu'on a appris le SQL avec, on va vers certaines déconvenues.
À l'inverse, on n'est plus obligé non plus de s'en tenir à SQL92. On peut aujourd'hui choisir de reconnaître SQL 2003 (même s'il y a eu 2008, 2011 et 2016 depuis) et profiter des fenêtres WINDOW, et même des requêtes récursives qui sont définies depuis 1999 et avec lesquelles j'ai implémenté le forum du site de mon quartier.
[^] # Re: Chacun cherche son film
Posté par Obsidian . En réponse au journal Optimisez votre code !. Évalué à 5.
… et en rappelant également que LIMIT ne fait pas partie de la norme ! ;)
[^] # Re: Passionnant
Posté par Obsidian . En réponse à la dépêche Un nouveau moteur de rendu ultra‐rapide pour Firefox : Quantum Render. Évalué à 3.
Ah non ! Moi je n'ai rien proposé… :)
# Il est arrivé !
Posté par Obsidian . En réponse au journal D'un kernel panic à un patch…. Évalué à 6.
Ça y est ! Le patch est arrivé mercredi dernier dev crypto-dev/master et linux-next/master sous le numéro 4c0e22c90510308433272d7ba281b1eb4eda8209
Si l'importance du bug est bien relayée aux mainteneurs successifs, on a des chances de le voir arriver dans les prochaines rc. Peut-être pas la rc2 à venir demain soir mais encore que… les gens sont invités pendant cette période à tester intensivement le noyau et c'est le genre de correctif qu'on aime voir arriver assez vite. Surtout qu'étant très concis, il peut se permettre d'être examiné rapidement.
Donc, j'imagine qu'il va d'abord être publié avec le noyau 4.15, puis rétroporté. Les règles disent que le patch doit se trouver dans la branche de Linus pour pouvoir être ajouté à -stable, mais ne précisent pas si un noyau officiel doit être sorti ou si les -rc suffisent (sachant qu'elles servent à cela).
Autre ambiguïté : il y a aussi les règles de soumissions des patches à la branche -stable, mais impossible de savoir si cela doit être fait à l'initiative du développeur, si ces règles ne s'adressent qu'aux mainteneurs, ou si c'est ouvert aux deux. Elles précisent aussi que le patch concerné — ou un patch équivalent – doit se trouver dans la branche principale. C'est évidemment utile quand on veut rajouter un correctif au noyaux LTS et il se trouve que le dernier en date (4.14) en est un ! Mais évidemment, on peut faire des rétroportages sur de très anciens noyaux (branche 3.x par exemple) et dans ce cas, il se peut que les patches à appliquer pour corriger la même chose soient très différents.
Tout cela pour dire que c'est bon pour le noyau 4.15 à sortir le mois prochain, mais impossible de dire s'il va être automatiquement rétroporté.
# Mes 2 ¢
Posté par Obsidian . En réponse à la dépêche My name is looker…. Évalué à 6.
En fait, ce n'est pas « Tom's diner » mais « Luka », qui est l'autre (le seul autre ?) grand titre de Suzanne Vega.
Voila, voila, voila.
# Arborescences utiles
Posté par Obsidian . En réponse au journal D'un kernel panic à un patch…. Évalué à 6.
Juste une petite précision, parce cette page est effectivement un point d'entrée mais qu'elle ne contient pas moins de 800 arborescences, chacune contenant au moins une branche, souvent plusieurs.
D'abord la branche de Linus, qui recèle le noyau tel qu'il sera effectivement publié à la fin est «
kernel/git/torvalds/linux.git». C'est utile de le savoir parce qu'elle n'arrive qu'en 693 position sur 800 et que de nombreuses autres arborescences, dans les répertoires de leurs propriétaires respectifs, s'appellent égalementlinux.git.Ensuite, toutes ces branches sont faites pour être mergées, donc in fine être intégrées dans l'arborescence principale, et elles-mêmes s'appuient sur l'existant, donc sont toujours un fork de cette même lignée au départ. Cela veut dire que si on suit une arborescence spécifique et que l'on remonte une de ses branches, on va toujours retomber tôt ou tard sur le noyau officiel. Donc, si on clone dans un dépôt local vide la branche citée ci-dessus, on télécharge en fait le noyau entier jusqu'au moment où la branche a forké pour la dernière fois, c'est-à-dire généralement à la dernière version du noyau, en gros. Et si on est sûr d'avoir la branche au complet, il nous manque justement les dernières modifications apportées au noyau officiel, alors qu'on a téléchargé le reste de l'historique jusqu'à 2005 pratiquement pour rien.
C'est important aussi parce que si on clone indépendamment plusieurs dépôts de la même façon, on va se retrouver à chaque fois avec un répertoire de 3 Go par arborescence. Et il se trouve que tous ces dépôts vont en fait contenir à 90% la même chose.
Ça va être le cas en particulier avec
linux-next, qui est la branche de travail à suivre dès lors qu'on veut faire des contributions au noyau sur la durée. Ça l'est encore plus quand on débute avec Git et qu'on a l'habitude de fairegit pullpour rapatrier le contenu d'une branche distante. Ça se passe toujours bien avec la branche de Linus, mais c'est une autre affaire aveclinux-nextqui est reconstruite à intervalles réguliers. Quand on a recloné le dépôt deux ou trois fois en re-téléchargeant à chaque fois 3 Go de données, on apprend vite à faire autrement. :)Le mieux à faire est donc de cloner à la base la branche de Linus, et d'utiliser
git remote addpour ajouter des références vers des dépôts distants à notre dépôt local. La base d'objet étant commune, seul ce qui n'a pas déjà été rapatrié le sera lors d'une mise à jour des branches. La bonne idée étant donc d'ajouterlinux-nextet les arborescences des sous-systèmes qui nous intéressent. Cela évite également de créer automatiquement une branche locale associée si ce n'est pas nécessaire (cas de linux-next).Ensuite, il suffit de faire
git remote updatepour mettre à jour toutes les branches d'un coup et sans impacter les branches locale.[^] # Re: git ?
Posté par Obsidian . En réponse au journal D'un kernel panic à un patch…. Évalué à 5. Dernière modification le 16 novembre 2017 à 16:52.
Apparemment pas :
git blame ecc.c… et :
git log --format='%h %an %ad %s' ecc.cDonc, le fichier incriminé a été créé en 2016 et n'a fait l'objet que de six patches en tout, donc les quatre derniers au printemps dernier. La ligne fautive se trouve dans le tout dernier patch, qui lui même ne modifie pas l'existant mais déclare de nouvelles fonctions, qui n'ont donc encore jamais été amendées jusqu'ici.
C'est donc un authentique bug qui a passé tous les filtres jusqu'à présent.
[^] # Re: Mauvais timing...
Posté par Obsidian . En réponse au journal D'un kernel panic à un patch…. Évalué à 5. Dernière modification le 15 novembre 2017 à 15:58.
Absolument, et cela est même très codifié. On peut lire tout cela dans le Kernel Development Process, que l'on trouve également au format texte (et maintenant *.rst) sous Documentation/process dans l'arborescence des sources du noyau.
Le texte commence à avoir de l'âge mais on y lit notamment :
Soit littéralement :
Donc, concrètement, ça veut dire que quoi qu'il se passe, ton patch doit suivre la procédure normale, en passant par la branche de développement linux-next, pour vérifier entre autre qu'il compile bien et qu'il ne provoque pas d'autres régressions (ce qui serait un comble). Et cela signifie aussi qu'il doit d'abord inclus dans le noyau courant avant d'être backporté aux mises à jour des versions précédentes. On n'y pense pas mais ça tombe effectivement sous le sens une fois qu'on le dit : ce serait idiot de corriger un bug dans la version qui vient de sortir pour voir réapparaître le bug dans le noyau suivant…
Tout cela est important parce que la phase d'intégration (de nouveautés ou autres) ne dure que deux semaines à chaque fois, suivies de SEPT semaines environ de phase de stabilisation : les fameuses -rc1 à -rc7 (le plus souvent car pour 4.14, on a eu une -rc8), chaque rc (release candidate) étant publiée par Linus le dimanche soir. Et quand on regarde l'arbre Git ainsi que les notes de publication sur la LKML, que l'on peut retrouver par exemple dans l'actuelle dépêche sur la sortie du noyau 4.14 en cours de rédaction, on s'aperçoit que nombreux sont les gens à soumettre des patches, voire des lignées entières de soumissions « urgent-pour-linus » le vendredi soir de la dernière semaine, ce qui a généralement le don de mettre le chef de mauvaise humeur. :)
Tout cela pour dire que c'est cuit pour le 4.14 proprement dit, mais qu'on a de bonnes chances de le voir apparaître dans le 4.14.1 ou .2 dans les prochaines semaines, avant d'attendre la stabilisation du 4.15, sachant qu'un kernel panic doit être considéré comme un bug non négligeable. :)
[^] # Re: Attendre un peu
Posté par Obsidian . En réponse au message Projet Numéro Anti-Harcélement. Évalué à 1.
Je contribue beaucoup aussi et heureusement, je ne passe pas mon temps à reprendre les gens sur l'orthographe (et heureusement, parce que c'est un océan qui serait devant moi). Nous avons la chance d'être relativement bien lotis sur DLFP. Mais dans le cas présent, la faute réapparaît tout au long du fil, et est assez fréquente en règle générale.
C'est important aussi parce que « suffire » est l'un des rares (peut-être même le seul ?) verbes du TROISIÈME groupe (parce qu'il finit par un E) à se conjuguer au passé comme un verbe du deuxième.
[^] # Re: Attendre un peu
Posté par Obsidian . En réponse au message Projet Numéro Anti-Harcélement. Évalué à 2.
Loin de moi l'idée de tout harcèlement mais, de grâce, « ont suffi » sans le T.
Merci.
# Nagios ?
Posté par Obsidian . En réponse au message Gérer ses serveurs facilement sans se brainfuck. Évalué à 4.
Ça fait bien longtemps que je ne l'ai plus fait moi-même, mais un bête Nagios, ça ne suffirait pas ?
[^] # Re: ca ressemble à un exo de TP
Posté par Obsidian . En réponse au message MV de tout les fichiers et sous dossier ayant moins de une semaine. Évalué à 3.
Salut,
Merci du partage (qui est un peu l'âme du site) mais juste pour info, ici, tu ne résous pas du tout ton problème initial. Au contraire, tu te limites ici à ce qui se trouve dans ton répertoire « source » SANS descendre dans ses sous-répertoires, ce qui est justement le problème qui t'amène ici.
Le problème principal est que, contrairement à d'autres commandes, « mv » ne va pas créer le sous-répertoire parent s'il n'existe pas à l'avance. Tu pourrais tout faire tenir en une seule commande
findmais il faudrait pour cela tester l'existence du sous-répertoire (avectestou avec les opérateurs de bash, le créer le cas échéant avecmkdir -p(-p pour créer les sous-répertoires parents si nécessaire) et enfin, y copier ton fichier.Mais il y a plus rapide : « cp -R » permet de COPIER récursivement une ou plusieurs sources vers une destination donnée et par conséquent, les sous-répertoires et toute l'arborescence. Donc, si ton répertoire initial n'est pas trop lourd, je le copierais en entier avec cette commande puis j'utiliserais ensuite find pour supprimer toutes les copies des fichiers âgés de MOINS d'une semaine.
Plutôt que les supprimer directement, je les déplacerais dans un répertoire temporaire pour éviter tout accident puis, une fois m'être assuré de son contenu, je supprimerais le répertoire temporaire en question.
Enfin, si l'opération que tu comptes faire est régulière, alors tu peux te permettre de saisir directement la commande que tu cites sans même utiliser « maxdepth » puisque tu sais que les sous-répertoires de destination existeront déjà.
Et en bonus : si tu comptes mettre en place une copie de l'arborescence vide (c'est-à-dire juste les sous-répertoires sans les fichiers) justement pour l'exploiter de cette façon, tu peux utiliser l'option « -type d » de find pour lui demander de trouver tous les répertoires.
Bon courage.
# Quelle machine ?
Posté par Obsidian . En réponse au message Quelle distribution est la mieux ?. Évalué à 5.
Bonjour et bienvenue,
J'adorais le Linux Distribution Chooser de ZeGenieStudios qui était assez pertinent et qui avait le bon goût de poser des questions à la fois simples et en français mais, malheureusement, il semble qu'il n'existe plus. :-(
« Intel Premium » ? Je ne vois pas.
Sinon, avant toute chose, quel âge a ton PC et quelles sont ses caractéristiques ? Si c'est une machine contemporaine, tu pourras envisager toutes les distributions avant d'en choisir une, mais si c'est un ordinateur hors d'âge, il faudra t'orienter vers des distributions spécialement conçues pour.
[^] # Re: Pour quelles applications ?
Posté par Obsidian . En réponse au message quand et pourquoi implementer un pilote?. Évalué à 3.
En fait, sans surprise, je me reconnais beaucoup de mon parcours de développeur dans tes propos, et effectivement, avoir un bon prétexte pour étudier une certaine partie d'une technologie, est généralement le meilleur moyen de s'y mettre, tant au niveau de la motivation que du support de travail.
Pourtant, deux ans, ce n'est pas grand chose. :)
Faire du vrai nettoyage, voire du refactoring, et même in fine un plan de transition douce d'une techno à l'autre sans interruption de service sont des projets extrêmement intéressants en eux-mêmes, surtout avec des outils comme Git (une fois qu'on le maîtrise bien). À condition d'arriver à le faire admettre, comme on en parlait ailleurs. C'est toujours pénible quand on a un chef qui nous dit qu'on a pas le temps de tout ré-écrire quand on est face à une bouse infâme et qui donne ensuite l'ordre exact inverse une fois qu'on a fini d'appréhender la chose.
Que tu le nettoies ou que tu le refasses entièrement, profites-en pour le documenter. C'est une bonne occasion de le faire parce que tu ne seras pas poussé aux fesses pour sortir en temps et en heure un produit qui n'existe pas encore. Et tant qu'à faire, essaie de faire quelque chose qui soit auto-généré, donc soit du Doxygen, soit une page de référence interactive à la manière de celle d'Apache.
Je le dis d'expérience parce que pour avoir travaillé sur un gros projet interne à une compagnie, il m'a fallu beaucoup de temps pour m'approprier la chose et une fois cela fait, je n'avais plus le temps de documenter mes propres contributions. Pourtant, le leader initial du projet a eu le bon goût (parce qu'on lui a demandé) d'écrire un gros document dans un traitement de texte (écrit comme un livre, donc) pour présenter la chose. C'était bien, mais c'était assez rébarbatif à lire, c'était un cours presque déjà obsolète étant donné la rapidité des cycles de développement, et surtout : ce n'était de fait pas un « manuel », quelque chose qu'on pourrait directement ouvrir à la bonne page quand on travaille sur un point particulier du projet.
[^] # Re: LiveCD
Posté par Obsidian . En réponse au message Demande du mot de passe ubuntu 17.10. Évalué à 2.
Le QWERTY c'était une bonne idée mais la prochaine fois, vérifie quand même que :
– CAPS LOCK n'est pas enfoncée ;
– NUM LOCK, elle, l'est bien (si tu as l'habitude d'utiliser le pavé numérique).
9 fois sur 10, c'est à cause de ça. :)
[^] # Re: Pour quelles applications ?
Posté par Obsidian . En réponse au message quand et pourquoi implementer un pilote?. Évalué à 3.
Effectivement.
Bon, comme on l'a dit, on développe un pilote pour un produit dès lors que ce produit réalise à sa manière une tâche qui est déjà connue et identifiée dans ses grandes lignes par l'utilisateur et/ou le système d'exploitation. Par exemple, si l'une de tes cartes était une imprimante, ça vaudrait le coup de l'associer à l'existant pour pouvoir automatiquement profiter des facilités de composition et de mise en page.
Ça reste une bonne idée en soi. C'est juste que ces modules ne seraient pas forcément des pilotes.
Tu peux déjà faire un distingo entre le côté matériel, de bas niveau, et le haut de la pile, c'est-à-dire son exploitation par l'utilisateur. Comment fonctionne globalement cette application à l'écran ? Est-ce qu'il y a juste un menu du style « 1. … 2. … 3. … 4. … 5. … » qui se contente de basculer vers une application distincte à chaque fois, ou est-ce que l'on a, par exemple, un tableau de bord qui serait toujours présent ?
Tu peux aussi t'inspirer d'OBD2 (le protocole de la prise diagnostic des voitures) qui, d'un côté, spécifie le protocole lui-même et, de l'autre, une quantité impressionnante de codes produits et des réponses qu'ils peuvent envoyer, sachant que chaque véhicule n'implémente qu'un petit sous-ensemble de cette liste (correspondant aux équipements réellement embarqués dans le véhicule). Et ensuite, tu regardes si, à chaque fois, tu peux inscrire une carte donnée dans ce cadre.
M'enfin cela ne reste que des pistes de réflexion. Il n'y a rien de pire qu'un standard écrit à l'arrache au départ et qu'il faut ensuite maintenir par compatibilité pendant des décennies (sans exagérer).
[^] # Re: Pour quelles applications ?
Posté par Obsidian . En réponse au message quand et pourquoi implementer un pilote?. Évalué à 2.
Là, par contre, ça peut être intéressant de développer une couche d'abstraction au-dessus de tout ça.
# Charset de l'éditeur
Posté par Obsidian . En réponse au message Linux ncurses emoticones. Évalué à 4.
Normalement, le C doit reproduire fidèlement ce qui se trouve entre deux guillemets " " dans ton programme. Si ça ne fonctionne pas, c'est que soit tu utilises un compilateur VRAIMENT trop vieux, soit (ce qui est beaucoup plus probable) tu utilises un éditeur de texte qui ne travaille pas en UTF-8 par défaut, voire qui choisit de ne pas le faire pour le type de fichier que tu édites (ici un *.c) parce qu'il est configuré pour utiliser un autre charset par défaut pour ce type de listing.
Du coup, la séquence doit bien être encodée dans ton programme, mais pas en UTF-8, si bien que lorsque ton application la restitue dans un terminal qui, lui, en attend, ça ne donne plus rien.
Avec quoi développes-tu ?
[^] # Re: Un coup de polish sur le design ?
Posté par Obsidian . En réponse à la dépêche Améliorons l’expérience utilisateur de LinuxFr.org !. Évalué à 3.
En fait, l'avantage, c'est 99,9% de la chose passeraient par une simple CSS. Nul besoin de scripts ou d'extensions particulières. Donc aucun ralentissement. Et si l'on veut quand même des animations flashy, CSS3 permet déjà d'en faire énormément avec
transitionettransform.Ce qui est bien, c'est que sur DLFP, les utilisateurs sont traditionnellement incités à le faire et il existe des facilités pour mettre facilement en place ses créations avec le lien changer de style, à gauche dans la boîte principale.
[^] # Re: Possibilité d'éditer ses propres contenus
Posté par Obsidian . En réponse à la dépêche Améliorons l’expérience utilisateur de LinuxFr.org !. Évalué à 2.
Ça se fait avec vBulletin aussi. Un commentaire rapidement modifié ne laisse aucune trace (je ne saurais dire si cela tient compte du fait qu'il y ait ou non des réponses), sinon la date de dernière modification est ajoutée, et cliquer dessus donne accès à l'historique et au différentiel des changements (à la Wikipédia).
[^] # Re: Journal VS depeche
Posté par Obsidian . En réponse à la dépêche Améliorons l’expérience utilisateur de LinuxFr.org !. Évalué à 4.
Les journaux, ici, sont surtout des « journaux de bord » ou des « journaux intimes (sauf qu'ils ne sont pas intimes) » et se traduisent en anglais par « log », soit en fait « blog » puisqu'ils sont sur le web.
Les journaux sont donc en fait les blogs personnels des membres, sauf que les derniers billets sont référencés par un lien qui se trouve directement dans la barre de haut de page, et cela marche parce que le public de linuxfr.org est en grande partie composé d'habitués de longue date.
De la même façon, les dépêches seraient des « news », mais ici, on est bien sur linux fr.org ;)
Les principales différences sont que d'une part, tout le monde peut participer à la rédaction d'une dépêche, qui généralement rédigée à plusieurs dans l'espace de rédaction alors qu'un blog est privé par nature, et que d'autre part, un journal soumis est immédiatement publié (comme un commentaire), alors qu'une dépêche est soumise à approbation finale de la modération. De fait, les dépêches sont en fait publiées en page d'accueil au nom du site (même si elles sont quand même créditées à leur auteur), alors que les billets de blog, d'un point de vue moral, n'engagent que leur auteur.
Évidemment, d'un point de vue légal, les unes et les autres doivent être modérés de la même façon et, de toutes façons, on rend toujours crédit à l'auteur d'un papier, quel qu'il soit. Mais c'est comparable aux articles d'un journal papier écrits par les membres de sa rédaction, par rapport aux petites annonces qui sont publiées dans ses pages.
Enfin, dans cet esprit, une dépêche se soit d'avoir un intérêt pour tout le lectorat du site, alors qu'un
billet de blogjournal, lui, peut parler de tout ce qui intéresse son auteur, tant que cela ne devient pas du spam caractérisé et qu'il n'y a pas flood.Comme il est très difficile de produire en continu des dépêches valides sur l'actualité sur un site communautaire et sans avoir de chroniqueur attitré, alors les journaux sont ici mis en évidence car on a la chance qu'ils soient de bonne qualité par rapport à certains autres sites (et ce, parce que les gens ont l'habitude de les utiliser de longue date). Un billet de blog particulièrement intéressant et bien écrit peut ensuite, éventuellement, être promue en dépêche.
[^] # Re: Possibilité d'éditer ses propres contenus
Posté par Obsidian . En réponse à la dépêche Améliorons l’expérience utilisateur de LinuxFr.org !. Évalué à 3.
J'ajoute également, comme dit plus haut (et parce que mon commentaire qui a HUIT minutes ne peut plus être édité) que j'ai écrit un site web entier en PHP (+ PostGreSQL) et implémentant un forum organisé en arbre (comme celui de DLFP) avec possibilité d'édition et messages privés.
Ce n'est pas un exploit en soi, mais ça répond à ta question, dans le sens où je l'ai déjà écrit. C'est juste que ce n'est pas en Ruby. :)
[^] # Re: Il y a un autre truc "chiant"...
Posté par Obsidian . En réponse à la dépêche Améliorons l’expérience utilisateur de LinuxFr.org !. Évalué à 3.
J'ai oublié de dire, pour ceux que cela intéresse, qu'on peut aussi soit mettre en ligne soit carrément uploader ce bout de CSS en bas de cette page : https://linuxfr.org/stylesheet/modifier
Il suffit de copier-coller le bloc présenté et de le faire précéder de la déclaration «
@import url("//linuxfr.org/assets/application.css");» présentée sur ladite page.[^] # Re: Possibilité d'éditer ses propres contenus
Posté par Obsidian . En réponse à la dépêche Améliorons l’expérience utilisateur de LinuxFr.org !. Évalué à 4.
Je fréquente linuxfr.org depuis 1999. J'ai déjà ouvert quelques tickets qui ont fini par être implémentés, dont le [^], évoqué dans un autre commentaire, et qui est en place depuis Templeet.
J'ai contribué en postant une ou deux dépêches, j'ai fait un certain nombre de traductions dans les dépêches noyau, et j'avais proposé les CSS Nightgrey et Springtime en leur temps, toujours sous Templeet (la dernière m'a demandé environ 80 heures de travail, à l'époque. Les CSS éponymes actuelles ne sont pas les mêmes et ont été écrites par d'autres personnes).
Pour le patch MP, tu as tout-à-fait raison en soi et la seule raison pour laquelle ce n'est pas encore proposé, c'est que je ne connais RIEN au Ruby. Il y a des moments où on ne peut plus courir tous les lièvres à la fois. Je suis principalement codeur C, et j'ai pourtant déjà fait pas mal de web.
Par contre, et c'est une vraie question, puisque tu utilises cet argument pour conclure ce fil, peux-tu nous indiquer si tu as déjà toi-même contribué au site (autrement que par les commentaires, ce qui est déjà beaucoup) et si oui, dans quelle mesure ?