Raphael R a écrit 102 commentaires

A ceci près qu'il y a justement des alternatives crédibles en terme de logiciel pour les PC et les smartphones. Sans compter qu'aux moments des faits, l’hégémonie (pour ne pas le monopole) d'un certain OS était à son paroxysme, et que cette hégémonie s'est construite justement quasiment grâce à des principes de ventes liée. D'où aussi la question sur la ventilation des prix, qui aurait pu permettre de savoir jusqu'où l'éditeur en question était près à aller pour s'assurer de cette hégémonie.

… mais qui évolue un peu trop lentement malheureusement. Il faut dire, le nombre de développeurs est assez restreint.

Utilisateur depuis une dizaine d'XFCE que ce soit au début sous FreeBSD 4.x et maintenant Linux, j'aime beaucoup ce environnement de bureau pour sa stabilité, sa légèreté et sa rapidité. Cependant, j'ai eu beaucoup de mal à trouver des thèmes GTK3 qui fonctionnent correctement avec la version 4.8 et 4.10. Et surtout j'avais pas mal de problèmes avec les applications pures GTK3 qui dut coup n'acceptaient que près peu de thèmes ou sinon s'affichaient n'importe comment au niveau des menus déroulants par exemple. Peut être cela vient-il de ma distribution, de ma configuration, mais j'ai l'impression que globalement XFCE a (avait ?) du chemin à faire de ce coté la.

Par contre, j'aime le coté évolution sans révolution, j'ai cru lire ici et la que pour gnome, la direction qu'il voulaient prendre n'étaient pas très claire ! Je souhaite en tout cas longue vie à XFCE, j'espère juste des sorties un peu moins espacées.

Car c'est parfois le genre de chose qu'il faut "montrer" si l'on veut que Xen s'impose dans certains SI à la place de mastodontes assez connus.

Ah mais je plussoie, Sinatra + Slim + Rouge, c'est vraiment très sympa ! \o/

Hooouuu, I2BP, cela ne nous rajeuni pas du tout ça !! Mais quelle belle épopée tout de même !

D'un autre coté, l'enjeu commercial ne se situe pas sur la VoD / Stream ? Que le H.265 soit bien évidement enrobé de DRM et autres conn**ies du genre (qui m’empêche de lire mes Bluray (plus ou moins récents) sous Linux), on y échappera pas. Mais on ne peut pas dire que la dématérialisation ne les intéresse pas (avec tous les problèmes de contrôle que cela donne aux pourvoyeurs de contenu), c'est pour ça que je m’interroge sur le moyen/long terme. D'un autre coté, si eux aussi le faisait, on en serait pas la non plus…

Il est finalisé depuis peu (même pas un an) mais le MPEG High Efficiency Video Coding est très prometteur justement pour on utilisation "réseau" avec des débits moindres demandé pour une qualité "équivalente". On va encore y passer des années avec sûrement ces mêmes histoires de brevets.

C'est sur que ça va bien dépoussiérer la gestion des packages de FreeBSD, je ne vais pas regretter certains ancêtres que j'ai utilisé il y a 10 ans écrits en Modula4 ! Même si la version 10 n'est prévue (en version finale j'entends bien) que dans quelques mois, elle promet de bonne chose et pas mal d'innovations.

Sincèrement, je ne vois pas comment on peut arguer que le support du noyau ne dure que 3 ans, surtout avec RedHat et SuSE pour les professionnels. Et puis ce n'est pas vraiment mieux du coté d'AIX : http://www-03.ibm.com/systems/power/software/aix/support/release_strategy.html ! Ça me laisse à penser que ceux qui ont fait ces choix ne connaissaient pas vraiment l'alternative aux des systèmes fermés du genre AIX.

Je baigne aussi professionnellement dans ce genre d'univers avec du Mainframe, de l'AIX, du Linux, mais aussi de la (grosse) base de données DB2 qui a migré sur de l'Oracle tout ça sous Linux (et même du Windows Server pour d'autre choses). Le problème étant que certaines sociétés savent se montrer "persuasives" envers les décideurs, qui n'ont pas forcement les compétences techniques pour déceler un enfumage caractérisé.

