Au temps pour moi, c'est effectivement ce que je voulais dire.
Comme la FSF a fondé son cahier des charges sur celui de Fedora, je trouvais amusant qu'au final, pour donner un exemple concret que BLAG Linux (dérivée de Fedora) soit reconnue par libre par la FSF (ils utilisent le kernel du projet linux-libre) mais qu'en même temps, BLAG ne respecte pas les critères Fedora (ils fournissent les codecs multimédias brevetés).
Une anecdote intéressante, jusqu'à fin 2006, la FSF n'avait pas défini de cahier des charges définissant ce qu'était une distribution libre selon la FSF. À l'époque, le projet avait approché la FSF pour définir ce cahier des charges qui d'ailleurs s'inspire directement des guidelines Fedora.
La principale différence étant que Fedora est plus stricte sur les brevets logiciels, et autorise exceptionnellement les firmwares binaires (au départ, RMS était d'accord pour mettre temporairement de côté le problème des firmwares). https://fedoraproject.org/wiki/FreeSoftwareAnalysis https://fedoraproject.org/wiki/FreeSoftwareAnalysis/FSF
Chose amusante, la plupart des distros reconnues comme libre par la FSF, ne le sont pas par Fedora.
Dans ces 2 cas, c'est parce que Debian et Fedora proposent des dépôts tiers permettant d'installer des paquets proprio
Fedora ne propose AUCUN paquets propriétaires (à l'exception des firmwares), nonfree n'existent pas chez Fedora. Tout les dépôts tiers fournissant ces paquets (rpmfusion, rpmforge, etc...) sont indépendants du projet, même si certains contributeurs participent aux deux projets (par exemple, rpmfusion reconnait automatiquement le statut de développeur à tout développeur Fedora qui le souhaite, l'inverse n'est pas vrai).
RHEL en entreprise, c'est plein de logiciels compilés à la main parce que ceux fournis par RH sont trop vieux
Si tu compiles à la main, tu n'as pas besoin de support. Enfin, cette critique, on pourrait la faire pour toute les distros entreprises, à partir du moment où tu t'engages contractuellement à maintenir un ensemble de logiciels: tu dois borner l'ensemble (les paquets concernés, versions etc ...). Bien évidemment, tu pourrais faire de la maintenance à la carte, mais ça reviendrait extrêmement cher au client.
(sur une débian ça semble plus facile de panacher).
Panacher mais comment ?
En activant les dépôts sid sur une stable ? t'as à peu près autant de chance de flinguer ton installation qu'en activant les dépôts Fedora sur une RHEL.
Les backports ? certes, mais ça reste basé sur le volontariat, RHEL & cie ont bien EPEL mais c'est un effort communautaire donc hors contrat de maintenance. Les PPA de Canonical sont probablement l'outil adéquat pour répondre à ce genre de problèmes, mais ça reste délicat à intégrer dans un contrat et ça recrée en partie, le même problème qu'ont connus les utilisateurs de feu RedHat Linux: l'enfer des dépendances.
Du coup SELinux quasi toujours désactivé car dès que tu sors des paquets RH, c'est une plaie à gérer.
Les politiques SELinux sont relativement génériques, tout ce que tu as à faire si tu compiles à la main la plupart du temps, c'est d'affecter le bon contexte.
En général ça sert à rien, c'est peu utilisé ou mal (du genre on trouve la solution avant l'ingénieur de support) et c'est juste la pour protéger les fesses des managers.
Je partage tout à fait ton avis, il vaut mieux embaucher un admin compétent que de payer un contrat de maintenance qui coute la peau des fesses.
Les contrats de maintenance sont destinés à des gens qui ont besoin d'accèder une expertise technique pointue (ce qui concerne relativement peu de personnes) ou bien d'avoir un système dont la stabilité est garantie sur le long terme (c'est pas rare des environnements de prod dont la durée de vie excédent 5 ans, voire 10 ou 20 ans).
Un point fort de Debian, c'est qu'il est relativement facile de trouver des prestataires compétents (souvent des DD indépendants, je ne parle pas des proxénètes type SSII) pour résoudre des problèmes ponctuels sans devoir payer un contrat de maintenance inutile. Ce genre de réseaux professionnels est beaucoup moins développé autour des autres distros même si les compétences existent.
Frugalware est un fork de slackware (leur init contient encore des bouts de code de slackware), par contre, le gestionnaire de paquets est un fork de celui d'Archlinux.
Pour l'avoir fait, ça marche très bien sur un serveur, mais c'est pas aussi bien intégré que sous Fedora pour une station de travail.
À la décharge de Debian, réussir à avoir un système utilisable par monsieur-tout-le-monde avec selinux activé par défaut sur une station de travail, c'est pas une mince affaire. Ça nous a pris plusieurs années sous Fedora pour y arriver et ça demande un effort constant en terme d'empaquetage pour développer, maintenir et tester les politiques selinux associées.
Comment tu peux dire que le support de Fedora soit meilleur que les autres, en n'ayant que les données de Fedora ?
Smolt n'a jamais été fermé aux autres distros, bien au contraire, les autres distros ont été invités à participer au projet (une instance est dispo sur un nom de domaine générique: smolts.org) mais seul openSuSE a répondu (mais n'installe pas le client par défaut). Le client et le serveur ont été testé sur la plupart des distros majeures.
Sinon, c'était pour illustrer le fait que Fedora n'en a pas rien à foutre du support matériel, un travail énorme a été fait au niveau de l'intégration des pilotes WiFi (merci John Linville), sur le bluetooth (merci Hadess), le réseau, les cartes graphiques (radeon, nouveau, etc ... ont largement bénéficié des Fedora testing days).
Si le support matériel se résume à "installation automatique des pilotes proprio", Fedora a effectivement un "mauvais" support de base (et encore, en installant le dépôt rpmfusion, on arrive au même niveau que les autres), sinon Fedora a un très bon support matériel (des développeurs et des testeurs qui travaillent d'arrache pied avec upstream pour que ça fonctionne, je doute que les autres distros communautaire fassent autant d'efforts, sans compter un noyau régulièrement mis à jour ou des backports)
Fedora n'est pas destiné à un serveur de prod, ça n'est tout simplement pas compatible avec les objectifs techniques ambitieux du projet ni avec un support de 13 mois.
Par contre, il y'a encore du centos en dehors des DSI mais c'est toujours pour faire tourner un produit proprio qui demande Redhat dans ses prérequis.
C'est pas très cohérent, parce que si ton produit a été certifié pour RHEL, en général, tu te fais bouler par le support si tu utilises un clone (pour diverses raisons: quelques différences mineures au niveau de certains paquets, le fait que ton système n'est pas passé à la moulinette RH pour vérifier les histoires de compatibilité).
En revanche, il n'est pas rare de rencontrer des serveurs à base RHEL (clones compris) et pas que pour faire tourner un tas de merde proprio. Si tu fais de la virtualisation côté serveur, tu trouveras beaucoup de RHEL & cie, ou du SuSE.
Je relève quelques incohérences à propos de Fedora:
Credit has to go to Ubuntu and SUSE for at least trying to maintain some sort of compatibility list, a task which Fedora gave up on long ago.
C'est du grand n'importe quoi, avec smolt, Fedora dispose de la plus grande base de données à ce sujet. http://smolt.fedoraproject.org/
Par expérience, Fedora a plutôt un très bon support matériel comparé aux autres distributions binaires (côté distributions sources, Gentoo se défends bien dans ce domaine),
There's more to a Linux community than just numbers.
Sauf que le classement place Ubuntu devant Fedora alors que le paragraphe précédent expliquait que les communautés openSuSE et Fedora étaient nettement plus proactives à ce niveau. Soit on utilise la métrique nombre d'utilisateurs, soit la métrique activité mais on ne fait pas un classement basée sur la première en disant qu'on se fonde sur la seconde.
Pour le reste, le comparatif n'est pas très exhaustif (où sont passé Mandriva ? Gentoo ? Slackware ? etc...), un gros biais vis à vis de Debian/Ubuntu même si l'auteur essaie de corriger le tir mais on a vu plus trollesque dans la catégorie.
ça m'a bien fait marrer :]
Par contre, un vrai fedobear porterait une casquette blanche avec le logo fedora devant, le projet ayant explicitement banni la symbolique associé à RedHat (le fameux chapeau en feutre rouge et la couleur dominante rouge) pour distinguer les deux entités.
pour le reste, vous noterez mon silence ;)
Perso, ce qui m'a surpris c'est la rapidité de la validation, je l'ai même pas vu dans le pipe le jour même. C'est dommage d'avoir un éditeur collaboratif si on n'a même pas le temps de permettre aux autres membres de relire la dépêche (notamment pour la compléter).
Pour le reste, no comment.
L'inconvénient des branches "nommées" dans mercurial sont que le nom est inscrit dans les metadata des changesets qu'on se traine éternellement ce qui n'est pas pratique dans l'optique des branches à durée de vie très courtes.
C'est la principale différence entre les branches git et les branches mercurial, les commits git ne conservent aucune information de branches.
En revanche, mercurial a toujours supportés les branches type git via les "heads", sauf que les heads n'avaient pas de nom à l'origine et du coup, c'est très chiant pour changer de head. L'extension bookmark (désormais intégré dans le coeur de mercurial) a permis d'ajouter une étiquette à un head et d'avoir un équivalent total aux branches git.
C'est très pratique de pouvoir créer une branche pour expérimenter sans se soucier à priori de savoir si on réintegrera ou non nos expérimentations (et éventuellement se trainer des metadata inutiles ad vitam eternam - surtout quand on donne des noms très cons aux branches jetables -).
Dans le même ordre de considération, les mercurial queues permettent d'avoir une souplesse similaire (voire supérieure) mais ça n'est pas forcément du goût de tout le monde de gérer des patchs queues.
SNMP ? Pas tout à fait, SNMP permet d'interroger des machines physiques mais ça reste très basique et relativement très faible niveau sécurité.
Matahari a été développé dans l'optique de gérer des infrastructures virtualisées (c'est ce qui est utilisé dans l'offre virtualisation, grille et cloud de Red Hat). Matahari repose sur le protocole QMF une extension du protocole normalisé AMQP (QMF permet de structurer le développement d'une infrastructure basé sur AMQP en ajoutant la notion d'agent et d'objet + introspection)
Bonne news dans l'ensemble, j'en profite pour rajouter mon grain de sel :o)
La délégation de constructeur
On peut également signaler un constructeur par défaut et même demander au compilateur de ne pas générer certaines fonctions membres (très pratique, pour interdire la copie par exemple)
> On peut quand même regretter l'absence de sémaphore dans la spécification.
À l'origine, boost::thread (dont s'inspire cette spécification) proposait un type semaphore mais il a été retiré parce qu'il était source d'erreurs (pas de notion de lock, inversion de priorité). La solution recommandée c'est d'utiliser un mutex + une condition, même si dans certains cas, ça ne convient pas (gestion de signaux posix entre autres).
Derrière, std::thread propose la plupart des facilités des threads Posix (mutex, condition, barrière, R/W locks, etc...) en plus sûr mais également les futures. D'ailleurs, le langage gagne le mot clé thread_local pour signaler les variables TLS.
Les expressions régulières font leur entrée dans la bibliothèques standard
Je tiens à souligner que l'implémentation de référence (aka boost::regex de John Maddock) est particulièrement performante (et bénéficie énormément des templates), et offre bon nombre des facilités des expressions régulières compatibles Perl, ainsi qu'un header de compatibilité avec l'API Posix.
Je trouve dommage qu'on ne mentionne pas la grosse nouveauté (depuis l'abandon des concepts pour ce round) de la norme mais également la plus complexe à appréhender: la sémantique move qui permet d'économiser certains copies inutiles mais impossible à éviter de par le langage. Les utilisateurs peuvent ainsi bénéficier de façon transparente de cette optimisation à travers la bibliothèque standard si celle-ci a été adaptée en conséquence (mais leur code peut également en bénéficier à condition d'écrire un constructeur et un opérateur move adéquats)
Bjarne stroustrup l'expliquera certainement beaucoup mieux que moi: http://www2.research.att.com/~bs/C++0xFAQ.html#rval
Certes, ça complexifie le langage mais c'est un exemple typique de ce qui fait l'attrait du C++: un langage extrêmement souple, performant et robuste.
rebase, ça permet d'avoir un historique linéaire, plus lisible (pas de message automatique de merge qui pollue les logs).
En règle générale, on privilègie le rebase pour travailler sur une même branche ou les branches à durée de vie courte (par exemple, développer une fonctionnalité sans péter sa branche, faire un POC etc rapide), le merge pour fusionner deux branches.
Les mercurial queues sont aussi une alternative aux branches à durée de vie courte. Transplant pour récupérer des bug fixes à partir d'autres branches.
bookmarks (multi-head avec une étiquette) qui est plus ou moins l'équivalent des branches git. Bookmarks a été intégré au coeur de mercurial depuis la version 1.8 (auparavant c'était une extension fournie dans la distribution officielle)
Pour les versions, je te conseille de les tagger et de créer les branches au fur et à mesure (ça ne sert à rien une branche si derrière, tu bosses jamais dessus)
l'intérêt de bitbucket & cie, c'est de partager ton code: t'as un bug tracker, un wiki, une exposition, un dépôt central pour pas cher
oui, RhodeCode, mais c'est pas aussi bien chiadé que Bitbucket
http://rhodecode.org/
Perso, j'ai un compte bitbucket payant pour mes projets freelance et j'utilise mercurial-server pour les autres (un gitolite-like pour ceux qui connaissent)
http://www.lshift.net/mercurial-server.html
Lis cet article http://lwn.net/Articles/342892/
Quant à la pérennité du projet, btrfs a été désigné comme étant le successeur d'ext4 (il n'y aura pas d'ext5), certes Oracle reste le premier contributeur au projet, mais ils sont talonnés par Redhat (Josef Bacik bosse uniquement sur btrfs depuis quelques années), Novell, Canonical participent également à l'effort.
Qu'est-ce qui s'est passé depuis ? Oracle a racheté Sun. Et qu'avait Sun dans le domaine des systèmes de fichiers ? ZFS.
Sauf que Btrfs de l'aveu de Valerie Aurora (qui a bossé sur ZFS chez Sun) a une architecture plus efficace que ZFS notamment du fait que ZFS est antérieur aux travaux d'Ohad Rodeh sur B-Tree.
La licence LLVM est une dérivée de la BSD, tu as des bouts sous licence MIT (entre autre la bibliothèque C++ standard et le runtime du compilo), seul le déprécié llvm-gcc est sous licence GPL http://llvm.org/docs/DeveloperPolicy.html#license
c'est donc CEDET qui pourrait porter plainte contre la FSF, pour contrefaçon.
Sauf que ce sont les auteurs de CEDET qui ont oubliés de fournir les grammaires, donc la FSF pourrait porter plainte pour violation de la GPL parce que CEDET n'a pas distribué les sources.
Certains fichiers distribués avec Emacs ne sont en effet disponible que sous forme binaire.
Nope, c'est des fichiers sources générées par bison, certes, ça n'est pas GPL-compliant (si tes fichiers sources sont générés à partir d'autres sources -en l'occurence, les grammaires bison-, il faut également les fournir), mais ça démontre que l'auteur a baclé son travail de troll et n'a aucun respect pour ce saint jour de trolldi que nous devons aux illustres ancêtres de usenet.
Je pense qu'il rêve que brtfs soit porté sur d'autres os. Si c'est ça je pense que c'est en effet qu'un rêve. Sous license BSD pourquoi pas, *BSD l'auraient peut être repris et peut être même apple (qui voulait porter zfs il n'y a pas si longtemps). On peut espérer que d'autres en fasse une nouvelle implémentation sans reprendre les sources sous gpl, mais j'y crois assez peu.
ZFS est sous licence CDDL, ça n'a pas empêché FreeBSD de fournir le support de ZFS en réutilisant le code d'OpenSolaris (sous forme d'un module noyau), rien n'empêcherait les *BSD de fournir le support de Btrfs sous forme d'un module noyau (pour respecter le sacro-saint principe que le système de base est 100% BSD, hein, dans l'absolu, rien n'interdit de fournir un noyau BSD avec le support de Btrfs en statique).
Au passage, la CDDL (qui n'est qu'une vilaine MPL maquillée par feu Sun) n'est pas plus BSD-friendly que la GPL.
[^] # Re: Pas choqué.
Posté par GeneralZod . En réponse au journal Debian: meilleure distribution de l'année 2011. Évalué à 5.
Au temps pour moi, c'est effectivement ce que je voulais dire.
Comme la FSF a fondé son cahier des charges sur celui de Fedora, je trouvais amusant qu'au final, pour donner un exemple concret que BLAG Linux (dérivée de Fedora) soit reconnue par libre par la FSF (ils utilisent le kernel du projet linux-libre) mais qu'en même temps, BLAG ne respecte pas les critères Fedora (ils fournissent les codecs multimédias brevetés).
[^] # Re: Pas choqué.
Posté par GeneralZod . En réponse au journal Debian: meilleure distribution de l'année 2011. Évalué à 4.
Une anecdote intéressante, jusqu'à fin 2006, la FSF n'avait pas défini de cahier des charges définissant ce qu'était une distribution libre selon la FSF. À l'époque, le projet avait approché la FSF pour définir ce cahier des charges qui d'ailleurs s'inspire directement des guidelines Fedora.
La principale différence étant que Fedora est plus stricte sur les brevets logiciels, et autorise exceptionnellement les firmwares binaires (au départ, RMS était d'accord pour mettre temporairement de côté le problème des firmwares).
https://fedoraproject.org/wiki/FreeSoftwareAnalysis
https://fedoraproject.org/wiki/FreeSoftwareAnalysis/FSF
Chose amusante, la plupart des distros reconnues comme libre par la FSF, ne le sont pas par Fedora.
Fedora ne propose AUCUN paquets propriétaires (à l'exception des firmwares), nonfree n'existent pas chez Fedora. Tout les dépôts tiers fournissant ces paquets (rpmfusion, rpmforge, etc...) sont indépendants du projet, même si certains contributeurs participent aux deux projets (par exemple, rpmfusion reconnait automatiquement le statut de développeur à tout développeur Fedora qui le souhaite, l'inverse n'est pas vrai).
[^] # Re: Pas choqué.
Posté par GeneralZod . En réponse au journal Debian: meilleure distribution de l'année 2011. Évalué à 6.
Pour les principes directeurs du projet:
https://fedoraproject.org/wiki/Foundations
Pour la politique au niveau des licences:
https://fedoraproject.org/wiki/Packaging:LicensingGuidelines (un audit est mené régulièrement par les community managers sur les licences des paquets importés, et les paquets controversés -brevets, licences extraterrestres, etc... - nécessitent d'être validés par le comité technique élus par les contributeurs)
Le document que doivent signer tout les contributeurs Fedora concernant leurs contributions au projet:
https://fedoraproject.org/wiki/Legal:Fedora_Project_Contributor_Agreement#FPCA_Text
Différents documents:
https://fedoraproject.org/wiki/Overview
https://fedoraproject.org/wiki/Objectives
Même si il n'y a pas un seul contrat social, il y a un vrai souci de l'éthique au niveau du projet.
[^] # Re:
Posté par GeneralZod . En réponse au journal Debian: meilleure distribution de l'année 2011. Évalué à 7.
Si tu compiles à la main, tu n'as pas besoin de support. Enfin, cette critique, on pourrait la faire pour toute les distros entreprises, à partir du moment où tu t'engages contractuellement à maintenir un ensemble de logiciels: tu dois borner l'ensemble (les paquets concernés, versions etc ...). Bien évidemment, tu pourrais faire de la maintenance à la carte, mais ça reviendrait extrêmement cher au client.
Panacher mais comment ?
En activant les dépôts sid sur une stable ? t'as à peu près autant de chance de flinguer ton installation qu'en activant les dépôts Fedora sur une RHEL.
Les backports ? certes, mais ça reste basé sur le volontariat, RHEL & cie ont bien EPEL mais c'est un effort communautaire donc hors contrat de maintenance. Les PPA de Canonical sont probablement l'outil adéquat pour répondre à ce genre de problèmes, mais ça reste délicat à intégrer dans un contrat et ça recrée en partie, le même problème qu'ont connus les utilisateurs de feu RedHat Linux: l'enfer des dépendances.
Les politiques SELinux sont relativement génériques, tout ce que tu as à faire si tu compiles à la main la plupart du temps, c'est d'affecter le bon contexte.
Je partage tout à fait ton avis, il vaut mieux embaucher un admin compétent que de payer un contrat de maintenance qui coute la peau des fesses.
Les contrats de maintenance sont destinés à des gens qui ont besoin d'accèder une expertise technique pointue (ce qui concerne relativement peu de personnes) ou bien d'avoir un système dont la stabilité est garantie sur le long terme (c'est pas rare des environnements de prod dont la durée de vie excédent 5 ans, voire 10 ou 20 ans).
Un point fort de Debian, c'est qu'il est relativement facile de trouver des prestataires compétents (souvent des DD indépendants, je ne parle pas des proxénètes type SSII) pour résoudre des problèmes ponctuels sans devoir payer un contrat de maintenance inutile. Ce genre de réseaux professionnels est beaucoup moins développé autour des autres distros même si les compétences existent.
[^] # Re: Frugalware
Posté par GeneralZod . En réponse au journal Debian: meilleure distribution de l'année 2011. Évalué à 5.
Frugalware est un fork de slackware (leur init contient encore des bouts de code de slackware), par contre, le gestionnaire de paquets est un fork de celui d'Archlinux.
[^] # Re:
Posté par GeneralZod . En réponse au journal Debian: meilleure distribution de l'année 2011. Évalué à 7.
Pour l'avoir fait, ça marche très bien sur un serveur, mais c'est pas aussi bien intégré que sous Fedora pour une station de travail.
À la décharge de Debian, réussir à avoir un système utilisable par monsieur-tout-le-monde avec selinux activé par défaut sur une station de travail, c'est pas une mince affaire. Ça nous a pris plusieurs années sous Fedora pour y arriver et ça demande un effort constant en terme d'empaquetage pour développer, maintenir et tester les politiques selinux associées.
[^] # Re: Trolldi à l'eau
Posté par GeneralZod . En réponse au journal Debian: meilleure distribution de l'année 2011. Évalué à 7.
Smolt n'a jamais été fermé aux autres distros, bien au contraire, les autres distros ont été invités à participer au projet (une instance est dispo sur un nom de domaine générique: smolts.org) mais seul openSuSE a répondu (mais n'installe pas le client par défaut). Le client et le serveur ont été testé sur la plupart des distros majeures.
Sinon, c'était pour illustrer le fait que Fedora n'en a pas rien à foutre du support matériel, un travail énorme a été fait au niveau de l'intégration des pilotes WiFi (merci John Linville), sur le bluetooth (merci Hadess), le réseau, les cartes graphiques (radeon, nouveau, etc ... ont largement bénéficié des Fedora testing days).
Si le support matériel se résume à "installation automatique des pilotes proprio", Fedora a effectivement un "mauvais" support de base (et encore, en installant le dépôt rpmfusion, on arrive au même niveau que les autres), sinon Fedora a un très bon support matériel (des développeurs et des testeurs qui travaillent d'arrache pied avec upstream pour que ça fonctionne, je doute que les autres distros communautaire fassent autant d'efforts, sans compter un noyau régulièrement mis à jour ou des backports)
[^] # Re:
Posté par GeneralZod . En réponse au journal Debian: meilleure distribution de l'année 2011. Évalué à 4.
Fedora n'est pas destiné à un serveur de prod, ça n'est tout simplement pas compatible avec les objectifs techniques ambitieux du projet ni avec un support de 13 mois.
C'est pas très cohérent, parce que si ton produit a été certifié pour RHEL, en général, tu te fais bouler par le support si tu utilises un clone (pour diverses raisons: quelques différences mineures au niveau de certains paquets, le fait que ton système n'est pas passé à la moulinette RH pour vérifier les histoires de compatibilité).
En revanche, il n'est pas rare de rencontrer des serveurs à base RHEL (clones compris) et pas que pour faire tourner un tas de merde proprio. Si tu fais de la virtualisation côté serveur, tu trouveras beaucoup de RHEL & cie, ou du SuSE.
# Trolldi à l'eau
Posté par GeneralZod . En réponse au journal Debian: meilleure distribution de l'année 2011. Évalué à 6.
Je relève quelques incohérences à propos de Fedora:
C'est du grand n'importe quoi, avec smolt, Fedora dispose de la plus grande base de données à ce sujet.
http://smolt.fedoraproject.org/
Par expérience, Fedora a plutôt un très bon support matériel comparé aux autres distributions binaires (côté distributions sources, Gentoo se défends bien dans ce domaine),
Sauf que le classement place Ubuntu devant Fedora alors que le paragraphe précédent expliquait que les communautés openSuSE et Fedora étaient nettement plus proactives à ce niveau. Soit on utilise la métrique nombre d'utilisateurs, soit la métrique activité mais on ne fait pas un classement basée sur la première en disant qu'on se fonde sur la seconde.
Pour le reste, le comparatif n'est pas très exhaustif (où sont passé Mandriva ? Gentoo ? Slackware ? etc...), un gros biais vis à vis de Debian/Ubuntu même si l'auteur essaie de corriger le tir mais on a vu plus trollesque dans la catégorie.
[^] # Re:
Posté par GeneralZod . En réponse au journal Debian: meilleure distribution de l'année 2011. Évalué à 3.
Fedora is not RedHat.
[^] # Re: 16 printemps ?
Posté par GeneralZod . En réponse à la dépêche Fedora devient une grande fille. Évalué à 4.
ça m'a bien fait marrer :]
Par contre, un vrai fedobear porterait une casquette blanche avec le logo fedora devant, le projet ayant explicitement banni la symbolique associé à RedHat (le fameux chapeau en feutre rouge et la couleur dominante rouge) pour distinguer les deux entités.
pour le reste, vous noterez mon silence ;)
[^] # Re: Politiquement correcte
Posté par GeneralZod . En réponse à la dépêche Fedora devient une grande fille. Évalué à 9.
Perso, ce qui m'a surpris c'est la rapidité de la validation, je l'ai même pas vu dans le pipe le jour même. C'est dommage d'avoir un éditeur collaboratif si on n'a même pas le temps de permettre aux autres membres de relire la dépêche (notamment pour la compléter).
Pour le reste, no comment.
[^] # Re: 16 printemps ?
Posté par GeneralZod . En réponse à la dépêche Fedora devient une grande fille. Évalué à 2.
majeure non, légale (du moins en France), oui.
[^] # Re: my 2 cts
Posté par GeneralZod . En réponse au message Mercurial bis. Évalué à 3.
L'inconvénient des branches "nommées" dans mercurial sont que le nom est inscrit dans les metadata des changesets qu'on se traine éternellement ce qui n'est pas pratique dans l'optique des branches à durée de vie très courtes.
C'est la principale différence entre les branches git et les branches mercurial, les commits git ne conservent aucune information de branches.
En revanche, mercurial a toujours supportés les branches type git via les "heads", sauf que les heads n'avaient pas de nom à l'origine et du coup, c'est très chiant pour changer de head. L'extension bookmark (désormais intégré dans le coeur de mercurial) a permis d'ajouter une étiquette à un head et d'avoir un équivalent total aux branches git.
C'est très pratique de pouvoir créer une branche pour expérimenter sans se soucier à priori de savoir si on réintegrera ou non nos expérimentations (et éventuellement se trainer des metadata inutiles ad vitam eternam - surtout quand on donne des noms très cons aux branches jetables -).
Dans le même ordre de considération, les mercurial queues permettent d'avoir une souplesse similaire (voire supérieure) mais ça n'est pas forcément du goût de tout le monde de gérer des patchs queues.
[^] # Re: un bon nom de librairie
Posté par GeneralZod . En réponse à la dépêche Fedora devient une grande fille. Évalué à 2.
SNMP ? Pas tout à fait, SNMP permet d'interroger des machines physiques mais ça reste très basique et relativement très faible niveau sécurité.
Matahari a été développé dans l'optique de gérer des infrastructures virtualisées (c'est ce qui est utilisé dans l'offre virtualisation, grille et cloud de Red Hat). Matahari repose sur le protocole QMF une extension du protocole normalisé AMQP (QMF permet de structurer le développement d'une infrastructure basé sur AMQP en ajoutant la notion d'agent et d'objet + introspection)
[^] # Re: y fait frisquet ce matin
Posté par GeneralZod . En réponse à la dépêche Nouvel installateur pour ArchLinux. Évalué à 4.
libvirt/virsh/virt-manager supportent tout aussi bien xen que kvm.
# commentaires
Posté par GeneralZod . En réponse à la dépêche Le standard C++0x a enfin été voté. Évalué à 6.
Bonne news dans l'ensemble, j'en profite pour rajouter mon grain de sel :o)
On peut également signaler un constructeur par défaut et même demander au compilateur de ne pas générer certaines fonctions membres (très pratique, pour interdire la copie par exemple)
> On peut quand même regretter l'absence de sémaphore dans la spécification.
À l'origine, boost::thread (dont s'inspire cette spécification) proposait un type semaphore mais il a été retiré parce qu'il était source d'erreurs (pas de notion de lock, inversion de priorité). La solution recommandée c'est d'utiliser un mutex + une condition, même si dans certains cas, ça ne convient pas (gestion de signaux posix entre autres).
Derrière, std::thread propose la plupart des facilités des threads Posix (mutex, condition, barrière, R/W locks, etc...) en plus sûr mais également les futures. D'ailleurs, le langage gagne le mot clé thread_local pour signaler les variables TLS.
Je tiens à souligner que l'implémentation de référence (aka boost::regex de John Maddock) est particulièrement performante (et bénéficie énormément des templates), et offre bon nombre des facilités des expressions régulières compatibles Perl, ainsi qu'un header de compatibilité avec l'API Posix.
Je trouve dommage qu'on ne mentionne pas la grosse nouveauté (depuis l'abandon des concepts pour ce round) de la norme mais également la plus complexe à appréhender: la sémantique move qui permet d'économiser certains copies inutiles mais impossible à éviter de par le langage. Les utilisateurs peuvent ainsi bénéficier de façon transparente de cette optimisation à travers la bibliothèque standard si celle-ci a été adaptée en conséquence (mais leur code peut également en bénéficier à condition d'écrire un constructeur et un opérateur move adéquats)
Bjarne stroustrup l'expliquera certainement beaucoup mieux que moi:
http://www2.research.att.com/~bs/C++0xFAQ.html#rval
Certes, ça complexifie le langage mais c'est un exemple typique de ce qui fait l'attrait du C++: un langage extrêmement souple, performant et robuste.
# my 2 cts
Posté par GeneralZod . En réponse au message Mercurial bis. Évalué à 2.
# Commence par lire la documentation ou le retour de RTFM
Posté par GeneralZod . En réponse au message Compiler VLC avec l'encodage MPEG2. Évalué à 2.
https://wiki.ubuntu.com/ffmpeg
http://doc.ubuntu-fr.org/ffmpeg
# rm -rf /usr
Posté par GeneralZod . En réponse au message optimus et bumblebee. Évalué à 1.
ça te fera gagner du temps ;)
https://github.com/MrMEEE/bumblebee/commit/a047be85247755cdbe0acce6#diff-1
PS: si tu es nouveau, ne tapes surtout pas la commande contenue dans le titre - trolldi inside -
[^] # Re: À se demander…
Posté par GeneralZod . En réponse au journal Verne privé de système de fichiers au beurre. Évalué à 8.
Lis cet article http://lwn.net/Articles/342892/
Quant à la pérennité du projet, btrfs a été désigné comme étant le successeur d'ext4 (il n'y aura pas d'ext5), certes Oracle reste le premier contributeur au projet, mais ils sont talonnés par Redhat (Josef Bacik bosse uniquement sur btrfs depuis quelques années), Novell, Canonical participent également à l'effort.
Sauf que Btrfs de l'aveu de Valerie Aurora (qui a bossé sur ZFS chez Sun) a une architecture plus efficace que ZFS notamment du fait que ZFS est antérieur aux travaux d'Ohad Rodeh sur B-Tree.
C'est pas encore trolldi
[^] # Re: Moins de gnu, plus de pas BSD.
Posté par GeneralZod . En réponse à la dépêche FreeBSD 9 pointe le bout du nez. Évalué à 3.
La licence LLVM est une dérivée de la BSD, tu as des bouts sous licence MIT (entre autre la bibliothèque C++ standard et le runtime du compilo), seul le déprécié llvm-gcc est sous licence GPL
http://llvm.org/docs/DeveloperPolicy.html#license
[^] # Re: Question existentielle
Posté par GeneralZod . En réponse au journal Emacs sapusaipalibre. Évalué à 1.
Sauf que ce sont les auteurs de CEDET qui ont oubliés de fournir les grammaires, donc la FSF pourrait porter plainte pour violation de la GPL parce que CEDET n'a pas distribué les sources.
# ESR doit se retourner dans sa tombe !
Posté par GeneralZod . En réponse au journal Emacs sapusaipalibre. Évalué à 10.
Nope, c'est des fichiers sources générées par bison, certes, ça n'est pas GPL-compliant (si tes fichiers sources sont générés à partir d'autres sources -en l'occurence, les grammaires bison-, il faut également les fournir), mais ça démontre que l'auteur a baclé son travail de troll et n'a aucun respect pour ce saint jour de trolldi que nous devons aux illustres ancêtres de usenet.
[^] # Re: Btrfs
Posté par GeneralZod . En réponse à la dépêche Le noyau Linux est disponible en version 3.0. Évalué à 4.
ZFS est sous licence CDDL, ça n'a pas empêché FreeBSD de fournir le support de ZFS en réutilisant le code d'OpenSolaris (sous forme d'un module noyau), rien n'empêcherait les *BSD de fournir le support de Btrfs sous forme d'un module noyau (pour respecter le sacro-saint principe que le système de base est 100% BSD, hein, dans l'absolu, rien n'interdit de fournir un noyau BSD avec le support de Btrfs en statique).
Au passage, la CDDL (qui n'est qu'une vilaine MPL maquillée par feu Sun) n'est pas plus BSD-friendly que la GPL.