Misc a écrit 6314 commentaires

Facilement, j'ai pas tenté, mais graphiquement, il semble que oui, j'ai une option "pont" quand je fait "ajouter une connexion"

On peut supposer que Google ayant décidé de s'attaquer frontalement à Amazon ( le cloud Google, google play, etc ), les robots sont juste une manière d'éviter les soucis qui plombent le dit libraire dématérialisé US en Allemagne ?

( oui, c'est moins sexy de se dire ça ). Voir même pour améliorer la production de Motorola, ou de ses potentielles voitures sans chauffeurs. Voir, chose folle, de ses datacenters géants ( car un robot, ça va pas aller poser des fibres pour la NSA en douce par la magie de la corruption )

Le système est libre, sauf les parties non libres, tout comme la chine est démocratique, sauf la partie ou c'est une dictature ?

Il y a plein de bonnes distributions basées sur Debian

Mais ça ne te gène pas que tant de projet ne cherche pas à contribuer à Debian plutôt ?

Ou est ce que le travail d'intégrer plus de personnes est inférieur à celle d'intégrer 2 noyau totalement différent ?

Alors que maintenant, y a non-free directement proposé par le projet parce que le consensus de la communauté est que le logiciel libre n'est pas suffisant, donc le souci de QT n'arriveras plus si il devait se reproduire. je suppose que Debian, comme pour d'autres softs proprios, va proposer son infrastructure ( bugs, miroirs ) pour que le runtime de Valve soit disponible pour tous pour encore mieux défendre le libre via Steam et les DRMs.

( attention, un troll pas subtile se cache dans ce commentaire, je me permet au vue du thread suggérant de tout migrer sur Debian )

pfff, difficile de troller, ton journal est trop neutre et
factuel…

tu sais pas t'y prendre, si tu trouves pas l'info, faut la sortir des liens. Moi, j'identifie 3 axes de troll :

• visiblement, l'équipe de steam os ne choisit pas Ubuntu. est ce qu'il s'agit d'éviter de dépendre des choix de Canonical ( ie, indépendance vis à vis d'un concurent ), ou justement des choix annoncés ( ie, upstart, mir, unity ), voir de la volatilité de l'éditeur ?

• enchainons sur le fait que prendre Debian comme base, ça n'utilise pas systemd, mais un bon vieux sysvinit. est ce que ça veut dire que Valve va investir pour maintenance de la plateforme et de ses trucs vieillissants, est ce que Valve va maintenir xorg, etc, etc ?

• partir sur la conclusion "Néanmoins, je pense que par effet de bord, cette guerre économique nous est profitable". La, on peut commencer par dire "pourquoi ?", par exemple, est ce que android a été profitable à Linux, comment, etc, etc; j'ai pas vraiment vu des changements radicaux en terme d'userspace, et je ne vois rien dans mes cas d'usage.

Donc je suis pas sur qu'une appliance de steam change vraiment beaucoup la donne, surtout si le but est de s'appuyer sur les drivers proprios ( drivers proprios qui sont aussi un frein vers certains nettoyages et la maintenance ).

Donc voila, si avec ça, on arrive pas à trouver de quoi débattre, c'est qu'il y a un souci.

Le pays basque, la savoie et l'alsace.

et tu as peur qu'on tombe sur un pépin ?

Je n'ai pas regardé en profondeur mais j'ai l'impression qu'il y
a beaucoup de services qui utilisent les .service de systemd et
pas le mode de compatibilité.

Après un rapide coup de yum, je trouve 2 paquets avec un script d'init, iprutils et yum ( et le paquet initscripts, avec network, netconsole ). Ça fait 6 scripts d'init au total.

Comme dit plus haut :

ftp://ftp.redhat.com/redhat/rhel/beta/7/

( certes en terme moins clair )

Moi, je parlerais pas de systemd, qui n'est pas beaucoup mentionné dans les notes de versions, est ce que ça veut dire qu'il est la dans un mode de compatiblité, quel version est prise, tant de suspens !

je dirais pas un mot sur kde, y a rien à dire, ou peut être que si, enfin je sais pas.

Et parler de détails comme "est ce que ifconfig est la" ou "mariadb, mysql, vers lequel notre coeur balance…"

D'après mon client ftp et d'après le site de Red hat, RHEL 7 Beta est sorti. Donc si les gens veulent voir le choix par défaut, il y a une iso.

si tu lis le lien que je donnes, tu va voir que ça permet plus que de dire si tu veux activer ou pas le job :

"Change a Jobs Start/Stop Conditions"

Ou

"Adding Stanzas that are Not Present in the .conf File"

Donc je persiste qu'il est possible de rajouter des choses de façon semblable. C'est pas aussi bien que systemd, certes, mais tu peux totalement remplacer le contenu du fichier job, comme dit toujours dans le lien :

"Note: We assume here that the corresponding /etc/init/my-daemon.conf file does not already specify a pre-start since if it did, our override file would replace it."

On m'a pointé sur irc :
https://bugzilla.mozilla.org/show_bug.cgi?id=693450#c24
( et http://googleonlinesecurity.blogspot.it/2013/12/further-improving-digital-certificate.html )

Je laisse les gens choisirent entre :
- l'ANSSI est pas capable de gérer correctement la délégation de ses certificats

ou
- l'ANSSI cherche à abuser de ses certificats.

Je miserais plus sur le premier, vu les histoires qu'on me raconte sur le dit organisme, mais bon…

On noteras que upstart supporte aussi un mécanisme semblable sur les versions récentes :

http://upstart.ubuntu.com/cookbook/#override-files

Je pense que pour rhel6, l'idée était d'intégrer upstart parce que Fedora a pris upstart, et si l'intégration avait été poussé plus loin, ça aurait été bien mieux.

Mais même Canonical n'avait pas vraiment poussé upstart et apparmor à l'époque ( vers la 10.04 ), ce qui m'a un peu déçu. Je comprends qu'ils ont pas le staff requis pour ça, mais ça a rajouté une raison de plus pour moi de prendre ce qu'ils disent avec des pincettes. Dieu merci, maintenant, ça semble se faire, même si il reste encore pas mal de boulot.

Non mais tu as raison sur le fait que les gens sortent l'argument de la méritocratie bien souvent pour dire que tout est parfait alors que non. De la même façon que la démocratie n'est pas sans faille ( vu que ça dépend grandement de qui vote, de la façon dont les arguments sont présentés, etc ), mais en effet, la méritocratie est souvent idéalisé alors que c'est pas le cas, y a plein de souci malgré le fait qu'on croit que tout le monde est égal devant la contribution, alors que la seule égalité qu'on a, c'est celle des contraintes du code ( ie, tout le monde ou presque a les mêmes opportunités donnés par une license libre, sauf cas spéciaux ).

Il reste à coté les contraintes de temps, de compétences, de trouver des gens proches de chez toi, proche d'un point de vue temporel, proche pour t'aider, etc, etc. Contraintes qu'on peut pas nier, mais contraintes qu'on peut pas résoudre facilement et complétement juste par la volonté et 3/4 lignes en anglais.

D'une part, c'est considérer que dans les distribs, il y a
toujours unanimité des choix, ce qui est faux

Tu veux dire quoi par "unanimité dans les distros". Unanimité, ça implique d'avoir un ensemble fini de gens avec des critères, et la, je pense que "une distro", c'est flou. Est ce que la distribution, c'est "tout les gens qui ont le droit de commit", tout les gens qui sont sur une ml, dans un ldap, qui utilisent à un moment T, etc. En général, le but n'est pas d'avoir l'unanimité, c'est bien plus pragmatique que ça, le but est de réduire la maintenance du projet tout en permettant de faire un certains nombres de choses avec le produit.

Et bien que ça reste subjectif comme définition, il faut pas oublier que c'est ça. Les gens peuvent rajouter tout ce qu'ils veulent par dessus, à la fin, faut produire un truc. Si ton but n'est pas de sortir un produit, alors c'est pas une distribution que tu fait. Y a rien de mal à ça, c'est juste pas la même chose.

D'autre part, cette histoire permanente de contribution ne
devient rien d'autre qu'un prétexte pour envoyer les gens se
faire foutre.

J'aurais tendance à dire que ça peut être pris comme ça, mais en pratique, tu verra que même sans parler de contribution, si quelqu'un dit "faut faire ça" et personne ne le fait, le travail ne se fait pas tout seul et la personne est frustré. D'un point de vue de la dynamique de groupe qui en résulte, vu qu'on veut que le travail se fasse, on récompense ceux qui font le travail par rapport à ceux qui font pas.

Que ça soit aliénant pour les gens qui veulent/peuvent pas faire le travail est hélas secondaire, car vu qu'il n'y aucun impact sur la sortie ou non du produit alors il y a aucune boucle de feedback qui fait que dire merde a un effet suffisamment négatif. On pourrait trés bien en effet avoir des gens qui sont la uniquement pour faire le taf de ceux qui peuvent/veulent pas le faire, mais ça ne tient pas la charge. Pour une personne qui va être dans ce groupe, tu va avoir 10, 20 voir plus dans le groupe des gens qui peuvent/veulent pas. Donc à un moment, faut voir les ressources que tu as, et dire non. ( et être gentil en disant 'non' est juste un palliatif pour réduire la frustration mais ça fait pas disparaitre la cause de la frustration, à savoir le fait de pas le faire )

Et pour finir la méritocratie est un mythe qui a fait long
feu, on sait que ce sont des fadaises pour enfumer les gens en
bas de l'échelle

C'est bien joli, mais on parle pas d'un vaste système politique qui décide de ta vie de tout les jours, mais de gens qui collabore pour faire un produit, soit sur leur temps libre, soit sur leur temps de travail.

Donc même si la méritocratie dans le milieu en général est une fumisterie et ne devrait pas être employé, ça change rien au principe de base que soit les gens bossent, soit les gens bossent pas, et ceux qui bossent pas n'ont pas d'influence parce que ne rien faire ne produit rien.

C'est pas parce qu'on dit que c'est une méritocratie qu'il y a une hiérarchie supposé, c'est parce qu'il y a collaboration et dépendance entre les membres du groupe ( ie, les contributeurs du projet comme les non contributeurs, avec toutes les nuances possibles ). C'est parce que l'utilisateur dépend de quelqu'un d'autre ( et dépend de par son propre choix dans pas mal de cas ) qu'il y a une relation de pouvoir de l'un vers l'autre.

Dans un échange marchand, je pense que l'équilibre est plus facile à atteindre. IE le vendeur et l'acheteur font un échange. Dans le libre, en renonçant à avoir un truc en retour via un don ( car bosser et filer son code sans que ça coute à la personne qui recoit, c'est ça ), la personne qui fait le don gagne en échange la liberté de pas écouter la personne qui reçoit le dit don ( autrement dit "le droit de dire merde" ).

Donc oui, si tu veux avoir plus de pouvoir, il faut contribuer. Sinon quoi que tu fasses, ça sera inégal sauf coercition externe tel qu'on retrouve dans un groupe humain par le biais de la police, de l'ancien du village, de la loi, du shérif, etc. Et à ce moment la, tu as juste passé le pouvoir ailleurs donc tu n'as rien réglé au problème d'égalité de base.

En conclusion, ouais, les gens qui font rien par choix ou par contrainte l'auront dans l'os, surtout parce que je pense personne ne doit rien à personne. Personne ne va dire qu'il y a pas de droit inhérent à avoir ses bugs lus et corrigés pour le moment, contrairement au fait d'avoir un toit, etc, et tant de choses dans les droits de l'homme ( et pourtant pas mis en pratique partout ).

En même temps, si ceux qui ont l'usage sont pas ceux qui contribuent, tant pis pour eux. On se gargarise de méritocratie de partout ( bien que ça ne soit pas le cas ), mais dans ce cas précis, c'est les gens qui font qui décident.

L'intérêt du shell, à mon avis, c'est que c'est le langage par
défaut d'administration de la machine, et celui qu'on trouve par
défaut en console. On y est confronté à un moment ou un autre,
et normalement, on apprend à le connaître et à le maîtriser.

Permet moi de douter la capacité des gens à maitriser le shell.

Il suffit de voir le simple fait que les gens confondent shell et bash, il suffit de voir le nombre de gens qui utilisent pas trap dans leur code, le nombre de gens pour qui la syntaxe ${i#plop#coin} va être trop ésotérique, le nombre de gens qui savent pas qu'il faut éviter d'utiliser /tmp et que le shell est le seul language ou tu peux pas garantir de faire ça de façon parfaitement propre sans race condition.

Dire que le shell, c'est bien parce que tout le monde comprends, c'est comme dire que php est bien car tout le monde sait en faire.

Il reste plus qu'à porter sur le hurd et minix :)

Ceci dit, j'ai regardé un peu le code de upstart en vue de voir si il serait dur de faire une couche de compatibilité pour l'activation des sockets ( entre systemd et upstart vu que ça semble presque compatible, ça passe un FD via une variable d'env ), et j'ai un peu sourcillé de voir la macro NIH_MUST, une macro qui tente une fonction jusqu'à ce que ça réussisse ( cf http://ifdeflinux.blogspot.fr/2012/05/quick-libnih-tutorial.html ).

Je sais pas si c'est vachement bien foutu, ou juste vachement bourrin (ou les deux).

helas, les budgets pour pardus ont disparus, si je me souviens bien après avoir discuté sur irc avec un professeur d'istanbul, membre du projet.

j'ai lu le truc vu que j'ai répondu.

Mais pourquoi utiliser une variable d'environnement et pas autre chose comme maniére de transmettre l'information, et entre quoi et quoi. Pourquoi au boot et pas à chaque fois, pour détecter quoi, etc, etc.

Donc récapitulons, l'incompatibilité entre haproxy et systemd, c'est le fait de devoir rajouter 1 ligne de bash dans l'unité systemd, chose qui a bien du prendre 5 minutes, vu que la ligne vient du script d'init haproxy avec une rapide adaptation pour l'accès à $MAINPID. Si une ligne de bash est un souci, j'ose me demander ce que les 108 autres lignes du script d'init sont…

J'imagine dire que "attention, des logiciels comme haproxy et plein d'autres que je ne cite pas peuvent requérir un oneliner bash pour fonctionner", ça casse vachement moins la baraque.

Je pense qu'il serait plus efficace de dire ce que tu veux obtenir comme résultat plutôt que comment tu veux implémenter ce que tu penses être une solution.