Bien sur, faire un projet libre, ça impliquerais de suivre les bonnes pratiques, comme "envoyer les patchs pour publication et revue auprès des externes", et pas "coder dans notre coin puis faire un produit semi proprio". Enfin, tant que Davfi ne tente pas de poser des brevets à l'étranger sur ses "innovations" ça devrait aller. Ça serait quand même un truc qui risquerait de ternir sa réputation auprès des libristes, ça. Et ça serait un peu nulle de l'avoir dit dans un événement du libre un jour à quelqu'un.
Donc motivé, sans doute. Qui connait son sujet, ça dépend fortement du sujet. Il a dit avoir cassé AES, mais en fait non ( cf http://eprint.iacr.org/2003/022.ps ) . Il a dit avoir cassé tor, mais en fait, non. Ou plutôt, l'attaque, c'est "si je rajoute assez de noeud compromis, le réseau est compromis". Comme dirait un collègue, "no shit sherlock". Mais c'est une attaque connu ( à savoir celle d'un attaquant global avec assez de noeuds ), et il a monté toute la sauce autour de ça en utilisant des choses complexes comme "utiliser un virus pour infecter les relais sous windows pour compromettre le code de tor par injection dans le process", ce qui est plus vendeur que "remplacer le binaire de tor via un exploit IE". Et j'invite les gens à lire ce post de blog, et à suivre les liens : https://blog.torproject.org/blog/rumors-tors-compromise-are-greatly-exaggerated
Et pour la petite histoire, mon commentaire a amené un des responsable du projet à venir me parler lors de l'Open WOrld Forum pour ce que j'ai personnellement pris pour des menaces, en me demandant d’arrêter sinon des choses seront mises en place. Après enquête rapide ( car bon, quand on connait vraiment du monde, ça va plus vite ), ce que j'ai compris, c'est surtout que quelqu'un a fait remarquer à quelqu'un de l'APRIL que le projet est pas si libre qu'on veut nous le faire croire, et qu'il y a eu discussion entre des gens de l'APRIL et le dit responsable, et il pense que c'est moi qui a tuyauté et donc sali la réputation du logiciel auprès de l'association. N'importe qui capable de lire les annonces va voir que le projet est pas clair du tout et que le qualifier de libre ou d'opensource, c'est juste un raccourci marketing. Ou alors va falloir revoir le jugement sur github et mac os x à ce niveau si il suffit d'avoir juste un morceau sous une licence potable pour que tout soit libre.
Et vue qu'on a déjà bien entamé 2013 mine de rien, je trouve curieux de voir que les fiches de recrutements sont encore la depuis plus de 8 mois ( http://www.davfi.fr/recrutement.html ) et qu'il y a pour le moment que de la communication autour du projet. Peut être qu'il y a pas assez de personne pour mettre à jour le site. C'est vrai que 5 millions de cash, ça permet pas de payer un webmaster.
Oui, et puis, c'est pas parce que tu peux avoir un truc gratuitement qu'il n'a pas de valeur, ou que quelqu'un n'a pas passé du temps et de l’énergie dessus.
Mandriva s'en sortait pas si mal avec le club ( ou du moins, était en bonne voie ), avant que Canonical n'arrive, ne réduise le marché du desktop à zero ( en sciant aussi la branche sur laquelle elle voulait s’assoir dans le futur )
50€ par an, c'est largement moins que le crédit que tu rembourses sur un iphone par exemple. Mais bon, c'est aussi vachement moins hype, je comprends que les gens préfèrent financer l'innovation chez Apple que la maintenance chez d'autres ( car Suse propose aussi le même genre d'offre ).
Ben si personne ne paye, forcément, personne ne va se dire que ça vaut le coup d'investir la dedans. En fait, faut pas chercher plus loin le pourquoi personne investit dans le poste de travail pour particulier.
Alors j'ai chopé la vidéo, et pendant 5 minutes, y a pas de son ( ce qui m'a fait chercher pendant 30 secondes le problème )
Sinon, à 23/24 minutes : "Jessy, the next release, we will probably use sysvinit on most system".
"In gnome 3, I think, we will start to depend on systemd, and that will create lots of interesting flamewar."
"By default, I think, we will likely see sysvinit as still the default, systemd is going to be supported. If we can move to a single init system for jessy, that would make me very happy, but I don't think that's gonna fly politically. because this is as much a political question as a technical question."
Donc en gros, systemd supporté officiellement, mais pas installé par défaut.
Suivi d'une discussion sur le passage de jessie à logind pour l'équipe gnome, avec un impact inconnu pour kfreebsd. Ils n'ont pas les ressources pour maintenir consolekit et pas d'utilisateur de kfreebsd et de gnome, ce qui leur prends du temps pour rien d’après un des 2 conférenciers.
Ensuite, Tolef ( je crois ), explique qu'ils veulent rendre systemd plus facile à packager ( outil systemd aware, synchronisation de l'état des systems d'init ), et il y a une question de l'assistance.
De ce que je sais, l'équipe ovirt serait intéressé par quelqu'un pour faire le paquet debian, et pour le moment, il y a juste des instructions sur le web ( http://www.ovirt.org/Ovirt_build_on_debian/ubuntu ).
Par contre, je vois pas le support de SAP pour Debian, du coup, j'ai du mal à voir en quoi Debian serait si en avance. Et la comparaison entre un système avec une durée de vie de 2 à 3 ans comme Debian, et un truc à plus longue durée ( genre 10 ans ) comme SLES ou RHEL me parait aussi curieuse. Du coup, le qualificatif "blaireaux" me semble un chouia mal trouvé.
Novell et Suse sont 2 business unit séparés maintenant.
Et c'était plus un accord commercial de vente conjointe de support linux et windows, ce qui en soit me semble pas totalement déconnant dans un environnement mixte. C'est pas comme si les SSIIs ou les revendeurs n'étaient pas déja tous en train de faire ça depuis des années.
Alors pour tout ceux qui comme moi n'ont jamais entendu parler de quoi parle ce journal, et dans le but d'essayer d'aider Samuel à être pertinent :
Delta Lloyd Lebensversicherung AG est visiblement un courtier en assurance allemand. En fait, c'est la filiale d'une filiale d'une banque présente dans 3 pays, le 6eme assureur des pays bas. J'ai pas trouvé grand chose sur la filiale mais on parle d'une migration d'un parc de 60 serveurs en RHEL.
Les chiffres proviennent directement d'un pdf sur le site de novell ( www.novell.com/docrep/2013/01/delta_lloyd_lebensversicherung_ee.pdf ). Le pdf souffre d'un manque de précision, il parle de cout de license au lieu de cout de souscription ( la différence est subtile ), et il oublie des détails. Par exemple, pourquoi l'interface de Suse Manager ressemble à celle de RHN ( ce qui évite donc les couts de formation ), ou pourquoi se concentrer sur l'OS alors que les couts d'Oracle et de SAP sont souvent les plus importants ( et ceci sans compter les 70 à 90% de réductions par rapport au prix public, je pige pas pourquoi personne ne proteste contre ça auprès des autorités ).
Pour ceux qui n'ont jamais entendu parler de Suse manager ( car c'est quand même une offre assez peu connu ), c'est une version de Spacewalk ( http://spacewalk.redhat.com/ ), le produit à la base de satellite ( qui est l'offre commercial de Red Hat du code de spacewalk, cad avec un travail de stabilisation, de documentation, de support sur une version "figé" dans le temps ), mais proposé par Suse. Satelitte ayant été annoncé comme projet communautaire en 2008 lors du RH Summit à Boston, il a donc fallu un peu de temps pour que des gens se penchent dessus.
Les 2 sociétés travaillent main dans la main sur l'engineering d'un produit libre, ça n'arrive pas si souvent hélas.
A noter qu'une version plus moderne est en cours d'écriture sous le nom de Katello ( http://www.katello.org/ ) avec pulp, candlepin, etc. J'ai pas encore compris comment tout s'emboite exactement, vu que c'est encore en cours d'écriture et dispo officiellement dans aucune distribution, mais les gens qui s'intéressent au sujet peuvent regarder en détail.
En fait, le coup de faire une modif de contab, c'est de pas avoir de locking. Je suppose qu'il y a peu de risque en pratique, mais je pense que /etc/cron.d est plus sur à ce niveau la.
Pour moi lorsque Misc me sous entend [il n'a pas dit] que systemd = 16/20 et init 12/20
je m'attends à une révolution.
Donc attends, tu inventes ce que je dit, puis tu dit que ça correspond pas à la réalité. Et ensuite tu dit que tu n'utilises pas d'argument de l'homme de paille, vraiment ?
Donc, si je vous suis bien, lorsque chez google ils utilisent le format json-like (je me souviens plus du nom du
format) ce sont des idiots.
Vu que visiblement, tes arguments ne s'encombrent pas de précision, je vais compléter pour toi.
Le format que tu cherches, c'est protobuf : http://code.google.com/p/protobuf/
Bien que tu ne donnes pas de définition de ton neologisme "json-like", je suppose que tu parles de ça à cause des '{' et '}' servant de délimiteurs. Ça n'a rien de json, car l'avantage du json, c'est de se lire directement presque partout. La, il faut un parser spécifique pour le .proto, par exemple.
Encore une fois, la configuration d'un service n'a pas besoin d'une structure complexe, quoi que des années de java ont réussi à faire croire. Tu définit des variables simples pour définir ce que tu veux, et le reste dépend du logiciel. Donc à partir de la, un simple format clé/valeur doit suffire. D'ailleurs, il a suffit pendant des années pour justement la fameuse philosophie unix à base de variable d'environnement ( modulo le besoin d'avoir des tableaux comme $PATH, $LS_COLORS, mais c'est minoritaire )
Donc non, je pense que chaque format a ses avantages, et à partir de la, il faut choisir.
par exemple, mon blog, je pense qu'il a pas besoin d'être en permanence entre de prendre de la ram pour 10 visites par jour. Ou un phpmyadmin par exemple.
Donc le moins de ram on prends, le mieux c'est, surtout sur des trucs genre beagleboard, raspberrypi, etc, ou sur des serveurs ou on paye à la ram, genre amazon ec2, gandi, etc…
Ensuite, on rentre aussi dans la sémantique. par exemple, dire que tout ce qui n'est pas interdit est autorisé. Et c'est pas interdit d'avoir d'autres repertoire haut niveau, et que les liens permettent de garder la compatibilité. Dire que si tu trouves ton soft dans /bin/ alors les executables pour booter y sont.
Enfin, je pense que personne ne suit à la lettre la FHS. Exemple gentoo à /usr/portage ( alors que ça devrait être dans /var ), Debian a du /usr/games, avec des régles en plus, Fedora/RHEL ont longtemps eu /selinux, et ont toujours /usr/libexec ( suivant les gnu coding standards http://www.gnu.org/prep/standards/html_node/Directory-Variables.html ).
Donc au final, c'est aussi pour ça que je trouve l'auteur du blog comme se focalisant sur les détails "visibles", alors qu'il y avait déjà plein de problème. Le fait d'avoir un /usr/libexec pose des soucis pour les outils qui codent en dur les chemins tout comme /usr/games. ( et c'est juste les détails que j'ai en tête un dimanche matin avant le fosdem ).
Le point de blocage 718, dont dépend celui que que tu pointes et qui traite précisément de la question est toujours
ouvert.
sauf erreur de ma part, le blocage est de savoir si les admins peuvent ou pas mettre /run sur autre chose qu'un tmpfs.
Et le reste est commité dans le draft.
Et je pense que tu as visiblement une idée bien précise sur la façon dont le standard doit évoluer, à savoir d'abord discuter et ensuite coder. Ça, ça s'appelle du design by comitee. Parfois ça marche. Parfois ça marche pas.
Si la FHS fonctionne autrement et se décide à juste documenter le consensus, ça marche aussi. Donc au final, si les distributions y trouvent leur comptes, qui va être emmerdé ?
nulle-part il est question de placer des points de montages dans ce répertoire, qui est le second reproche de
l'auteur du blog.
l'auteur du blog reproche surtout "oula, faut que je tape des noms longs", et le fait d'avoir changé le chemin. Sauf erreur de ma part, le montage est fait par udisk2. Une recherche donne ce commit : http://cgit.freedesktop.org/udisks/commit/?id=aa02e5fc53efdeaf66047d2ad437ed543178965b
Malheureusement, le commit ne donne pas des masses de détails.
De ce que je vois, le changement a 2 composantes : passage sur un tmpfs ( donc /run, supposement tmpfs par défaut ) et passage dans un dossier utilisateur ( /run/media/$USER/$DISQUE ).
Mettre /media en tmpfs aurait sans doute été un problème pour les mises à jours ( ie, changement de comportement ).
Donc tu doit prendre /run ou un autre chemin.
Mettre /run/ entier, c'est niet. Donc un sous repertoire. /run/$USER ou /run/$DISQUE, y a des risques de conflits ( surtout /run/$DISQUE ). Donc ajout de /media, nom fixe.
/run/media/$USER, ça permet de monter 1 disque à la fois, ce qui est niet.
/run/media/$DISQUE, ça marche dans les cas simples, mais pas dans le cas d'une station ou plus d'une personne peut se connecter ( le fameux multiseat qu'on a tous deja utilisé via ssh ). On retrouve çavia du thin client, etc. En effet, si tu fait ça, quelqu'un peut mettre une clé du même nom, et toi, au mieux, tu te demandes laquelle c'est, au pire, tu écrit sur la mauvaise. De surcroit, avec des clés en fat32 ( ou en udf, comme Tanguy le propose sur son blog ) en lecture pour tous, il y a une fuite de données évidentes ( ie, tout le monde peut lire ma clé avec mes documents via ssh ). Une solution alternative serait de faire le montage en forcant l'umask et les droits, mais tout les fs ne le supportent pas; et il y a peut être un souci caché que j'ai pas trouvé dans cette façon de faire ( ne serais que parce que sauf erreur de ma part, aucune distro ne le fait ).
donc /run/media/$USER//$DISQUE, avec $USER ayant des acls.
Bien que je n'ai pas pu tester, je pense qu'une solution au problème d'avoir à taper des chemins plus long serait pour l'utilisateur expert de rajouter son device directement dans /etc/fstab. Udisks respecte les réglages et devrait du coup monter la clé la ou c'est demandé.
À l'inverse, le "standard" continue à spécifier une séparation claire entre /bin et /usr/bin,
ce qui fonde le premier reproche fait (qui est que ça enfreint le FHS).
Le souci, c'est que la FHS dit juste "faut mettre les commandes pour monter les autres fs", en ne spécifiant rien.
Du coup, tu te retrouves à mettre tout ce qui pourrait servir à un moment à monter un disque dans /. Donc par exemple, sur debian, une des rares distros à se donner la peine de le faire proprement ( vu que les autres s'en foutent un peu, dans le sens ou personne ne teste vraiment, et surtout, personne n'ouvre de bug ), tu as tout les fs réseau et toutes les dépendances dans /lib, /bin, et /sbin/. Et j'ai eu du mal à trouver un contre exemple, mais j'ai fini par en trouver 1 ( aprés 4/5 essais ). Si tu veux avoir ton /usr en iscsi, tu peux pas : http://packages.debian.org/sid/alpha/open-iscsi/filelist car les commandes sont dans /usr/
( et le iscsi est vachement plus courant que l'exemple capilotracté de sshfs que j'aurais pou sortir, ou celui d'avoir ton /usr en afs via kerberos ( http://packages.debian.org/sid/armel/openafs-client/filelist ))
En pratique, le fait d'avoir tout dans /usr, ça permet de faire des containers plus facilement ( ou justement, de monter totalement /usr via le réseau comme avant sans avoir à garder le /bin local en synchro avec le /usr distant ), ça permet de faire des rollbacks plus facilement ( même si personne ne le fait, je pense que snapper devrait réussir à en tirer parti sous peu ). Je comprends que ça dérange, car la migration entraine un risque, parce qu'on a le sentiment de bousculer l'ordre établi ( un comme avoir quelqu'un qui range ton bureau, ça te fait toujours chier ).
Mais en pratique, c'était à la bonne franquette pour savoir quoi était ou, et c'était pas terrible la façon dont les distros l'ont mis en place.
Ensuite, tout le monde n'a pas suivi, et pour l'avoir fait, je doit reconnaitre que si on m'avais pas dit, j'aurais sans doute rien remarqué tellement c'était sans douleur. Il ne reste plus qu'à attendre que quelqu'un en tire parti.
c'est sur un tmpfs pour pouvoir nettoyer tout seul le truc. C'est pas déconnant. Et pour des questions de sécurité, de simplification
Pour les menus freedesktop, j'ai un peu de mal à comprendre pourquoi il a été choisi par rapport à JSON/XML, on pourrait pré-supposer qu'un menu est une hiérarchie d'entrées.
Parce que le json, c'est pas si vieux que ça ( dans le principe et dans l'usage en temps que tel, car sinon on aurait pu l'avoir plus tôt ).
Et parce qu'on veut avoir 1 fichier par entrée du menu, pour avoir 1 fichier par paquet installé. Ça rends le packaging trivial. ( donc pas besoin de hiérarchie d'objets )
Et parce qu'il y a pas que des menus chez freedesktop.
Enfin, les archives des discussions sont sur le web, tu doit réussir à trouver ça ( et les devs sont encore la, y a leur nom sur les documents )
Mais bon, des choses comme nodejs utilise le json pour les metadatas, donc c'est pas non plus un mauvais choix.
lxc de base utilise le même kernel que le système hote, donc on est pas à l'abri d'un souci. C'est pour ça aussi que des gens ont mis au point des choses comme des containers confinés par selinux. En fait, je devrait même pas avoir à expliquer à quelqu'un qui a fait une formation en sécurité, comme toi.
Et vous allez me faire croire qu'un admin ne sait pas gérer çà simplement ?
si tu étais admin, tu travaillerais sans doute avec des admins, et tu comprendrais que non, tout le monde ne le fait pas. Il suffit de voir le nombre de gens qui ne passent pas par la commande service pour ce genre de chose.
En gros, pour vous les Gentooistes sont incapables d'avoir une bonne méthode pour connaître les problèmes de sécurité
d'un soft sans la MAJ. Par exemple, si le OpenSSL nouveau débarque, ils ne sauraient pas ? Vous plaisantez là ?
Je dit que le projet gentoo n'a pas réussi à trouver de volontaire pour avoir les alertes sécurités par email pendant un temps. Ensuite, ouais, les gens peuvent lire à la main les listes des autres distributions sans problème.
Dans un monde de bisounours ton environnement est clean
ben, systemd le fait pour moi, donc oui. Je parle d'environnement au sens variable d'environnement.
Dites vous croyez qu'ils sont stupides chez Nginx, ou dans le kernel.org pour préferer un JSON like ?
Je crois pas que le kernel utilise un json like. Mais genre, nulle part.
En fait, nginx non plus. Un json-like, ça implique de se faire charger par un eval ( vu que le json, c'est juste du javascript ) et la config de nginx ne le fait pas. Mais la configuration de nginx a choisi d'exprimer des choses que le .ini ne supporte pas ( genre avoir une hiérarchie de réglage ), donc le .ini n'était pas bon pour eux.
En fait, je crois pas que le fait de faire d'autre choix implique la stupidité en général. Les contraintes sont différentes.
Ca prouve qu'il ne sait pas de quoi il parle. J'arrive à faire chauffer mon processeur, donc il doit bien être capable de faire fonctionner ras la gueule un serveur.
Peut être qu'il veut pas faire planter son serveur en prod. Ou peut être qu'il a mieux à faire que de faire des comparatifs. Mais son email est sur le site, tu devrais directement lui dire de lancer google chrome avec des tas d'onglets sur son serveur, histoire qu'il puisse compléter l'article.
J'ai bien ri: on vous dira sûrement: il suffit d'écrire un script pour régler vos problèmes.
Donc pourquoi personne chez debian n'a écrit de script pour ça ? ( sauf à nier la race condition que j'ai évoqué, et à me dire ce qui ne va pas dans le raisonnement )
2/ Si le gars a trop peur pour son système, il pourra toujours faire du git et/ou du svn avec son répertoire /var/* et/ou /etc/*
Avec un peu d'entraînement il va y arriver. Lorsqu'il maîtrise le processus, il automatisera la tâche…
ah, la bonne vielle idée de mettre /etc dans git ou svn. J'ai déjà tenté, comme tout le monde. Et comme tout le monde, j'ai vu que c'était une idée à la con.
Déjà, tout ne rentre pas dans git/svn. /etc/localtime, un superbe fichier binaire, n'a rien à faire la. /etc/password, qui va changer aprés chaque installation de demon, c'est pareil. Tout les fichiers avec des mots de passes, c'est pas terrible. Et puis, ça gére pas forcément bien les owner des fichiers. Ou le stockage des liens, ça coince ( ou du moins, c’était pas bon à l'époque ). Ensuite, bah, /etc/ c'est pas tout ce qui sert à ton systéme, vu qu'il manque les paquets, etc. On va me dire "mais y a aussi /var/ dans sa proposition". Oui, parce que c'est bien connu, on peut prendre la base des paquets rpms ou deb et pouf, ç'est bon, ça se mets dans un vcs sans prendre une tonne de place, sans poser des soucis avec les diffs parce que c'est du binaire. Et surtout, ça bouge pas à chaque upgrade.
Et au final, on a quoi ? Ben rien, parce que ton dépôt, tu peux pas l'appliquer à une autre bécane sauf à vouloir un clone imparfait. Tu peux tout juste revenir en arriére d'un coup.
Mais en fait, quand on fait les choses bien, on utilise un outil comme puppet, chef, cfengine, etc. Comme le font toute les grosses distros comme dit à une table ronde au fosdem l'année dernière.
Systemd est refusé par deux distributions majeures et à peine acceptée par d'autres.
En effet, ils savent très bien que linux est tiré par RedHat, parce que RedHat a des sous, les autres moins.
Alors, à peine accepté, c'est ni l'avis des gens de Mageia, ni l'avis des gens d'Opensuse. Ni des devs d'archs.
Et Suse a des sous, ils sont numéro 2 sur le marché, ( voir 1 sur certains marché ssi j'en croit leur plaquette ). Si ils voulaient refuser, ils pourraient. Par exemple, ils ont ni anaconda, ni yum.
Quand à Canonical, ils ont aussi assez de sous pour faire unity ( donc refuser gnome 3 ou kde ), pour faire tourner une boite de 400 ou 500 personnes, pour avoir son propre truc de gestion de cloud ( juju, maas ), voir même pour faire son propre systéme d'init. Donc j'ose supposer à partir de la 2 choses :
- si une boite qui gagne pas assez pour être à l'équilibre ( aka canonical ) a les moyens de pas suivre RH, d'autres ont les moyens. L'argument des sous est donc faux.
- si les distrib totalement communautaire veulent prendre openrc, upstart, init-ng ou juste garder sysvinit ( ce code shell si facile à maintenir, je pige pas que personne n'ai encore fait de fork à la MATE ), elles peuvent aussi. Y a rien qui les force.
Tu semble n'avoir aucune idée de la façon dont une distribution marche ou de la façon dont les décisions sont prises, donc tu te raccroche à un modèle erroné ou l'argent règne.
un bug ou le reporter n'a plus rien posté depuis 10 jours, ce qui nous laisse un peu sur notre faim sur son origine ou le problème réel. A plus forte raison si personne n'arrive à reproduire.
Pourquoi ne pas l'avoir contruit avec un JSON like bon sang de bonsoir ?
Parce que c'est pourri ?
Soit c'est du json, et c'est pourri pour de la configuration ( exemple, comment on fait un commentaire en json ).
Soit c'est du truc qui ressemble à du json ( cad, dans le cas que tu cites, nginx, un vague format avec des {} ) et c'est chiant à parser ( vu que c'est plus du json, tu oublies les outils classiques), et ça revient à faire ton propre DSL. Ce qui revient à augmenter encore la courbe d'apprentissage pour rien ( car ton histoire de json-like, en d'un péremptoire "c'est pas pro", ça apporte quoi ? ). Et c'est pourri.
Où il m'a mis la patée ?
Un peu dans tout les commentaires. Dans celui la aussi.
Je dirais pour terminer que je souhaiterais que linux ne dépende pas trop de RedHat [freedesktop, xorg, pusleaudio, nouvel init (systemd), etc.].
Mais en effet, moi, j'aimerais bien aussi que l’origine des contributions soit plus varié.
Et pour ça, y a pas de secret, faut se bouger. Je suis sur qu'un spécialiste du sujet devrait sans souci apporter son expertise à un projet.
Sinon, bah, juste soutenir opensuse ( ah non, la communauté choisit plutôt de ressortir des trucs sans rapport datant d'il y a 5 ans ce qui démotive les rares gens motivés ), soutenir nokia ( ah non trop tard ), filer du pognon à Canonical ( ah non, personne paye ) ou à Mandriva ( ah non, comme Nokia ), enfin bref, injecter de l'argent dans les boites qui contribuent autre que RH.
Tiens je suis déjà à -3 alors que je viens juste de poster…
D’après https://linuxfr.org/wiki/karma , tu peux aller jusqu'à -10 par défaut.
Donc, si tu es à -3, ça veut dire que tu as un karma entre -20 et -10, ce qui veut dire que tu as perdu non seulement les 20 points de base, mais aussi ce que tu as pu avoir au fil du temps. Et je pense qu'à ce rythme, tu va juste être à -10 par défaut d'ici 2 semaines au mieux.
Par exemple, il est pas formellement spécifié. Si j'ai :
[foo]
Toto=tata
Toto=coin
Je suis pas sur que tout les parsers le lisent ( et me donne que toto a 2 valeurs, ou l'ordre ).
Genre python a 3 classe de parsers pour le .ini .
Il permet pas de faire de tableau, et de trucs à plusieurs niveaux imbriqués, n'a pas de schema ( même si ça pourrait se rajouter )
contrairement à du yaml, du xml, ou du json.
Ensuite, la syntaxe est comprise par tout le monde de façon quasiment intuitive, il y a des parsers pour tout
( même si ça peut coincer dans les détails ). C'est pas le format qui va résoudre tout les soucis du monde, mais je doute qu'il existe, et dans le cas de systemd, ça fait l'affaire. On s'en sert déjà pour le reste des projets freedesktop ( genre les menus, etc ), donc il est en plus "standard".
Sinon, le blog que tu as pointé manque de perspective, par exemple, sur l'histoire du /usr merge, il ne pige pas que le role de / est passé à l'initrd, et que dont celui du /usr partagé est passé à tout /usr par le dit merge, ie, que c'est en faisant un système minimaliste à façon qu'on règle le problème du bloat de /.
Il dit que le passage à /run a été d'ignorer le FHS, mais justement, le changement vers /run fait parti du FHS 3.0 justement parce que les distributions se sont mis d'accord ( https://bugs.linuxfoundation.org/show_bug.cgi?id=758 ), et que le passage vers un sous dossier de /run est pour des questions de robustesses ( ie, pour une ressources non partagés sur un système qui lui est partagé , pour éviter les conflits de nom ).
Les divers changements sont pas la pour faire joli, en général, ça vise à tenter de corriger des vrais soucis. Personne ne se rajoute du boulot pour rien, y a déjà assez à faire sur les distributions classiques
Le fait est que les gestionnaires de paquets pourraient faire le merge automatiquement. Sauf qu'ils font pas pour la plupart ( et je dit pour la plupart, car de ce que j'ai vu, au mieux, c'est un hook avec etc-update configuré à la mano par l'admin, mais je doute pas que quelqu'un a du faire un truc plus chiadé un jour ).
Par exemple, quelqu'un avait tenté d'intégrer ça dans mandriva : http://blog.zerodogg.org/2005/09/29/common-configuration-parser-ccp/
Quand au fait d'être incompatible, bien sur. Si la solution miracle aux upgrades existait, je pense bien qu'on l'utiliserais depuis le temps ( exemple le ccp proposé plus haut ).
Maintenant, si tu prends l'exemple d'apache qui fourni un répertoire ou tu mets ta config en plus du fichier de base de la distro, le seul risque, c'est le jour ou apache change radicalement ( passage en 2.4 ), genre une fois tout les 4/5 ans. Pas une fois à chaque upgrade de version de la distro, ou une fois de temps en temps lors d'un souci de sécurité qui va modifier la config pour bloquer l'action TRACE ou changer je ne sais pas quel config par défaut incorrect.
systemd existe depuis 7 ans et n'est toujours pas implémenté dans toutes les distributions !!! )
Le premier commit sur le git de systemd, c'est pas en 2006.
Par contre, tu confond sans doute avec udev, qui a été fusionné dans systemd, et lui, il est utilisé presque partout.
Les rares articles que j'ai lu sur systemd faisaient souvent des critiques sur lui.
Et la réalité des faits sur la mailling list montre le contraire. Faut pas croire tout ce qu'on dit sur le web, à commencer les attaques personnels. Personne ne va dire que Linus Torvalds a tendance à s'enerver, alors que ça serait sans doute intolérable par n'importe ui d'autre. Personne ne dit "faut pas utiliser openbsd car theo de raadt est un colérique", alors qu'il a plus d'une fois poussé une gueulante. Et personne n'a dit "ne pas utiliser la glibc,Ulrich Drepper est un asocial".
Vous n'allez pas me faire croire que vous qui vous vantez d'être un utilisateur très averti de linux
ne mélangez pas des paquets.
Non, je pousse mes paquets directement dans la distro. Ou je reprends le paquet et le recompile. Je mélange pas les paquets binaires le moins du monde, c'est moche.
sous entendu, il n'est pas EXACTEMENT le même. C'est bien ce que je pense.
Les packageurs backportent les correctifs. C'est facile à vérifier, vu que tout est publié.
Je ne vous permets pas de dire que Mageia est petite
J'ai été admin du projet Mageia pendant 2 ans, secretaire de l'association, membre du board, donc je connais la taille de la communauté, je sais combien y a de compte dans le ldap ( que j'ai aidé à mettre en place, que j'ai tenu à jour ), donc je pense être parfaitement capable de déterminer si c'est petit ou pas. Donc le droit de le dire, je le prends avec ou sans la permission d'un inconnu.
Oui, mais ce qu'on ne vous dira jamais c'est que tout cela est propriétaire.
Launchpad est libre, sous AGPL depuis 2009. Y compris Soyuz, la partie responsable du build system.
Sinon, l'OBS est libre aussi et supporte debian directement.
Ensuite que launchpad soit difficile à installer est bien connu. En fait, qu'un système de build soit compliqué à déployer est aussi connu. Et que les systémes de build soit spécifique est aussi hélas bien connu, mais sans doute parce que personne ne bosse pour les rendre compatible ( à part suse ).
J'aurais pu être admin si je le voulais. J'ai même suivi une formation en sécurité informatique.
Impressionnant. J'ai bossé dans une boite spécialisé en sécurité informatique après avoir eu un DESS en sécurité, on peut donc continuer à jouer celui qui a la plus grosse, mais je pense que c'est pas productif.
Et avoir suivi une formation est une chose, mais ça dépend de la durée, du contenu. Et la sécurité, c'est vague, ça va du très théorique ( genre la séparation de domaine et l'analyse haut niveau comme le ferait un analyste ) au plus pratique ( genre, savoir coder de manière sécurisé, mettre en place un firewall, faire un audit ). J'ai fait des cours de compta à la fac, je vais pas dire à un comptable comment il doit faire son métier.
Stallman vous contredirait: vous avez la liberté de copier, cloner, tout ou partie, etc.
La liberté de faire un truc implique pas de ne pas être ridicule. Exemple, tu as la liberté de poster des trucs ridicules, tu t'en sert, ça veut pas dire que ça reste pas ridicule.
En raid logiciel pur, ie sans /boot séparé hors des partoches en raid ?
Dans mon souvenir, le souci est que grub ne comprenant par le raid, il faut charger le kernel et l'initrd depuis une partoche /boot en dehors du raid, et faire la synchro plus ou moins à la main.
Oui, et visiblement, il y a encore d'autres endroits dans le cookbook d'upstart ( que j'ai commencé à relire ) ou ils reprennent le même système de modifier des fichiers qui sont pas de la configuration.
Mais c'est un problème compliqué, car parfois, un fichier de configuration n'arrive pas à exprimer toutes les subtilités de ce que tu veux exprimé, et parfois, faut juste essayer de rentrer dans les clous.
dpkg-divert, c'est un moyen de hacker sans trop de dégât immédiat ton système, mais c'est pas tenable. Et tu peux pas rendre tout configurable non plus.
[^] # Re: ClamWin
Posté par Misc (site web personnel) . En réponse au journal Davfi, le premier antivirus libre français.. Évalué à 10.
bah, suffirait pour les gens de davfi de bosser sur clamav directement au lieu de repartir de 0 en se disant "je fait mieux que tout le monde".
Ah non, on me dit qu'il s'agit d'un antivirus sur la base de clamav :
http://pro.clubic.com/it-business/securite-et-donnees/actualite-449556-securite-davfi-projet-antivirus-francais-open-source.html
Bien sur, faire un projet libre, ça impliquerais de suivre les bonnes pratiques, comme "envoyer les patchs pour publication et revue auprès des externes", et pas "coder dans notre coin puis faire un produit semi proprio". Enfin, tant que Davfi ne tente pas de poser des brevets à l'étranger sur ses "innovations" ça devrait aller. Ça serait quand même un truc qui risquerait de ternir sa réputation auprès des libristes, ça. Et ça serait un peu nulle de l'avoir dit dans un événement du libre un jour à quelqu'un.
[^] # Re: Mouais
Posté par Misc (site web personnel) . En réponse au journal Davfi, le premier antivirus libre français.. Évalué à 10.
Ah aha ah.
pardon.
Donc motivé, sans doute. Qui connait son sujet, ça dépend fortement du sujet. Il a dit avoir cassé AES, mais en fait non ( cf http://eprint.iacr.org/2003/022.ps ) . Il a dit avoir cassé tor, mais en fait, non. Ou plutôt, l'attaque, c'est "si je rajoute assez de noeud compromis, le réseau est compromis". Comme dirait un collègue, "no shit sherlock". Mais c'est une attaque connu ( à savoir celle d'un attaquant global avec assez de noeuds ), et il a monté toute la sauce autour de ça en utilisant des choses complexes comme "utiliser un virus pour infecter les relais sous windows pour compromettre le code de tor par injection dans le process", ce qui est plus vendeur que "remplacer le binaire de tor via un exploit IE". Et j'invite les gens à lire ce post de blog, et à suivre les liens :
https://blog.torproject.org/blog/rumors-tors-compromise-are-greatly-exaggerated
Je pourrait aussi parler de perseus ou seclamav.
Et en fait, plutot que de me répéter, j'ai déjà dit tout ce que je pense de Davfi sur le premier journal, avec déjà le même type de titre, fait par la même personne :
https://linuxfr.org/users/vida18/journaux/davfi-le-premier-antivirus-open-source-made-in-france
Et pour la petite histoire, mon commentaire a amené un des responsable du projet à venir me parler lors de l'Open WOrld Forum pour ce que j'ai personnellement pris pour des menaces, en me demandant d’arrêter sinon des choses seront mises en place. Après enquête rapide ( car bon, quand on connait vraiment du monde, ça va plus vite ), ce que j'ai compris, c'est surtout que quelqu'un a fait remarquer à quelqu'un de l'APRIL que le projet est pas si libre qu'on veut nous le faire croire, et qu'il y a eu discussion entre des gens de l'APRIL et le dit responsable, et il pense que c'est moi qui a tuyauté et donc sali la réputation du logiciel auprès de l'association. N'importe qui capable de lire les annonces va voir que le projet est pas clair du tout et que le qualifier de libre ou d'opensource, c'est juste un raccourci marketing. Ou alors va falloir revoir le jugement sur github et mac os x à ce niveau si il suffit d'avoir juste un morceau sous une licence potable pour que tout soit libre.
Et vue qu'on a déjà bien entamé 2013 mine de rien, je trouve curieux de voir que les fiches de recrutements sont encore la depuis plus de 8 mois ( http://www.davfi.fr/recrutement.html ) et qu'il y a pour le moment que de la communication autour du projet. Peut être qu'il y a pas assez de personne pour mettre à jour le site. C'est vrai que 5 millions de cash, ça permet pas de payer un webmaster.
[^] # Re: redhat en poste de travail
Posté par Misc (site web personnel) . En réponse à la dépêche Sortie de Red Hat Enterprise Linux 6.4. Évalué à 5.
Oui, et puis, c'est pas parce que tu peux avoir un truc gratuitement qu'il n'a pas de valeur, ou que quelqu'un n'a pas passé du temps et de l’énergie dessus.
Mandriva s'en sortait pas si mal avec le club ( ou du moins, était en bonne voie ), avant que Canonical n'arrive, ne réduise le marché du desktop à zero ( en sciant aussi la branche sur laquelle elle voulait s’assoir dans le futur )
50€ par an, c'est largement moins que le crédit que tu rembourses sur un iphone par exemple. Mais bon, c'est aussi vachement moins hype, je comprends que les gens préfèrent financer l'innovation chez Apple que la maintenance chez d'autres ( car Suse propose aussi le même genre d'offre ).
[^] # Re: c'est donc bien votre faute à tous
Posté par Misc (site web personnel) . En réponse au sondage Quel est votre niveau d'utilisation du libre ?. Évalué à 2.
Bah attends, si tu as la solution, pourquoi tu poses la question :/
[^] # Re: redhat en poste de travail
Posté par Misc (site web personnel) . En réponse à la dépêche Sortie de Red Hat Enterprise Linux 6.4. Évalué à 6.
Ben si personne ne paye, forcément, personne ne va se dire que ça vaut le coup d'investir la dedans. En fait, faut pas chercher plus loin le pourquoi personne investit dans le poste de travail pour particulier.
# 5 premières minutes sans son
Posté par Misc (site web personnel) . En réponse au journal Systemd dans Debian, la vidéo. Évalué à 10.
Alors j'ai chopé la vidéo, et pendant 5 minutes, y a pas de son ( ce qui m'a fait chercher pendant 30 secondes le problème )
Sinon, à 23/24 minutes : "Jessy, the next release, we will probably use sysvinit on most system".
"In gnome 3, I think, we will start to depend on systemd, and that will create lots of interesting flamewar."
"By default, I think, we will likely see sysvinit as still the default, systemd is going to be supported. If we can move to a single init system for jessy, that would make me very happy, but I don't think that's gonna fly politically. because this is as much a political question as a technical question."
Donc en gros, systemd supporté officiellement, mais pas installé par défaut.
Suivi d'une discussion sur le passage de jessie à logind pour l'équipe gnome, avec un impact inconnu pour kfreebsd. Ils n'ont pas les ressources pour maintenir consolekit et pas d'utilisateur de kfreebsd et de gnome, ce qui leur prends du temps pour rien d’après un des 2 conférenciers.
Ensuite, Tolef ( je crois ), explique qu'ils veulent rendre systemd plus facile à packager ( outil systemd aware, synchronisation de l'état des systems d'init ), et il y a une question de l'assistance.
Le reste attendras.
[^] # Re: Hein
Posté par Misc (site web personnel) . En réponse au journal Delta Lloyd Lebensversicherung AG fait confiance à SUSE pour gérer ses serveurs Redhat. Évalué à 8.
De ce que je sais, l'équipe ovirt serait intéressé par quelqu'un pour faire le paquet debian, et pour le moment, il y a juste des instructions sur le web ( http://www.ovirt.org/Ovirt_build_on_debian/ubuntu ).
Visiblement, il y a aussi une équipe autour de freeipa ( http://qa.debian.org/developer.php?login=pkg-freeipa-devel@lists.alioth.debian.org )
Et spacewalk supporte debian.
Par contre, je vois pas le support de SAP pour Debian, du coup, j'ai du mal à voir en quoi Debian serait si en avance. Et la comparaison entre un système avec une durée de vie de 2 à 3 ans comme Debian, et un truc à plus longue durée ( genre 10 ans ) comme SLES ou RHEL me parait aussi curieuse. Du coup, le qualificatif "blaireaux" me semble un chouia mal trouvé.
[^] # Re: Vla le débat
Posté par Misc (site web personnel) . En réponse au journal Delta Lloyd Lebensversicherung AG fait confiance à SUSE pour gérer ses serveurs Redhat. Évalué à 2.
Novell et Suse sont 2 business unit séparés maintenant.
Et c'était plus un accord commercial de vente conjointe de support linux et windows, ce qui en soit me semble pas totalement déconnant dans un environnement mixte. C'est pas comme si les SSIIs ou les revendeurs n'étaient pas déja tous en train de faire ça depuis des années.
# Plus de précision
Posté par Misc (site web personnel) . En réponse au journal Delta Lloyd Lebensversicherung AG fait confiance à SUSE pour gérer ses serveurs Redhat. Évalué à 10.
Alors pour tout ceux qui comme moi n'ont jamais entendu parler de quoi parle ce journal, et dans le but d'essayer d'aider Samuel à être pertinent :
Delta Lloyd Lebensversicherung AG est visiblement un courtier en assurance allemand. En fait, c'est la filiale d'une filiale d'une banque présente dans 3 pays, le 6eme assureur des pays bas. J'ai pas trouvé grand chose sur la filiale mais on parle d'une migration d'un parc de 60 serveurs en RHEL.
Les chiffres proviennent directement d'un pdf sur le site de novell ( www.novell.com/docrep/2013/01/delta_lloyd_lebensversicherung_ee.pdf ). Le pdf souffre d'un manque de précision, il parle de cout de license au lieu de cout de souscription ( la différence est subtile ), et il oublie des détails. Par exemple, pourquoi l'interface de Suse Manager ressemble à celle de RHN ( ce qui évite donc les couts de formation ), ou pourquoi se concentrer sur l'OS alors que les couts d'Oracle et de SAP sont souvent les plus importants ( et ceci sans compter les 70 à 90% de réductions par rapport au prix public, je pige pas pourquoi personne ne proteste contre ça auprès des autorités ).
Pour ceux qui n'ont jamais entendu parler de Suse manager ( car c'est quand même une offre assez peu connu ), c'est une version de Spacewalk ( http://spacewalk.redhat.com/ ), le produit à la base de satellite ( qui est l'offre commercial de Red Hat du code de spacewalk, cad avec un travail de stabilisation, de documentation, de support sur une version "figé" dans le temps ), mais proposé par Suse. Satelitte ayant été annoncé comme projet communautaire en 2008 lors du RH Summit à Boston, il a donc fallu un peu de temps pour que des gens se penchent dessus.
Les 2 sociétés travaillent main dans la main sur l'engineering d'un produit libre, ça n'arrive pas si souvent hélas.
Le logiciel permet de voir à quel niveau d'update sont les serveurs, d'installer des paquets, de gérer les dépôts et les migrations ( genre test => production, etc ), via une interface web, mais également via une API tout ce qu'il y a de plus classique.
Plus d'info sur la doc, soit de suse manager :
https://www.suse.com/documentation/suse_manager/book_susemanager_quickstart/data/art_susemanager_quick.html
ou les documentations du produit original :
https://access.redhat.com/knowledge/docs/Red_Hat_Network_Satellite/?locale=en-US
A noter qu'une version plus moderne est en cours d'écriture sous le nom de Katello ( http://www.katello.org/ ) avec pulp, candlepin, etc. J'ai pas encore compris comment tout s'emboite exactement, vu que c'est encore en cours d'écriture et dispo officiellement dans aucune distribution, mais les gens qui s'intéressent au sujet peuvent regarder en détail.
[^] # Re: Mauvaise interprétation
Posté par Misc (site web personnel) . En réponse au journal Systemd dans Debian. Évalué à 2.
ou EDITOR="perl -e + stuff " crontab -e
En fait, le coup de faire une modif de contab, c'est de pas avoir de locking. Je suppose qu'il y a peu de risque en pratique, mais je pense que /etc/cron.d est plus sur à ce niveau la.
[^] # Re: Vraiment ?
Posté par Misc (site web personnel) . En réponse au journal Systemd: tuons les mythes. Évalué à 3.
Donc attends, tu inventes ce que je dit, puis tu dit que ça correspond pas à la réalité. Et ensuite tu dit que tu n'utilises pas d'argument de l'homme de paille, vraiment ?
Vu que visiblement, tes arguments ne s'encombrent pas de précision, je vais compléter pour toi.
Le format que tu cherches, c'est protobuf :
http://code.google.com/p/protobuf/
Bien que tu ne donnes pas de définition de ton neologisme "json-like", je suppose que tu parles de ça à cause des '{' et '}' servant de délimiteurs. Ça n'a rien de json, car l'avantage du json, c'est de se lire directement presque partout. La, il faut un parser spécifique pour le .proto, par exemple.
Encore une fois, la configuration d'un service n'a pas besoin d'une structure complexe, quoi que des années de java ont réussi à faire croire. Tu définit des variables simples pour définir ce que tu veux, et le reste dépend du logiciel. Donc à partir de la, un simple format clé/valeur doit suffire. D'ailleurs, il a suffit pendant des années pour justement la fameuse philosophie unix à base de variable d'environnement ( modulo le besoin d'avoir des tableaux comme $PATH, $LS_COLORS, mais c'est minoritaire )
Donc non, je pense que chaque format a ses avantages, et à partir de la, il faut choisir.
[^] # Re: Mauvaise interprétation
Posté par Misc (site web personnel) . En réponse au journal Systemd dans Debian. Évalué à 2.
C'est le cas car tout le monde est passé à cronie, qui a pris le patch debian sur le sujet.
IE, la version cron d'avant ( ie, vixie cron ), non maintenu, n'a jamais fait ça de base.
[^] # Re: Mauvaise interprétation
Posté par Misc (site web personnel) . En réponse au journal Systemd dans Debian. Évalué à 2.
Mais seulement pour root, via /etc/cron.d .
[^] # Re: Intégration de LXC
Posté par Misc (site web personnel) . En réponse au journal Systemd dans Debian. Évalué à 3.
En F18, y a déjà http://danwalsh.livejournal.com/59144.html
Mais c'est vrai que le lancement à la demande d'un containeur , comme montrer ici : http://savanne.be/articles/deploying-node-js-with-systemd/ , ça permet d'envisager faire des trucs sympas en auto hebergement.
par exemple, mon blog, je pense qu'il a pas besoin d'être en permanence entre de prendre de la ram pour 10 visites par jour. Ou un phpmyadmin par exemple.
Donc le moins de ram on prends, le mieux c'est, surtout sur des trucs genre beagleboard, raspberrypi, etc, ou sur des serveurs ou on paye à la ram, genre amazon ec2, gandi, etc…
[^] # Re: Je ne suis toujours pas convaincu
Posté par Misc (site web personnel) . En réponse au journal Systemd: tuons les mythes. Évalué à 3.
Ensuite, on rentre aussi dans la sémantique. par exemple, dire que tout ce qui n'est pas interdit est autorisé. Et c'est pas interdit d'avoir d'autres repertoire haut niveau, et que les liens permettent de garder la compatibilité. Dire que si tu trouves ton soft dans /bin/ alors les executables pour booter y sont.
Enfin, je pense que personne ne suit à la lettre la FHS. Exemple gentoo à /usr/portage ( alors que ça devrait être dans /var ), Debian a du /usr/games, avec des régles en plus, Fedora/RHEL ont longtemps eu /selinux, et ont toujours /usr/libexec ( suivant les gnu coding standards http://www.gnu.org/prep/standards/html_node/Directory-Variables.html ).
Donc au final, c'est aussi pour ça que je trouve l'auteur du blog comme se focalisant sur les détails "visibles", alors qu'il y avait déjà plein de problème. Le fait d'avoir un /usr/libexec pose des soucis pour les outils qui codent en dur les chemins tout comme /usr/games. ( et c'est juste les détails que j'ai en tête un dimanche matin avant le fosdem ).
[^] # Re: Je ne suis toujours pas convaincu
Posté par Misc (site web personnel) . En réponse au journal Systemd: tuons les mythes. Évalué à 2.
sauf erreur de ma part, le blocage est de savoir si les admins peuvent ou pas mettre /run sur autre chose qu'un tmpfs.
Et le reste est commité dans le draft.
https://bugs.linuxfoundation.org/show_bug.cgi?id=718#c13
Et je pense que tu as visiblement une idée bien précise sur la façon dont le standard doit évoluer, à savoir d'abord discuter et ensuite coder. Ça, ça s'appelle du design by comitee. Parfois ça marche. Parfois ça marche pas.
Si la FHS fonctionne autrement et se décide à juste documenter le consensus, ça marche aussi. Donc au final, si les distributions y trouvent leur comptes, qui va être emmerdé ?
Malheureusement, le commit ne donne pas des masses de détails.
De ce que je vois, le changement a 2 composantes : passage sur un tmpfs ( donc /run, supposement tmpfs par défaut ) et passage dans un dossier utilisateur ( /run/media/$USER/$DISQUE ).
Mettre /media en tmpfs aurait sans doute été un problème pour les mises à jours ( ie, changement de comportement ).
Donc tu doit prendre /run ou un autre chemin.
Mettre /run/ entier, c'est niet. Donc un sous repertoire. /run/$USER ou /run/$DISQUE, y a des risques de conflits ( surtout /run/$DISQUE ). Donc ajout de /media, nom fixe.
/run/media/$USER, ça permet de monter 1 disque à la fois, ce qui est niet.
/run/media/$DISQUE, ça marche dans les cas simples, mais pas dans le cas d'une station ou plus d'une personne peut se connecter ( le fameux multiseat qu'on a tous deja utilisé via ssh ). On retrouve çavia du thin client, etc. En effet, si tu fait ça, quelqu'un peut mettre une clé du même nom, et toi, au mieux, tu te demandes laquelle c'est, au pire, tu écrit sur la mauvaise. De surcroit, avec des clés en fat32 ( ou en udf, comme Tanguy le propose sur son blog ) en lecture pour tous, il y a une fuite de données évidentes ( ie, tout le monde peut lire ma clé avec mes documents via ssh ). Une solution alternative serait de faire le montage en forcant l'umask et les droits, mais tout les fs ne le supportent pas; et il y a peut être un souci caché que j'ai pas trouvé dans cette façon de faire ( ne serais que parce que sauf erreur de ma part, aucune distro ne le fait ).
donc /run/media/$USER//$DISQUE, avec $USER ayant des acls.
Bien que je n'ai pas pu tester, je pense qu'une solution au problème d'avoir à taper des chemins plus long serait pour l'utilisateur expert de rajouter son device directement dans /etc/fstab. Udisks respecte les réglages et devrait du coup monter la clé la ou c'est demandé.
Le souci, c'est que la FHS dit juste "faut mettre les commandes pour monter les autres fs", en ne spécifiant rien.
Du coup, tu te retrouves à mettre tout ce qui pourrait servir à un moment à monter un disque dans /. Donc par exemple, sur debian, une des rares distros à se donner la peine de le faire proprement ( vu que les autres s'en foutent un peu, dans le sens ou personne ne teste vraiment, et surtout, personne n'ouvre de bug ), tu as tout les fs réseau et toutes les dépendances dans /lib, /bin, et /sbin/. Et j'ai eu du mal à trouver un contre exemple, mais j'ai fini par en trouver 1 ( aprés 4/5 essais ). Si tu veux avoir ton /usr en iscsi, tu peux pas :
http://packages.debian.org/sid/alpha/open-iscsi/filelist car les commandes sont dans /usr/
( et le iscsi est vachement plus courant que l'exemple capilotracté de sshfs que j'aurais pou sortir, ou celui d'avoir ton /usr en afs via kerberos ( http://packages.debian.org/sid/armel/openafs-client/filelist ))
En pratique, le fait d'avoir tout dans /usr, ça permet de faire des containers plus facilement ( ou justement, de monter totalement /usr via le réseau comme avant sans avoir à garder le /bin local en synchro avec le /usr distant ), ça permet de faire des rollbacks plus facilement ( même si personne ne le fait, je pense que snapper devrait réussir à en tirer parti sous peu ). Je comprends que ça dérange, car la migration entraine un risque, parce qu'on a le sentiment de bousculer l'ordre établi ( un comme avoir quelqu'un qui range ton bureau, ça te fait toujours chier ).
Mais en pratique, c'était à la bonne franquette pour savoir quoi était ou, et c'était pas terrible la façon dont les distros l'ont mis en place.
Ensuite, tout le monde n'a pas suivi, et pour l'avoir fait, je doit reconnaitre que si on m'avais pas dit, j'aurais sans doute rien remarqué tellement c'était sans douleur. Il ne reste plus qu'à attendre que quelqu'un en tire parti.
c'est sur un tmpfs pour pouvoir nettoyer tout seul le truc. C'est pas déconnant. Et pour des questions de sécurité, de simplification
[^] # Re: Vraiment ?
Posté par Misc (site web personnel) . En réponse au journal Systemd: tuons les mythes. Évalué à 2.
Parce que le json, c'est pas si vieux que ça ( dans le principe et dans l'usage en temps que tel, car sinon on aurait pu l'avoir plus tôt ).
Et parce qu'on veut avoir 1 fichier par entrée du menu, pour avoir 1 fichier par paquet installé. Ça rends le packaging trivial. ( donc pas besoin de hiérarchie d'objets )
Et parce qu'il y a pas que des menus chez freedesktop.
Enfin, les archives des discussions sont sur le web, tu doit réussir à trouver ça ( et les devs sont encore la, y a leur nom sur les documents )
Mais bon, des choses comme nodejs utilise le json pour les metadatas, donc c'est pas non plus un mauvais choix.
[^] # Re: Vraiment ?
Posté par Misc (site web personnel) . En réponse au journal Systemd: tuons les mythes. Évalué à 6.
lxc de base utilise le même kernel que le système hote, donc on est pas à l'abri d'un souci. C'est pour ça aussi que des gens ont mis au point des choses comme des containers confinés par selinux. En fait, je devrait même pas avoir à expliquer à quelqu'un qui a fait une formation en sécurité, comme toi.
si tu étais admin, tu travaillerais sans doute avec des admins, et tu comprendrais que non, tout le monde ne le fait pas. Il suffit de voir le nombre de gens qui ne passent pas par la commande service pour ce genre de chose.
Je dit que le projet gentoo n'a pas réussi à trouver de volontaire pour avoir les alertes sécurités par email pendant un temps. Ensuite, ouais, les gens peuvent lire à la main les listes des autres distributions sans problème.
ben, systemd le fait pour moi, donc oui. Je parle d'environnement au sens variable d'environnement.
Je crois pas que le kernel utilise un json like. Mais genre, nulle part.
En fait, nginx non plus. Un json-like, ça implique de se faire charger par un eval ( vu que le json, c'est juste du javascript ) et la config de nginx ne le fait pas. Mais la configuration de nginx a choisi d'exprimer des choses que le .ini ne supporte pas ( genre avoir une hiérarchie de réglage ), donc le .ini n'était pas bon pour eux.
En fait, je crois pas que le fait de faire d'autre choix implique la stupidité en général. Les contraintes sont différentes.
Peut être qu'il veut pas faire planter son serveur en prod. Ou peut être qu'il a mieux à faire que de faire des comparatifs. Mais son email est sur le site, tu devrais directement lui dire de lancer google chrome avec des tas d'onglets sur son serveur, histoire qu'il puisse compléter l'article.
Donc pourquoi personne chez debian n'a écrit de script pour ça ? ( sauf à nier la race condition que j'ai évoqué, et à me dire ce qui ne va pas dans le raisonnement )
ah, la bonne vielle idée de mettre /etc dans git ou svn. J'ai déjà tenté, comme tout le monde. Et comme tout le monde, j'ai vu que c'était une idée à la con.
Déjà, tout ne rentre pas dans git/svn. /etc/localtime, un superbe fichier binaire, n'a rien à faire la. /etc/password, qui va changer aprés chaque installation de demon, c'est pareil. Tout les fichiers avec des mots de passes, c'est pas terrible. Et puis, ça gére pas forcément bien les owner des fichiers. Ou le stockage des liens, ça coince ( ou du moins, c’était pas bon à l'époque ). Ensuite, bah, /etc/ c'est pas tout ce qui sert à ton systéme, vu qu'il manque les paquets, etc. On va me dire "mais y a aussi /var/ dans sa proposition". Oui, parce que c'est bien connu, on peut prendre la base des paquets rpms ou deb et pouf, ç'est bon, ça se mets dans un vcs sans prendre une tonne de place, sans poser des soucis avec les diffs parce que c'est du binaire. Et surtout, ça bouge pas à chaque upgrade.
Et au final, on a quoi ? Ben rien, parce que ton dépôt, tu peux pas l'appliquer à une autre bécane sauf à vouloir un clone imparfait. Tu peux tout juste revenir en arriére d'un coup.
Mais en fait, quand on fait les choses bien, on utilise un outil comme puppet, chef, cfengine, etc. Comme le font toute les grosses distros comme dit à une table ronde au fosdem l'année dernière.
Alors, à peine accepté, c'est ni l'avis des gens de Mageia, ni l'avis des gens d'Opensuse. Ni des devs d'archs.
Et Suse a des sous, ils sont numéro 2 sur le marché, ( voir 1 sur certains marché ssi j'en croit leur plaquette ). Si ils voulaient refuser, ils pourraient. Par exemple, ils ont ni anaconda, ni yum.
Quand à Canonical, ils ont aussi assez de sous pour faire unity ( donc refuser gnome 3 ou kde ), pour faire tourner une boite de 400 ou 500 personnes, pour avoir son propre truc de gestion de cloud ( juju, maas ), voir même pour faire son propre systéme d'init. Donc j'ose supposer à partir de la 2 choses :
- si une boite qui gagne pas assez pour être à l'équilibre ( aka canonical ) a les moyens de pas suivre RH, d'autres ont les moyens. L'argument des sous est donc faux.
- si les distrib totalement communautaire veulent prendre openrc, upstart, init-ng ou juste garder sysvinit ( ce code shell si facile à maintenir, je pige pas que personne n'ai encore fait de fork à la MATE ), elles peuvent aussi. Y a rien qui les force.
Tu semble n'avoir aucune idée de la façon dont une distribution marche ou de la façon dont les décisions sont prises, donc tu te raccroche à un modèle erroné ou l'argent règne.
un bug ou le reporter n'a plus rien posté depuis 10 jours, ce qui nous laisse un peu sur notre faim sur son origine ou le problème réel. A plus forte raison si personne n'arrive à reproduire.
Parce que c'est pourri ?
Soit c'est du json, et c'est pourri pour de la configuration ( exemple, comment on fait un commentaire en json ).
Soit c'est du truc qui ressemble à du json ( cad, dans le cas que tu cites, nginx, un vague format avec des {} ) et c'est chiant à parser ( vu que c'est plus du json, tu oublies les outils classiques), et ça revient à faire ton propre DSL. Ce qui revient à augmenter encore la courbe d'apprentissage pour rien ( car ton histoire de json-like, en d'un péremptoire "c'est pas pro", ça apporte quoi ? ). Et c'est pourri.
Un peu dans tout les commentaires. Dans celui la aussi.
ça va être dur :
http://community.redhat.com/contributions/
Mais en effet, moi, j'aimerais bien aussi que l’origine des contributions soit plus varié.
Et pour ça, y a pas de secret, faut se bouger. Je suis sur qu'un spécialiste du sujet devrait sans souci apporter son expertise à un projet.
Sinon, bah, juste soutenir opensuse ( ah non, la communauté choisit plutôt de ressortir des trucs sans rapport datant d'il y a 5 ans ce qui démotive les rares gens motivés ), soutenir nokia ( ah non trop tard ), filer du pognon à Canonical ( ah non, personne paye ) ou à Mandriva ( ah non, comme Nokia ), enfin bref, injecter de l'argent dans les boites qui contribuent autre que RH.
[^] # Re: Vraiment ?
Posté par Misc (site web personnel) . En réponse au journal Systemd: tuons les mythes. Évalué à 2.
D’après https://linuxfr.org/wiki/karma , tu peux aller jusqu'à -10 par défaut.
Donc, si tu es à -3, ça veut dire que tu as un karma entre -20 et -10, ce qui veut dire que tu as perdu non seulement les 20 points de base, mais aussi ce que tu as pu avoir au fil du temps. Et je pense qu'à ce rythme, tu va juste être à -10 par défaut d'ici 2 semaines au mieux.
[^] # Re: Vraiment ?
Posté par Misc (site web personnel) . En réponse au journal Systemd: tuons les mythes. Évalué à 3.
Bah, le .ini, c'est pas transcendant non plus.
Par exemple, il est pas formellement spécifié. Si j'ai :
Je suis pas sur que tout les parsers le lisent ( et me donne que toto a 2 valeurs, ou l'ordre ).
Genre python a 3 classe de parsers pour le .ini .
Il permet pas de faire de tableau, et de trucs à plusieurs niveaux imbriqués, n'a pas de schema ( même si ça pourrait se rajouter )
contrairement à du yaml, du xml, ou du json.
Ensuite, la syntaxe est comprise par tout le monde de façon quasiment intuitive, il y a des parsers pour tout
( même si ça peut coincer dans les détails ). C'est pas le format qui va résoudre tout les soucis du monde, mais je doute qu'il existe, et dans le cas de systemd, ça fait l'affaire. On s'en sert déjà pour le reste des projets freedesktop ( genre les menus, etc ), donc il est en plus "standard".
[^] # Re: Je ne suis toujours pas convaincu
Posté par Misc (site web personnel) . En réponse au journal Systemd: tuons les mythes. Évalué à 5.
Oui lxc marche avec les cgroups et systemd ( même en dehors du framework libvirt-sandbox http://fedoraproject.org/wiki/Features/Securecontainers )
Lennart explique sur un des nombreux blogs posts ce que systemd fait avec les cgroups :
http://0pointer.de/blog/projects/cgroups-vs-cgroups.html
Et il y a une documentation sur comment ne pas se marcher sur les pieds si tu veux utiliser les cgroups aussi :
http://www.freedesktop.org/wiki/Software/systemd/PaxControlGroups
Sinon, le blog que tu as pointé manque de perspective, par exemple, sur l'histoire du /usr merge, il ne pige pas que le role de / est passé à l'initrd, et que dont celui du /usr partagé est passé à tout /usr par le dit merge, ie, que c'est en faisant un système minimaliste à façon qu'on règle le problème du bloat de /.
Il dit que le passage à /run a été d'ignorer le FHS, mais justement, le changement vers /run fait parti du FHS 3.0 justement parce que les distributions se sont mis d'accord ( https://bugs.linuxfoundation.org/show_bug.cgi?id=758 ), et que le passage vers un sous dossier de /run est pour des questions de robustesses ( ie, pour une ressources non partagés sur un système qui lui est partagé , pour éviter les conflits de nom ).
Les divers changements sont pas la pour faire joli, en général, ça vise à tenter de corriger des vrais soucis. Personne ne se rajoute du boulot pour rien, y a déjà assez à faire sur les distributions classiques
[^] # Re: Et pour en remettre une couche
Posté par Misc (site web personnel) . En réponse au journal Systemd: tuons les mythes. Évalué à 3.
Le fait est que les gestionnaires de paquets pourraient faire le merge automatiquement. Sauf qu'ils font pas pour la plupart ( et je dit pour la plupart, car de ce que j'ai vu, au mieux, c'est un hook avec etc-update configuré à la mano par l'admin, mais je doute pas que quelqu'un a du faire un truc plus chiadé un jour ).
Par exemple, quelqu'un avait tenté d'intégrer ça dans mandriva :
http://blog.zerodogg.org/2005/09/29/common-configuration-parser-ccp/
Quand au fait d'être incompatible, bien sur. Si la solution miracle aux upgrades existait, je pense bien qu'on l'utiliserais depuis le temps ( exemple le ccp proposé plus haut ).
Maintenant, si tu prends l'exemple d'apache qui fourni un répertoire ou tu mets ta config en plus du fichier de base de la distro, le seul risque, c'est le jour ou apache change radicalement ( passage en 2.4 ), genre une fois tout les 4/5 ans. Pas une fois à chaque upgrade de version de la distro, ou une fois de temps en temps lors d'un souci de sécurité qui va modifier la config pour bloquer l'action TRACE ou changer je ne sais pas quel config par défaut incorrect.
[^] # Re: Fedora : Le lièvre et la tortue
Posté par Misc (site web personnel) . En réponse à la dépêche Sortie de Fedora 18 alias Spherical Cow. Évalué à 2.
Non, je pousse mes paquets directement dans la distro. Ou je reprends le paquet et le recompile. Je mélange pas les paquets binaires le moins du monde, c'est moche.
J'ai été admin du projet Mageia pendant 2 ans, secretaire de l'association, membre du board, donc je connais la taille de la communauté, je sais combien y a de compte dans le ldap ( que j'ai aidé à mettre en place, que j'ai tenu à jour ), donc je pense être parfaitement capable de déterminer si c'est petit ou pas. Donc le droit de le dire, je le prends avec ou sans la permission d'un inconnu.
Ensuite que launchpad soit difficile à installer est bien connu. En fait, qu'un système de build soit compliqué à déployer est aussi connu. Et que les systémes de build soit spécifique est aussi hélas bien connu, mais sans doute parce que personne ne bosse pour les rendre compatible ( à part suse ).
Impressionnant. J'ai bossé dans une boite spécialisé en sécurité informatique après avoir eu un DESS en sécurité, on peut donc continuer à jouer celui qui a la plus grosse, mais je pense que c'est pas productif.
Et avoir suivi une formation est une chose, mais ça dépend de la durée, du contenu. Et la sécurité, c'est vague, ça va du très théorique ( genre la séparation de domaine et l'analyse haut niveau comme le ferait un analyste ) au plus pratique ( genre, savoir coder de manière sécurisé, mettre en place un firewall, faire un audit ). J'ai fait des cours de compta à la fac, je vais pas dire à un comptable comment il doit faire son métier.
La liberté de faire un truc implique pas de ne pas être ridicule. Exemple, tu as la liberté de poster des trucs ridicules, tu t'en sert, ça veut pas dire que ça reste pas ridicule.
[^] # Re: Serveurs
Posté par Misc (site web personnel) . En réponse au journal Systemd: tuons les mythes. Évalué à 4.
En raid logiciel pur, ie sans /boot séparé hors des partoches en raid ?
Dans mon souvenir, le souci est que grub ne comprenant par le raid, il faut charger le kernel et l'initrd depuis une partoche /boot en dehors du raid, et faire la synchro plus ou moins à la main.
[^] # Re: Et pour en remettre une couche
Posté par Misc (site web personnel) . En réponse au journal Systemd: tuons les mythes. Évalué à 2.
Oui, et visiblement, il y a encore d'autres endroits dans le cookbook d'upstart ( que j'ai commencé à relire ) ou ils reprennent le même système de modifier des fichiers qui sont pas de la configuration.
http://upstart.ubuntu.com/cookbook/#list-all-jobs-with-no-stop-on-condition
Mais c'est un problème compliqué, car parfois, un fichier de configuration n'arrive pas à exprimer toutes les subtilités de ce que tu veux exprimé, et parfois, faut juste essayer de rentrer dans les clous.
dpkg-divert, c'est un moyen de hacker sans trop de dégât immédiat ton système, mais c'est pas tenable. Et tu peux pas rendre tout configurable non plus.