Et puis, bon si ça marche et que tu décides de ne rien changer, que ça soit sur AIX ou Linux, je ne vois pas trop la différence.

Mais bon au moins on a le contexte pour ce faire une idée du choix qui a été opéré.

Malheureusement, c'est le cas typique de bashing systemd avec une méconnaissance de l'objet "critiqué". Au moins avec systemd, ce dernier n'essaie pas de lancer ntpd avec des interfaces réseau qui n'ont pas encore initialisées, comme ça m'est arrivé dernièrement sur une distribution pourtant récente sous sysvinit. Une des raisons de l'existence de systemd c'est justement la gestion de dépendances de ce genre, et franchement, de ce point de vue la, ce n'est pas 30 ans d'histoire, mais plutôt vu comme 30 ans de retard.

Dommage que ce dérapage trollesque gâche un peu l'interview intéressante surtout en tant qu'utilisateur de FreeBSD (certes moins que Linux maintenant).

Je ne vois pas ce que pourrait dire un développeur *BSD pourrait véritablement dire sur systemd à part qu'il n'est pas évident à porter (voir impossible ?) sur d'autres OS que Linux à cause de l'utilisation des cgroups.

Ceci dit, les débats entre Linuxiens sur systemd virant souvent au troll ont du tellement avoir d'échos que vu de l'extérieur (quoi que François Tigeot utilise aussi du Linux) que cela donne une piètre image d'une communauté avec des personnes qui aiment donner leur avis sur des choses qu'elles ne connaissent pas sans véritablement argument de surcroît.

Donc ça dernière remarque que l'on pourrait trouver bien "déplacée" donne tout de même à réfléchir au final.

NB: j'utilise avec mes différentes distributions, aussi bien sysvinit et systemd (depuis près d'un an pour ce dernier).

Pour ma culture personnelle, je serais curieux de connaître le contexte du type de projet qui prend 3 ans à prendre forme avec une telle adhérence avec un noyau tout de même. Surtout avec une telle criticité, on doit être assez loin de cas "classiques". Merci d'avance.

Tout dépend de ta distribution : https://www.archlinux.org/packages/community/x86_64/rust/

Bon par contre, le build s'est fait avec : ./configure --prefix=/usr --disable-docs mais bon, elle n'est pas très difficile à trouver.

Forcement, j'ai tellement mis de temps à re-lire l'article que j'ai posté sans avoir vu la réponse au dessus pour la Arch.

Intégrée depuis peu sur la Arch en non-Testing, il y a déjà eu une seconde release pour le CVE-2013-4237 et un 'hackfxi" pour strstr.

En fait, déjà RVM c'est pour beaucoup de monde maintenant, un mauvais choix, rbenv étant nnnneeettemeent plus propre dans son fonctionnement. Ensuite, les déploiements sont souvent gérés par capistrano de nos jours.

Je remarque (à tord ?) que de plus en plus de projets, certes d'ampleur modeste en général, commencent à migrer de GTK2/3 vers Qt, comme par exemple LXDE dernièrement. Effet de "mode" ou vague de fond en devenir ?

Je ne saurais que trop te conseiller de passer à rbenv à la place de RVM. Je n'aime pas trop la façon de fonctionner de RVM et des bidouilles à la sauce 'cd' même si certains vont te dire que rbenv n'a pas un support des gemsets. Oui mais comme pour cela, il y Bundler qui s'impose pas mal (moi j'aime beaucoup aussi), on peut donc facilement s'en passer (je m'en passe avec Sinatra).

Une piste au cas où : http://rakeroutes.com/blog/how-to-use-bundler-instead-of-rvm-gemsets/

Outch, rbenv 0.3.0.

Par contre, je suis assez perplexe en terme de sécurité avec ça car la CVE-2013-2065 et la CVE-2013-4073 ne sont pas corrigées.

