Je pense que misc a parfaitement expliqué ce point-ci. Malgré les outils, malgré la bonne volonté, il reste encore la question épineuse du management (comme quoi, les p'tits chefs hexagonaux n'ont pas le monopole de la vision courte)
On te dit qu'on va faire mieux que Wayland qui a bientôt 5 ans d'existence et le soutien de l'ensemble de l'industrie ! Ils sont tellement forts qu'ils le feront avec 2x moins de lignes de code !
Pas un problème, Wayland n'a jamais été un projet RH y compris lorsque Kristian bossait chez RH (il est actuellement chez Intel)
historiquement parlant Canonical s'est toujours fait rejeter toute ses propositions de changement
T'as des preuves de ce que t'avances ? c'est bizarre que des tas d'autres boites y compris concurrentes de RH n'ont aucun soucis à collaborer pour GNOME.
En revanche, Canonical adore lancer des projets dans son coin et balancer des patchs mal branlés sans vraiment dialoguer avec upstream pour les intégrer proprement. Le problème, il se situe au niveau du management de Canonical plutôt qui ne laisse aucune place à la collaboration upstream.
RH commence a avoir la sale habitude de forcer ses propres technos sans aucune concertation, PA, systemd pour ne pas les nommer, et sans bosser avec les autres distribs AVANT leur inclusion quasi definitive
Foutaises, PA a été développé pendant des années pour être le remplaçant d'esound avant intégration. La seule distro qui a foiré son intégration de PA est la seule à l'avoir fait sans concertation avec upstream (qui lui aurait conseillé d'attendre une release non-LTS et aidé à corriger des problèmes évidents de packaging), je te laisse deviner laquelle …
Quant à systemd, il a été développé dès le premier jour avec des développeurs d'autres distros (le co-leader Kay Sievers bossait à l'époque chez SUSE).
aujourd'hui avec l'inclusion de udev dans systemd sans tenir compte de toutes les autres distributions qui ne sont pas passe a ce truc
Non, libre à eux de maintenir udev tel quel, d'ailleurs c'est ce qu'ils ont fait.
Sans compter le fait que les bindings Python sont pas toujours très pythonnique et sont même redondantes parfois avec les piles incluses (PyQt a eu le même problème, l'API v2 a pas mal amélioré les choses par contre). Mettre Python en avant, aurait demandé de passer plus de temps à peaufiner l'API et n'aurait pas rempli le critère essentiel "abaisser le niveau du ticket d'entrée" dans GNOME.
Aujourd'hui, GNOME a beaucoup de mal à recruter de nouveaux développeurs, il est plus simple de recruter des développeurs javascript que C, Python & cie, sans compter que javascript est déjà au coeur du Shell.
systemd s'appuie sur des APIs spécifiques au noyau Linux (cgroups, signalfd, timerfd, fanotify etc…)
Ça n'a jamais posé problème que l'ensemble des fonctionnalités proposés par systemd ne soit pas portable car c'est déjà le cas en pratique !
Ce qui dérange certains, c'est la dépendance à l'API systemd par les bureaux, compréhensible du fait qu'historiquement, ces API étaient mal documentées donc difficilement réimplémentable et pensées linux-only (alsa, udev etc..).
Néanmoins, systemd a l'avantage par rapport à ses prédécesseurs d'être extrêmement bien documenté, d'avoir stabilisé son API externe (qui peut être réimplémenté indépendemment de systemd). Il y a même un tableau résumant la stabilité et la portabilité des différentes API de systemd
Il y a très clairement un terrain d'entente possible, sachant qu'au final, ce que demande les communautés BSD et Linux/systemd sont au final assez proches. La difficulté est surtout d'arriver à trouver un processus pour formaliser ces APIs externes (qui au final simplifie la maintenance des projets).
Moi, ce qui m'a impressionné c'est que systemd qui s'appuie à fond sur cgroups est passé à la vitesse supérieure en intégrant les LinuX Containers. On peut déjà limiter les ressources à un ensemble de processus créés par un service systemd très finement (essayer de le faire avec sysvinit …, lors de la conférence, Lennart a donné le très bon exemple d'apache/php/mysql), mais on pourra à l'avenir confiner un processus.
[1] je précise que la liste des features pour F19 est encore en cours de discussion, et que celles-ci n'ont pas encore été approuvées même si il y a de fortes chances qu'elles soient acceptées. https://fedoraproject.org/wiki/Releases/19/FeatureList
Vincent Untz l'a évoqué dans sa conférence, il est acquis que systemd sera une dépendance de GNOME uniquement pour les fonctionnalités non essentielles au bon fonctionnement de GNOME.
1. tu as systemd, tu as la full GNOME experience
2. tu n'as pas systemd, certaines fonctionnalités secondaires seront désactivées. La plupart repose sur du code non maintenu, et le projet GNOME acceptera tout patch pour les rétablir (y compris basé sur le code précédemment viré)
La réalité est que 99.5% des contributeurs GNOME sont sous Linux, le problème est qu'il y a un manque cruel de développeurs sous les plateformes moins favorisées comme les *BSD. La question se poserait tôt ou tard.
J'étais présent à la conférence (et même eu l'occasion de papoter avec lui et Kay), et je vous conseille de regarder la vidéo parce qu'il explique très clairement son point de vue. L'idée est que bon nombre de ces utilitaires (du moins ceux qui interagissent avec le noyau) ont pas mal de code dupliqué, sont très petits et mal maintenu. L'idée est de centraliser le développement de ses utilitaires en un endroit pour avoir un ensemble cohérent (et non pas monolithique Cf. mon dernier nourjal). Il a même souligné que c'était la pratique BSD (tout ce qui a trait à l'OS est développé dans le même gestionnaire de sources), bien que ça ne soit guère possible de le faire avec Linux qui propose différentes surcouches.
systemd est avant un framework pour construire l'ensemble des utilitaires nécessaires pour former un système d'exploitation cohérent avec le noyau Linux, il n'impose pas le remplacement des composants précédemment cités, vous pouvez les utilisez en // de systemd, vous ne bénéficierez pas des avancées fournies par le projet.
Ceux qui ont été présent à la conférence de Vincent Untz sur GNOME, on même pu entendre Bastien Nocera expliquait comment le passage à systemd a pu résoudre certains bugs complexes liés au matériel et virer du code non maintenu (je précise: systemd n'est pas un composant obligatoire pour utiliser GNOME, certaines fonctionnalités annexes ne sont plus accessibles tout simplement). Contribution accepted.
La conférence était claire, limpide et s'est très bien passé malgré un public pas forcément acquis (je m'attendais même à un clash qui n'a pas eu lieu)
J'ai un serveur d'intégration continue pour ça (environnements neutres avec différentes configurations) et je nuance mes propos précédents: j'utilise et teste avec g++ régulièrement (ne serait-ce que pour le packaging).
Néanmoins, un compilo qui consomme moins de ressources, plus rapide, et qui offre un meilleur reporting (sans oublier l'analyseur statique pour le C), ça apporte un gain appréciable à mon workflow personnel.
Pourquoi ce langage reste aussi peu utilisé? Pas assez de bibliothèques, l'habitude, autre chose?
C'est très difficile pour un nouveau langage de programmation généraliste de s'imposer dans un marché somme toute fortement concurrentiel sans appuis industriels. Et surtout le manque de compétences (même si Andrei Alexandrescu fait du très bon boulot d'évangélisation), D n'est pas un langage qu'on enseigne ou promeut auprès des développeurs.
Les bibliothèques actuellement disponibles permettent de faire pas mal de choses, déjà.
Je ne suis pas certain que C++11 ait encore un véritable impact (aucun compilateur n'implémente 100% de la norme: http://wiki.apache.org/stdcxx/C%2B%2B0xCompilerSupport), par ailleurs, c++11 simplifie beaucoup de choses, ça reste un langage expert-friendly (expliquer les R-values références au développeur C++ lambda est un exercice acrobatique)
Je viens de découvrir DragonEgg, question: est-ce que les optimisations apportées valent le coup?
non, gcc est bien meilleur pour optimiser le code, même si il consomme plus de mémoire et est bcp plus lent lors de la phase de compilation
dragonegg commence à être utilisable en production mais depuis que clang++ supporte c++98 en production (et un excellent support de C++11), il est beaucoup moins intéressant, d'autant plus que clang est très bon pour la partie reporting d'erreurs.
Mon setup actuel est g++ pour le code en production, clang++ pour le développement
Gnome est soutenu par Redhat car Redhat n'aime pas Qt.
Tu m'expliqueras pourquoi Red Hat emploie plusieurs développeurs KDE pour développer (et maintenir dans Fedora) KDE depuis plusieurs années. C'est un fait que Red Hat investit énormément dans GNOME pour des raisons historiques entre autre (la licence de Qt n'était pas libre à l'époque) et qu'ils vont pas s'amuser à changer de fusil d'épaule.
Voir de l'affect là où il n'y a que de la logique c'est du troll de petites classes.
Le plus pathétique est arrivé avec ces projets où certains développeurs Gnome se contentent de labelliser une techno dans leur coin en la déclarant spécification Freedesktop sans se préoccuper une seconde de l'interopérabilité.
one word: indicators …
La fameuse spécification faite dans un coin par Canonical et KDE et labellisé FD.o sans discussion publique… Bref, c'est loin d'être les méchants contre les gentils. La plupart du temps quand les KDEistes se plaignent que les méchants GNOMers leur impose une techno GNOME, c'est souvent qu'il y a eu une discussion sur fd.o et que la première implémentation incorpore la GLib et que ça les fait chier parce que KDE a pas toujours le manpower pour le réimplémenter à leur convenance.
Les pages features ne sont pas toujours à jour, mais je confirme que c'est bien la faute des développeurs d'Anaconda que F18 a accumulé autant de retard.
Ils n'ont pas prévu de retour en arrière si le nouveau Anaconda n'était pas prêt et ont menés tout le monde en bateau jusqu'à la béta qui est sensé valider l'installeur entre autre. On a rarement eu une (pré-)béta aussi stable …
F19 sera probablement une release double à ce rythme-là.
Pas très dur, il est en train de dire que la syntaxe ne lui plait pas…
La syntaxe d'IPtables est juste imbitable mais ce n'est pas la seule raison.
IPtables ne permet pas de modifier une règle dynamiquement (même si ipset comble partiellement ce besoin aujourd'hui), le traitement des paquets est particulièrement complexe alors qu'avec PF ça revient à faire passer le paquet à travers les règles listés dans la conf de manière linéaire.
Faire du NAT, de la limitation de bande passante, c'est beaucoup plus simple avec PF qu'avec IPtables.
C'est uniquement mon point de vue en tant que sysadmin bénévole, je n'ai aucunement la prétention de comparer les perfs ou les fonctionnalités entre les deux solutions.
Je ne m'attendais pas à une réponse aussi étoffée mais ça valait le coup d'attendre !
Je comprends beaucoup mieux ton point de vue même si je ne partage pas la conclusion finale (mais ça ne m'empêche pas de te pertinenter).
Plus haut, je parle du process C4 qui conduit le projet zeromq et je pense que c'est en bonne partie la source de tes mésaventures (et la raison du fork cité ci-dessus). Il est difficile dans un projet avec une gouvernance aussi ouverte d'avoir un vision à moyen et long terme cohérente mais également de s'assurer de la qualité du code.
À titre professionnel, même si zeromq n'est pas parfait, il a l'intérêt d'avoir une communauté active et de répondre à mon besoin: construire des applications distribuées (parfois polyglottes) et qui passent à l'échelle et tolérante aux fautes.
Pour info, les alternatives possibles étaient de loin pires encore -je précise dans mon contexte-: CORBA (mwhahahaha !), ZeroC ICE (git fermé, forum pour échanger des patchs qui s'accumulent, horrible à packager), Thrift (pétage régulier, horrible à packager), AMQP (RabbitMQ est intéressant mais packager toute la stack Erlang sur les Unix commerciaux ne m'emballait pas et toujours le problème du SPOF malgré le support des fédérations), etc …
Le fork est surtout dû à des divergences au niveau de la gouvernance du projet: Pieter Hintjens (aussi l'ancien employeur de Sustrik) veut un projet le plus ouvert possible [1], Sustrik et Lucina les principaux développeurs veulent une gouvernance plus restrictive [2].
Le plus marrant, c'est que Hintjens voulait au départ que zeromq soit écrit en C, mais que Sustrik et les autres développeurs d'iMatix avaient insistés pour utiliser C++. L'annonce de Sustrik de tout réécrire en C a été l'occasion d'un joli échange de piques :o)
[1] http://rfc.zeromq.org/spec:16 Le Contrat de Construction Collective de Code aka C4 résume bien le modèle basé sur les pull requests de github (et non git, Cf. la râlerie de Linus sur les pull requests de github)
[2] Aucun jugement de valeur, les deux modèles ont leurs avantages et inconvénients et les relations entre les projets sont amicales. En tant que hacktiviste, je trouve très intéressant le modèle C4 et pour le moment ça a l'air de fonctionner malgré le départ du principal développeur.
L'auteur a fait des choses très bien et publie dans un média impressionnant par ses connotations scientifiques, mais à part les anecdotes historiques qui sont toujours enrichissantes ça reste une râlerie moyenne d'un utilisateur aigri.
c'est une description assez réaliste des lutins. :o)
Si on mets de côté le côté polémique du nom, examinons le descriptif.
Linux Lite is based on Ubuntu 12.04 LTS with 5 years support. The following software included: GParted, LibreOffice Writer, LibreOffice Calc, XFBurn CD/DVD Burner, VLC Media Player, Firefox Web Browser with Flash, OpenJDK Java v6, Mumble Voice Chat, Thunderbird Email, XChat IRC Client, Gimp Image Editor, Leafpad Text Editor, Xarchiver.
ça commence bien, c'est basé sur Ubuntu qui est loin d'être une distro light
pour le bureau, on utilise XFCE -c'est plus cohérent déjà- mais dans les screenshots c'est LXTerminal ???
LibreOffice Writer/Calc, Abiword/Gnumeric, ils connaissent ?
Firefox mais avec Flash, certes beaucoup de distros ne respectent pas le choix par défaut des DE à ce niveaux, mais Midori choisis par XFCE me semblait cohérent avec le "Lite" de Linux Lite. Quant à Flash, WTF ?
OpenJDK Java6 c'est une blague ? Qui a besoin de Java de nos jours sur une machine desktop ?
Mumble, ça dépends de ZeroC ICE et Qt (hein, le bureau c'est XFCE, je rappelle), c'est un truc bien "Light" ça encore. Ça pue le puceau de 12 ans qui se branle la nouille en jouant aux meuporgs.
Thunderbird, sigh XFCE recommande Claws Mail
Gimp dans une distro desktop Lite, bof
Je propose de renommer Linux Lite en Linux Over Lite, Linux teh LOL way !
L'opinion actuelle est que GCC 4.7 risque de rester dans la base pour un moment, même si clang pourrait y être introduit, notamment car il est le dernier GCC qui ne nécessite pas C++.
Y a un truc que je pige pas, DragonFlyBSD envisage de passer à clang/llvm uniquement parce que GCC >= 4.8.x sera (partiellement) réécrit en C++ (enfin un sous-ensemble) ?
Le truc c'est que clang/llvm c'est écrit en C++, donc ça me semble un peu léger comme argumentaire.
FreeBSD a longtemps été bloqué à GCC 4.2.x parce que c'était la dernière version non GPLv3 (jugée incompatible avec les valeurs du projet FreeBSD), ça et l'idée d'avoir une chaine de compilation 100% sous licence BSD constituait une bonne raison de switcher.
[^] # Re: Discussion entre un dev MIR et les dev Wayland
Posté par GeneralZod . En réponse au journal Mir, un serveur d'affichage de trop ?. Évalué à 2.
Je pense que misc a parfaitement expliqué ce point-ci. Malgré les outils, malgré la bonne volonté, il reste encore la question épineuse du management (comme quoi, les p'tits chefs hexagonaux n'ont pas le monopole de la vision courte)
PS: merci pour l'édition !
[^] # Re: Differences ?
Posté par GeneralZod . En réponse au journal Canonical: les fouteurs de merde, le retour. Évalué à 2. Dernière modification le 05 mars 2013 à 20:53.
On te dit qu'on va faire mieux que Wayland qui a bientôt 5 ans d'existence et le soutien de l'ensemble de l'industrie ! Ils sont tellement forts qu'ils le feront avec 2x moins de lignes de code !
[^] # Re: Discussion entre un dev MIR et les dev Wayland
Posté par GeneralZod . En réponse au journal Mir, un serveur d'affichage de trop ?. Évalué à 9. Dernière modification le 05 mars 2013 à 21:32.
Pas un problème, Wayland n'a jamais été un projet RH y compris lorsque Kristian bossait chez RH (il est actuellement chez Intel)
T'as des preuves de ce que t'avances ? c'est bizarre que des tas d'autres boites y compris concurrentes de RH n'ont aucun soucis à collaborer pour GNOME.
En revanche, Canonical adore lancer des projets dans son coin et balancer des patchs mal branlés sans vraiment dialoguer avec upstream pour les intégrer proprement. Le problème, il se situe au niveau du management de Canonical plutôt qui ne laisse aucune place à la collaboration upstream.
Foutaises, PA a été développé pendant des années pour être le remplaçant d'esound avant intégration. La seule distro qui a foiré son intégration de PA est la seule à l'avoir fait sans concertation avec upstream (qui lui aurait conseillé d'attendre une release non-LTS et aidé à corriger des problèmes évidents de packaging), je te laisse deviner laquelle …
Quant à systemd, il a été développé dès le premier jour avec des développeurs d'autres distros (le co-leader Kay Sievers bossait à l'époque chez SUSE).
Non, libre à eux de maintenir udev tel quel, d'ailleurs c'est ce qu'ils ont fait.
[^] # Re: QML bis?
Posté par GeneralZod . En réponse à la dépêche Javascript comme langage par défaut pour GNOME. Évalué à 3.
Sans compter le fait que les bindings Python sont pas toujours très pythonnique et sont même redondantes parfois avec les piles incluses (PyQt a eu le même problème, l'API v2 a pas mal amélioré les choses par contre). Mettre Python en avant, aurait demandé de passer plus de temps à peaufiner l'API et n'aurait pas rempli le critère essentiel "abaisser le niveau du ticket d'entrée" dans GNOME.
Aujourd'hui, GNOME a beaucoup de mal à recruter de nouveaux développeurs, il est plus simple de recruter des développeurs javascript que C, Python & cie, sans compter que javascript est déjà au coeur du Shell.
[^] # Re: Kernels compatible ?
Posté par GeneralZod . En réponse au journal Systemd dans Debian. Évalué à 10.
systemd s'appuie sur des APIs spécifiques au noyau Linux (cgroups, signalfd, timerfd, fanotify etc…)
Ça n'a jamais posé problème que l'ensemble des fonctionnalités proposés par systemd ne soit pas portable car c'est déjà le cas en pratique !
Ce qui dérange certains, c'est la dépendance à l'API systemd par les bureaux, compréhensible du fait qu'historiquement, ces API étaient mal documentées donc difficilement réimplémentable et pensées linux-only (alsa, udev etc..).
Néanmoins, systemd a l'avantage par rapport à ses prédécesseurs d'être extrêmement bien documenté, d'avoir stabilisé son API externe (qui peut être réimplémenté indépendemment de systemd). Il y a même un tableau résumant la stabilité et la portabilité des différentes API de systemd
Il y a très clairement un terrain d'entente possible, sachant qu'au final, ce que demande les communautés BSD et Linux/systemd sont au final assez proches. La difficulté est surtout d'arriver à trouver un processus pour formaliser ces APIs externes (qui au final simplifie la maintenance des projets).
# Intégration de LXC
Posté par GeneralZod . En réponse au journal Systemd dans Debian. Évalué à 10.
Moi, ce qui m'a impressionné c'est que systemd qui s'appuie à fond sur cgroups est passé à la vitesse supérieure en intégrant les LinuX Containers. On peut déjà limiter les ressources à un ensemble de processus créés par un service systemd très finement (essayer de le faire avec sysvinit …, lors de la conférence, Lennart a donné le très bon exemple d'apache/php/mysql), mais on pourra à l'avenir confiner un processus.
Une feature F19 consiste à poursuivre l'effort sur systemd-nspawn (qui permet de lancer un conteneur LXC) afin d'arriver à avoir l'équivalent des zones Solaris à terme. Les conteneurs serait même activable via socket, on envisage même d'utiliser ça pour faire des clouds haute-densité (autre feature F19 dont l'implémentation dépendra de l'avancée de celle-ci) [1]
https://fedoraproject.org/wiki/Features/SystemdLightweightContainers
https://fedoraproject.org/wiki/Features/High_Availability_Container_Resources
[1] je précise que la liste des features pour F19 est encore en cours de discussion, et que celles-ci n'ont pas encore été approuvées même si il y a de fortes chances qu'elles soient acceptées.
https://fedoraproject.org/wiki/Releases/19/FeatureList
[^] # Re: Gnome dans debian
Posté par GeneralZod . En réponse au journal Systemd dans Debian. Évalué à 5.
Vincent Untz l'a évoqué dans sa conférence, il est acquis que systemd sera une dépendance de GNOME uniquement pour les fonctionnalités non essentielles au bon fonctionnement de GNOME.
1. tu as systemd, tu as la full GNOME experience
2. tu n'as pas systemd, certaines fonctionnalités secondaires seront désactivées. La plupart repose sur du code non maintenu, et le projet GNOME acceptera tout patch pour les rétablir (y compris basé sur le code précédemment viré)
La réalité est que 99.5% des contributeurs GNOME sont sous Linux, le problème est qu'il y a un manque cruel de développeurs sous les plateformes moins favorisées comme les *BSD. La question se poserait tôt ou tard.
[^] # Re: Mauvaise interprétation
Posté par GeneralZod . En réponse au journal Systemd dans Debian. Évalué à 10.
J'étais présent à la conférence (et même eu l'occasion de papoter avec lui et Kay), et je vous conseille de regarder la vidéo parce qu'il explique très clairement son point de vue. L'idée est que bon nombre de ces utilitaires (du moins ceux qui interagissent avec le noyau) ont pas mal de code dupliqué, sont très petits et mal maintenu. L'idée est de centraliser le développement de ses utilitaires en un endroit pour avoir un ensemble cohérent (et non pas monolithique Cf. mon dernier nourjal). Il a même souligné que c'était la pratique BSD (tout ce qui a trait à l'OS est développé dans le même gestionnaire de sources), bien que ça ne soit guère possible de le faire avec Linux qui propose différentes surcouches.
systemd est avant un framework pour construire l'ensemble des utilitaires nécessaires pour former un système d'exploitation cohérent avec le noyau Linux, il n'impose pas le remplacement des composants précédemment cités, vous pouvez les utilisez en // de systemd, vous ne bénéficierez pas des avancées fournies par le projet.
Ceux qui ont été présent à la conférence de Vincent Untz sur GNOME, on même pu entendre Bastien Nocera expliquait comment le passage à systemd a pu résoudre certains bugs complexes liés au matériel et virer du code non maintenu (je précise: systemd n'est pas un composant obligatoire pour utiliser GNOME, certaines fonctionnalités annexes ne sont plus accessibles tout simplement). Contribution accepted.
La conférence était claire, limpide et s'est très bien passé malgré un public pas forcément acquis (je m'attendais même à un clash qui n'a pas eu lieu)
[^] # Re: Mauvaise interprétation
Posté par GeneralZod . En réponse au journal Systemd dans Debian. Évalué à 2.
Euh, suffit juste de jouer avec ton éditeur de texte et d'un lien symbolique (ou pas si t'es crade) pour activer une unité systemd (timer ou autre)
[^] # Re: Ça m'apprend des choses
Posté par GeneralZod . En réponse à la dépêche Sortie de Fedora 18 alias Spherical Cow. Évalué à 6.
J'ai un serveur d'intégration continue pour ça (environnements neutres avec différentes configurations) et je nuance mes propos précédents: j'utilise et teste avec g++ régulièrement (ne serait-ce que pour le packaging).
Néanmoins, un compilo qui consomme moins de ressources, plus rapide, et qui offre un meilleur reporting (sans oublier l'analyseur statique pour le C), ça apporte un gain appréciable à mon workflow personnel.
[^] # Re: Ça m'apprend des choses
Posté par GeneralZod . En réponse à la dépêche Sortie de Fedora 18 alias Spherical Cow. Évalué à 6.
C'est très difficile pour un nouveau langage de programmation généraliste de s'imposer dans un marché somme toute fortement concurrentiel sans appuis industriels. Et surtout le manque de compétences (même si Andrei Alexandrescu fait du très bon boulot d'évangélisation), D n'est pas un langage qu'on enseigne ou promeut auprès des développeurs.
Les bibliothèques actuellement disponibles permettent de faire pas mal de choses, déjà.
Je ne suis pas certain que C++11 ait encore un véritable impact (aucun compilateur n'implémente 100% de la norme: http://wiki.apache.org/stdcxx/C%2B%2B0xCompilerSupport), par ailleurs, c++11 simplifie beaucoup de choses, ça reste un langage expert-friendly (expliquer les R-values références au développeur C++ lambda est un exercice acrobatique)
non, gcc est bien meilleur pour optimiser le code, même si il consomme plus de mémoire et est bcp plus lent lors de la phase de compilation
dragonegg commence à être utilisable en production mais depuis que clang++ supporte c++98 en production (et un excellent support de C++11), il est beaucoup moins intéressant, d'autant plus que clang est très bon pour la partie reporting d'erreurs.
Mon setup actuel est g++ pour le code en production, clang++ pour le développement
[^] # Re: Le succès c'est maintenant
Posté par GeneralZod . En réponse au journal Vous avez demandé le Desktop, ne quittez pas. Évalué à 2.
ça existe déjà (FOSS depuis peu) et Angry Birds tourne pas trop mal dessus ;)
http://androvm.org/blog/
[^] # Re: Typo.
Posté par GeneralZod . En réponse au journal Comment Freedesktop divise le desktop. . Évalué à 2.
Gtk+ est déjà indépendant de GNOME, il y a tout un écosystéme industrielle qui vit autour de Gtk+.
[^] # Re: Typo.
Posté par GeneralZod . En réponse au journal Comment Freedesktop divise le desktop. . Évalué à 3.
Avant GNOME 3, c'était: "Est-ce que KDE4 est pertinent?" <= la même réponse s'applique tout autant à GNOME3
[^] # Re: lapin compris
Posté par GeneralZod . En réponse au journal Comment Freedesktop divise le desktop. . Évalué à 0.
Voir de l'affect là où il n'y a que de la logique c'est du troll de petites classes.
[^] # Re: Je plussoie
Posté par GeneralZod . En réponse au journal Comment Freedesktop divise le desktop. . Évalué à -2.
one word: indicators …
La fameuse spécification faite dans un coin par Canonical et KDE et labellisé FD.o sans discussion publique… Bref, c'est loin d'être les méchants contre les gentils. La plupart du temps quand les KDEistes se plaignent que les méchants GNOMers leur impose une techno GNOME, c'est souvent qu'il y a eu une discussion sur fd.o et que la première implémentation incorpore la GLib et que ça les fait chier parce que KDE a pas toujours le manpower pour le réimplémenter à leur convenance.
[^] # Re: Nouvelle expérimentation ?
Posté par GeneralZod . En réponse à la dépêche Retard++ de Fedora 18 et nom de code quantique pour la version 19. Évalué à 3.
[^] # Re: Le vendredi c'est permis
Posté par GeneralZod . En réponse à la dépêche Retard++ de Fedora 18 et nom de code quantique pour la version 19. Évalué à 7.
Les pages features ne sont pas toujours à jour, mais je confirme que c'est bien la faute des développeurs d'Anaconda que F18 a accumulé autant de retard.
Ils n'ont pas prévu de retour en arrière si le nouveau Anaconda n'était pas prêt et ont menés tout le monde en bateau jusqu'à la béta qui est sensé valider l'installeur entre autre. On a rarement eu une (pré-)béta aussi stable …
F19 sera probablement une release double à ce rythme-là.
[^] # Re: Œil de Moscou
Posté par GeneralZod . En réponse à la dépêche Le Parti de Gauche publie le code de son site sous licence libre. Évalué à 3.
Le parti de gauche c'est des communistes, forcément ils ne pouvaient que choisir Ruby qui est déjà aux couleurs de la RAIEVOLUTION !
[^] # Re: pam_systemd
Posté par GeneralZod . En réponse au journal Non, systemd n'est vraiment pas parfait ! (ni prêt). Évalué à 4.
La syntaxe d'IPtables est juste imbitable mais ce n'est pas la seule raison.
IPtables ne permet pas de modifier une règle dynamiquement (même si ipset comble partiellement ce besoin aujourd'hui), le traitement des paquets est particulièrement complexe alors qu'avec PF ça revient à faire passer le paquet à travers les règles listés dans la conf de manière linéaire.
Faire du NAT, de la limitation de bande passante, c'est beaucoup plus simple avec PF qu'avec IPtables.
C'est uniquement mon point de vue en tant que sysadmin bénévole, je n'ai aucunement la prétention de comparer les perfs ou les fonctionnalités entre les deux solutions.
# Merci de ta réponse construite et argumentée
Posté par GeneralZod . En réponse au journal ZeroMQ et les mangoustes. Évalué à 5.
Je ne m'attendais pas à une réponse aussi étoffée mais ça valait le coup d'attendre !
Je comprends beaucoup mieux ton point de vue même si je ne partage pas la conclusion finale (mais ça ne m'empêche pas de te pertinenter).
Plus haut, je parle du process C4 qui conduit le projet zeromq et je pense que c'est en bonne partie la source de tes mésaventures (et la raison du fork cité ci-dessus). Il est difficile dans un projet avec une gouvernance aussi ouverte d'avoir un vision à moyen et long terme cohérente mais également de s'assurer de la qualité du code.
À titre professionnel, même si zeromq n'est pas parfait, il a l'intérêt d'avoir une communauté active et de répondre à mon besoin: construire des applications distribuées (parfois polyglottes) et qui passent à l'échelle et tolérante aux fautes.
Pour info, les alternatives possibles étaient de loin pires encore -je précise dans mon contexte-: CORBA (mwhahahaha !), ZeroC ICE (git fermé, forum pour échanger des patchs qui s'accumulent, horrible à packager), Thrift (pétage régulier, horrible à packager), AMQP (RabbitMQ est intéressant mais packager toute la stack Erlang sur les Unix commerciaux ne m'emballait pas et toujours le problème du SPOF malgré le support des fédérations), etc …
[^] # Re: M'enfin !
Posté par GeneralZod . En réponse au journal ZeroMQ et les mangoustes. Évalué à 6.
Le fork est surtout dû à des divergences au niveau de la gouvernance du projet: Pieter Hintjens (aussi l'ancien employeur de Sustrik) veut un projet le plus ouvert possible [1], Sustrik et Lucina les principaux développeurs veulent une gouvernance plus restrictive [2].
Le plus marrant, c'est que Hintjens voulait au départ que zeromq soit écrit en C, mais que Sustrik et les autres développeurs d'iMatix avaient insistés pour utiliser C++. L'annonce de Sustrik de tout réécrire en C a été l'occasion d'un joli échange de piques :o)
[1] http://rfc.zeromq.org/spec:16 Le Contrat de Construction Collective de Code aka C4 résume bien le modèle basé sur les pull requests de github (et non git, Cf. la râlerie de Linus sur les pull requests de github)
[2] Aucun jugement de valeur, les deux modèles ont leurs avantages et inconvénients et les relations entre les projets sont amicales. En tant que hacktiviste, je trouve très intéressant le modèle C4 et pour le moment ça a l'air de fonctionner malgré le départ du principal développeur.
[^] # Re: Inepties
Posté par GeneralZod . En réponse à la dépêche « Une génération perdue dans le bazar ». Évalué à 4. Dernière modification le 10 novembre 2012 à 03:13.
c'est une description assez réaliste des lutins. :o)
# LOL
Posté par GeneralZod . En réponse au journal Linux Lite : comme des connards.. Évalué à 1.
Si on mets de côté le côté polémique du nom, examinons le descriptif.
Je propose de renommer Linux Lite en Linux Over Lite, Linux teh LOL way !
# Quelqu'un pourrait m'expliquer ?
Posté par GeneralZod . En réponse à la dépêche DragonFlyBSD 3.2, la libellule s’envole toujours plus haut. Évalué à 6.
Y a un truc que je pige pas, DragonFlyBSD envisage de passer à clang/llvm uniquement parce que GCC >= 4.8.x sera (partiellement) réécrit en C++ (enfin un sous-ensemble) ?
Le truc c'est que clang/llvm c'est écrit en C++, donc ça me semble un peu léger comme argumentaire.
FreeBSD a longtemps été bloqué à GCC 4.2.x parce que c'était la dernière version non GPLv3 (jugée incompatible avec les valeurs du projet FreeBSD), ça et l'idée d'avoir une chaine de compilation 100% sous licence BSD constituait une bonne raison de switcher.