Ce n'est le cas ni du xml, ni du json, à fortiori quand le fichier en question dépasse les 20 lignes.
Un format qui fait plus q'une liste clef => valeur de facile à modifier pour un humain, personnellement j'en connais pas (mais je suis intéressé si tu as).
Je ne parlerai même pas de versionner ou differ ce genre d'horreur…
Ça se fait plutôt bien (le versionnement très bien) le diff un peu moins pour XML.
JSON s'en sort un peu mieux.
Mais YAML est le meilleur AMHA pour ça (il est sensible au retour à la ligne).
Je suppose que mon opinion différente viens du fait que j'aime pouvoir assembler mon écosystème logiciel moi-même, plutôt qu'être obligé de me reposer sur les choix de quelqu'un d'autre et devoir forker (et donc maintenir) une structure complexe dès que je veux changer customiser un truc dans un sens pas prévu par le(s) dev(s) d'origine.
Je ne vois pas ce que ça change. Que ce soit du protobuf, de l'INI, du YAML ou autre ça ne te change pas grand chose pour ça.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
Franchement j'aime pas trop ce genre de posts où des donneurs de leçon bien opportunistes viennent se faire mousser en montrant du doigt le code des autres
Moi j'apprécie qu'on remette en question le marbre qu'on a tendance à imaginer dur comme de la pierre et qui se révèle être fragile au final. Sincèrement voir encore des gens avancer l'argument de l'âge pour affirmer qu'un code est de qualité (cf ci-dessus) après heartbleed et shellshock va falloir apprendre à :
remettre en question les piliers (ce n'est pas parce que c'est vieux et/ou très utilisé que c'est bien/performant/sûre)
prendre en considération ce genre de projet et les aider à s'améliorer (par exemple avec des dons)
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
Dans ce qu'il présente, il y a des choses qui étaient moche même si elles avaient était écrite à la création du C. Tout ce qui est vieux ne peut pas utiliser son age pour expliquer sa mauvaise qualité.
Par contre c'est du code bien éprouvé.
On est sûr qu'il n'y a pas de faille qui traine dedans depuis 20 ans ?
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
Et aussi : les principes de maintenance, ça n'a rien à voir avec Linux, ce serait BSD, Mac, Windows ou Hurd, ça serait pareil, donc vraiment aucun rapport.
Et donc, toi qui n'aime pas les préjugés, qu'est-ce qui t'a fait imaginer qu'il n'avait pas documenté son warkaround en pointant dans sa documentation le bug en question qui donne l'explication du warkaround utilisé ?
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
on utilise des ORMs ? C'est bien, mais cela rajoute un léger surcoût (dans le cas où on sait s'en servir) à un gros surcout (dans le cas contraire) par rapport à des requêtes écrites directement.
Faut savoir qu'est ce que tu compare avec quoi. Bien des développeurs ne sont pas très grands connaisseurs des SGBD et ne font pas forcément des requêtes bien optimisées. À cela il faut ajouter le coup de la gestion de la donnée dans ton programme (la sérialisation et déserialisation dans une structure/un objet).
La question qui est intéressante c'est : est-ce que je saurais faire mieux que l'ORM ?
C'est un peu comme de dire qu'il faut acheter un reflex parce que le RAW c'est génial. Oui c'est génial quand tu sais correctement développer du RAW et que tu saura faire mieux que ce que fais l'appareil. Dans la pratique ce n'est pas le cas très souvent.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
Déjà si ton système de fichier est inutilisable à cause d’un bloc corrompu tu devrais en changer très vite.
Qu'est-ce qui te fais dire que ce n'est pas le cas des log binaires de systemd ? Ils sont ouvert en mode append si je ne m'abuse donc il n'y a pas ce genre de corruption totale.
Mes informations importantes, du point de vue du log, c’est ce qu’il s’est passé aux alentours de 6h.
Tu aura accès à toutes les entrée qui précèdent le problème (si le problème a bien corrompu les logs ce qui reste à imaginer).
Ensuite pour le reste, tu dois pouvoir te retrouver grâce à l'entête de chaque entrée et donc pouvoir lire la suite.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
un admin qui s'est constitué sa collection de scripts au fil du temps, je pense qu'on est plus sur le simple "faire chier", mais sur l'augmentation de la charge de travail: tout à refaire, à déboguer à nouveau, etc.
Youpi.
Il aura surtout un paquet de scripts inutiles car fournit de base.
Il aurait du se pencher sérieusement sur les outils de gestion de log qui gère les 14 formats et les futures de manières indistinctes en entrée et qui fournissent les même services pour tous (logstash, splunk, etc). Quand on fait les choses dans son coin c'est logique tout reviens à la charge de celui qui crée.
systemd est en mesure de fournir le format de syslog.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
Ben j'sais pas change de version, lis la doc de ce que tu utilise avant d'imaginer,…
La correction est surtout arrivée partout ailleurs, chez Debian (stable et unstable) ou chez Red Hat et autres, mais pas chez testing.
La première (la CVE-2014-6271) correction est arrivé dans testing (hier soir ou dans la nuit si je ne m'abuse), toute fois la seconde (celle qui est arrivé dans les autres versions de Debian ce matin) n'y est toujours pas.
C'est rigolo de faire celui qui est choqué par le temps que ça prend sans regarder le temps que ça prend.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
N'importe quoi. Du moins tant que tu ne m'a pas donné de critères complets.
La faille est resté quelque soit le système d'exploitation que tu utilise pendant une vingtaine d'année, si j'ai bien compris et le bug est connu depuis au moins le 14 septembre, la mise à jour upstream a mis quelques jours. Je crois pas qu'il y ai eu de mise à jour des distrib' avant le 24. Donc avant toute chose c'est bien de mettre en balance les délais. Les 10 jours entre le fait que la faille soit connue et l'application des correctifs tout le monde se l'est pris.
Ensuite et encore une fois l'objectif de testing-security n'est pas que tu trouve ça acceptable, juste d'améliorer un peu la sécurité d'une version de test de Debian. Si tu as des critères importants de sécurité lis la doc de ce que tu installe et n'installe pas testing, personne ne t'en voudra.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
Est-ce que cmake t'apporte un vrai gain ? Il est pas mal pour la gestion des dépendance (qu'il est le seul à gérer avec les autotools), mais si ça ne t'arrange pas il y a un paquet d'outils de build qui te ferront du café torréfié sous l'aisselle, font revenir l'être aimé et rende le poil plus soyeux, les plus avancés soignent les phobies administratives.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
J'ai essayé quelques IDE, avant de me rendre compte que Eclipse ou Netbeans sont les seuls à proposer une bonne complétion, du refactoring qui marche et à ne pas planter lamentablement (kdevelop, c'est de toi que je parle). Les meilleurs IDE C++ sont donc en Java…
Pour aussi bosser en Java (mais c'est pareil pour les développeurs C#), c'est vraiment des manières de travailler différentes. Un intellij est capable de faire de l'autocomplétion intelligente, de faire des refactoring sophistiqués (tu utilise un identifiant qui n'existe pas, il te propose d'ajouter un paramètre à ta fonction avec un type cohérent (que tu peut changer), et de lui donner une valeur par défaut (partout où la méthode sera appelée il ajoutera cette valeur dans les paramètre) ou d'ajouter une donnée membre à ta classe etc).
Bien sûr les IDE c'est mal quand on apprend, il faut comprendre ce qu'on fait, etc, etc. Mais personnellement j'ai plus à apprendre les bases du langage dans le quel je travail, maintenant je l'utilise et j'essaie de produire du code de qualité. Plus important, je relis mes diff avant de commiter/pusher. Au lieux de perdre 2h à faire des refacto à la main (à coup de Ctrl+c/Ctrl+v, pas très enrichissant1) voir à coup de grep/sed (pour ceux qui utilisent cette dernière méthode j'ose espérer qu'ils relisent en détail les diff parce que c'est nettement plus casse gueule que ce que fait un IDE), je passe 10-15 minutes à relire mes diff. Le gain est réel.
Aucun rapport mais pour l'édition du code, moi qui utilise vim à longueur de temps j'ai commencé à jouer avec les multi-curseur. C'est vachement bien ça ! Il va vraiment falloir que ce soit ajouté dans vim ou au pire emacs.
les macro vim peuvent aider, intellij a une fonctionnalité pas mal aussi avec SSR. ↩
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
Je ne vois pas où est le problème. Ce dépôt intègre les mises à jour de sécurité elles sont pas aussi rapide que pour les deux autres versions, c'est tout.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
Ça améliore vachement la sécurité alors : la correction est disponible pour stable et unstable mais pas testing.
La correction est arrivée en moins de 2 jours là où avant elle aurait mis 10 jours. L'une des métriques importantes pour mesurer la sécurité d'un système informatique c'est le temps qu'une correction met a arriver. Ils ont réduit ce chiffre de 80%, si tu ne vois pas le gain je ne peux pas y faire grand chose.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
Je ne crois pas que le fait de créer un dépôt change grand chose quant à la réactivité des packageurs. lts existe probablement pour séparer une nouvelle phase de vie de la distribution et parce que ce ne sont pas les même personnes qui s'occupent de debian stable et de la LTS. Quand on utilise testing faut pas déconner ça fait un bail qu'on dit à tut tête que les MAJ de sécurité mettent plus de temps à arriver, il ne faut pas être surpris quand on en a l'exemple. Pour rappel elle s'appelle Debian Testing.
Pour donner des exemples si tu va sur le wiki officiel Debian sur la page de testing tu pourra lire :
Compared to stable and unstable, next-stable testing has the worst security update speed. Don't prefer testing if security is a concern.
Il est aussi question du dépôt testing security :
Q. : Comment est gérée la sécurité pour testing ?
R. : La sécurité pour testing bénéficie des efforts sur la sécurité réalisés par tout le projet pour unstable. Cependant, un délai minimal de deux jours existe pour la migration, et les correctifs de sécurité peuvent parfois être retenus par les transitions. L’équipe chargée de la sécurité aide à faire avancer ces transitions qui retiennent les envois de sécurité importants, mais ce n’est pas toujours possible et des contretemps peuvent survenir. En particulier, les mois qui suivent une nouvelle publication de stable, quand de nombreuses nouvelles versions sont envoyées dans unstable, les correctifs de sécurité pourraient être mis en attente. Si vous souhaitez un serveur sûr (et stable), vous devriez garder la distribution stable.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
manipulation de programme et de fichier trivial (find, globings)
la manipulation d'autres programmes
Le parallélisme en perl c'est mort bien souvent et utiliser POE c'est euh… comme chercher à détruire l'univers pour tuer une mouche. La gestion des fichier, je crois qu'il y a un module pour avoir comme les globings, mais c'est peu utilisé je sais pas si c'est dans les distrib' de base. La manipulation de programme est pas trop mal avec la possibilité d'ouvrir de lancer des programme comme on ouvre des fichiers.
Comprends bien j'aime perl (vraiment), mais ce que je fais avec perl et ce que je fais en shell forment 2 ensembles totalement disjoints.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
Par contre la nébuleuse systemd elle, en mettant des locks exclusifs dans tous les sens créé une vraie différence avec le déroulement traditionnel d'un init.
"dans tous les sens" ? Carrément ? Ça veut dire quoi pour toi dans tous les sens ? Vu que les mots n'ont plus vraiment de sens il semble.
Je ne vois pas en quoi c'est un vrai plus que l'init tire partie des fonctionnalités avancées du noyau
Sérieusement ? Va falloir réexpliquer l'intérêt de l'utilisation des cgroup dans l'init ? T'es juste ridicule.
du moins pas plus que si il s'agit d'Apache, de MySQL ou de Xorg.
ces logiciels peuvent toujours se servir des cgroups
ces logiciels ne se sont JAMAIS servi des cgroups. Les cgroups ne sont pas nouveaux et c'est que maintenant que toi tu te réveil et tu voudrais les utiliser partout ? T'a 7 ans de retard.
c'est une problématique d'intégration. L'administrateur d'un site d'e-commerce peu vouloir gérer ça différemment de celui qui fait de l'hébergement. Donc c'est forcément au niveau de l'intégration dans l'OS que ça va devoir se gérer (comment choisi-tu de cloisonner PHP ? quel proportion de ressources tu laisse à PHP par rapport à Apache ? etc). Le fait d'utiliser l'API direct de linux ou via systemd ou via LXC ou via docker ou sur un autre système grâce aux jails, ne change pas grand chose.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
L'init va lancer le premier processus qui a son tour peut lancer d'autres processus.
Pourquoi s'arrêter en si bon chemin ? Le noyau devrait lancer l'init qui lance le premier processus (mais c'est quoi alors l'init ?) qui lance un autre premier processus (appelons-le init) qui va lancer un processus (genre l'init), là s'il fait beau c'est lui qui va initialiser le système, mais les années bissextiles il va se contenter d'appeler un autre init…
Tout ça pour ? Rien on est dans l'userland depuis le premier processus.
Mais l'init (traditionnel, systemd étant en train de changer la donne à ce niveau là) n'a aucun avantage au niveau de ses interfaces ou des pseudo-fs comparé à n'importe quel processus avec les droits root.
Hum ? J'ai jamais entendu parlé de changement à ce niveau là pour systemd. Ce dernier ne se gène juste pas pour utiliser toutes les interfaces que linux utilise (et n'hésite pas à aller voir la ligne de commande qui a lancé le noyau (mais ça tout le monde peut le faire).
L'init est juste un processus comme les autres, lancé en premier et avec les droits root.
Et en quoi c'est différent avec systemd ? Il y a dans le noyau des if (init == SYSTEMD) ?
Pour ce qu'il voulait dire, je pense qu'il dit que c'est cool de voir des init qui utilisent toute la puissance du noyau sous-jacent. Linux est un noyau particulièrement avancé (qui propose beaucoup d'API en plus de POSIX), mais si demain rc.d de FreeBSD simplifie l'utilisation des capabilities de zfs ou des jails ce sera tout aussi cool et ça ne fonctionnera pas sous linux.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Un avis différent sur bash
Posté par barmic . En réponse à la dépêche Une faille nommée « shellshock ». Évalué à 1.
Ok. Si tu pense qu'il n'y a rien à apprendre de tout cela tant mieux.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Gestionnaire de projets
Posté par barmic . En réponse au journal Retour aux sources. Évalué à 3.
Un format qui fait plus q'une liste clef => valeur de facile à modifier pour un humain, personnellement j'en connais pas (mais je suis intéressé si tu as).
Ça se fait plutôt bien (le versionnement très bien) le diff un peu moins pour XML.
JSON s'en sort un peu mieux.
Mais YAML est le meilleur AMHA pour ça (il est sensible au retour à la ligne).
Je ne vois pas ce que ça change. Que ce soit du protobuf, de l'INI, du YAML ou autre ça ne te change pas grand chose pour ça.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Un avis différent sur bash
Posté par barmic . En réponse à la dépêche Une faille nommée « shellshock ». Évalué à 0.
Je te moinsse rien que pour ça.
Moi j'apprécie qu'on remette en question le marbre qu'on a tendance à imaginer dur comme de la pierre et qui se révèle être fragile au final. Sincèrement voir encore des gens avancer l'argument de l'âge pour affirmer qu'un code est de qualité (cf ci-dessus) après heartbleed et shellshock va falloir apprendre à :
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Corrections
Posté par barmic . En réponse à la dépêche Une faille nommée « shellshock ». Évalué à 7.
Pourquoi ne pas retirer ce bashisme du mode POSIX ?
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Un avis différent sur bash
Posté par barmic . En réponse à la dépêche Une faille nommée « shellshock ». Évalué à 4.
Dans ce qu'il présente, il y a des choses qui étaient moche même si elles avaient était écrite à la création du C. Tout ce qui est vieux ne peut pas utiliser son age pour expliquer sa mauvaise qualité.
On est sûr qu'il n'y a pas de faille qui traine dedans depuis 20 ans ?
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Rendre à César ...
Posté par barmic . En réponse au journal Pantheon, Cinnamon, MATE, Budgie, Endless Mobile, Tizen Shell...: Un bureau pour les gouverner tous!. Évalué à 5.
Je te déteste pour m'avoir rappelé l'existence de (feu) moblin. J'apréciais beaucoup le look et l'ergonomie du bouzin. Snif… :(
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: [HS] Préjugés
Posté par barmic . En réponse au journal mdadm: No devices listed in conf file were found. Évalué à 3.
Et donc, toi qui n'aime pas les préjugés, qu'est-ce qui t'a fait imaginer qu'il n'avait pas documenté son warkaround en pointant dans sa documentation le bug en question qui donne l'explication du warkaround utilisé ?
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Retourne à la raison!
Posté par barmic . En réponse au journal Retour aux sources. Évalué à 4.
Faut savoir qu'est ce que tu compare avec quoi. Bien des développeurs ne sont pas très grands connaisseurs des SGBD et ne font pas forcément des requêtes bien optimisées. À cela il faut ajouter le coup de la gestion de la donnée dans ton programme (la sérialisation et déserialisation dans une structure/un objet).
La question qui est intéressante c'est : est-ce que je saurais faire mieux que l'ORM ?
C'est un peu comme de dire qu'il faut acheter un reflex parce que le RAW c'est génial. Oui c'est génial quand tu sais correctement développer du RAW et que tu saura faire mieux que ce que fais l'appareil. Dans la pratique ce n'est pas le cas très souvent.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Du point de vue utilisateur ou mainteneur ?
Posté par barmic . En réponse au journal Ne dites pas à ma mère que j'ai installé systemd, elle croit que je suis pianiste dans un bordel.. Évalué à 3.
Qu'est-ce qui te fais dire que ce n'est pas le cas des log binaires de systemd ? Ils sont ouvert en mode append si je ne m'abuse donc il n'y a pas ce genre de corruption totale.
Tu aura accès à toutes les entrée qui précèdent le problème (si le problème a bien corrompu les logs ce qui reste à imaginer).
Ensuite pour le reste, tu dois pouvoir te retrouver grâce à l'entête de chaque entrée et donc pouvoir lire la suite.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Surprenant, non ? finalement non...
Posté par barmic . En réponse au journal Ne dites pas à ma mère que j'ai installé systemd, elle croit que je suis pianiste dans un bordel.. Évalué à 4.
Qui utilise sysvinit mis à part GNU/Linux ?
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Du point de vue utilisateur ou mainteneur ?
Posté par barmic . En réponse au journal Ne dites pas à ma mère que j'ai installé systemd, elle croit que je suis pianiste dans un bordel.. Évalué à 4.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Yahou peut être enfin des jeux qui marchent !
Posté par barmic . En réponse au journal Retour aux sources. Évalué à 10.
Même pas, c'est sur la manière d'écrire un tel programme grâce à un uniligne…
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Debian Jessie
Posté par barmic . En réponse au journal Mets à jour ton bash. Maintenant.. Évalué à 7.
Ben j'sais pas change de version, lis la doc de ce que tu utilise avant d'imaginer,…
La première (la CVE-2014-6271) correction est arrivé dans testing (hier soir ou dans la nuit si je ne m'abuse), toute fois la seconde (celle qui est arrivé dans les autres versions de Debian ce matin) n'y est toujours pas.
C'est rigolo de faire celui qui est choqué par le temps que ça prend sans regarder le temps que ça prend.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Debian Jessie
Posté par barmic . En réponse au journal Mets à jour ton bash. Maintenant.. Évalué à 8.
N'importe quoi. Du moins tant que tu ne m'a pas donné de critères complets.
La faille est resté quelque soit le système d'exploitation que tu utilise pendant une vingtaine d'année, si j'ai bien compris et le bug est connu depuis au moins le 14 septembre, la mise à jour upstream a mis quelques jours. Je crois pas qu'il y ai eu de mise à jour des distrib' avant le 24. Donc avant toute chose c'est bien de mettre en balance les délais. Les 10 jours entre le fait que la faille soit connue et l'application des correctifs tout le monde se l'est pris.
Ensuite et encore une fois l'objectif de testing-security n'est pas que tu trouve ça acceptable, juste d'améliorer un peu la sécurité d'une version de test de Debian. Si tu as des critères importants de sécurité lis la doc de ce que tu installe et n'installe pas testing, personne ne t'en voudra.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: ...
Posté par barmic . En réponse au journal Retour aux sources. Évalué à 8.
Est-ce que cmake t'apporte un vrai gain ? Il est pas mal pour la gestion des dépendance (qu'il est le seul à gérer avec les autotools), mais si ça ne t'arrange pas il y a un paquet d'outils de build qui te ferront du café torréfié sous l'aisselle, font revenir l'être aimé et rende le poil plus soyeux, les plus avancés soignent les phobies administratives.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
# IDE
Posté par barmic . En réponse au journal Retour aux sources. Évalué à 8.
Pour aussi bosser en Java (mais c'est pareil pour les développeurs C#), c'est vraiment des manières de travailler différentes. Un intellij est capable de faire de l'autocomplétion intelligente, de faire des refactoring sophistiqués (tu utilise un identifiant qui n'existe pas, il te propose d'ajouter un paramètre à ta fonction avec un type cohérent (que tu peut changer), et de lui donner une valeur par défaut (partout où la méthode sera appelée il ajoutera cette valeur dans les paramètre) ou d'ajouter une donnée membre à ta classe etc).
Bien sûr les IDE c'est mal quand on apprend, il faut comprendre ce qu'on fait, etc, etc. Mais personnellement j'ai plus à apprendre les bases du langage dans le quel je travail, maintenant je l'utilise et j'essaie de produire du code de qualité. Plus important, je relis mes diff avant de commiter/pusher. Au lieux de perdre 2h à faire des refacto à la main (à coup de Ctrl+c/Ctrl+v, pas très enrichissant1) voir à coup de
grep/sed(pour ceux qui utilisent cette dernière méthode j'ose espérer qu'ils relisent en détail les diff parce que c'est nettement plus casse gueule que ce que fait un IDE), je passe 10-15 minutes à relire mes diff. Le gain est réel.Aucun rapport mais pour l'édition du code, moi qui utilise vim à longueur de temps j'ai commencé à jouer avec les multi-curseur. C'est vachement bien ça ! Il va vraiment falloir que ce soit ajouté dans vim ou au pire emacs.
les macro vim peuvent aider, intellij a une fonctionnalité pas mal aussi avec SSR. ↩
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Debian Jessie
Posté par barmic . En réponse au journal Mets à jour ton bash. Maintenant.. Évalué à 3.
Je ne vois pas où est le problème. Ce dépôt intègre les mises à jour de sécurité elles sont pas aussi rapide que pour les deux autres versions, c'est tout.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Debian Jessie
Posté par barmic . En réponse au journal Mets à jour ton bash. Maintenant.. Évalué à 5.
La correction est arrivée en moins de 2 jours là où avant elle aurait mis 10 jours. L'une des métriques importantes pour mesurer la sécurité d'un système informatique c'est le temps qu'une correction met a arriver. Ils ont réduit ce chiffre de 80%, si tu ne vois pas le gain je ne peux pas y faire grand chose.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Debian Jessie
Posté par barmic . En réponse au journal Mets à jour ton bash. Maintenant.. Évalué à 5.
A améliorer la sécurité, pas à la rendre parfaite.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Debian Jessie
Posté par barmic . En réponse au journal Mets à jour ton bash. Maintenant.. Évalué à 5.
Je ne crois pas que le fait de créer un dépôt change grand chose quant à la réactivité des packageurs. lts existe probablement pour séparer une nouvelle phase de vie de la distribution et parce que ce ne sont pas les même personnes qui s'occupent de debian stable et de la LTS. Quand on utilise testing faut pas déconner ça fait un bail qu'on dit à tut tête que les MAJ de sécurité mettent plus de temps à arriver, il ne faut pas être surpris quand on en a l'exemple. Pour rappel elle s'appelle Debian Testing.
Pour donner des exemples si tu va sur le wiki officiel Debian sur la page de testing tu pourra lire :
Il est aussi question du dépôt testing security :
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Presque d'accord ...
Posté par barmic . En réponse à la dépêche Revue des techniques de programmation en shell. Évalué à 4.
L'intérêt du shell c'est :
Le parallélisme en perl c'est mort bien souvent et utiliser POE c'est euh… comme chercher à détruire l'univers pour tuer une mouche. La gestion des fichier, je crois qu'il y a un module pour avoir comme les globings, mais c'est peu utilisé je sais pas si c'est dans les distrib' de base. La manipulation de programme est pas trop mal avec la possibilité d'ouvrir de lancer des programme comme on ouvre des fichiers.
Comprends bien j'aime perl (vraiment), mais ce que je fais avec perl et ce que je fais en shell forment 2 ensembles totalement disjoints.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Pub
Posté par barmic . En réponse à la dépêche Nouvelle distribution Linutop OS 14.04 pour PC. Évalué à 5.
On arrête de parler de RedHat ?
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Du point de vue utilisateur ou mainteneur ?
Posté par barmic . En réponse au journal Ne dites pas à ma mère que j'ai installé systemd, elle croit que je suis pianiste dans un bordel.. Évalué à 2.
"dans tous les sens" ? Carrément ? Ça veut dire quoi pour toi dans tous les sens ? Vu que les mots n'ont plus vraiment de sens il semble.
Sérieusement ? Va falloir réexpliquer l'intérêt de l'utilisation des cgroup dans l'init ? T'es juste ridicule.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Du point de vue utilisateur ou mainteneur ?
Posté par barmic . En réponse au journal Ne dites pas à ma mère que j'ai installé systemd, elle croit que je suis pianiste dans un bordel.. Évalué à 5.
La question n'est pas nouvelle : https://linuxfr.org/users/patrick_g/journaux/linux-ou-posix
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Du point de vue utilisateur ou mainteneur ?
Posté par barmic . En réponse au journal Ne dites pas à ma mère que j'ai installé systemd, elle croit que je suis pianiste dans un bordel.. Évalué à 4.
Pourquoi s'arrêter en si bon chemin ? Le noyau devrait lancer l'init qui lance le premier processus (mais c'est quoi alors l'init ?) qui lance un autre premier processus (appelons-le init) qui va lancer un processus (genre l'init), là s'il fait beau c'est lui qui va initialiser le système, mais les années bissextiles il va se contenter d'appeler un autre init…
Tout ça pour ? Rien on est dans l'userland depuis le premier processus.
Hum ? J'ai jamais entendu parlé de changement à ce niveau là pour systemd. Ce dernier ne se gène juste pas pour utiliser toutes les interfaces que linux utilise (et n'hésite pas à aller voir la ligne de commande qui a lancé le noyau (mais ça tout le monde peut le faire).
Et en quoi c'est différent avec systemd ? Il y a dans le noyau des
if (init == SYSTEMD)?Pour ce qu'il voulait dire, je pense qu'il dit que c'est cool de voir des init qui utilisent toute la puissance du noyau sous-jacent. Linux est un noyau particulièrement avancé (qui propose beaucoup d'API en plus de POSIX), mais si demain rc.d de FreeBSD simplifie l'utilisation des capabilities de zfs ou des jails ce sera tout aussi cool et ça ne fonctionnera pas sous linux.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)