Alors de la à dire que c'est "mieux" parce que ça vient des dépôts officiels Debian, je suis quelque peu dubitatif pour le moment. Pour le moment, je préfère nettement faire des déploiements avec des sources sur GitHub (que l'on peut facilement vérifier) via rbenv et autres que mon baser aveuglement sur des paquets binaires.

PS: et on a le droit de trouver ça nul, je ne force personne =)

Petite précision pour l'utilisation de rbenv / rvm (avec une préférence personnelle pour le premier) est qu'il faut avoir d'installer un compilateur C car contrairement à une installation packagée binaire classique, dans les deux cas on passe par la case "compilation".

Et pour ceux qui trouveraient RoR un poil trop "lourd", il y un framework très sympa appelé Sinatra.

Et bien sur le même site on peut voir : http://cpprocks.com/c11-compiler-support-shootout-visual-studio-gcc-clang-intel/

Et justement avec ton lien, on voit par exemple qu'il a fallu attendre mai 2012 pour avoir les Initializer lists dans Clang/LLVM et que c'est maintenant supporté depuis peu sous VS2012. M’intéressant nettement plus à Clang qu'à gcc, j'ai pas mal lurké depuis des mois sur http://clang.llvm.org/cxx_status.html et globalement le support actuel est de l'ordre entre du 3.0/3.1.

C'est surtout le "rudimentaire" qui fait tache dans le commentaire de l'OP (on va passer sur le C99 qu'aucun des compilateurs n'a de façon complète par exemple) à mon sens.

Je suis bien content de pouvoir utiliser Clang/LLVM de façon de plus en plus sympathique sous Linux et j'espère que les patchs Kernel permettant une compilation seront intégrés dans un futur proche, même si il reste encore du code spécifique à gcc. Tout simplement pour avoir plus de choix déjà !

D'un autre coté que ça soit gcc et clang, le support de C99 n'est pas non plus complet, et si le support de C++11 dans VS2012 n'est pas non plus complet, il est du même tonneau que gcc/clang il y a un an a peu prêt. Sans compter qu'il y a des fonctionnalités de C++11 qui ont mis pas mal de temps à être implémentées du fait qu'elles sont loin de faire l'unanimité en terme d’intérêt. Joli appeau à troll, mais il fallait plutôt le sortir hier !

..avec cette annonce. Parce qu'autant si gcc avait des mois d'avance sur l'implémentation complète de C++11, ça aurait pu marquer le coup, mais que ça se joue sur quelques jours (Clang/LLVM 3.3 devait sortir le 5 juin, justement pour anniversaire de Phoronix). C'est étonnant de retrouvé ce coté un peu "sensationnel" du-dit site ici même.

Sinon, Clang/LLVM aura au moins le mérite d'en réveiller certains chez gcc pour nous pondre des choses utiles comme enfin des retour d'erreurs de compilation plus sympathiques depuis peu, chose que le nouveau compilateur (dont il manque quand même un pendant OpenMP malheureusement) avait depuis des années.

Passage de 2.3 en 3.0 qui s'est passée sans problème (juste un serveur en bare-metal, pas de cluster), ma seule déception étant de ne pas voir le support du protocole SPICE pour la version 3.0 comme convenu depuis quelques mois, mais ça avait été annoncé il y a quelques temps sur leur forum. Vivement la suite avec SPICE et QEMU 1.5 \o/

Je ne peux que plussoyer ceci, le passage de la 4.8.6-1 à 4.10.0-1 sur ma Arch en Testing n'a pas posé de problème mis à part ce drôle de séparateur. Alors du coup, j'ai du mal a comprendre comment cela se fait que la Debian il y ait eu perte de profil.

Que nginx ne supporte pas nativement les .htaccess c'est une chose, dire qu'il n'a pas de mécanisme équivalent, c'est pas franchement vrai. J'ai l'équivalent (en plus propre je trouve) sous nginx et de la même manière les .htpassword d'ailleurs pour un convertisseur "basique" : http://winginx.com/htaccess