MS subit un tort, la demande est d'arreter ce tort immediatement, la methode proposee est de rediriger les domaines. Le juge a dit oui car il a estime que la requete etait raisonnable au vu des arguments.
Franchement, un juge qui peut dire oui à ce genre de demande, soit il est très très mal conseillé techniquement (sans déconner, tu as déjà vu faire saisir des noms de domaines qui sont pourtant utilisés légitimement 90% du temps ?), soit on l'a un peu aidé avec un chèque, c'est pas possible autrement.
Le souci, c'est s'il faut apprendre un nouveau langage, et régler au poil de fesse le moindre logiciel, même en utilisant un nombre restreint de logiciels, ça fait quand même pas mal d'heures à régler des outils. Certes, la puissance qui en résulte est sûrement impressionnante, mais bon, je suis sceptique.
Je vais un peu faire comme les autres et essayer de te convaincre : on n'est pas obligé d'apprendre tout le langage de vim. Mais pouvoir copier/coller quelques fragments qu'on a trouvé à droite à gauche et les personnaliser un peu, c'est vraiment super utile. J'ai passé 10 ans avec un vim « de base », mais depuis quelques années j'ai commencé à faire plus attention à sa configuration (ça a commencé à cause du bépo…), et même si ça prend un peu de temps, c'est comme pour vim quand tu commences : c'est un investissement. Oui, la courbe est dure au début, mais après tu gagnes beaucoup en confort. Mon éditeur de texte est un outil que j'utilise beaucoup, et j'utilise toujours le même depuis longtemps, et je ne regrette pas du tout le temps que j'ai passé à apprendre les bases de son langage qui est effectivement un peu étrange.
De ce fait, par pudeur et par respect pour les autres, je ne souhaite pas forcément mettre à disposition ces versions intermédiaires moche et crade, mais plutot garder ça pour moi (avec commits intermédiaires dans mon repo local), et ne diffuser que les verions qui me paraissent suffisamment propre et finalisées.
D'un côté, ça se comprend, mais d'un autre, tu verras que le travail de refactorisation ça n'est pas anodin, et ça prend parfois beaucoup de temps. Au point où parfois tu ne finis par pas diffuser le code parce que tu n'as pas le temps de le refactoriser… (histoire vécue) Perso, j'ai appris à essayer de mettre vaguement au propre au moment où je code (éventuellement en squashant quelques commit, ou en essayant de pas commiter trop vite ; il y a un bon « rythme » à trouver entre tous commiter dès que possible, chose très facile en git, et prendre un peu son temps pour ne pas avoir trop de minuscules commits), et à ne pas faire trop attention aux « détails » de propreté une fois que c'est fait : c'est super chiant de revenir sur son code des jours ou des semaines après, parfois. Il faut accepter de publier du code pas tout à fait propre, parce que sinon ça devient une sorte de psychose qui t'empêche de publier plutôt qu'autre chose.
Est-ce possible de faire ça, sans que ceci ne perturbe trop les autres contributeurs ?
Avant du publier, oui, rebase autant que tu veux. Mais une fois publié, c'est public, c'est fini. En plus, publier des choses pas forcément idéales que tu corriges après, ça permet de montrer aux gens comment tu fais des erreurs mais aussi comment tu les corriges : c'est plus « humain », et ça apprend aussi à ceux qui te lisent.
Que pensez-vous de cette organisation ? Avez-vous des améliorations à proposer ? Faudrait-il plusieus dépots Git/Mercurial (ou autre) ? Comment faites-vous sur vos projets ?
Ne te prends pas trop la tête sur une organisation tip-top dès le départ : avec l'expérience, tu auras sûrement envie de changer… Donc je te conseille de faire un seul répo, avec tes branches qui correspondent aux stades de développement dont tu parles (en gérant bien évidemment comme tu le souhaites les permissions).
Remarque : peut-être que je ne diffuserai jamais mon code, mais la curiosité me pousse à vous poser ces questions.
Je pense que tu te prends beaucoup trop la tête sur la « propreté » d'un code :-) Tu n'en mourras pas, de publier des trucs « pas propres ». Au contraire, je pense que ça t'apprendra d'autant plus, car c'est en essayant et en se plantant qu'on apprend à s'améliorer.
Je suppose que Mageia, comme toute distrib linux un peu récente, installe avahi par défaut ; du coup, tu pourrais plutôt utiliser directement les noms de tes machines, en y ajoutant le suffixe ".local". Genre dans ton navigateur, tu tapes "http://monlaptop.local", et ça devrait marcher.
OpenShift et OpenStack ne sont pas concurrent, le premier est du PaaS et le deuxième du IaaS.
Oui, mais c'est pour dire que Red Hat privilégie une autre vision, je pense, plutôt que la virtualisation à outrance : une gestion de la virtualisation plus « bas niveau », avec des surcouches plus simples à libvirt (voire pas du tout), évitant l'énorme couche d'abstraction qu'est OpenStack (sachant que libvirt en est déjà une pas mal grosse, mais plutôt bien faite je trouve). Par-dessus par contre, une gestion plus Cloud mais pour du PaaS, comme tu dis, avec OpenShift. Leur intérêt là-dedans, c'est que la virtualisation à outrance c'est valable pour les applis/serveurs complètement fermés et proprios ; quand on est orienté libre, on n'a moins d'intérêt à se diriger vers de telles solutions, qui sont quand même assez lourdes. Je pense qu'ils verraient bien aussi un truc genre Docker, mais paf : LXC est déjà géré par libvirt, ils n'ont rien à faire de plus pour gérer ça (par contre je ne sais rien du support des conteneurs par OpenStack). OK, Docker c'est un peu plus que du LXC, mais tu vois le truc.
Après, je ne savais pas que eNovance faisait du OpenStack, du coup ça contre un peu mon argument…
Normalement en Chine, si tu le demandes, et si tu mets le prix adéquat, tu peux avoir de la qualité.
Tout à fait. C'est juste qu'après, c'est quoi l'intérêt de le fabriquer là-bas si on peut y arriver au même prix ici ? Bon après, Kyocera ce sont des coréens, alors pour eux la Chine ça n'est pas si loin…
Red Hat veut renforcer sa position dans le projet OpenStack sur lequel ils sont déjà leader en nombre de contributions.
Heu… mon analyse perso c'est qu'ils renforcent leur position dans des technos de virtualisation et de stockage distribuées qui pourraient être utilisées avec OpenStack, mais ça n'est vraiment pas renforcer sa position dans OpenStack lui-même. Voir pour ça l'avis des devs de libvirt sur OpenStack, et le fait que Ceph n'était pas vraiment un des backend prévu à la base pour OpenStack, etc. Bien sûr que la gestion de « Cloud » ça marche à fond en ce moment, donc ils s'y investissent, mais d'une Red Hat a sa propre techno avec OpenShift, et de deux il faut voir comment est le code d'OpenStack… D'ailleurs, en tant qu'expert python, j'aimerais bien ton avis sur le code, si tu es déjà allé faire un tour dedans (attention, ça pique les yeux ; enfin, j'en ai fait une étude il y a un peu moins de deux ans, et ça n'était pas joli à l'époque).
J'ai le Kyocera présenté dans ce lien. C'est effectivement un des seuls non-électriques que j'ai trouvé. Il a l'air bien costaud, même si c'est fabriqué en Chine pour ceux qui se demanderaient (enfin, ils mettent que le verre est fabriqué au Japon… j'aurais plutôt fait valoir la qualité des engrenages en céramiques, mais bon). Eh oui, même à ce prix… En parlant de prix, j'ai trouvé le miens moins cher dans ma Biocoop locale (43 € je crois). Un petit défaut : il n'a pas de couvercle supérieur donc quand on moud, des grains peuvent sauter en dehors. En passant, j'avais oublié que pour moudre du grain, il faut une certaine force quand même, ça n'est pas de tout repos.
Quel existant? Plein de commandes de systemd n’existaient pas avant.
C'te blague ; extrait de https://github.com/systemd/systemd/tree/master/src là ou je vois des outils qui existaient déjà : ask-password, backlight, cryptsetup, fsck (sans déconner !), hostname, locale, modules-load, network (je vois qu'ils ont réimplémenté tout iproute, sans même utiliser libnl), readahead, remount-fs, resolve, sysctl, …
En passant, à chaque fois aucun commentaire en haut du fichier pour expliquer ce que ça fait exactement : il faut aller voir le main().
Alors après, l'existant c'est un paquet de spaghetti hétéroclite immonde, mais avec des années et des années de polissage derrière. On sait très bien que quand un mec arrive en disant qu'il va tout régler d'un coup, on va se prendre des systèmes cassés pendant des lustres. Peut-être qu'il était tant, mais bon, non, ça n'a pas été fait de manière « modulaire » itérative, comme on aurait pu remplacer petit à petit les outils.
Je ne vois pas ce qu’il y a de mal, systemd est en quelque sortes une couche d’abstraction du noyau;
Ah ouai, carrément ?
normal qu’il empêche les autres programmes de mettre le bazar et qu’il donne des API pour les programmes externes. Et la hiérarchie a l’air plutôt propre comme ça.
Heu… Lennart ne trouvait pas ça « normal » à priori avant, vu que c'est comme ça que c'était depuis un bout de temps. Et donc maintenant, les cgroup ça doit appartenir à systemd et c'est tout point ; voilà un système coopératif… Alors après, ils ont étudié les solutions et c'est à priori la meilleure, mais alors qu'on ne se targue pas de se la jouer « à la UNIX » : non, tu fais différemment ; et bien assume-le.
Ensuite, la façon dont notre projet est géré (c'est-à-dire maintenir la majeure partie du cœur de l’OS dans un unique dépôt git) est plus proche du modèle BSD (qui est un vrai UNIX, pas comme Linux) dans la façon de faire (où la plus grande partie du cœur de l’OS est conservé dans un seul répertoire CVS/SVN) que de la façon de faire de Linux.
Ça, effectivement, c'est quelque chose de vraiment embêtant je trouve.
En quoi?
Et bien maintenant tu as un mainteneur tête de nœuds pour la base d'une partie énorme de ton système. Pour caricaturer UNIX, les « haters » disaient que l'auteur de "head" n'était pas le même que celui de "tail" (et c'est vrai !) ; c'est un peu extrême, mais ça a toujours été comme ça que ça se passe. Les projets avec un mono-maniaque qui décide d'une partie énorme de ton système, ça craint. Torvalds est visé du coup, mais disons que lui fait plus « consensus », si on peut dire.
Non c’est pas hypocrite, c’est les autres projets qui sont venus se greffer à systemd, pas le contraire.
Heu… ça fait un peu « parain de la mafia » comme remarque…
Il n’y a jamais eu de XML dans systemd, et même s’il y en avait le XML c’est pas un truc maléfique hein.
Je parlais des communications par dbus. Choses que l'utilisateur ne voit pas, mais quand tu écris un soft et que tu veux communiquer avec le démon « système » maintenant, tu dois te palucher du XML.
Et genre les «petits bénévoles» avant ils modifiaient SysV ou Upstart? Non. De la même façon, les «petits bénévoles» ne vont pas faire de grosses modifications au cœur de Firefox.
Nan mais tu as pris la grosse tête comme Lennart ? Moi j'ai écrit des scripts SysV pour des softs, oui, et je me permet d'aller voir dans le code que je veux, quand il est pas trop mal fait.
Non, ça gère plus que ça (j'ai des projets en shell avec autotools), et à priori, ça marche sur un paquet de plateformes (au moins OSX et BSD), même si pour Windows, c'est peut-être pas l'idéal car il faut MinGW.
Comme d'hab, ça n'est pas que je n'aime pas systemd (il y a plein de bonnes idées dedans), mais la manière dont c'est fait et présenté. Mes quelques remarques :
systemd est constitué de plus de 70 binaires (NdT : 72 sur ma machine !) clairement séparés.
Qui ont leur propres standards d'options et ne réutilisent pas l'existant. Être modulaire, c'est une chose, mais généralement quand on dit ça c'est qu'on interagit bien avec le reste de l'écosystème. Ça va dans le sens du « il faut tout réapprendre », qui peut parfois être nécessaire, certes, mais là c'est vraiment « on refait tout sans utiliser l'existant ». Pourquoi pas, mais de là à se vanter de séparer ses modules et de se dire modulaire au sens d'UNIX… Busybox fait ça, de manière un peu moins « je remplace tout » puisqu'il remplace tout, mais avec des commandes qui respectent scrupuleusement la syntaxe de celles d'origine.
Par exemple, l’idée d’UNIX du « tout est fichier » trouve son jumeau dans systemd où tous les services sont exposés au lancement dans un système de fichiers du noyau, le cgroupfs.
Dommage, cette idée vient d'être foutue en l'air pour les prochaines version de systemd, cf http://lists.freedesktop.org/archives/systemd-devel/2013-June/011521.html : tout devra passer par l'API dbus désormais. On pourra éventuellement, pour la lecture, passer par cgroupfs, mais je vous laisse déguster la syntaxe de la nouvelle hiérarchie (la compatibilité ascendante c'est pour les nuls), par exemple ici présentée dans le projet libvirt : http://libvirt.org/cgroups.html
Ensuite, la façon dont notre projet est géré (c'est-à-dire maintenir la majeure partie du cœur de l’OS dans un unique dépôt git) est plus proche du modèle BSD (qui est un vrai UNIX, pas comme Linux) dans la façon de faire (où la plus grande partie du cœur de l’OS est conservé dans un seul répertoire CVS/SVN) que de la façon de faire de Linux.
Ça, effectivement, c'est quelque chose de vraiment embêtant je trouve.
systemd n’est pas la mafia. C’est un logiciel libre, vous pouvez en faire ce que vous voulez, ce qui inclut ne pas l’utiliser. C’est plutôt l’opposé de « forcer ».
C'est tellement hypocrite… les devs du kernel ont même fait des rustines spéciales pour udev, c'est dire s'ils n'ont pas été « forcés ».
Un but de systemd est d’unifier un peu le paysage dispersé de Linux. Nous essayons de nous débarrasser de beaucoup des différences inutiles entre distributions dans différents domaines du cœur de l’OS.
Voilà, ça c'est plus honnête. J'aimerais bien que les devs avouent juste ça : on veut essayer de faire une nouvelle « API » de l'OS, devenir la nouvelle couche d'abstraction des services (voire plus), et ça sera forcément moins UNIX que l'était System V (franchement, du XML c'est pas très UNIX…). Encore une fois, pourquoi pas, mais il faut arrêter de jouer les vierges effarouchées quand on vous le renvoie dans la figure.
Faux, vous pouvez désactiver et remplacer à peu près n’importe quel bout de systemd, à de très rares exceptions près.
Sauf que systemd couvre tellement de choses qu'il est impossible pour des libristes bénévoles d'espérer rattraper ça.
Après, c'est peut-être ça l'avenir du Libre : ça devient plus professionnel, et les petits bénévoles ne pourront plus suivre le développement des composants au cœur du système. Je ne sais pas si c'est un bien ou un mal.
soit une organisation au dessus des distributions.
Il y a un truc fait par le projet GNU qui existe depuis longtemps qui s'appelle les autotools et qui fait ça « très bien » depuis des lustres. Faire un .deb depuis un projet autotoolifié c'est très peu de boulot. Après, chacun a sa manière de haïr les autotools, mais bon… et aussi, n-ième standard, toussa…
Rendre obligatoire la conservation d'une ligne de copyright dans un fichier AUTHORS ou dans un menu "about", ca ne me semble pas du tout genant. Par contre en signature de chaque mail, c'est pire que l'ancienne license BSD.
Effectivement, ça me semble complètement délirant ! Le commit est ici :
Je pense que ça n'a rien à voir avec la condition de raison de la clause 7. Bref, on a deux acteurs qui dans un sens comme dans l'autre (puisque Blue Mind avait l'air, avant d'être revenu en arrière, de vouloir proposer des versions commerciales de logiciels libres) à des gens qui veulent abuser du Libre et se tirent là bourre commercialement, et maintenant en plus en public… je ne crois pas que l'un vaille mieux qui l'autre. Comme quoi le Libre peut malheureusement gravement déraper quand de certaines sommes d'argent sont en jeu.
Mais ma question reste la même: Pourquoi ne sont-ils pas exploités (au lieu de l'objet) pour construire les discutions sur ces ID et avec des objets distincts plutôt que de répéter N fois le même message?
Parce que l'interopérabilité ça ne te permet pas d'avoir un « avantage compétitif »… mieux vaut réinventer la roue avec des sémantiques légèrement différentes, de manière obfusquée !
Il y a donc encore des évolutions possible pour les clients de messagerie.
C'est sûr. Après, là on parle d'évolution pour quelques geeks qui utilisent de « bons » clients (enfin, qui inter-opèrent bien quoi ; je ne parle pas de l'UI qui est justement le problème). Les « autres » (soit 99,9%) resteront malheureusement assez stagnant.
ou des 5 qu'il cherche pour faire du remplissage avec pour seule condition d'être une femme parce qu'il n'y a pas assez de militantes?
Dans le dernier cas, ça ne me dérange pas…
Là, c'est sûr que tu vas vachement attirer les candidates ! Au cas où certains pensaient que le PP en avait quelque chose à faire de la parité…
Ce qui m'embête, perso, c'est que le mec en question est l'auteur principal de la RFC définissant l'extension heartbeat : https://tools.ietf.org/html/rfc6520
Comme j'ai lu sur slashdot, « si même le mec qui a écrit la RFC n'est pas capable de l'implémenter correctement… ».
(après, perso, le code a l'air tellement crade que je le crois quand il plaide l'incompétence)
Posté par benoar .
En réponse à la dépêche Firefox 28.
Évalué à 3.
Ca fait longtemps que les plugins dont Flash sont dans un processus separe (plugin-container).
Heu… à l'époque (ça fait quelque temps, certes), on attendait cette feature, mais j'avais entendu d'une personne de Mozilla directement que ça avait été repoussé et que ça serait sûrement abandonné car trop galère.
Si Firefox plante, c'est probablement un bug dans Firefox lui-meme: soit dans le coeur, soit a cause d'une extension qui part en vrille et que Firefox ne sait pas rattraper.
Bah moi j'ai jamais, du tout, vu Firefox planter, et pourtant j'utilise un certain nombre d'extensions. Je me demande donc bien comment on peut dire qu'il plante, à moins que j'ai vraiment un setup spécial…?
Normalement, si c'est Flash qui plante tu as la surface du player qui affiche un message d'erreur et il suffit de recharger la page. C'est facilement testable en tuant plugin-container pendant qu'on regarde une video sur YouTube par exemple.
Bah, peut-être qu'il sait gérer un processus tué, mais à priori pour un truc qui plante bien grassement comme Flash, il n'a pas l'air d'aimer.
Posté par benoar .
En réponse à la dépêche Firefox 28.
Évalué à 6.
Je pense que ce qui fait le plus planter Firefox, c'est Flash…
+1000. Je n'ai pas vu Firefox planter depuis des lustres, et pourtant je teste pas mal de version différentes (les stables, certes). Tous les gens qui me parlent de plantage, à chaque fois on trouve que le dénominateur commun c'est Flash…
Non, je parle bien d'une partie du SSD (quelques Go) qui sert à aller très très vite, et il y a une copie en arrière plan vers la partie "lente", et du coup si par exemple si la partie rapide est de 1 Go tu fais une écriture de 900 Mo et tu trouves que ça déchires, tu fais une écriture de 2 Go les perfs tombent.
Ah, étrange, je me renseigne pas mal sur les SSD mais je n'ai jamais entendu parler de ça. Les SSD ont un cache sous forme de RAM, mais qui n'atteint pas le Go, mais plutôt la centaine de Mo, et qui sert à « aller vite » pendant que l'écriture se fait sur la Flash… mais je suppose que tu ne parles pas de ça.
Bref, ce qu'il faut retenir est les constructeurs ont des tonnes d'idées pour avoir un bon rapport perfs/coût, et que quand on benche il faut de nos jours avec les SSD le faire en conditions réelles de chez réelles tellement le moindre petit paramètre qui change peut changer le résultat d'une compétition de SSD, et qu'un Bench synthétique ne peut donner qu'une idée partielle de la partie la plus rapide du SSD, bref juste donner une direction.
Zut, je n'arrive pas à trouver des liens rapidos de si bon matin, mais des SSD on une partie "rapide" (SLC chère) et une partie "lente" (MLC moins chère), et le contrôleur joue avec les deux, du coup si tu ne touche pas la limite de la SLC (si tu fais des perfs que de manière ponctuelle) les perfs sont bonnes et sinon au bout de quelques secondes les perfs peuvent tomber.
Ça n'est pas qu'il y a une « partie » SLC, c'est que tant que ton disque n'est qu'à moitié utilisé, le SSD utilise seulement 2 niveaux par cellule, pour coder un bit, alors que quand tu dépasses cette limite, il se met à utiliser 4 niveaux par cellule, pour pouvoir coder 2 bits (le « Multi » de MLC c'est pour dire que tu codes plus d'un bit par cellule ; en général 2 bits, mais aujourd'hui on a aussi de la TLC qui est de la MLC à 3 bits/cellule). Le truc, c'est que pour écrire/lire une cellule à deux niveaux, tu mets moins de temps car tu peux y aller plus « à l'arrache » en ayant que deux « zones » de reconnaissance de l'état de charge de ta cellule. Quand tu passe à quatre niveaux, il faut être plus fin, alors ça met plus de temps, et tes perfs tombent.
[^] # Re: Vive la démocratie d'Internet !
Posté par benoar . En réponse au journal Microsoft débranche 22 domaines No-IP. Évalué à 5.
Franchement, un juge qui peut dire oui à ce genre de demande, soit il est très très mal conseillé techniquement (sans déconner, tu as déjà vu faire saisir des noms de domaines qui sont pourtant utilisés légitimement 90% du temps ?), soit on l'a un peu aidé avec un chèque, c'est pas possible autrement.
[^] # Re: Vive la démocratie d'Internet !
Posté par benoar . En réponse au journal Microsoft débranche 22 domaines No-IP. Évalué à 3.
Heu… en théorie ça ne devrait faire aucune différence : il y a peut-être un bug chez toi.
[^] # Re: Dommage
Posté par benoar . En réponse au message divers utilitaires . Évalué à 2.
Je vais un peu faire comme les autres et essayer de te convaincre : on n'est pas obligé d'apprendre tout le langage de vim. Mais pouvoir copier/coller quelques fragments qu'on a trouvé à droite à gauche et les personnaliser un peu, c'est vraiment super utile. J'ai passé 10 ans avec un vim « de base », mais depuis quelques années j'ai commencé à faire plus attention à sa configuration (ça a commencé à cause du bépo…), et même si ça prend un peu de temps, c'est comme pour vim quand tu commences : c'est un investissement. Oui, la courbe est dure au début, mais après tu gagnes beaucoup en confort. Mon éditeur de texte est un outil que j'utilise beaucoup, et j'utilise toujours le même depuis longtemps, et je ne regrette pas du tout le temps que j'ai passé à apprendre les bases de son langage qui est effectivement un peu étrange.
# Publication et propreté
Posté par benoar . En réponse au message Gestionnaire de version : organisation et distribution. Évalué à 5.
D'un côté, ça se comprend, mais d'un autre, tu verras que le travail de refactorisation ça n'est pas anodin, et ça prend parfois beaucoup de temps. Au point où parfois tu ne finis par pas diffuser le code parce que tu n'as pas le temps de le refactoriser… (histoire vécue) Perso, j'ai appris à essayer de mettre vaguement au propre au moment où je code (éventuellement en squashant quelques commit, ou en essayant de pas commiter trop vite ; il y a un bon « rythme » à trouver entre tous commiter dès que possible, chose très facile en git, et prendre un peu son temps pour ne pas avoir trop de minuscules commits), et à ne pas faire trop attention aux « détails » de propreté une fois que c'est fait : c'est super chiant de revenir sur son code des jours ou des semaines après, parfois. Il faut accepter de publier du code pas tout à fait propre, parce que sinon ça devient une sorte de psychose qui t'empêche de publier plutôt qu'autre chose.
Avant du publier, oui, rebase autant que tu veux. Mais une fois publié, c'est public, c'est fini. En plus, publier des choses pas forcément idéales que tu corriges après, ça permet de montrer aux gens comment tu fais des erreurs mais aussi comment tu les corriges : c'est plus « humain », et ça apprend aussi à ceux qui te lisent.
Ne te prends pas trop la tête sur une organisation tip-top dès le départ : avec l'expérience, tu auras sûrement envie de changer… Donc je te conseille de faire un seul répo, avec tes branches qui correspondent aux stades de développement dont tu parles (en gérant bien évidemment comme tu le souhaites les permissions).
Je pense que tu te prends beaucoup trop la tête sur la « propreté » d'un code :-) Tu n'en mourras pas, de publier des trucs « pas propres ». Au contraire, je pense que ça t'apprendra d'autant plus, car c'est en essayant et en se plantant qu'on apprend à s'améliorer.
[^] # Re: Autrement
Posté par benoar . En réponse au message Obtenir l'IP locale. Évalué à 2.
Le nom de ta machine est affiché dans l'invite de ton shell, si tu ne le connais pas. Ou sinon avec la commande "hostname".
# Autrement
Posté par benoar . En réponse au message Obtenir l'IP locale. Évalué à 3.
Je suppose que Mageia, comme toute distrib linux un peu récente, installe avahi par défaut ; du coup, tu pourrais plutôt utiliser directement les noms de tes machines, en y ajoutant le suffixe ".local". Genre dans ton navigateur, tu tapes "http://monlaptop.local", et ça devrait marcher.
[^] # Re: Moulin à café
Posté par benoar . En réponse au journal un café avec Bill Gates. Évalué à 2.
Oups mea culpa, j'ai toujours cru qu'ils étaient coréens, je ne sais pas pourquoi… ils sont bien japonnais, pardon.
[^] # Re: La vraie nouvelle du jour
Posté par benoar . En réponse à la dépêche Red Hat Software Collections 1.1. Évalué à 2.
Oui, mais c'est pour dire que Red Hat privilégie une autre vision, je pense, plutôt que la virtualisation à outrance : une gestion de la virtualisation plus « bas niveau », avec des surcouches plus simples à libvirt (voire pas du tout), évitant l'énorme couche d'abstraction qu'est OpenStack (sachant que libvirt en est déjà une pas mal grosse, mais plutôt bien faite je trouve). Par-dessus par contre, une gestion plus Cloud mais pour du PaaS, comme tu dis, avec OpenShift. Leur intérêt là-dedans, c'est que la virtualisation à outrance c'est valable pour les applis/serveurs complètement fermés et proprios ; quand on est orienté libre, on n'a moins d'intérêt à se diriger vers de telles solutions, qui sont quand même assez lourdes. Je pense qu'ils verraient bien aussi un truc genre Docker, mais paf : LXC est déjà géré par libvirt, ils n'ont rien à faire de plus pour gérer ça (par contre je ne sais rien du support des conteneurs par OpenStack). OK, Docker c'est un peu plus que du LXC, mais tu vois le truc.
Après, je ne savais pas que eNovance faisait du OpenStack, du coup ça contre un peu mon argument…
[^] # Re: Moulin à café
Posté par benoar . En réponse au journal un café avec Bill Gates. Évalué à 2.
Tout à fait. C'est juste qu'après, c'est quoi l'intérêt de le fabriquer là-bas si on peut y arriver au même prix ici ? Bon après, Kyocera ce sont des coréens, alors pour eux la Chine ça n'est pas si loin…
[^] # Re: La vraie nouvelle du jour
Posté par benoar . En réponse à la dépêche Red Hat Software Collections 1.1. Évalué à 1.
Heu… mon analyse perso c'est qu'ils renforcent leur position dans des technos de virtualisation et de stockage distribuées qui pourraient être utilisées avec OpenStack, mais ça n'est vraiment pas renforcer sa position dans OpenStack lui-même. Voir pour ça l'avis des devs de libvirt sur OpenStack, et le fait que Ceph n'était pas vraiment un des backend prévu à la base pour OpenStack, etc. Bien sûr que la gestion de « Cloud » ça marche à fond en ce moment, donc ils s'y investissent, mais d'une Red Hat a sa propre techno avec OpenShift, et de deux il faut voir comment est le code d'OpenStack… D'ailleurs, en tant qu'expert python, j'aimerais bien ton avis sur le code, si tu es déjà allé faire un tour dedans (attention, ça pique les yeux ; enfin, j'en ai fait une étude il y a un peu moins de deux ans, et ça n'était pas joli à l'époque).
[^] # Re: Moulin à café
Posté par benoar . En réponse au journal un café avec Bill Gates. Évalué à 2.
J'ai le Kyocera présenté dans ce lien. C'est effectivement un des seuls non-électriques que j'ai trouvé. Il a l'air bien costaud, même si c'est fabriqué en Chine pour ceux qui se demanderaient (enfin, ils mettent que le verre est fabriqué au Japon… j'aurais plutôt fait valoir la qualité des engrenages en céramiques, mais bon). Eh oui, même à ce prix… En parlant de prix, j'ai trouvé le miens moins cher dans ma Biocoop locale (43 € je crois). Un petit défaut : il n'a pas de couvercle supérieur donc quand on moud, des grains peuvent sauter en dehors. En passant, j'avais oublié que pour moudre du grain, il faut une certaine force quand même, ça n'est pas de tout repos.
[^] # Re: question sur le moteur de recherche
Posté par benoar . En réponse au journal éClaircie : un moteur de blog et de site personnel statique et sans nuage. Évalué à 3.
Pour aller voir dans les entrailles, en prenant l'exemple de la doc de python :
https://docs.python.org/2/searchindex.js
(attention, ce JS est très gros puisqu'il contient tous les mots de la doc python avec les endroits de leur(s) occurrence(s))
C'est effectivement plutôt bien fait, même si j'ai souvenir d'avoir vu un « bug » qui fait que le contenu des titres n'est pas indexé, il me semble.
[^] # Re: À mon tour
Posté par benoar . En réponse à la dépêche Mise aux poings sur systemd. Évalué à 2.
C'te blague ; extrait de https://github.com/systemd/systemd/tree/master/src là ou je vois des outils qui existaient déjà : ask-password, backlight, cryptsetup, fsck (sans déconner !), hostname, locale, modules-load, network (je vois qu'ils ont réimplémenté tout iproute, sans même utiliser libnl), readahead, remount-fs, resolve, sysctl, …
En passant, à chaque fois aucun commentaire en haut du fichier pour expliquer ce que ça fait exactement : il faut aller voir le main().
Alors après, l'existant c'est un paquet de spaghetti hétéroclite immonde, mais avec des années et des années de polissage derrière. On sait très bien que quand un mec arrive en disant qu'il va tout régler d'un coup, on va se prendre des systèmes cassés pendant des lustres. Peut-être qu'il était tant, mais bon, non, ça n'a pas été fait de manière « modulaire » itérative, comme on aurait pu remplacer petit à petit les outils.
Ah ouai, carrément ?
Heu… Lennart ne trouvait pas ça « normal » à priori avant, vu que c'est comme ça que c'était depuis un bout de temps. Et donc maintenant, les cgroup ça doit appartenir à systemd et c'est tout point ; voilà un système coopératif… Alors après, ils ont étudié les solutions et c'est à priori la meilleure, mais alors qu'on ne se targue pas de se la jouer « à la UNIX » : non, tu fais différemment ; et bien assume-le.
Et bien maintenant tu as un mainteneur tête de nœuds pour la base d'une partie énorme de ton système. Pour caricaturer UNIX, les « haters » disaient que l'auteur de "head" n'était pas le même que celui de "tail" (et c'est vrai !) ; c'est un peu extrême, mais ça a toujours été comme ça que ça se passe. Les projets avec un mono-maniaque qui décide d'une partie énorme de ton système, ça craint. Torvalds est visé du coup, mais disons que lui fait plus « consensus », si on peut dire.
Heu… ça fait un peu « parain de la mafia » comme remarque…
Je parlais des communications par dbus. Choses que l'utilisateur ne voit pas, mais quand tu écris un soft et que tu veux communiquer avec le démon « système » maintenant, tu dois te palucher du XML.
Nan mais tu as pris la grosse tête comme Lennart ? Moi j'ai écrit des scripts SysV pour des softs, oui, et je me permet d'aller voir dans le code que je veux, quand il est pas trop mal fait.
[^] # Re: En pratique
Posté par benoar . En réponse au journal La diversité ou la complexité inutile ?. Évalué à 1.
Non, ça gère plus que ça (j'ai des projets en shell avec autotools), et à priori, ça marche sur un paquet de plateformes (au moins OSX et BSD), même si pour Windows, c'est peut-être pas l'idéal car il faut MinGW.
# À mon tour
Posté par benoar . En réponse à la dépêche Mise aux poings sur systemd. Évalué à 10.
Comme d'hab, ça n'est pas que je n'aime pas systemd (il y a plein de bonnes idées dedans), mais la manière dont c'est fait et présenté. Mes quelques remarques :
Qui ont leur propres standards d'options et ne réutilisent pas l'existant. Être modulaire, c'est une chose, mais généralement quand on dit ça c'est qu'on interagit bien avec le reste de l'écosystème. Ça va dans le sens du « il faut tout réapprendre », qui peut parfois être nécessaire, certes, mais là c'est vraiment « on refait tout sans utiliser l'existant ». Pourquoi pas, mais de là à se vanter de séparer ses modules et de se dire modulaire au sens d'UNIX… Busybox fait ça, de manière un peu moins « je remplace tout » puisqu'il remplace tout, mais avec des commandes qui respectent scrupuleusement la syntaxe de celles d'origine.
Dommage, cette idée vient d'être foutue en l'air pour les prochaines version de systemd, cf http://lists.freedesktop.org/archives/systemd-devel/2013-June/011521.html : tout devra passer par l'API dbus désormais. On pourra éventuellement, pour la lecture, passer par cgroupfs, mais je vous laisse déguster la syntaxe de la nouvelle hiérarchie (la compatibilité ascendante c'est pour les nuls), par exemple ici présentée dans le projet libvirt : http://libvirt.org/cgroups.html
Ça, effectivement, c'est quelque chose de vraiment embêtant je trouve.
C'est tellement hypocrite… les devs du kernel ont même fait des rustines spéciales pour udev, c'est dire s'ils n'ont pas été « forcés ».
Voilà, ça c'est plus honnête. J'aimerais bien que les devs avouent juste ça : on veut essayer de faire une nouvelle « API » de l'OS, devenir la nouvelle couche d'abstraction des services (voire plus), et ça sera forcément moins UNIX que l'était System V (franchement, du XML c'est pas très UNIX…). Encore une fois, pourquoi pas, mais il faut arrêter de jouer les vierges effarouchées quand on vous le renvoie dans la figure.
Sauf que systemd couvre tellement de choses qu'il est impossible pour des libristes bénévoles d'espérer rattraper ça.
Après, c'est peut-être ça l'avenir du Libre : ça devient plus professionnel, et les petits bénévoles ne pourront plus suivre le développement des composants au cœur du système. Je ne sais pas si c'est un bien ou un mal.
[^] # Re: En pratique
Posté par benoar . En réponse au journal La diversité ou la complexité inutile ?. Évalué à 2.
Il y a un truc fait par le projet GNU qui existe depuis longtemps qui s'appelle les autotools et qui fait ça « très bien » depuis des lustres. Faire un .deb depuis un projet autotoolifié c'est très peu de boulot. Après, chacun a sa manière de haïr les autotools, mais bon… et aussi, n-ième standard, toussa…
[^] # Re: Intro
Posté par benoar . En réponse au journal Linagora vs BlueMind. Évalué à 7.
Effectivement, ça me semble complètement délirant ! Le commit est ici :
https://github.com/linagora/OBM/commit/a0a4b7b1e63cc92e190ac4010b7d5f1fb9cea2d7
Je pense que ça n'a rien à voir avec la condition de raison de la clause 7. Bref, on a deux acteurs qui dans un sens comme dans l'autre (puisque Blue Mind avait l'air, avant d'être revenu en arrière, de vouloir proposer des versions commerciales de logiciels libres) à des gens qui veulent abuser du Libre et se tirent là bourre commercialement, et maintenant en plus en public… je ne crois pas que l'un vaille mieux qui l'autre. Comme quoi le Libre peut malheureusement gravement déraper quand de certaines sommes d'argent sont en jeu.
[^] # Re: webmail
Posté par benoar . En réponse au journal Thunderbird : j'en peux plus ! Qui arrive à l'utiliser pour de vrai ? Quoi d'autre ?. Évalué à 2.
Parce que l'interopérabilité ça ne te permet pas d'avoir un « avantage compétitif »… mieux vaut réinventer la roue avec des sémantiques légèrement différentes, de manière obfusquée !
C'est sûr. Après, là on parle d'évolution pour quelques geeks qui utilisent de « bons » clients (enfin, qui inter-opèrent bien quoi ; je ne parle pas de l'UI qui est justement le problème). Les « autres » (soit 99,9%) resteront malheureusement assez stagnant.
[^] # Re: webmail
Posté par benoar . En réponse au journal Thunderbird : j'en peux plus ! Qui arrive à l'utiliser pour de vrai ? Quoi d'autre ?. Évalué à 4.
Voire le mettre dans un « standard pour l'ARPA » http://tools.ietf.org/html/rfc822#section-4.6
[^] # Re: Au nom de l'égalité…
Posté par benoar . En réponse au journal Le Parti Pirate cherche 5 femmes pour les Européennes avant le 21 avril. Évalué à 3.
Là, c'est sûr que tu vas vachement attirer les candidates ! Au cas où certains pensaient que le PP en avait quelque chose à faire de la parité…
[^] # Re: un effet Snowden?
Posté par benoar . En réponse à la dépêche Nouvelle vulnérabilité dans l’implémentation OpenSSL. Évalué à 3.
Ce qui m'embête, perso, c'est que le mec en question est l'auteur principal de la RFC définissant l'extension heartbeat :
https://tools.ietf.org/html/rfc6520
Comme j'ai lu sur slashdot, « si même le mec qui a écrit la RFC n'est pas capable de l'implémenter correctement… ».
(après, perso, le code a l'air tellement crade que je le crois quand il plaide l'incompétence)
[^] # Re: onglets bien ronds
Posté par benoar . En réponse à la dépêche Firefox 28. Évalué à 3.
Heu… à l'époque (ça fait quelque temps, certes), on attendait cette feature, mais j'avais entendu d'une personne de Mozilla directement que ça avait été repoussé et que ça serait sûrement abandonné car trop galère.
Bah moi j'ai jamais, du tout, vu Firefox planter, et pourtant j'utilise un certain nombre d'extensions. Je me demande donc bien comment on peut dire qu'il plante, à moins que j'ai vraiment un setup spécial…?
Bah, peut-être qu'il sait gérer un processus tué, mais à priori pour un truc qui plante bien grassement comme Flash, il n'a pas l'air d'aimer.
[^] # Re: onglets bien ronds
Posté par benoar . En réponse à la dépêche Firefox 28. Évalué à 6.
+1000. Je n'ai pas vu Firefox planter depuis des lustres, et pourtant je teste pas mal de version différentes (les stables, certes). Tous les gens qui me parlent de plantage, à chaque fois on trouve que le dénominateur commun c'est Flash…
[^] # Re: Ok voici plus de précisions
Posté par benoar . En réponse au journal Linux Centos et disque SSD. Évalué à 2.
Ah, étrange, je me renseigne pas mal sur les SSD mais je n'ai jamais entendu parler de ça. Les SSD ont un cache sous forme de RAM, mais qui n'atteint pas le Go, mais plutôt la centaine de Mo, et qui sert à « aller vite » pendant que l'écriture se fait sur la Flash… mais je suppose que tu ne parles pas de ça.
Tout à fait.
[^] # Re: Ok voici plus de précisions
Posté par benoar . En réponse au journal Linux Centos et disque SSD. Évalué à 1.
Ça n'est pas qu'il y a une « partie » SLC, c'est que tant que ton disque n'est qu'à moitié utilisé, le SSD utilise seulement 2 niveaux par cellule, pour coder un bit, alors que quand tu dépasses cette limite, il se met à utiliser 4 niveaux par cellule, pour pouvoir coder 2 bits (le « Multi » de MLC c'est pour dire que tu codes plus d'un bit par cellule ; en général 2 bits, mais aujourd'hui on a aussi de la TLC qui est de la MLC à 3 bits/cellule). Le truc, c'est que pour écrire/lire une cellule à deux niveaux, tu mets moins de temps car tu peux y aller plus « à l'arrache » en ayant que deux « zones » de reconnaissance de l'état de charge de ta cellule. Quand tu passe à quatre niveaux, il faut être plus fin, alors ça met plus de temps, et tes perfs tombent.
Je n'ai pas de lien précis mais ça se trouve sur le très bon http://www.hardware.fr/.