C'est con, parce qu'il parait que les nouveaux propriétaires de skype ont déjà contribué au noyau :)
Ceci dit, j'imagine que pour eux, d'un point de vue technique, c'est plus simple ( comme pour google et chrome, pour mozilla et firefox ( sqlite ), comme pour nodejs et la libevent ).
prendre du code, et le modifier dans ton coin, ou juste faire le code dans ton coin sans intégration avec d'autres projets, ç'est plus facile que de devoir expliquer à d'autres ton design et qu'on te dise "non" ( je dit pas que c'est mieux, ni la chose à faire, je précise )
Sauf si les gens ont mis des ppas de partout, ou si les gens utilisent des applis un chouia moins classiques ( ou si, comme ma copine, utilise une version oem d'Ubuntu payé par Dell sur une archi qui a été abandonné par Canonical )
En fait, je pense que les débutants pensent qu'il y a un truc magique dans apt ou dans debian ( ou ailleurs ), mais la seule chose qui aide, c'est de tester les upgrades, et je pense à ce niveau que toute les distributions sont au même point, à savoir :
- des tests automatisés d'upgrade ( via autoqa ou openqa, ou les dizaines de scripts debian comme piupart )
- des tests manuels fait par un nombre toujours insuffisant de gens ( par définition )
ce qui aboutit globalement à toujours les mêmes histoires, à savoir "$distr_qu_on_utilise marche parfaitement, et tout le reste est tout pourri et c'est tellement une vérité vrai que j'ai pas besoin de donner plus de détails, ou de rapporter de bugs". J'ai eu l'occasion d'avoir des gens se plaindre de tout ce qui existe globalement, passé un certain niveau de popularité. J'ai eu le temps de constater des problèmes sur les divers distros, upgrade debian, ubuntu, fedora, mandriva, mageia. De rapporter des bugs, voir de les corriger.
Mais au final, ça change rien au fait que faire un upgrade d'un système complet sans erreur, c'est juste un problème difficile. Il y a des gens qui font des thèses sur le sujet depuis des années ( projet edos, mancoosi et j'ai oublié la suite ), et qui à mon avis vont en faire encore un paquet.
Ça pourrait être facile si on avait moins de paquets, moins de choix, plus de temps. En fait, avoir le cycle de release de debian avec le choix de paquets de LFS. Mais bon, ça , personne ne le veut, curieusement. Et curieusement, dire "non, on rajoute pas plus de paquet", au mieux, ça te fait passer pour un pisse vinaigre et les gens retentent après 3 mois, au pire, ça te fait passer pour un faciste.
AU contraire, ça montre bien ce que je dit à savoir que garder les trucs pour eux nuit un peu à Google. Dans le cas de MapReduce, ils ont justement communiqué autour, et ça leur a bénéficié via la reprise et l'amélioration de l'idée. Mais le retour aurait pu être plus grand en ayant directement fourni le code pour tous, ils auraient plus facilement pu embaucher du monde ou des gens déjà au courant d'une partie des spécificités.
Mise à part le nombre de gens ( qui n'est pas non plus trivial, je précise ), Google a les mêmes problématiques que d'autres boites classiques du secteur, faire rentrer les gens qu'il faut et ne pas faire rentrer les gens qu'il ne faut pas. Quand tu cherches à embaucher un dev sur un projet particulier, si il est libre, il suffit de piocher dans la communauté ( ce qui entraine d'autres soucis, mais on va mettre ça aussi de coté ). Quand le projet est pas libre, il y a déja plus d'incertitude.
Ensuite, je sais aussi que Google a des problématiques autres, avec un impact sur le télétravail, sur la taille des locaux et la répartition des gens, etc, et je suppose que le choix de garder tout en interne est mesuré.
Vu que ça parle de s'appuyer sur les libs et softs internes de Google, je pense comme toi.
A terme, je pense que ça doit nuire à Google, car le temps d'adaptation des gens est plus grands qu'en utilisant des technos plus standards, et ça coute à maintenir. Et c'est à mon sens pas super attirant d'aller bosser sur des trucs que tu pourras jamais reprendre ailleurs ( mais peut être que c'est un effet de bord positif pour Google, vu que ça incite les gens à rester chez eux ).
Ça, c'est le support grand publique. Dans le domaine pro j'ai toujours eu des gens polis quand j'ai appelé, et même si y a eu des couacs du style le support technique qui renvoie vers le support commercial, et vice versa, je pense qu'il y a plus des problèmes liés à la taille de la boite et à l'ambiance ( ie, si les gens se suicident, c'est pas non plus par hasard ) que parce que les employés sont mauvais.
Le problème est mal pris, il y a des gens chez google qui font des trucs ouverts parce qu'il pense que c'est mieux, et d'autres qui pensent que ça n'apporte rien.
Y a 32 000 employés, que tout le monde soit sur la même longueur d'onde me ferait un chouia peur.
Moi, de ce que j'ai vu, c'est :
1) addictif quand tu commences à te prendre aux jeux des points
2) foireux sans une communauté assez grande pour gérer ça
Si tu l'utilises tout seul, je suis pas sur que ça soit mieux qu'un wiki. En fait, faut voir ça comme un mix entre un forum et un wiki, mais pour plusieurs.
Plus tu restes et tu fais des choses positives, plus tu as de points, plus tu deviens de facto un modérateur du systèmes.
Je rajouterais même : http://communitymgt.wikia.com/wiki/Bikeshedding ( avec une spécial dédicace pour les discussions en cours sur la fondation Mandriva, ou ça parle plus du nom de la structure que de sa gouvernance )
En général, le problème, c'est pas tant de la structure qu'un manque de connaissances des gens. Par exemple, chacun a son forum favori, et tout le monde va pousser pour l'avoir, sans être capable d'exprimer le besoin. J'ai constaté qu'en fait, c'est souvent du bikesheding. Surtout quand tu as des gens un peu technique, ce qui dans le libre veux dire "beaucoup de monde". ( mon éxpérience avec les gens non techniques, c'est qu'ils s'en foutent vachement plus )
Personnellement, sur le projet mageia, c'etait simple, la solution tiens en 3 lettres : "non".
Non à l'explosion de moyen de communication ( ie, il y a pas 2 listes de supports dans chaque langue, avec X forums, et une plateforme style askbot/shapado, non à avoir joomla et drupal et wordpress et etc ). Dire non à l'ouverture de listes sans avoir suffisamment de gens pour l'utiliser, dire non à l'ajout d'outil si personne s'en occupe ( en prenant en compte le bus factor ). Pour ça, faut réussir à déléguer et je recommande l'usage d'outil comme puppet + un vcs et la mise à disposition du code pour pouvoir obtenir le plus haut niveau de delegation ( aka "envoie un patch" ). Mettre à dispo des vms pour les gens, comme ce que fait fedora, ça peut aussi être pas mal.
Si tu n'arrives pas à mettre les gens d'accord sur les outils, alors ça semble pas compromis pour se mettre d'accord sur le reste.
Pareil, si tu multiplies les outils, tu va arriver à avoir des comptes de partout, et le bordel. Pareil, la solution, c'est "non". Non si ça rentre pas dans un annuaire ldap partagé. Il faut se battre avec certains outils ( j'ai fiat une conf à ce sujet lors du fosdem, y a peut etre une video ), exemple tantôt le login, tantôt l'email, parfoi avec des limites ( exemple, mediawiki ) et parfois se battre avec les gens ( "bon, ok, on a ldap partout, mais ce truc, c'est trop bien, est ce que juste pour lui, on peut pas faire une exception ?" ). Il y a aussi des gens qui vont raler sur la centralisation, surtout parce que ça implique de plus travailler dans son coin ( ce qui fait que tu va sans doute avoir droit au qualificatif de faciste tôt ou tard, j'ai pas eu le droit personnellement, mais je me dit que j'ai pas du passer trop loin ).
Ou si quelqu'un fait une réunion, c'est "non", tant que 1) personne n'a posté d'agenda 2) personne n'est volontaire pour faire des minutes.
La solution, c'est la simplification. Le minimum d'endroit ou chercher l'info, voir 1 et 1 seul place canonique ( exemple, un wiki qu'on peut chercher ). Si personne fait de CR d'une réunion, bah la réunion ne compte pas. Pareil pour toute discussion importante. Et tout le monde doit pouvoir faire un résumé.
En fait, ce qu'il te faut, c'est un documentaliste.
Par exemple, c'est une proposition, pas une décision pour le moment. Elle est encore débattue.
De même, se focaliser sur les tablettes Windows , c'est aussi totalement ignorer que c'est déjà le cas pour plein de tablettes autres, et donc que le secureboot n'est que la normalisation d'une tendance de fond déjà existante et déjà sur le marché.
Enfin, c'est pas Microsoft qui a autorisé la désactivation, c'est le groupe UEFI suite aux réclamations de Red Hat, de Ubuntu et sans doute d'autres durant les meetings de mise au point du standard. Et Microsoft a demandé à ce que la désactivation soit possible pour avoir le logo kivabien.
Enfin, il est totalement passé sous la trappe la possibilité d'utiliser ses propres clés. Dans un contexte de certificat volé à Microsoft, ça me semble un point important à rappeler.
Comme les rpmnew ( pour les paquets rpm ). En fait, je me demande donc quel distro ne fait pas ça, vu que gentoo fait ça aussi.
En fait, est ce que ça voudrait dire que finalement, les gens mettent en avant une feature de archlinux que toutes les distros proposent ? ( ce qui ne fait que renforcer mon opinion des archeux )
Mais est ce que ça gère le fast-user switching de façon propre ( http://fedoraproject.org/wiki/Desktop/FastUserSwitching ) ? ( car consolekit permet aussi ça, vu que tu as une vue plus haut niveau du concept de session )
De plus, pam_group requiert de monter le fs avec une option spécial pour être sur ( d'après sa page de man ), ce qui exclue du coup l'usage d'une partition /home non séparé de / ( ou ce qui justement interdit des usages légitimes du setgid par les utilisateurs. Bien que ça soit une solution pour pas mal de gens ( et que je pense qu'avoir un /home séparé devrait être forcé et que personne n'utilise le setgid ), je pense pas que ça soit super pour une distro de forcer ça.
Consolekit permet d'ajuster dynamiquement les permissions des devices, ( de maniére concrete ) et de gérer le concept de session utilisateur ( ie, qui est connecté, à distance, pas à distance ). Un des problèmes de l'approche traditionnel, c'est de filer les droits sur la carte son de façon indiscriminé, que je sois en ssh ou pas. Peut être que je suis le seul à avoir l'esprit taquin, mais sous solaris, via telnet, on pouvait lancer des commandes pour jouer de la musique sur la station du voisin. Bien sur, ça veut aussi dire qu'à distance, je peux activer le micro, et ça, c'est moins cool. Conséquence direct du "je suis loggué et dans le bon groupe donc j'ai accés sur la carte son".
Pareil sur les cdroms ( eject ? ) ou la webcam, etc.
Le /tmp est séparé, ie le service démarre, il écrit dans /tmp , mais de façon transparente, c'est pas le même que celui des autres services et de l'utilisateur. Regarde http://0pointer.de/blog/projects/security.html
Et le lien est si ton programme utilise une socket dans /tmp pour communiquer, tu ne la voit pas. Ou le bête problème de Linux Mint ( http://www.openwall.com/lists/oss-security/2012/03/19/14 ) qui va lancer un soft en root, et va faire des traitements dans /tmp, sans vérifier la présence de fichier déjà présent, etc.
Bah, ça aurait autant que de dire "une majeur partie des devs d'udev sont blonds, donc on a pas besoin de faire la distinction". Les devs sur Fedora sont relativement libres de leur choix, et si tu regardes un peu les archives des listes, tu va voir que même dans les gens avec un email @redhat, tout le monde n'est pas d'accord avec le choix. Tout comme tout le monde sans email @redhat n'est pas d'accord, ou comme tout le monde n'est pas contre.
Tu va voir aussi que les discussions ont comencés avant que le mainteneur d'udev quitte novell/suse pour aller chez RH.
Bravo, maintenant, il va voir qu'il a pas d'ami en fait.
Ceci dit, j'ai fait une expérience du même genre il y a 4 ans avec twisted. J'ai mis un faux serveur ssh qui accepte tout login/mot de passe, et qui enregistre le couple dans un fichier de log. Et j'ai vu que les bots qui vont tenter de bruteforcer ssh tente des mots de passes bidons ( genre login : test/ mot de passe : test ), et ne font rien ensuite si le mot de passe est correct. ( ou mon faux serveur ssh n'a pas suffit pour que le bot continue à s'installer ). J'ai pas non plus regardé si quelqu'un est revenu plus tard avec.
Donc j'aurais tendance à ne pas m'inquéter plus que ça sur les tentatives de scans.
Ça implique aussi d'avoir une API, et ça implique que les gens sachent chercher par version d'API plutot que par version, c'est pas forcément plus évident. Autre cas, si tu prends le cas d'unison, y a pas d'api, y a juste des versions incompatibles au niveau du protocole. Donc la solution est suffisament générique pour permettre tout, et l'usage va vers reprendre le numero de version ( même si ça dépend du packageur, parfois, c'est la version de la lib, donc de l'API ).
Ou des anciens joueurs qui ont moins de temps ( travail, famille )
Il y a eu un article y a quelques mois sur Ars Technica sur le fait que les gens veulent plus investir du temps dans les jeux, donc du coup, ils deviennent plus court, mais plus beau.
Je pense que Microsoft peut le faire. C'est juste que ça rapporte rien. Tout comme Apple savait recompiler son os sur x86 et sur ppc. Ça n'a juste servi à rien sauf le jour de la migration.
La portabilité au niveau processeur, ça coute en QA si tu veux faire les choses bien. Ça coute en support si tu veux faire les choses bien aussi. En fait, ça coute comme le support de plusieurs versions d'OS? voir de plusieurs OS.
A un moment, si tu veux garder les couts à un niveau convenable ( genre, pour pouvoir justement te pencher sur des trucs qui servent à plus de gens comme des fonctionnalités demandé par une majorité de client ), faut arrêter de partir dans tout les sens.
[^] # Re: Skype a ses propres drivers de caméra ?
Posté par Misc (site web personnel) . En réponse au journal Skype. Évalué à 1.
C'est con, parce qu'il parait que les nouveaux propriétaires de skype ont déjà contribué au noyau :)
Ceci dit, j'imagine que pour eux, d'un point de vue technique, c'est plus simple ( comme pour google et chrome, pour mozilla et firefox ( sqlite ), comme pour nodejs et la libevent ).
prendre du code, et le modifier dans ton coin, ou juste faire le code dans ton coin sans intégration avec d'autres projets, ç'est plus facile que de devoir expliquer à d'autres ton design et qu'on te dise "non" ( je dit pas que c'est mieux, ni la chose à faire, je précise )
[^] # Re: Mint LTS
Posté par Misc (site web personnel) . En réponse au sondage Quelle distribution de logiciels libres installez-vous aux copains non geeks?. Évalué à 5.
LMDE ou les codeurs de mint ne corrigent pas les bugs de sécurité :
https://bugs.launchpad.net/linuxmint/+bug/1008501
[^] # Re: Mandriva et Mageia
Posté par Misc (site web personnel) . En réponse au sondage Quelle distribution de logiciels libres installez-vous aux copains non geeks?. Évalué à 6.
Sauf si les gens ont mis des ppas de partout, ou si les gens utilisent des applis un chouia moins classiques ( ou si, comme ma copine, utilise une version oem d'Ubuntu payé par Dell sur une archi qui a été abandonné par Canonical )
En fait, je pense que les débutants pensent qu'il y a un truc magique dans apt ou dans debian ( ou ailleurs ), mais la seule chose qui aide, c'est de tester les upgrades, et je pense à ce niveau que toute les distributions sont au même point, à savoir :
- des tests automatisés d'upgrade ( via autoqa ou openqa, ou les dizaines de scripts debian comme piupart )
- des tests manuels fait par un nombre toujours insuffisant de gens ( par définition )
ce qui aboutit globalement à toujours les mêmes histoires, à savoir "$distr_qu_on_utilise marche parfaitement, et tout le reste est tout pourri et c'est tellement une vérité vrai que j'ai pas besoin de donner plus de détails, ou de rapporter de bugs". J'ai eu l'occasion d'avoir des gens se plaindre de tout ce qui existe globalement, passé un certain niveau de popularité. J'ai eu le temps de constater des problèmes sur les divers distros, upgrade debian, ubuntu, fedora, mandriva, mageia. De rapporter des bugs, voir de les corriger.
Mais au final, ça change rien au fait que faire un upgrade d'un système complet sans erreur, c'est juste un problème difficile. Il y a des gens qui font des thèses sur le sujet depuis des années ( projet edos, mancoosi et j'ai oublié la suite ), et qui à mon avis vont en faire encore un paquet.
Ça pourrait être facile si on avait moins de paquets, moins de choix, plus de temps. En fait, avoir le cycle de release de debian avec le choix de paquets de LFS. Mais bon, ça , personne ne le veut, curieusement. Et curieusement, dire "non, on rajoute pas plus de paquet", au mieux, ça te fait passer pour un pisse vinaigre et les gens retentent après 3 mois, au pire, ça te fait passer pour un faciste.
[^] # Re: Pas disponible
Posté par Misc (site web personnel) . En réponse au journal F1, la base de données de Google pour remplacer Mysql. Évalué à 5.
AU contraire, ça montre bien ce que je dit à savoir que garder les trucs pour eux nuit un peu à Google. Dans le cas de MapReduce, ils ont justement communiqué autour, et ça leur a bénéficié via la reprise et l'amélioration de l'idée. Mais le retour aurait pu être plus grand en ayant directement fourni le code pour tous, ils auraient plus facilement pu embaucher du monde ou des gens déjà au courant d'une partie des spécificités.
Mise à part le nombre de gens ( qui n'est pas non plus trivial, je précise ), Google a les mêmes problématiques que d'autres boites classiques du secteur, faire rentrer les gens qu'il faut et ne pas faire rentrer les gens qu'il ne faut pas. Quand tu cherches à embaucher un dev sur un projet particulier, si il est libre, il suffit de piocher dans la communauté ( ce qui entraine d'autres soucis, mais on va mettre ça aussi de coté ). Quand le projet est pas libre, il y a déja plus d'incertitude.
L'idée ne viens pas de moi, mais d'un ancien employé ( http://rethrick.com/#waving-goodbye ).
Ensuite, je sais aussi que Google a des problématiques autres, avec un impact sur le télétravail, sur la taille des locaux et la répartition des gens, etc, et je suppose que le choix de garder tout en interne est mesuré.
[^] # Re: Pas disponible
Posté par Misc (site web personnel) . En réponse au journal F1, la base de données de Google pour remplacer Mysql. Évalué à 4.
Vu que ça parle de s'appuyer sur les libs et softs internes de Google, je pense comme toi.
A terme, je pense que ça doit nuire à Google, car le temps d'adaptation des gens est plus grands qu'en utilisant des technos plus standards, et ça coute à maintenir. Et c'est à mon sens pas super attirant d'aller bosser sur des trucs que tu pourras jamais reprendre ailleurs ( mais peut être que c'est un effet de bord positif pour Google, vu que ça incite les gens à rester chez eux ).
[^] # Re: ah le S.A.V. d'Orange
Posté par Misc (site web personnel) . En réponse au journal Le SAV d'Orange ? Nul à ch*er !. Évalué à 3.
Ça, c'est le support grand publique. Dans le domaine pro j'ai toujours eu des gens polis quand j'ai appelé, et même si y a eu des couacs du style le support technique qui renvoie vers le support commercial, et vice versa, je pense qu'il y a plus des problèmes liés à la taille de la boite et à l'ambiance ( ie, si les gens se suicident, c'est pas non plus par hasard ) que parce que les employés sont mauvais.
En fait, je les plaint plus qu'autre chose.
[^] # Re: Google fait de l'ouvert et du ferme aussi
Posté par Misc (site web personnel) . En réponse à la dépêche Sergey Brin dénonce les « cages dorées » de Facebook et Apple. Évalué à 4.
Le problème est mal pris, il y a des gens chez google qui font des trucs ouverts parce qu'il pense que c'est mieux, et d'autres qui pensent que ça n'apporte rien.
Y a 32 000 employés, que tout le monde soit sur la même longueur d'onde me ferait un chouia peur.
[^] # Re: et le grand œil Google
Posté par Misc (site web personnel) . En réponse à la dépêche Sergey Brin dénonce les « cages dorées » de Facebook et Apple. Évalué à 6.
T u veux dire que google ne suis pas le robots.txt ?
[^] # Re: Dire nonà l'explosionde plateforme
Posté par Misc (site web personnel) . En réponse au journal Linuxfr+ldap ? Une solution de gestion de communauté efficace ?. Évalué à 2.
Moi, de ce que j'ai vu, c'est :
1) addictif quand tu commences à te prendre aux jeux des points
2) foireux sans une communauté assez grande pour gérer ça
Si tu l'utilises tout seul, je suis pas sur que ça soit mieux qu'un wiki. En fait, faut voir ça comme un mix entre un forum et un wiki, mais pour plusieurs.
Plus tu restes et tu fais des choses positives, plus tu as de points, plus tu deviens de facto un modérateur du systèmes.
[^] # Re: Dire non à l'explosion de plateforme
Posté par Misc (site web personnel) . En réponse au journal Linuxfr+ldap ? Une solution de gestion de communauté efficace ?. Évalué à 4.
Je rajouterais même : http://communitymgt.wikia.com/wiki/Bikeshedding ( avec une spécial dédicace pour les discussions en cours sur la fondation Mandriva, ou ça parle plus du nom de la structure que de sa gouvernance )
[^] # Re: Dire non à l'explosion de plateforme
Posté par Misc (site web personnel) . En réponse au journal Linuxfr+ldap ? Une solution de gestion de communauté efficace ?. Évalué à 3.
En général, le problème, c'est pas tant de la structure qu'un manque de connaissances des gens. Par exemple, chacun a son forum favori, et tout le monde va pousser pour l'avoir, sans être capable d'exprimer le besoin. J'ai constaté qu'en fait, c'est souvent du bikesheding. Surtout quand tu as des gens un peu technique, ce qui dans le libre veux dire "beaucoup de monde". ( mon éxpérience avec les gens non techniques, c'est qu'ils s'en foutent vachement plus )
# Dire non à l'explosion de plateforme
Posté par Misc (site web personnel) . En réponse au journal Linuxfr+ldap ? Une solution de gestion de communauté efficace ?. Évalué à 10.
Personnellement, sur le projet mageia, c'etait simple, la solution tiens en 3 lettres : "non".
Non à l'explosion de moyen de communication ( ie, il y a pas 2 listes de supports dans chaque langue, avec X forums, et une plateforme style askbot/shapado, non à avoir joomla et drupal et wordpress et etc ). Dire non à l'ouverture de listes sans avoir suffisamment de gens pour l'utiliser, dire non à l'ajout d'outil si personne s'en occupe ( en prenant en compte le bus factor ). Pour ça, faut réussir à déléguer et je recommande l'usage d'outil comme puppet + un vcs et la mise à disposition du code pour pouvoir obtenir le plus haut niveau de delegation ( aka "envoie un patch" ). Mettre à dispo des vms pour les gens, comme ce que fait fedora, ça peut aussi être pas mal.
Si tu n'arrives pas à mettre les gens d'accord sur les outils, alors ça semble pas compromis pour se mettre d'accord sur le reste.
Pareil, si tu multiplies les outils, tu va arriver à avoir des comptes de partout, et le bordel. Pareil, la solution, c'est "non". Non si ça rentre pas dans un annuaire ldap partagé. Il faut se battre avec certains outils ( j'ai fiat une conf à ce sujet lors du fosdem, y a peut etre une video ), exemple tantôt le login, tantôt l'email, parfoi avec des limites ( exemple, mediawiki ) et parfois se battre avec les gens ( "bon, ok, on a ldap partout, mais ce truc, c'est trop bien, est ce que juste pour lui, on peut pas faire une exception ?" ). Il y a aussi des gens qui vont raler sur la centralisation, surtout parce que ça implique de plus travailler dans son coin ( ce qui fait que tu va sans doute avoir droit au qualificatif de faciste tôt ou tard, j'ai pas eu le droit personnellement, mais je me dit que j'ai pas du passer trop loin ).
Ou si quelqu'un fait une réunion, c'est "non", tant que 1) personne n'a posté d'agenda 2) personne n'est volontaire pour faire des minutes.
La solution, c'est la simplification. Le minimum d'endroit ou chercher l'info, voir 1 et 1 seul place canonique ( exemple, un wiki qu'on peut chercher ). Si personne fait de CR d'une réunion, bah la réunion ne compte pas. Pareil pour toute discussion importante. Et tout le monde doit pouvoir faire un résumé.
En fait, ce qu'il te faut, c'est un documentaliste.
[^] # Re: UEFI ca ne se désactive pas
Posté par Misc (site web personnel) . En réponse à la dépêche UEFI en question. Évalué à 5. Dernière modification le 06 juin 2012 à 13:24.
ça ne serait pas la seule erreur dans la dépêche.
Par exemple, c'est une proposition, pas une décision pour le moment. Elle est encore débattue.
De même, se focaliser sur les tablettes Windows , c'est aussi totalement ignorer que c'est déjà le cas pour plein de tablettes autres, et donc que le secureboot n'est que la normalisation d'une tendance de fond déjà existante et déjà sur le marché.
Enfin, c'est pas Microsoft qui a autorisé la désactivation, c'est le groupe UEFI suite aux réclamations de Red Hat, de Ubuntu et sans doute d'autres durant les meetings de mise au point du standard. Et Microsoft a demandé à ce que la désactivation soit possible pour avoir le logo kivabien.
Enfin, il est totalement passé sous la trappe la possibilité d'utiliser ses propres clés. Dans un contexte de certificat volé à Microsoft, ça me semble un point important à rappeler.
[^] # Re: elle ne modifie pas les fichiers de configuration à l’insu de l’administrateur
Posté par Misc (site web personnel) . En réponse à la dépêche Arch Linux signe ses paquets !. Évalué à -2.
Comme les rpmnew ( pour les paquets rpm ). En fait, je me demande donc quel distro ne fait pas ça, vu que gentoo fait ça aussi.
En fait, est ce que ça voudrait dire que finalement, les gens mettent en avant une feature de archlinux que toutes les distros proposent ? ( ce qui ne fait que renforcer mon opinion des archeux )
[^] # Re: Mauvaise distro, changer de distro
Posté par Misc (site web personnel) . En réponse au journal Quelle distribution restera dans l'esprit UNIX?. Évalué à 3.
Mais est ce que ça gère le fast-user switching de façon propre ( http://fedoraproject.org/wiki/Desktop/FastUserSwitching ) ? ( car consolekit permet aussi ça, vu que tu as une vue plus haut niveau du concept de session )
De plus, pam_group requiert de monter le fs avec une option spécial pour être sur ( d'après sa page de man ), ce qui exclue du coup l'usage d'une partition /home non séparé de / ( ou ce qui justement interdit des usages légitimes du setgid par les utilisateurs. Bien que ça soit une solution pour pas mal de gens ( et que je pense qu'avoir un /home séparé devrait être forcé et que personne n'utilise le setgid ), je pense pas que ça soit super pour une distro de forcer ça.
[^] # Re: Mauvaise distro, changer de distro
Posté par Misc (site web personnel) . En réponse au journal Quelle distribution restera dans l'esprit UNIX?. Évalué à 5.
Consolekit permet d'ajuster dynamiquement les permissions des devices, ( de maniére concrete ) et de gérer le concept de session utilisateur ( ie, qui est connecté, à distance, pas à distance ). Un des problèmes de l'approche traditionnel, c'est de filer les droits sur la carte son de façon indiscriminé, que je sois en ssh ou pas. Peut être que je suis le seul à avoir l'esprit taquin, mais sous solaris, via telnet, on pouvait lancer des commandes pour jouer de la musique sur la station du voisin. Bien sur, ça veut aussi dire qu'à distance, je peux activer le micro, et ça, c'est moins cool. Conséquence direct du "je suis loggué et dans le bon groupe donc j'ai accés sur la carte son".
Pareil sur les cdroms ( eject ? ) ou la webcam, etc.
[^] # Re: Où est le problème ?
Posté par Misc (site web personnel) . En réponse au journal Quelle distribution restera dans l'esprit UNIX?. Évalué à 5.
En effet, ce qui manque, c'est les gens qui codent. Hint, un rant sur Linuxfr, c'est pas du code.
[^] # Re: les fontes
Posté par Misc (site web personnel) . En réponse à la dépêche Sortie de Fedora 17 nommée Beefy Miracle. Évalué à 2.
Purée, c'est à destination des ubuntistes pour pas les perdre ?
activation de sudo, activation des paquets proprios ( flash skype, google earth ), usage de yum comme apt ( avec un cache à rafraichir à la main ).
ça me défrise.
[^] # Re: Remarques
Posté par Misc (site web personnel) . En réponse à la dépêche Sortie de Fedora 17 nommée Beefy Miracle. Évalué à 2.
Le /tmp est séparé, ie le service démarre, il écrit dans /tmp , mais de façon transparente, c'est pas le même que celui des autres services et de l'utilisateur. Regarde http://0pointer.de/blog/projects/security.html
Et le lien est si ton programme utilise une socket dans /tmp pour communiquer, tu ne la voit pas. Ou le bête problème de Linux Mint ( http://www.openwall.com/lists/oss-security/2012/03/19/14 ) qui va lancer un soft en root, et va faire des traitements dans /tmp, sans vérifier la présence de fichier déjà présent, etc.
[^] # Re: HFS
Posté par Misc (site web personnel) . En réponse à la dépêche Sortie de Fedora 17 nommée Beefy Miracle. Évalué à 1.
Bah, ça aurait autant que de dire "une majeur partie des devs d'udev sont blonds, donc on a pas besoin de faire la distinction". Les devs sur Fedora sont relativement libres de leur choix, et si tu regardes un peu les archives des listes, tu va voir que même dans les gens avec un email @redhat, tout le monde n'est pas d'accord avec le choix. Tout comme tout le monde sans email @redhat n'est pas d'accord, ou comme tout le monde n'est pas contre.
Tu va voir aussi que les discussions ont comencés avant que le mainteneur d'udev quitte novell/suse pour aller chez RH.
[^] # Re: Refais le test
Posté par Misc (site web personnel) . En réponse au journal J'ai plein d'amis ... et je ne le savais pas ;o). Évalué à 4.
Bravo, maintenant, il va voir qu'il a pas d'ami en fait.
Ceci dit, j'ai fait une expérience du même genre il y a 4 ans avec twisted. J'ai mis un faux serveur ssh qui accepte tout login/mot de passe, et qui enregistre le couple dans un fichier de log. Et j'ai vu que les bots qui vont tenter de bruteforcer ssh tente des mots de passes bidons ( genre login : test/ mot de passe : test ), et ne font rien ensuite si le mot de passe est correct. ( ou mon faux serveur ssh n'a pas suffit pour que le bot continue à s'installer ). J'ai pas non plus regardé si quelqu'un est revenu plus tard avec.
Donc j'aurais tendance à ne pas m'inquéter plus que ça sur les tentatives de scans.
[^] # Re: non
Posté par Misc (site web personnel) . En réponse au journal (Le journal du vendredi) : Vous-êtes hasbeen avec vos petits jeux Linux ! :). Évalué à 2.
En effet, j'ai même pas vu après 3 relectures que ça manque, désolé.
[^] # Re: Tilde
Posté par Misc (site web personnel) . En réponse à la dépêche RPM 4.10 est sorti. Évalué à 4.
Ça implique aussi d'avoir une API, et ça implique que les gens sachent chercher par version d'API plutot que par version, c'est pas forcément plus évident. Autre cas, si tu prends le cas d'unison, y a pas d'api, y a juste des versions incompatibles au niveau du protocole. Donc la solution est suffisament générique pour permettre tout, et l'usage va vers reprendre le numero de version ( même si ça dépend du packageur, parfois, c'est la version de la lib, donc de l'API ).
[^] # Re: non
Posté par Misc (site web personnel) . En réponse au journal (Le journal du vendredi) : Vous-êtes hasbeen avec vos petits jeux Linux ! :). Évalué à 2.
Ou des anciens joueurs qui ont moins de temps ( travail, famille )
Il y a eu un article y a quelques mois sur Ars Technica sur le fait que les gens veulent plus investir du temps dans les jeux, donc du coup, ils deviennent plus court, mais plus beau.
[^] # Re: Conclusion
Posté par Misc (site web personnel) . En réponse au journal Ta Fedora sera signée par Microsoft. Évalué à 6.
Je pense que Microsoft peut le faire. C'est juste que ça rapporte rien. Tout comme Apple savait recompiler son os sur x86 et sur ppc. Ça n'a juste servi à rien sauf le jour de la migration.
La portabilité au niveau processeur, ça coute en QA si tu veux faire les choses bien. Ça coute en support si tu veux faire les choses bien aussi. En fait, ça coute comme le support de plusieurs versions d'OS? voir de plusieurs OS.
A un moment, si tu veux garder les couts à un niveau convenable ( genre, pour pouvoir justement te pencher sur des trucs qui servent à plus de gens comme des fonctionnalités demandé par une majorité de client ), faut arrêter de partir dans tout les sens.