Une philosophie n'est pas une application de règles strictes…
Lennart a bien expliqué que le système d'init est un cas bien particulier où les différents "parties" (théorique) sont tellement interdépendantes que les rassembler simplifie le développement et apporte des fonctionnalités que tu ne pourrais pas avoir si tu gardais ces parties disjointes.
Et si tu essayes d'imposer à quelqu'un une philosophie, c'est que c'est plutôt un dogme.
D'ailleurs par certains côtés le noyau linux ne respecte pas la philosophie unix (noyau monolithique avec tous les drivers dans l'arbre des sources) et pourtant peu de personnes n'y ont jamais trouvé rien à redire car cela apporte d'autres avantages (perfs, plus facile à développer et à maintenir,…).
Comme quoi, comme presque tout le temps, c'est une affaire de peser le pour et le contre et il me semble qu'il y a plutôt un consensus pour dire que dans le cadre de systemd, il y a plus d'avantages.
Il n'y a que ceux qui regardent de loin (ou qui n'ont jamais eu à toucher le système d'init) que ça embête….
Je note vos humbles remarques pour le prochain nal
pas que pour le prochain journal, pour le reste de ta vie (prochaine présentation, dialogue avec un inconnu,…) j'espère… d'ailleurs la remarque n'étais pas destinée qu'à toi.
Bref, pour les incultes comme moi ITSM = « Gestion des services informatiques ».
C'est pas une question d'inculture. C'est juste qu'on utilise des acronymes seulement quand on s'adresse à une cible qu'on connait (on sait si il vont comprendre ou non). Car sinon un acronyme peut vouloir dire plusieurs chose dans des domaines différents…
Quand on sait pas à qui on s'adresse (typiquement quand on écrit un journal sur linuxfr), on n'utilise pas d'acronyme sans l'avoir au moins défini une fois. C'est une question de bon sens assez basique!
A part si on veux passer pour un mec qui est sait plus que les autres. A ce moment là, on peut continuer, mais le problème c'est qu'on se fait spotter assez rapidement et tout le travail d'enfumage tombe à l'eau…
systemd n’est pas et ne sera jamais portable parce qu’il expose des fonctionnalités spécifiques à Linux, donc prétendre que « systemd c’est bien parce que ça va enfin nous donner un init universel », je ris très fort
Ris très fort, mais si tu fais exprès de ne pas comprendre, tu peux aller rire tout seul dans ton coin.
Lorsqu'il est dit « systemd c’est bien parce que ça va enfin nous donner un init universel », il faut bien comprendre l'ellipse faite ici qui est : un init universel pour toutes les distribs linux!
Comme çà:
- un utilisateur/admin système peut intervenir sur n'importe qu'elle distrib, il n'aura pas à réapprendre un init différent ou à analyser un script d'init différent,
- le fichier de config d'un service sera le même sur TOUTES les distribs et pourra être contribué en upstream
En regardant la dernière image, on voit que la colonne taille clignote.
C'est pour mettre en valeur ici ou ça clignote vraiment dans la console? Parce que je pense que c'est une mauvaise idée. C'est vraiment agaçant! Quand on veut lire une valeur, elle disparait avant qu'on l'ai entièrement lue et il faut attendre que ça se raffiche… Et pareil pour la suivante. J'imagine pas la frustration….
J'ai été contacté pour faire le beta test de cette fonctionnalité et lors des échanges, j'ai cru comprendre que la fonctionnalité de download était un peu détourné de ce qu'il voulait en faire et qu'il l'on donc supprimé pour resortir quelque chose de mieux (avec une API pour permettre d'automatiser la sortie d'une release).
Effectivement, j'ai vu le lien qu'après avoir posté. Aucun paragraphe n'en parlait dans la dépêche (ce que je trouve bien dommage soit dit en passant)…
Ouais, en même temps, dire que c'est de la diffamation, c'est un peu exagéré.
Pour diffamer, il faut qu'il y est volonté de nuire alors que c'était juste un constat, genre tableau de comparaison…
Parce que des infos fausses ou pas claires ou incomplètes, y'en a plein le web et s'il y a diffamation à chaque fois, les avocats vont être encore plus riche que ce que je pensais…
Le principe c'est qu'il faut trouver une regex qui match un ensemble de valeurs tout en excluant un autre ensemble (et trouver la meilleur permet de gagner plus de points)
Pour ceux qui utilisent encore windows et qui veulent un système d'installation (facile) se rapprochant (vaguement) de ce que permet un dépot comme sous linux, il y a : http://chocolatey.org/
ça marche avec les principaux logiciels libres et d'autres propriétaires…
Les avantages:
- plus besoin d'aller de parcourir le web pour trouver le site de téléchargement
- installation silencieuse (quand possible) avec évitement des crapwares
- gère aussi la mise à jour (donc on peut enfin! mettre à jour ses logiciels sous windows)
Moi, je dis que c'est moins bien! Sur Chrome, on se retrouve très rapidement à ne voir que les favicons des onglets car on ne peut plus lire le texte dès qu'on a plusieurs onglets d'ouvert. Et ceci en partie à cause de cette forme qui gâche de la place. Mais, bon pour le côté marketing, c'est plus vendeur…
Donc je serais toi, je ne m'attendrais pas à des miracles. Si déjà dans le cadre de jboss (qui est poussé par redhat & tutti quanti) les devs sont pas foutu de faire un fichier d'init à peu près propre pour leur propre distrib, que dire d'un dev lambda qui devra gérer trois système d'init différent.
Il me semble que ta façon de juger un système d'init est un peu foireuse…
Si j'ai bien compris, faire un fichier .unit pour systemd est plus facile que faire un script d'init. Tu peux donc juste t'estimer heureux que les développeurs (qui ne sont pas forcement des packageurs et que ça fait donc chier de faire les fichiers d'init et qui n'ont peut-être pas les compétences) ne t'aient pas pondu un script d'init encore pire!
En plus, le gros avantage que j'y vois est que le fichier de conf de systemd étant upstream, il suffit que t'aillant aperçu que le fichier est bancal, tu pousses la correction au projet pour que toutes les distributions en profitent. Tu n'auras pas à corriger tous les scripts d'init foireux (et différents) que les différentes distributions auront du écrire! De même, il suffit qu'un mainteneur d'une distribution écrive un bon fichier d'init et le propose au projet pour que TOUTES les distributions en profitent.
Quant à ton avis sur la documentation, si tu t'en ai aperçu, c'est qu'il y a peut-être un besoin et la doc pourra être améliorée. Il me semble qu'améliorer une documentation est bien plus facile qu'améliorer l'architecture foireuse d'un logiciel, non?
Pour moi, un sel doit avoir les même caractéristiques qu'un mot de passe : contenir des chiffres, des lettres en minuscules et majuscules, contenir des caractères autres et d'être d'une certaine taille ( en plus tu n'es pas contraint par la mémoire d'un utilisateur alors tu peux te lâcher!! 100 caractères si besoin…). Comme ça tu invalides TOTALEMENT les rainbow tables et il ne reste que le brute force pour l'attaquant.
Si tu permet à tes utilisateurs de changer son login (par exemple le login est en fait leur adresse mail), tout ta stratégie (en plus d'être déjà mauvaise) tombe encore plus à l'eau…
Plus que d'accord! Quand tu as choisi un toolkit graphique, tu ne reviens (presque) jamais en arrière car le cout de migration est trop conséquent. Cela ne veut pourtant pas dire que s'il devaient refaire le choix aujourd'hui, ils referaient le même. Chaque toolkit peut avoir de nouveaux avantages et de nouveaux inconvénients et l'un être devenu mieux alors qu'avant il était moins bien…(suivant tes critères de choix, qui peuvent aussi varier en fonction du projet).
Car, en effet, les différents toolkit ont surement évolués et conviendraient peut-être maintenant à leur besoin alors qu'avant non. Mais surtout maintenir son propre toolkit graphique a un cout énorme!
Je crois que LibreOffice voudrait se débarrasser de son vieux toolkit historique mais que l'effort est très (trop?) important.
Dans ces 2 outils, les branches et les tags sont des répertoires. Brancher est aussi simple que de copier un répertoire.
Dans ce genre de contrôleur de code source, merger devient un enfer!
Il faut bien comprendre que quelque soit le contrôleur de source utilisé, brancher n'est JAMAIS un problème. C'est merger (ou reporter des commits) qui devient un problème.
Et ceux qui ont cette stratégie de "early branching" où on recopie l'ensemble des fichiers dans un autre "répertoire" ont plus de difficultés à retrouver les modifications et à faciliter la gestion des branche (après branchement donc).
Euh… je croyais avoir été clair pourtant. Je disais que c'était pas possible car tu peux pas vraiment travailler avec (puisque tu ne peux pas faire de 'push') et c'est l'objet du débat. Avoir une vrai solution pour pouvoir travailler, non?!?
Sinon, le clone --depth fait exactement ce que je décris et on se retrouve avec des sha1 différents, donc un dépot local qui sert à pas grand chose à part la consultation (et la collaboration à base de patchs).
Pour travailler sur des sous-ensemble les DVCS ne proposent que 3 solutions.
1 N'extraire que les derniers niveaux de commits (1 niveau correspond alors à une simple snapshot de SVN)
2 Ne cloner qu'une branche
3 Ne checkouter qu'un sous-répertoire et travailler dessus.
Le point 1 n'est pas possible avec Git car on obtient un sha1 différent car le sha1 est dépendant du commit parent (qui ici n'est pas présent). Apparement, c'est juste pour la consultation. Contrairement, apparement, à Mercurial qui permet de le faire?
Le point 3 ne me parait pas possible également.
Ceci présente 2 contraintes. L'importation est trèèèèès longue et il faut que le dépôt initial soit propre en terme d'architecture (Par exemple, si 2 projets séparés dans 2 branches distinctes ont par la suite été gérés dans une même branche, ca ne marche pas).
…ainsi qu'une petite blague:
Facebook a choisi Mercurial car c'est écrit en Python et donc plus facilement extensible et au moins un des patch conséquent fourni a consisté a réécrire en C la fonction de détection du statut des fichiers. Encore quelques patch et Mercurial sera entièrement en C…comme git ;)
[^] # Re: je suis le seul ou quoi ?
Posté par cosmocat . En réponse au journal Debian rejoint les utilisateurs de Systemd. Évalué à 10.
Une philosophie n'est pas une application de règles strictes…
Lennart a bien expliqué que le système d'init est un cas bien particulier où les différents "parties" (théorique) sont tellement interdépendantes que les rassembler simplifie le développement et apporte des fonctionnalités que tu ne pourrais pas avoir si tu gardais ces parties disjointes.
On espère juste qu'il soit dans le "Ri" : http://www.qualitystreet.fr/2008/06/17/shu-ha-ri/
Et si tu essayes d'imposer à quelqu'un une philosophie, c'est que c'est plutôt un dogme.
D'ailleurs par certains côtés le noyau linux ne respecte pas la philosophie unix (noyau monolithique avec tous les drivers dans l'arbre des sources) et pourtant peu de personnes n'y ont jamais trouvé rien à redire car cela apporte d'autres avantages (perfs, plus facile à développer et à maintenir,…).
Comme quoi, comme presque tout le temps, c'est une affaire de peser le pour et le contre et il me semble qu'il y a plutôt un consensus pour dire que dans le cadre de systemd, il y a plus d'avantages.
Il n'y a que ceux qui regardent de loin (ou qui n'ont jamais eu à toucher le système d'init) que ça embête….
[^] # Re: 50 nuances de Grey ?
Posté par cosmocat . En réponse au journal Itop... l'ITSM opensource. Évalué à 3.
ce n'était pas mon objectif. Désolés!
pas que pour le prochain journal, pour le reste de ta vie (prochaine présentation, dialogue avec un inconnu,…) j'espère… d'ailleurs la remarque n'étais pas destinée qu'à toi.
[^] # Re: 50 nuances de Grey ?
Posté par cosmocat . En réponse au journal Itop... l'ITSM opensource. Évalué à 8.
C'est pas une question d'inculture. C'est juste qu'on utilise des acronymes seulement quand on s'adresse à une cible qu'on connait (on sait si il vont comprendre ou non). Car sinon un acronyme peut vouloir dire plusieurs chose dans des domaines différents…
Quand on sait pas à qui on s'adresse (typiquement quand on écrit un journal sur linuxfr), on n'utilise pas d'acronyme sans l'avoir au moins défini une fois. C'est une question de bon sens assez basique!
A part si on veux passer pour un mec qui est sait plus que les autres. A ce moment là, on peut continuer, mais le problème c'est qu'on se fait spotter assez rapidement et tout le travail d'enfumage tombe à l'eau…
[^] # Re: dépendance à un système d'init
Posté par cosmocat . En réponse au journal Debian à l'heure du choix. Évalué à 9.
Ris très fort, mais si tu fais exprès de ne pas comprendre, tu peux aller rire tout seul dans ton coin.
Lorsqu'il est dit « systemd c’est bien parce que ça va enfin nous donner un init universel », il faut bien comprendre l'ellipse faite ici qui est : un init universel pour toutes les distribs linux!
Comme çà:
- un utilisateur/admin système peut intervenir sur n'importe qu'elle distrib, il n'aura pas à réapprendre un init différent ou à analyser un script d'init différent,
- le fichier de config d'un service sera le même sur TOUTES les distribs et pourra être contribué en upstream
[^] # Re: Pari
Posté par cosmocat . En réponse au journal Debian à l'heure du choix. Évalué à 4.
Vu comment c'est parti, ça va plutôt finir en FD tout çà!
# Clignotement
Posté par cosmocat . En réponse au journal apti 0.5 : frontend à aptitude. Évalué à 10.
En regardant la dernière image, on voit que la colonne taille clignote.
C'est pour mettre en valeur ici ou ça clignote vraiment dans la console? Parce que je pense que c'est une mauvaise idée. C'est vraiment agaçant! Quand on veut lire une valeur, elle disparait avant qu'on l'ai entièrement lue et il faut attendre que ça se raffiche… Et pareil pour la suivante. J'imagine pas la frustration….
[^] # Re: Github, une référence ?
Posté par cosmocat . En réponse au journal La guerre des forges. Évalué à 4.
J'ai été contacté pour faire le beta test de cette fonctionnalité et lors des échanges, j'ai cru comprendre que la fonctionnalité de download était un peu détourné de ce qu'il voulait en faire et qu'il l'on donc supprimé pour resortir quelque chose de mieux (avec une API pour permettre d'automatiser la sortie d'une release).
[^] # Re: Github, une référence ?
Posté par cosmocat . En réponse au journal La guerre des forges. Évalué à 2.
Si, tu peux créer des release où tu peux mettre la version binaire de ton programme et où tu peux mettre un changelog :
https://github.com/blog/1547-release-your-software
[^] # Re: Plus dur
Posté par cosmocat . En réponse à la dépêche Regexcrossword : un subtil mélange de sudoku et de mots croisés, à la sauce Regex. Évalué à 3.
Effectivement, j'ai vu le lien qu'après avoir posté. Aucun paragraphe n'en parlait dans la dépêche (ce que je trouve bien dommage soit dit en passant)…
[^] # Re: Précision
Posté par cosmocat . En réponse au journal Le développeur de Poche menacé par la société Read It Later. Évalué à 9.
Ouais, en même temps, dire que c'est de la diffamation, c'est un peu exagéré.
Pour diffamer, il faut qu'il y est volonté de nuire alors que c'était juste un constat, genre tableau de comparaison…
Parce que des infos fausses ou pas claires ou incomplètes, y'en a plein le web et s'il y a diffamation à chaque fois, les avocats vont être encore plus riche que ce que je pensais…
[^] # Re: Plus dur
Posté par cosmocat . En réponse à la dépêche Regexcrossword : un subtil mélange de sudoku et de mots croisés, à la sauce Regex. Évalué à 7.
A oui et j'ai oublié, je me suis exercé au RegEx Golf : http://regex.alf.nu/
issu d'un xkcd : http://xkcd.com/1313/
Le principe c'est qu'il faut trouver une regex qui match un ensemble de valeurs tout en excluant un autre ensemble (et trouver la meilleur permet de gagner plus de points)
# Plus dur
Posté par cosmocat . En réponse à la dépêche Regexcrossword : un subtil mélange de sudoku et de mots croisés, à la sauce Regex. Évalué à 6.
sinon, en plus dur, il y a : http://nedbatchelder.com/blog/201302/a_regular_crossword.html
[^] # Re: Codingteam
Posté par cosmocat . En réponse au journal La guerre des forges. Évalué à 4.
Je connaissais pas donc je suis allé voir. Le mainteneur le dit lui même, il est tout seul donc ça joue largement pas en la faveur de cette forge :(
En plus y'a pas encore le support de git (c'est dans la version en développement). Le support de Mercurial est assez récent également il me semble…
Je sais pas si il peut lutter face aux autres forges et ça donne pas trop envie d'y mettre son projet par soucis de pérennité…
[^] # Re: sourceforge.net = adware et crapware
Posté par cosmocat . En réponse au journal La guerre des forges. Évalué à 4.
Pour ceux qui utilisent encore windows et qui veulent un système d'installation (facile) se rapprochant (vaguement) de ce que permet un dépot comme sous linux, il y a :
http://chocolatey.org/
ça marche avec les principaux logiciels libres et d'autres propriétaires…
Les avantages:
- plus besoin d'aller de parcourir le web pour trouver le site de téléchargement
- installation silencieuse (quand possible) avec évitement des crapwares
- gère aussi la mise à jour (donc on peut enfin! mettre à jour ses logiciels sous windows)
[^] # Re: on dirait chrome
Posté par cosmocat . En réponse au journal Firefox en GTK3. Évalué à 7.
Moi, je dis que c'est moins bien! Sur Chrome, on se retrouve très rapidement à ne voir que les favicons des onglets car on ne peut plus lire le texte dès qu'on a plusieurs onglets d'ouvert. Et ceci en partie à cause de cette forme qui gâche de la place. Mais, bon pour le côté marketing, c'est plus vendeur…
[^] # Re: OpenRC
Posté par cosmocat . En réponse au journal Des nouvelles de Debian et de systemd. Évalué à 8.
Il me semble que ta façon de juger un système d'init est un peu foireuse…
Si j'ai bien compris, faire un fichier .unit pour systemd est plus facile que faire un script d'init. Tu peux donc juste t'estimer heureux que les développeurs (qui ne sont pas forcement des packageurs et que ça fait donc chier de faire les fichiers d'init et qui n'ont peut-être pas les compétences) ne t'aient pas pondu un script d'init encore pire!
En plus, le gros avantage que j'y vois est que le fichier de conf de systemd étant upstream, il suffit que t'aillant aperçu que le fichier est bancal, tu pousses la correction au projet pour que toutes les distributions en profitent. Tu n'auras pas à corriger tous les scripts d'init foireux (et différents) que les différentes distributions auront du écrire! De même, il suffit qu'un mainteneur d'une distribution écrive un bon fichier d'init et le propose au projet pour que TOUTES les distributions en profitent.
Quant à ton avis sur la documentation, si tu t'en ai aperçu, c'est qu'il y a peut-être un besoin et la doc pourra être améliorée. Il me semble qu'améliorer une documentation est bien plus facile qu'améliorer l'architecture foireuse d'un logiciel, non?
[^] # Re: niveau -0.5
Posté par cosmocat . En réponse au journal L'art de stocker des mots de passe. Évalué à 4.
Pour moi, un sel doit avoir les même caractéristiques qu'un mot de passe : contenir des chiffres, des lettres en minuscules et majuscules, contenir des caractères autres et d'être d'une certaine taille ( en plus tu n'es pas contraint par la mémoire d'un utilisateur alors tu peux te lâcher!! 100 caractères si besoin…). Comme ça tu invalides TOTALEMENT les rainbow tables et il ne reste que le brute force pour l'attaquant.
[^] # Re: niveau -0.5
Posté par cosmocat . En réponse au journal L'art de stocker des mots de passe. Évalué à 6.
Si tu permet à tes utilisateurs de changer son login (par exemple le login est en fait leur adresse mail), tout ta stratégie (en plus d'être déjà mauvaise) tombe encore plus à l'eau…
[^] # Re: Uchronie
Posté par cosmocat . En réponse au journal Gtk to Qt - A strange journey. Évalué à 3.
Plus que d'accord! Quand tu as choisi un toolkit graphique, tu ne reviens (presque) jamais en arrière car le cout de migration est trop conséquent. Cela ne veut pourtant pas dire que s'il devaient refaire le choix aujourd'hui, ils referaient le même. Chaque toolkit peut avoir de nouveaux avantages et de nouveaux inconvénients et l'un être devenu mieux alors qu'avant il était moins bien…(suivant tes critères de choix, qui peuvent aussi varier en fonction du projet).
Car, en effet, les différents toolkit ont surement évolués et conviendraient peut-être maintenant à leur besoin alors qu'avant non. Mais surtout maintenir son propre toolkit graphique a un cout énorme!
Je crois que LibreOffice voudrait se débarrasser de son vieux toolkit historique mais que l'effort est très (trop?) important.
[^] # Re: Mensongeries
Posté par cosmocat . En réponse au journal "Scaling Mercurial at Facebook". Évalué à 2.
Dans ce genre de contrôleur de code source, merger devient un enfer!
Il faut bien comprendre que quelque soit le contrôleur de source utilisé, brancher n'est JAMAIS un problème. C'est merger (ou reporter des commits) qui devient un problème.
Et ceux qui ont cette stratégie de "early branching" où on recopie l'ensemble des fichiers dans un autre "répertoire" ont plus de difficultés à retrouver les modifications et à faciliter la gestion des branche (après branchement donc).
[^] # Re: KDE : Quel distrib ?
Posté par cosmocat . En réponse à la dépêche KDE SC 4.12, 4.11.5 et Frameworks 5. Évalué à 1.
Je sais pas si ça peut t'aider : Best 2013 KDE Ditribution
[^] # Re: Mensongeries
Posté par cosmocat . En réponse au journal "Scaling Mercurial at Facebook". Évalué à 2.
Euh… je croyais avoir été clair pourtant. Je disais que c'était pas possible car tu peux pas vraiment travailler avec (puisque tu ne peux pas faire de 'push') et c'est l'objet du débat. Avoir une vrai solution pour pouvoir travailler, non?!?
Sinon, le clone --depth fait exactement ce que je décris et on se retrouve avec des sha1 différents, donc un dépot local qui sert à pas grand chose à part la consultation (et la collaboration à base de patchs).
[^] # Re: Mensongeries
Posté par cosmocat . En réponse au journal "Scaling Mercurial at Facebook". Évalué à 1.
Le point 1 n'est pas possible avec Git car on obtient un sha1 différent car le sha1 est dépendant du commit parent (qui ici n'est pas présent). Apparement, c'est juste pour la consultation. Contrairement, apparement, à Mercurial qui permet de le faire?
Le point 3 ne me parait pas possible également.
Apparement, reposurgeon peut faire çà.
[^] # Re: Mercurial vu par Facebook
Posté par cosmocat . En réponse au journal "Scaling Mercurial at Facebook". Évalué à 8.
L'article sur InfoQ sur le sujet apporte un peu plus d'infos :
http://www.infoq.com/news/2014/01/facebook-scaling-hg
…ainsi qu'une petite blague:
Facebook a choisi Mercurial car c'est écrit en Python et donc plus facilement extensible et au moins un des patch conséquent fourni a consisté a réécrire en C la fonction de détection du statut des fichiers. Encore quelques patch et Mercurial sera entièrement en C…comme git ;)
[^] # Re: git ou mercurial, le choix n'est pas important...
Posté par cosmocat . En réponse au journal "Scaling Mercurial at Facebook". Évalué à 2.
Tu as raison, il faut faire des cpold des répertoires .git et .hg…