Ce qu'il dénonce est plutôt de l'ordre du style, de la cohérence globale et de l'organisation, permettant une collaboration entre plusieurs acteurs plus aisée parce que lorsqu'on adopte un style, on configure son cerveau d'une certaine façon qui nous permettra de lire et comprendre rapidement le texte (ou le code, ou la compta, etc.).
Je ne vois pas pourquoi lorsque je code par exemple, je devrais adopter un style qui ne me convient pas, ou auquel mon cerveau n'est pas habitué, juste parce que quelqu'un pense détenir la vérité et l'impose aux autres.
En voulant tout règlementer, on en arrive à des trucs sclérosés et contre productifs, qui inhibent la créativité.
Dans du code, par exemple, je ne vois pas pourquoi on irait pourrir la vie d'un développeur parce qu'il utilise un style de codage différent des autres, à partir du moment ou les interactions externes sont définies et normalisées (l'interface de codage).
Ensuite, on peut utiliser des outils de mise en forme pour uniformiser les trucs tels qu'indentation, etc … mais aller trop loin est en général contre productif.
Après, établir certaines conventions ne fait pas de mal lorsqu'elles sont simples et facilement assimilables (par exemple éviter d'utiliser des noms de variables qui ne veulent rien dire, par exemple a = machin, b = truc …), mais aller dans l'arbitraire (style coder des variables avec les 3 premiers caractères qui correspondent à un truc, les 5 suivants à un autre et les 2 dernier a encore autre chose) ne mène jamais à rien de bien.
Relis plus haut mon commentaire sur ibus qui prend plus de 100% de CPU et qui fait se décharger la batterie de mon ordinateur portable bien plus vite que la normale.
Alors certes sur un téléphone, c'est plus difficile à détecter, mais si les utilisateurs avaint moyen de voior que leur batterie ne tient pas la charge parce que ya un tas d'applis qui n'optimisent pas leurs algo et bouffent de l'énergie pour rien, je suis certain que le point de vu des développeurs changerait.
Juste pour info, j'ai éjà vu dans les commentaires de certaines applis, des gens qui l'ont désinstallé parce qu'ils ont remarqué que ces fameuses applis avaient tendance à diminuer l'autonomie de leur batterie.
Je trouve que systemd c'est justement une personne qui a voulu ré-écrire une partie du système justement où on accumulait du code dans tous les sens pour un service pas si fiable (les scripts de /etc/init.d était quand même vraiment lourd et lents pour la plupart, sans quasiment aucune unification).
La lourdeur et la lenteur ne sont pas forcément les points les plus importants. Je ne dis pas qu'il fallait garder les scripts d'inits comme ils étaient, par contre la façon de faire de systemd n'est pas non plus la bonne façon de faire.
Les scripts d'init avaient pour gros avantage d'être modifiables et personnalisables à l'envie, de ne pas enfermer les admins dans un moule rigide (ou t'es obligé de te tordre le cerveau dès que tu n'es pas dans un cas prévu), et de pouvoir corriger les bugs du système de démarrage sans avoir à recompiler et attendre une livraison de nouvelle version.
Le fait que les scripts soient des scripts permettait en outre si on le voulait d'étudier facilement ce qu'ils faisaient en les modifiants, sans avoir à passer par des phases de compilation assez lourdes (bien entendu, je parle de faire ça dans un environnement de test, pas sur de la prod …).
A contrario, systemd est un truc plutôt "boite noire" qui peut effectivement permettre de gagner du temps lorsque l'on rentre dans le moule (90% des cas), mais qui fait perdre bien plus de temps pour gérer les 10% de cas non prévus par le bouzin (et manque de bol pour moi, c mon job de gérer ces cas de figure).
Je ne nie pas que systemd apporte un certain nombre d'avantages (par exemple la possibilité de monitorer un process et de le relancer s'il se vautre tout seul), mais il apporte un gros lot d'inconvénients, notamment une perte de souplesse par rapport à init ou upstart.
Ben si on veut économiser de l'énergie, on a plutôt intéret à ne pas trop faire mouliner le CPU, donc ça répond à au moins aux 2 premières questions. Perso, je préfère sacrifier un peu de réactivité à une surconsomation d'énergie sur un mobile.
tu diras ça aux ordinateurs portables qui plantent sauvagement à cause de la surchauffe lors d'un test mémoire avec memtest.
La plupart des PC portables ne sont pas fait pour tourner à 100% de leur capacité en permanence. Quand tu exécutes un OS comme windows par exemple, celui-ci ralentit la vitesse à laquelle ta machine fonctionne lorsqu'il surchauffe, ce qui fait que tu ne t'en reds même pas compte. Par contre avec un test mémoire, ya pas de régulation de la vitesse en fonction de la température et ça plante.
La performance n'est pas la priorité absolue, c'est sur.
Pour des applis sur mobiles, je m'attends à ce que l'appli ne fasse pas de trucs inutiles, pour ne pas bouffer ma batterie, donc la perf à mon avis n'est absolument pas à négliger : un CPU qui mouline inutilement à cause d'un algo peu performant bouffe de l'énergie.
Par contre le service systemd présenté dans la même réponse ne propose ce niveau de configuration donc on n'est pas tout à fait en face de deux trucs qui font exactement la même chose.
Merci, tu confirmes bien ce que j'en avais compris.
Le bug que tu cites est lié à Fedora 26, une distribution expérimentale par nature, c'est un peu particulier.
Ben j'ai rencontré le même type de problème sur une redhat qui n'a rien d'expérimental. Je t'accorde que ce genre de bug a tendance à se faire un peu plus rare, mais ça arrive encore que systemd se vautre lamentablement dans certains cas. La ou ça me gène, c'est surtout qu'avant systemd, un bug sur le système d'init pouvait être facilement corrigé sans attendre de mise à jour d'OS (c'est du script), là ou aujourd'hui, il faut attendre le bon vouloir de RedHat pour corriger.
Tu as le script init de Nginx, et la version systemd. La seconde est beaucoup plus courte et surtout plus lisible humainement.
Je viens d'aller voir l'exemple que tu as donné, et je me pose une question : pourquoi le script init de redhat crée-t-il son user à cet endroit précis ? Et pourquoi la création de répertoire doit-elle se faire au démarrage ? côté systemd, ça se fait ou et à quel moment ? (je suis pas un expert nginx donc je ne sais pas trop pourquoi il a besoin de faire ce genre de truc)
On trouve souvent sur FreeBSD des ports qui n'ont pas de script d'init, et quand il faut les écrire c'est vraiment très long alors qu'avec systemd cela aurait été fait en quelques minutes.
Bah, quand il s'agit de faire un bete start/stop, ça prend pas beaucoup plus de temps (je l'ai déjà fait pas mal de fois). Et quand il s'agit de custommiser, systemd est bien chiant :j'ai passé pas mal de temps l'an dernier à faire une pauvre unit pour démarrer un apache compilé maison, auquel je devais faire passer certaines variables d'environnement (j'ai plus les détails en tête, mais si j'avais du faire ça en init classique, ça m'aurait pris bien moins de temps).
La norme EPUB 3 introduit la possibilité d'ajouter d'autres médias, animations, vidéos
euh … Faudrait penser à arrêter ce genre de délire. Après les livres qui ne te donnent que la moitiés des informations dont ils sont censés traiter (parce que des pans entiers de code source et d'exemples sont en ligne - a priori on ne sait pas pour combien de tamps), va-t-on voir sortir les ebooks que l'on ne peut lire que sur imachin ou galaxytruc parce que celui-ci contient des séquences animées qui ne sont absolument pas gérables par des liseuses ?
D'abord sur le fond, je suis assez d'accord avec le texte originel. Dernièrement, je me disais que la batterie de mon ordinateur portable se déchargeait bien vite. En regardant l'applet qui monitore les ressources systèmes, je me suis apperçu que le CPU était pas mal sollicité … et je me suis rendu compte en regardant les process qui tournaient, qu'un ibus prenait plus de 100% de CPU … :(
Je me suis demandé si je rêvais (d'autant plus qu'ibus m'a pris la tête sur mon fixe sous freebsd - il passe son temps
à ignorer le fait que j'utilise un clavier fr, du coup je l'ai désactivé). Sur mon portable, j'ai juste eu à tuer ibus et redémarrer les applications qui semblaient l'utiliser (la saisie clavier ne marchait plus sur l'une d'elles), et l'occupation CPU est redevenue plus raisonnable. Bilan : je me trouve sur ma machine avec un truc qui a priori ** ne sert a rien ** et prend plus de 100% CPU. Ce que je redoute, c'est que ce truc inutile devienne incontournable a l'avenir, et fasse perdre encore de l'autonomie à ma batterie.
Ici je parle d'ibus parce que c'est un truc qui m'est arrivé il y a peu, mais j'ai déjà bien ralé dans le passé parce que des gens ont voulu remplacer un truc qui marchait plutôt bien, qui avait mis du temps à être débuggé, par un truc pas fini qui vient pourrir la vie des utilisateurs (exemple : systemd), ou des trucs pas finis qui viennenet également pourrir la vie des gens (exemple : pulseaudio). J'ai constaté le même phénomène avec hplip: un processus python qui vient à utiliser de grosses quantités de CPU pour rien (au passage, je pense que pour développer ce genre de truc en python, faut être malade, ou avoir envie de décharger les batteries des portables des utilisateurs).
Celà dit, je pense qu'on arrive à la fin d'un cycle et que ces pratiques vont commencer à s'atténuer (si ce n'est disparaître - au moins pour quelques temps). En effet, le coût de la mémoire RAM a pas mal augmenté ces derniers temps, et le cout des processeurs Intel également: j'ai l'impression que l'ère du matériel pas cher est en train de se terminer, et qu'on va voir celui-ci augmenter considérablement dans les années à venir (sans compter le cout de l'énergie qui à mon avis risque d'augmenter fortement). Du coup les développeurs devront réapprendre à optimiser leurs programmes pour qu'ils puissent tourner sur des confs hardware moins gourmandes, et utilisent moins d'énergie pour fonctionner. Alors certes, les restrictions hardwares ne seront probablement pas aussi fortes que dans les débuts de l'informatique, mais je suis d'avis qu'on ne pourra plus faire comme aujourd'hui : considérer qu'optimiser le soft coute plus cher que d'ajouter des capacités hardware.
Cette autorité de donnera la possibilité de gérer to domaine comme tu le veux. Soit ton fournisseur te donnera une interface avec laquelle tu pourras directement enregistrer les informations, soit tu entreras l'IP de ton serveur DNS qui aura autorité pour répondre aux informations disponibles pour ton domaine.
Une approche pourrait être de ne pas pouvoir commenter les liens.
Je suis pas fermé par principe, mais pas convaincu non plus. Et au niveau du bouton, je préfèrerais une appellation du style "créer un journal à partir de ce lien". Celà dit, en y réfléchissant, on pourrait remplacer les commentaires par une liste de journaux qui se sont basés dessus avec un truc du genre " Ce lien a inspiré les journaux/dépèches suivantes". On ppurrait pousser le concept un peu plus loin en indiquant également la liste des journaux/dépèches référençant le lien en question. La question est de savoir si on pousse jusqu'à citer les commentaires qui pourraient citer le lien.
Ben déjà, si on pouvait contraindre les gens qui postent un lien à mettre une phrase explicative, ce serait pas mal. un truc du genre "Je partage ce lien ici avec vous parce que …"
Ensuite, je ne suis pas fan de la promotion telle qu'elle est faite aujourd'hui, car sauf changement relativement récent, il me semble que dans le cas d'un journal, les commentaires duit journal ne suivent pas le journal promu en dépèche. Il faut donc suivre deux entrées pour pouvoir suivre le sujet.
Enfin je trouve un peu pourri le principe de balancer des liens sans expliquer pourquoi on partage l'info en question.
Non, je suis content quand je ne peux pas le faire. Si je peux le faire, on va me forcer à le faire et je vais déclencher un post mortem pour expliquer aux gens pourquoi c'est pourri, que si leur prof est si importante que ça il va falloir changer certaines choses et on tente de mettre un plan à exécution pour que ça ne se reproduise jamais.
Donc toi tu préfères bloquer la prod potentiellement pendant plusieurs heures ? De toute façon, même dans un SI géré le mieux du monde, tu n'es pas à l'abri de ce genre de problème. Tellement pas à l'abri que c'est prévu par des pratiques comme ITIL: un workaround doit être tracé et faire l'objet d'une action correctrice.
Après je ne prone pas les modifs sauvages en prod, mais je ne prone pas non plus l'autre extrême dans laquelle tu sembles tomber.
Ça t'arrive tellement souvent que le rapatrier, ça prend trop de temps ?
Ben il n'y a pas que le temps qui rentre en compte. Parfois il y a aussi l'environnement qui est hostile (réseaux séparés nécessitant de passer par des machines de rebond plus ou moins sécurisées par exemple, qui rendent les transferts de fichier difficiles).
Parce que lire le fichier c'est bien,
Ben quand tu sais ce que tu cherches dans un fichier de conf qui n'ajoute pas de bruit, ça se fait plutôt bien.
le comparer avec n'importe quel autre version de ton gestionnaire de conf c'est encore mieux…
Pas toujours possible. On parle d'infra as code, avec des confs calculés, et qui peuvent se vautrer lorsqu'on se trouve dans un cas pas prévu ou mal spécifié dans la demande initiale. Exemple: combinaisons d'installation via déroulement de playbooks/roles ansible qui n'ont pas été prévus pour fonctionner ensemble, et peuvent se marcher l'un sur l'autre et produire des confs étranges dans un cas qui n'a pas été identifié. Difficile (mais pas impossible) de voir ce qui se passe dans le gestionnaire de conf. Si tu peux te baser sur la conf générée par ton outil, ça peut donner des pistes de recherche.
Tu va installer tout ça sur ta prod ?
Tout dépend de la criticité de la prod et des contraintes autour. parfois on va décider de revenir en arrière, corriger le problème, tester et redéployer ultérieurement. Parfois on va modifier direct la prod et ouvrir un ticket d'incident pour corriger le problème. Tout dépend de ce que ça coûte dans chacun des cas. Juste modifier un playbook ou un role + redéployer n'est pas toujours envisageable car les playbooks/roles peuvent être utilisés par ailleurs, et modifier pour le cas spécifique du bug peut en entrainer d'autres pour d'autres déploiements.
La meilleure méthode reste toujours de corriger à la source, mais parfois c'est long à implémenter/tester donc en attendant la correction à la source et l'automatisation, on utilise un workaround directement en prod.
Parce qu'il est déjà arrivé d'avoir un défaut et que tu as eu la flemme de le rapatrier ?
De mémoire non. De toute façon, que l'on corrige ou pas en direct sur la prod, il faut que le problème soit corrigé et que nos tests soient mis à jour pour éviter les régressions.
Parce que si je modifie la prod, je m'assure que ce soit tracé pour que le correctif soit apporté (et pour tout dire, en ce moment c pas moi qui modifie la prod, je suis plutôt chargé de créer les playbooks de déploiement et de les corriger en cas de problème). Et quand j'ai un bug à corriger, je dois passer par un cycle de développement/test/livraison qui peut parfois prendre plus de temps qu'une correction en live.
Mais c'est bizarre d'avoir les livrables qu'en prod
Bof, pas toujours très pratique. Ca se prête bien à certaisn types de contenu, mais pas à d'autres. Un blog vidéo pour montrer comment faire un fondant au chocolat, pourquoi pas, mais pour montrer du code, c'est peut-être pas la meilleure façon de faire (c'est comme le XML, faut pas en mettre partout à toutes les sauces).
Ben non : souvent, j'utilise un journal pour pouvoir ouvrir une discussion sur un thème donné. Or, si le thème a déjà été abordé dans la section lien, pourquoi se répéter ?
… ce qui est completement débile à mon avis car: on génère de la redondance inutile.
1/ on a 2 voire 3 entrées sur le même sujet
2/ on a potentiellement des commentaires redondants côté journal et côté lien
3/ balancer des URL à la g***** sans expliquer un minimum de quoi il est question, en laissant les autres rédiger, je trouve ça méprisant ou insultant.
Je suis allé voir côté liens et je trouve que certains sujets auraient mérité un journal (et en aurait eu il y a quelques temps). Par exemple :
- Les réseaux sociaux nous enferment dans des « bulles » de pensée
- Windows 10 installe des applications automatiquement, et vous le fait savoir
- solution logicielle générique d’archivage électronique interministériel Vitam
- Menace sur l'open data par défaut
Sinon, dans le genre débile j'ai ça :
- Google + Mastercard = ++ donnée personnel
Ca veut dire quoi ?
Et je persiste : quand je vois qu'un sujet a été posté en lien, ça ne me donne absolument pas envie de reposter sur le même siujet en journal ou en dépèche. Et je ne dois pas être le seul.
l'obligation d'écrire un long blabla freine les gens, les dissuade de contribuer.
Pourquoi ? Crois-tu que balancer un lien va encourager les gens à participer ? La rubrique lien a fortement fait baisser l'intéret de Linuxfr. Il m'est déjà arrivé à plusieurs reprises de vouloir partager une info ici, et d'ouvrir une discussion mais de m'arrêter juste parce que qqn avait déjà balancé un lien dans la rubrique en question. Alors oui, il y a plus de gens qui postent des liens, mais d'un autre côté, on perd en qualité sur les journaux par exemple.
Celà dit je comprends le raisonnement (avoir la possibilité de l'interdire par défaut mais de l'ouvrir si besion), mais l'idée est que potentiellement, tu peux en avoir besoin.
Ben moi ça m'est déjà arrivé de devoir au moins visualiser un fichier xml sur un serveur de prod, pour vérifier que celui-ci était bien conforme à ce qui était attendu.
Maintenant qu'on en a fini avec les personnes tu va m'expliquer que "dans la vraie vie" on édite les fichiers de prod à la main parce que le client c'est qu'un méchant etc ? Il n'y a personne qui a entendu parler d'infrastructures immuables ? Ou d'infra as code ?
Ben si, je bosse en plein dedans en ce moment. Il m'arrive d'aller voir sur des serveurs de prod si des fichiers de conf sont bien conforme à ce que je m'attends d'avoir, même dans le cadre d'infrastructure as code (parce que il nous est déjà arrivé dans des phases de déploiement d'avoir des choses bizarres qui se passent parce qu'une combinaison de causes non imaginées donc non testées ont pour conséquence de corrompre des confs). Et dans ce cas il peut être nécessaire de corriger manuellement le problème en attendant que les référentiels ou les outils de déploiement soient mis à jour.
Donc même avec des trucs du style infra as code, il sera toujours nécessaire d'avoir moyen de savoir ce qui se passe sur un serveur (là ou je suis en ce moment, ya des personnes qui veulent aller jusqu'à interdire les connections ssh, mais je suis certain que ça n'arrivera jamais, ou si ça se fait, on reviendra rapidement en arrière).
[^] # Re: question
Posté par totof2000 . En réponse au journal Déçu, déçu, déçu. Évalué à 2.
Je ne vois pas pourquoi lorsque je code par exemple, je devrais adopter un style qui ne me convient pas, ou auquel mon cerveau n'est pas habitué, juste parce que quelqu'un pense détenir la vérité et l'impose aux autres.
En voulant tout règlementer, on en arrive à des trucs sclérosés et contre productifs, qui inhibent la créativité.
Dans du code, par exemple, je ne vois pas pourquoi on irait pourrir la vie d'un développeur parce qu'il utilise un style de codage différent des autres, à partir du moment ou les interactions externes sont définies et normalisées (l'interface de codage).
Ensuite, on peut utiliser des outils de mise en forme pour uniformiser les trucs tels qu'indentation, etc … mais aller trop loin est en général contre productif.
Après, établir certaines conventions ne fait pas de mal lorsqu'elles sont simples et facilement assimilables (par exemple éviter d'utiliser des noms de variables qui ne veulent rien dire, par exemple a = machin, b = truc …), mais aller dans l'arbitraire (style coder des variables avec les 3 premiers caractères qui correspondent à un truc, les 5 suivants à un autre et les 2 dernier a encore autre chose) ne mène jamais à rien de bien.
[^] # Re: bof
Posté par totof2000 . En réponse au journal Un développeur qui dénonce. Évalué à 3. Dernière modification le 06 octobre 2018 à 12:01.
Relis plus haut mon commentaire sur ibus qui prend plus de 100% de CPU et qui fait se décharger la batterie de mon ordinateur portable bien plus vite que la normale.
Alors certes sur un téléphone, c'est plus difficile à détecter, mais si les utilisateurs avaint moyen de voior que leur batterie ne tient pas la charge parce que ya un tas d'applis qui n'optimisent pas leurs algo et bouffent de l'énergie pour rien, je suis certain que le point de vu des développeurs changerait.
Juste pour info, j'ai éjà vu dans les commentaires de certaines applis, des gens qui l'ont désinstallé parce qu'ils ont remarqué que ces fameuses applis avaient tendance à diminuer l'autonomie de leur batterie.
[^] # Re: Ce que j'en pense ....
Posté par totof2000 . En réponse au journal Un développeur qui dénonce. Évalué à 2.
La lourdeur et la lenteur ne sont pas forcément les points les plus importants. Je ne dis pas qu'il fallait garder les scripts d'inits comme ils étaient, par contre la façon de faire de systemd n'est pas non plus la bonne façon de faire.
Les scripts d'init avaient pour gros avantage d'être modifiables et personnalisables à l'envie, de ne pas enfermer les admins dans un moule rigide (ou t'es obligé de te tordre le cerveau dès que tu n'es pas dans un cas prévu), et de pouvoir corriger les bugs du système de démarrage sans avoir à recompiler et attendre une livraison de nouvelle version.
Le fait que les scripts soient des scripts permettait en outre si on le voulait d'étudier facilement ce qu'ils faisaient en les modifiants, sans avoir à passer par des phases de compilation assez lourdes (bien entendu, je parle de faire ça dans un environnement de test, pas sur de la prod …).
A contrario, systemd est un truc plutôt "boite noire" qui peut effectivement permettre de gagner du temps lorsque l'on rentre dans le moule (90% des cas), mais qui fait perdre bien plus de temps pour gérer les 10% de cas non prévus par le bouzin (et manque de bol pour moi, c mon job de gérer ces cas de figure).
Je ne nie pas que systemd apporte un certain nombre d'avantages (par exemple la possibilité de monitorer un process et de le relancer s'il se vautre tout seul), mais il apporte un gros lot d'inconvénients, notamment une perte de souplesse par rapport à init ou upstart.
[^] # Re: bof
Posté par totof2000 . En réponse au journal Un développeur qui dénonce. Évalué à 1. Dernière modification le 05 octobre 2018 à 17:59.
Ben si on veut économiser de l'énergie, on a plutôt intéret à ne pas trop faire mouliner le CPU, donc ça répond à au moins aux 2 premières questions. Perso, je préfère sacrifier un peu de réactivité à une surconsomation d'énergie sur un mobile.
[^] # Re: C'était mieux avant
Posté par totof2000 . En réponse au journal Un développeur qui dénonce. Évalué à 5. Dernière modification le 05 octobre 2018 à 12:53.
tu diras ça aux ordinateurs portables qui plantent sauvagement à cause de la surchauffe lors d'un test mémoire avec memtest.
La plupart des PC portables ne sont pas fait pour tourner à 100% de leur capacité en permanence. Quand tu exécutes un OS comme windows par exemple, celui-ci ralentit la vitesse à laquelle ta machine fonctionne lorsqu'il surchauffe, ce qui fait que tu ne t'en reds même pas compte. Par contre avec un test mémoire, ya pas de régulation de la vitesse en fonction de la température et ça plante.
[^] # Re: bof
Posté par totof2000 . En réponse au journal Un développeur qui dénonce. Évalué à 3.
Pour des applis sur mobiles, je m'attends à ce que l'appli ne fasse pas de trucs inutiles, pour ne pas bouffer ma batterie, donc la perf à mon avis n'est absolument pas à négliger : un CPU qui mouline inutilement à cause d'un algo peu performant bouffe de l'énergie.
[^] # Re: Ce que j'en pense ....
Posté par totof2000 . En réponse au journal Un développeur qui dénonce. Évalué à 3. Dernière modification le 04 octobre 2018 à 15:15.
Merci, tu confirmes bien ce que j'en avais compris.
[^] # Re: Ce que j'en pense ....
Posté par totof2000 . En réponse au journal Un développeur qui dénonce. Évalué à 0.
Ben j'ai rencontré le même type de problème sur une redhat qui n'a rien d'expérimental. Je t'accorde que ce genre de bug a tendance à se faire un peu plus rare, mais ça arrive encore que systemd se vautre lamentablement dans certains cas. La ou ça me gène, c'est surtout qu'avant systemd, un bug sur le système d'init pouvait être facilement corrigé sans attendre de mise à jour d'OS (c'est du script), là ou aujourd'hui, il faut attendre le bon vouloir de RedHat pour corriger.
Je viens d'aller voir l'exemple que tu as donné, et je me pose une question : pourquoi le script init de redhat crée-t-il son user à cet endroit précis ? Et pourquoi la création de répertoire doit-elle se faire au démarrage ? côté systemd, ça se fait ou et à quel moment ? (je suis pas un expert nginx donc je ne sais pas trop pourquoi il a besoin de faire ce genre de truc)
Bah, quand il s'agit de faire un bete start/stop, ça prend pas beaucoup plus de temps (je l'ai déjà fait pas mal de fois). Et quand il s'agit de custommiser, systemd est bien chiant :j'ai passé pas mal de temps l'an dernier à faire une pauvre unit pour démarrer un apache compilé maison, auquel je devais faire passer certaines variables d'environnement (j'ai plus les détails en tête, mais si j'avais du faire ça en init classique, ça m'aurait pris bien moins de temps).
[^] # Re: Ce que j'en pense ....
Posté par totof2000 . En réponse au journal Un développeur qui dénonce. Évalué à -1. Dernière modification le 03 octobre 2018 à 16:45.
Bah, voilà le genre de plaisanteries que peut faire systemd. Et j'en ai eu d'autres.
Ben moi il m'en fait perdre bien trop.
Au passage, j'aimerais bien comprendre en quoi systemd te manque sous freebsd.
[^] # Re: bof
Posté par totof2000 . En réponse au journal Un développeur qui dénonce. Évalué à 8.
On a compris ou sont passé les 150 Mo … ;)
[^] # Re: Pourquoi plutôt EPUB 2 ?
Posté par totof2000 . En réponse à la dépêche Des fichiers EPUB avec LibreOffice 6.1 sans extension. Évalué à 3. Dernière modification le 03 octobre 2018 à 15:00.
C'est pas toi qui est visée par mon commentaire, mais les gens qui ont ce genre d'idées.
[^] # Re: Pourquoi plutôt EPUB 2 ?
Posté par totof2000 . En réponse à la dépêche Des fichiers EPUB avec LibreOffice 6.1 sans extension. Évalué à 9.
euh … Faudrait penser à arrêter ce genre de délire. Après les livres qui ne te donnent que la moitiés des informations dont ils sont censés traiter (parce que des pans entiers de code source et d'exemples sont en ligne - a priori on ne sait pas pour combien de tamps), va-t-on voir sortir les ebooks que l'on ne peut lire que sur imachin ou galaxytruc parce que celui-ci contient des séquences animées qui ne sont absolument pas gérables par des liseuses ?
On part vraiment dans le gros n'importe quoi.
# Ce que j'en pense ....
Posté par totof2000 . En réponse au journal Un développeur qui dénonce. Évalué à 10. Dernière modification le 03 octobre 2018 à 11:45.
D'abord sur le fond, je suis assez d'accord avec le texte originel. Dernièrement, je me disais que la batterie de mon ordinateur portable se déchargeait bien vite. En regardant l'applet qui monitore les ressources systèmes, je me suis apperçu que le CPU était pas mal sollicité … et je me suis rendu compte en regardant les process qui tournaient, qu'un ibus prenait plus de 100% de CPU … :(
Je me suis demandé si je rêvais (d'autant plus qu'ibus m'a pris la tête sur mon fixe sous freebsd - il passe son temps
à ignorer le fait que j'utilise un clavier fr, du coup je l'ai désactivé). Sur mon portable, j'ai juste eu à tuer ibus et redémarrer les applications qui semblaient l'utiliser (la saisie clavier ne marchait plus sur l'une d'elles), et l'occupation CPU est redevenue plus raisonnable. Bilan : je me trouve sur ma machine avec un truc qui a priori ** ne sert a rien ** et prend plus de 100% CPU. Ce que je redoute, c'est que ce truc inutile devienne incontournable a l'avenir, et fasse perdre encore de l'autonomie à ma batterie.
Ici je parle d'ibus parce que c'est un truc qui m'est arrivé il y a peu, mais j'ai déjà bien ralé dans le passé parce que des gens ont voulu remplacer un truc qui marchait plutôt bien, qui avait mis du temps à être débuggé, par un truc pas fini qui vient pourrir la vie des utilisateurs (exemple : systemd), ou des trucs pas finis qui viennenet également pourrir la vie des gens (exemple : pulseaudio). J'ai constaté le même phénomène avec hplip: un processus python qui vient à utiliser de grosses quantités de CPU pour rien (au passage, je pense que pour développer ce genre de truc en python, faut être malade, ou avoir envie de décharger les batteries des portables des utilisateurs).
Celà dit, je pense qu'on arrive à la fin d'un cycle et que ces pratiques vont commencer à s'atténuer (si ce n'est disparaître - au moins pour quelques temps). En effet, le coût de la mémoire RAM a pas mal augmenté ces derniers temps, et le cout des processeurs Intel également: j'ai l'impression que l'ère du matériel pas cher est en train de se terminer, et qu'on va voir celui-ci augmenter considérablement dans les années à venir (sans compter le cout de l'énergie qui à mon avis risque d'augmenter fortement). Du coup les développeurs devront réapprendre à optimiser leurs programmes pour qu'ils puissent tourner sur des confs hardware moins gourmandes, et utilisent moins d'énergie pour fonctionner. Alors certes, les restrictions hardwares ne seront probablement pas aussi fortes que dans les débuts de l'informatique, mais je suis d'avis qu'on ne pourra plus faire comme aujourd'hui : considérer qu'optimiser le soft coute plus cher que d'ajouter des capacités hardware.
# Pour que ta machine soit joignable depuis le net ....
Posté par totof2000 . En réponse au message Configuration DNS. Évalué à 2. Dernière modification le 30 septembre 2018 à 18:47.
… il te faut enregistrer ton nom de domaine auprès d'un registrar.
En effet, le DNS est une espèce de base de données géante et distribuée (voir https://fr.wikipedia.org/wiki/Domain_Name_System ou https://openclassrooms.com/fr/courses/857447-apprenez-le-fonctionnement-des-reseaux-tcp-ip/857163-le-service-dns) , et pour pouvoir être enregistré dans cette base, il faut qu'une autorité habilitée à la modifier le fasse.
Cette autorité de donnera la possibilité de gérer to domaine comme tu le veux. Soit ton fournisseur te donnera une interface avec laquelle tu pourras directement enregistrer les informations, soit tu entreras l'IP de ton serveur DNS qui aura autorité pour répondre aux informations disponibles pour ton domaine.
As-tu déposé ton nom de domaine ?
[^] # Re: Nous les anciens
Posté par totof2000 . En réponse au journal Journal qui dénonce [E13S20]. Évalué à 6.
Je résume: on pourrait avoir un truc comme ça :
Lien: titre du lien
posté par ….
Puis une description succinte (avec début prérempli, via une liste de choix par exemple)
"Je partage ce lien avec vous parce que ….. "
En dessous, un bouton "créer un journal (ou une dépeche) a partir de ce lien.
Ensuite, à la place des commentaires, la liste des journaux et/ou dépèches créées en cliquant sur le bouton :
Ce lien a inspiré les contenus suivants:
Journal: [titre du journal] **### Votre titre
premiere(s) phrase(s) du journal, un peu comme dans les moteurs de recherches
Journal: [titre du journal]
premiere(s) phrase(s) du journal, un peu comme dans les moteurs de recherches
Dépèche: [titre de dépèche] **
premiere(s) phrase(s) de la dépèche, un peu comme dans les moteurs de recherches
Enfin, la liste des journaux/dépèches référençant ce lien :
Journal: [titre du journal] **### Votre titre
premiere(s) phrase(s) du journal, un peu comme dans les moteurs de recherches
Journal: [titre du journal]
premiere(s) phrase(s) du journal, un peu comme dans les moteurs de recherches
Dépèche: [titre de dépèche] **
premiere(s) phrase(s) de la dépèche, un peu comme dans les moteurs de recherches
Je ne sais pas si c'est clair …
[^] # Re: Nous les anciens
Posté par totof2000 . En réponse au journal Journal qui dénonce [E13S20]. Évalué à 2. Dernière modification le 28 septembre 2018 à 18:33.
Je suis pas fermé par principe, mais pas convaincu non plus. Et au niveau du bouton, je préfèrerais une appellation du style "créer un journal à partir de ce lien". Celà dit, en y réfléchissant, on pourrait remplacer les commentaires par une liste de journaux qui se sont basés dessus avec un truc du genre " Ce lien a inspiré les journaux/dépèches suivantes". On ppurrait pousser le concept un peu plus loin en indiquant également la liste des journaux/dépèches référençant le lien en question. La question est de savoir si on pousse jusqu'à citer les commentaires qui pourraient citer le lien.
[^] # Re: Nous les anciens
Posté par totof2000 . En réponse au journal Journal qui dénonce [E13S20]. Évalué à 5. Dernière modification le 28 septembre 2018 à 18:22.
Ben déjà, si on pouvait contraindre les gens qui postent un lien à mettre une phrase explicative, ce serait pas mal. un truc du genre "Je partage ce lien ici avec vous parce que …"
Ensuite, je ne suis pas fan de la promotion telle qu'elle est faite aujourd'hui, car sauf changement relativement récent, il me semble que dans le cas d'un journal, les commentaires duit journal ne suivent pas le journal promu en dépèche. Il faut donc suivre deux entrées pour pouvoir suivre le sujet.
Enfin je trouve un peu pourri le principe de balancer des liens sans expliquer pourquoi on partage l'info en question.
[^] # Re: Appel aux testeurs et aux contributeurs
Posté par totof2000 . En réponse à la dépêche Linux capabilities : se passer des commandes su et sudo. Évalué à 2.
Donc toi tu préfères bloquer la prod potentiellement pendant plusieurs heures ? De toute façon, même dans un SI géré le mieux du monde, tu n'es pas à l'abri de ce genre de problème. Tellement pas à l'abri que c'est prévu par des pratiques comme ITIL: un workaround doit être tracé et faire l'objet d'une action correctrice.
Après je ne prone pas les modifs sauvages en prod, mais je ne prone pas non plus l'autre extrême dans laquelle tu sembles tomber.
[^] # Re: Appel aux testeurs et aux contributeurs
Posté par totof2000 . En réponse à la dépêche Linux capabilities : se passer des commandes su et sudo. Évalué à 2. Dernière modification le 28 septembre 2018 à 18:00.
Ben il n'y a pas que le temps qui rentre en compte. Parfois il y a aussi l'environnement qui est hostile (réseaux séparés nécessitant de passer par des machines de rebond plus ou moins sécurisées par exemple, qui rendent les transferts de fichier difficiles).
Pas toujours possible. On parle d'infra as code, avec des confs calculés, et qui peuvent se vautrer lorsqu'on se trouve dans un cas pas prévu ou mal spécifié dans la demande initiale. Exemple: combinaisons d'installation via déroulement de playbooks/roles ansible qui n'ont pas été prévus pour fonctionner ensemble, et peuvent se marcher l'un sur l'autre et produire des confs étranges dans un cas qui n'a pas été identifié. Difficile (mais pas impossible) de voir ce qui se passe dans le gestionnaire de conf. Si tu peux te baser sur la conf générée par ton outil, ça peut donner des pistes de recherche.
Tout dépend de la criticité de la prod et des contraintes autour. parfois on va décider de revenir en arrière, corriger le problème, tester et redéployer ultérieurement. Parfois on va modifier direct la prod et ouvrir un ticket d'incident pour corriger le problème. Tout dépend de ce que ça coûte dans chacun des cas. Juste modifier un playbook ou un role + redéployer n'est pas toujours envisageable car les playbooks/roles peuvent être utilisés par ailleurs, et modifier pour le cas spécifique du bug peut en entrainer d'autres pour d'autres déploiements.
La meilleure méthode reste toujours de corriger à la source, mais parfois c'est long à implémenter/tester donc en attendant la correction à la source et l'automatisation, on utilise un workaround directement en prod.
De mémoire non. De toute façon, que l'on corrige ou pas en direct sur la prod, il faut que le problème soit corrigé et que nos tests soient mis à jour pour éviter les régressions.
Parce que si je modifie la prod, je m'assure que ce soit tracé pour que le correctif soit apporté (et pour tout dire, en ce moment c pas moi qui modifie la prod, je suis plutôt chargé de créer les playbooks de déploiement et de les corriger en cas de problème). Et quand j'ai un bug à corriger, je dois passer par un cycle de développement/test/livraison qui peut parfois prendre plus de temps qu'une correction en live.
Pas si bizarre que ça. Parce que
[^] # Re: LinuxFR change
Posté par totof2000 . En réponse au journal Journal qui dénonce [E13S20]. Évalué à 4.
Bof, pas toujours très pratique. Ca se prête bien à certaisn types de contenu, mais pas à d'autres. Un blog vidéo pour montrer comment faire un fondant au chocolat, pourquoi pas, mais pour montrer du code, c'est peut-être pas la meilleure façon de faire (c'est comme le XML, faut pas en mettre partout à toutes les sauces).
[^] # Re: Nous les anciens
Posté par totof2000 . En réponse au journal Journal qui dénonce [E13S20]. Évalué à 4. Dernière modification le 28 septembre 2018 à 17:17.
Ben non : souvent, j'utilise un journal pour pouvoir ouvrir une discussion sur un thème donné. Or, si le thème a déjà été abordé dans la section lien, pourquoi se répéter ?
[^] # Re: Nous les anciens
Posté par totof2000 . En réponse au journal Journal qui dénonce [E13S20]. Évalué à 9.
… ce qui est completement débile à mon avis car: on génère de la redondance inutile.
1/ on a 2 voire 3 entrées sur le même sujet
2/ on a potentiellement des commentaires redondants côté journal et côté lien
3/ balancer des URL à la g***** sans expliquer un minimum de quoi il est question, en laissant les autres rédiger, je trouve ça méprisant ou insultant.
Je suis allé voir côté liens et je trouve que certains sujets auraient mérité un journal (et en aurait eu il y a quelques temps). Par exemple :
- Les réseaux sociaux nous enferment dans des « bulles » de pensée
- Windows 10 installe des applications automatiquement, et vous le fait savoir
- solution logicielle générique d’archivage électronique interministériel Vitam
- Menace sur l'open data par défaut
Sinon, dans le genre débile j'ai ça :
- Google + Mastercard = ++ donnée personnel
Ca veut dire quoi ?
Et je persiste : quand je vois qu'un sujet a été posté en lien, ça ne me donne absolument pas envie de reposter sur le même siujet en journal ou en dépèche. Et je ne dois pas être le seul.
[^] # Re: Nous les anciens
Posté par totof2000 . En réponse au journal Journal qui dénonce [E13S20]. Évalué à 10.
Pourquoi ? Crois-tu que balancer un lien va encourager les gens à participer ? La rubrique lien a fortement fait baisser l'intéret de Linuxfr. Il m'est déjà arrivé à plusieurs reprises de vouloir partager une info ici, et d'ouvrir une discussion mais de m'arrêter juste parce que qqn avait déjà balancé un lien dans la rubrique en question. Alors oui, il y a plus de gens qui postent des liens, mais d'un autre côté, on perd en qualité sur les journaux par exemple.
[^] # Re: Permissions Android
Posté par totof2000 . En réponse à la dépêche Linux capabilities : se passer des commandes su et sudo. Évalué à 2.
Pourquoi ? Quid de ce genre de truc ?
Celà dit je comprends le raisonnement (avoir la possibilité de l'interdire par défaut mais de l'ouvrir si besion), mais l'idée est que potentiellement, tu peux en avoir besoin.
[^] # Re: Appel aux testeurs et aux contributeurs
Posté par totof2000 . En réponse à la dépêche Linux capabilities : se passer des commandes su et sudo. Évalué à 3.
Ben moi ça m'est déjà arrivé de devoir au moins visualiser un fichier xml sur un serveur de prod, pour vérifier que celui-ci était bien conforme à ce qui était attendu.
Ben si, je bosse en plein dedans en ce moment. Il m'arrive d'aller voir sur des serveurs de prod si des fichiers de conf sont bien conforme à ce que je m'attends d'avoir, même dans le cadre d'infrastructure as code (parce que il nous est déjà arrivé dans des phases de déploiement d'avoir des choses bizarres qui se passent parce qu'une combinaison de causes non imaginées donc non testées ont pour conséquence de corrompre des confs). Et dans ce cas il peut être nécessaire de corriger manuellement le problème en attendant que les référentiels ou les outils de déploiement soient mis à jour.
Donc même avec des trucs du style infra as code, il sera toujours nécessaire d'avoir moyen de savoir ce qui se passe sur un serveur (là ou je suis en ce moment, ya des personnes qui veulent aller jusqu'à interdire les connections ssh, mais je suis certain que ça n'arrivera jamais, ou si ça se fait, on reviendra rapidement en arrière).