GeneralZod a écrit 2316 commentaires

Tu as déja essayé la cli de virtualbox ?

Quel est le rapport entre la CLI et la qualité de VirtualBox ? Sinon, oui, j'utilise la CLI de préférence pour installer/piloter mes machines virtuelles (VBox, KVM, Xen, LXC).
VirtualBox est tellement merdique que les développeurs du noyau Linux ont rajouté le drapeau TAINT_CRAP à cause de lui, pour signaler que le module est de la merde en barre et qu'ils veulent plus recevoir des rapports de bogues automatisés si il est présent. Si VirtualBox est utilisé, c'est surtout parce qu'il a une jolie interface graphique, et quelques additions invités sympas, il aurait été propriétaire qu'il aurait fini droit à la poubelle pour sa nullité technique.

Xen c'est de la GPLv2

Un truc sympa, c'est que BHyVE supporte également les pilotes virtio, donc ce qui est un bon point pour les perfs.

Aujourd'hui, il manque clairement ce type de solution de virtualisation pour FreeBSD

Et VirtualBox ? Certes, c'est pourrave, mais ça tourne sous FreeBSD.

Pourquoi ne pas avoir porté gnome-panel vers GNOME3/GTK3 puisque l'essentiel du mécontentement envers GNOME3 vient de gnome-shell

déjà fait: c'est le fameux mode fallback sauf qu'on vient de l'abandonner puisque personne ne le maintient et que les gens préféraient améliorer le rendu logiciel via llvm-pipe

Gstreamer 0.10.0 est sorti décembre 2005, donc en 2006, il y avait encore du Gstreamer 0.8 qui trainait (et qui je te l'accorde était très brouillon), et la doc peu complète.

C'est un peu la vision "image d'Epinal". Les pipelines gstreamer sont beaucoup plus compliqués à comprendre que les filtres Unix.

En même temps, les filtres unix traitent du texte, les éléments gstreamer des flux multimédias beaucoup plus complexes, donc forcément. C'est surtout par rapport aux autres frameworks multimédias que le gain est appréciable.

Avec GStreamer, des utilisations avancées des flux multimédias sont accessibles à des non-spécialistes avec un peu d'effort. Je connais aucun autre framework multimédia qui soit autant extensible, flexible et productif, avec gst-launch, tu peux faire un POC en quelques minutes pour valider une idée, écrire des éléments propres à ton pipeline est bcp plus simple que de le faire avec FFmpeg ou xine, etc ... Oui, GStreamer n'est pas parfait, il n'a pas autant de maturité que ses concurrents mais c'est le couteau suisse.

Si y a pas de menus très compliqués, les gens croient que l'application sait rien faire -_-"
J'apprécie bcp VLC, mais l'ergonomie de l'interface graphique par défaut est clairement pourrie (et encore ça s'est amélioré lors du passage à Qt4).

Totem marche pas trop mal, il sait récupérer les sous titres, il sait lire des vidéos sur un partage daap, du DVB (avec gnome-dvb-daemon entre autre mais ça manque un peu d'intégration). Il juste marche, pour 99% des utilisateurs.

La contrepartie de la flexibilité de GStreamer, ce sont les APIs imbitables.

Je la trouve pas si compliquée que ça (pour une API C), c'est du GObject classique. Idem avec les wrappers C++, python.
Par contre les concepts associés (éléments, pipelines etc ...), ça demande un effort de compréhension mais c'est plus ou moins les filtres unix appliqués au multimédia (et c'est la killer feature de GStreamer)

(et je dirais le manque de documentation, mais peut-être que ça a évolué depuis 2006 :-))

Maintenant les guides sont plutôt complets: http://gstreamer.freedesktop.org/documentation/
L'API est à peu près documenté correctement, gst-inspect permet de récupérer les informations spécifiques à chaque élément, très pratique.

Le support initial de WebM dans GStreamer a été contribué par Collabora et Entropy Wave, Opera n'a jamais été mentionné.
http://blogs.gnome.org/uraeus/2010/05/19/webm-and-gstreamer/

En revanche, Opera a bel et bien développé ses plugins (en open source) pour implémenter le support de WebM:
http://sourcecode.opera.com/gstreamer/
http://blog.foolip.org/2010/05/19/vp8-has-landed/

Par contre c'est vrai que vlc supporte plus de formats.

C'est surtout faux.

Et dire que libVLC n'est pas un framework multimedia, c'est quoi alors ?

libVLC c'est du taillé sur-mesure pour un lecteur, ça n'a rien à voir avec un framework généraliste comme GStreamer. Certes, tu peux utiliser libVLC pour faire autre chose qu'un lecteur (ie: VLMC) mais ça n'a jamais été pensé pour, tu es très loin de la flexibilité d'un GStreamer.

VLC est un lecteur multimédia, GStreamer un framework multimédia, la plupart du temps, VLC utilise FFmpeg pour décoder les formats multimédia. GStreamer fourni des décodeurs/encodeurs mais rien ne t'empêche de greffer un autre moteur, c'est déjà fait pour FFmpeg d'ailleurs.

Personnellement, quand je vais (rarement) sur distrowatch c'est pour voir ce que propose les distributions que je n'utilise pas, celle que j'utilise je n'ai pas besoin de voir sur un site ce qu'elle propose, puisque je l'utilise déjà, suis-je le seul dans ce cas ?

Pendant longtemps, les ubuntistes ont prétendus que leur distro éclipsaient les autres sur la seule base de distrowatch (on attends toujours les stats vérifiables et celles sorties du chapeau). Et dès que distrowatch leur est défavorable, pouf, c'est pour voir les distros qu'on n'utilise pas !

Pour moi, ça reflète une tendance, la direction prise Ubuntu et Unity déplait à ses utilisateurs donc ils s'intéressent de plus en plus à une alternative, après savoir qui a la plus grosse bite communauté d'utilisateurs, j'en ai rien à foutre.

systemd fournit de base un outil graphique pour gérer les services.

On parle de quoi des membres associés ou actifs ? La principale différence est qu'un membre associé cotise et bénéficie de quelques avantages permettant de se faire identifier comme membre de la FSF mais n'a pas voix au chapitre. Pour ça, il faut être coopté en tant que membre actif, c'est avant tout une protection pour éviter qu'une organisation supportant des valeurs contraires à celles défendue par la FSF puisse la corrompre. La FSF maintient les licences GNU (et par conséquence, peut affecter tout les logiciels utilisant une licence GNU avec mention or later) et coordonne le copyright de nombreux projets libres (GNU ou non), c'est un mal nécessaire.

Si la FSF a du mal à recruter des membres associés, une campagne d'adhésion bien menée devrait pouvoir y remédier (FSF: 3000 membres associés, l'April: 5000 membres particuliers, donc pas de raison). Pour les membres actifs, c'est autre chose, il faudrait éventuellement réviser le processus de cooptation.

Debian is dying, tué par ubuntu

Aucun rapport, les rapports étaient déjà tendues entre la FSF et Debian, je dirais qu'Ubuntu les a même rapprochés un peu plus. Ubuntu a un système de valeurs différent de celui de la FSF ou Debian, et occupe une grande partie de l'espace médiatique alloué au libre donc ça n'aide pas. Plutôt que d'accuser Ubuntu de tout les maux médiatiques du libre, il faudrait se bouger le cul pour y remédier (FSF et libristes - y compris ceux au sein d'Ubuntu)

Difficulté de s'occuper des nouveaux marchés

C'est vrai, même si l'AGPL est une tentative de contrer le cloud computing, ça n'a pas eu le succès escompté. Néanmoins, maigre consolation, l'industrie a totalement intégré l'open source (et pas le libre) dans sa stratégie, la plupart des acteurs du cloud computing qui montent reposent sur du logiciel libre ou le sont eux-même.
Quant à l'embarqué, les solutions basés sur Linux plus ou moins ouvertes taillent des croupières aux solutions Microsoft.

Le schisme de la GPL

Le schisme a été provoqué par les défenseurs de l'open source mais pas du logiciel libre, si ils en avaient la possibilité, ils auraient imposés une licence BSD/MIT. Mettre ce schisme sur le dos de la FSF, c'est un peu de la mauvaise foi.

Intégrisme dans les positions de la FSF

La FSF est la gardienne du temple, ce n'est pas tant de l'intégrisme que de l'intégrité morale. On peut effectivement regretter que la FSF n'aille pas plus à la rencontre des communautés libristes pour des "futilités", ça limite son influence. Mais pour être honnête, la FSF (ou même RMS) n'a jamais refusé le dialogue, ils sont accessibles et disponibles.

Richard Stallman, le gaffeur

RMS est la figure charismatique du mouvement libriste, mais c'est un très mauvais communiquant. La FSF devrait réfléchir à embaucher un porte-parole ou du moins un marketeux pour lisser son discours vis à vis du grand public. Éventuellement, mettre plus en avant, les autres personnes habilités à s'exprimer au nom de la FSF et du projet GNU.

Le brevet portant sur l'interpréteur de bytecode a expiré depuis plus d'un an mais il comporte son lot de bogues (l'affichage des polices libres notamment est moins bon avec que sans). Enfin, je suppose que les utilisateurs d'Ubuntu s'en cognent des polices libres et installent derechef les polices microsoft.

Pour nous les utilisateurs finaux, c'est la seule configuration qui compte parce qu'on ne compte pas aller se tapper une documentation absconne en klingo

Tu sais lire ? J'ai dit que de son comparatif -qui vaut ce qu'il vaut- tu ne peux pas conclure que systemd et upstart se valent.

pourquoi Fedora ne propose pas en post install quelque chose pour ceux qui ne sont pas touchés par les brevets/restrictions

Parce que le projet est basé aux USA, sinon, tu as de base une installation de Java conforme au TCK (openjdk 6, openjdk 7 est dans les dépôts), les codecs sont automatiquement récupérés si tu as les dépôts qui vont bien (ça commence par rpm et finit par fusion) et que ton lecteur utilise gstreamer, flash sapusaipalibre (et la licence interdit explicitement la redistribution, à ma connaissance, la seule personne à avoir jamais eu l'autorisation explicite de Macromedia/Adobe fut Toshio Kuratomi le fondateur du projet Fedora).
Perso, j'ai jamais eu de problèmes d'affichage avec les polices avec freetype (même sans l'interpréteur de bytecode activé).

Sous Ubuntu c'est LVM/RAID/APPARMOR

Je ne sais pas si c'est dû à la configuration de Grub, mais Ubuntu ne te charge pas systématiquement les modules LVM et RAID si tu n'as pas ça au démarrage. Quant à AppArmor, il est loin de faire autant de checks que SELinux sans compter que la configuration SELinux livrée dans Fedora est nettement plus fournie que celle d'AppArmor sur Ubuntu.

C'est quoi, un PII 233Mhz ? Parce qu'ici sur un PIII 800Mhz, ca met moins d'une minute avec initrd...

Non, une workstation avec une carte maman un peu pourrave.

Ben, pour avoir un portable avec SSD je peux te dire que Ubuntu met une branlé à Fedora et OpenSuse...

Bof, sur un laptop Dell sans SSD, je boote en ~34s sans aucune configuration sous Fedora 16, à vue de nez, je devrais pouvoir approcher les 10s en virant l'initramfs et en virant les derniers services sans unités systemd natives

Élève GeneralZod, vous me copierez 100 fois, "Je dois faire preuve de plus de profondeur dans la critique des articles de Phoronix.".

C'est plutôt toi qui devra me copier 1000 fois "Je dois lire plus attentivement les commentaires du glorieux et tout-puissant GeneralZod"

J'ai bien précisé que comparer le démarrage avec les configurations par défaut de Fedora et d'Ubuntu ne permettait de comparer Upstart et systemd (d'ailleurs, il serait plus intéressant de faire le comparatif sur la même distro pour éliminer les facteurs inutiles).

C'est surtout que c'est inutile sous Fedora.

Comme d'habitude, il faut prendre les résultats fournis par Phoronix avec des pincettes.
Le comparatif ne précise absolument pas quelle est la configuration utilisé (probablement celle par défaut). Pour pouvoir affirmer que systemd n'apporte pas d'amélioration sur le temps de démarrage, il faudrait déjà lister les services démarrés (par défaut, Fedora en démarre beaucoup plus qu'Ubuntu), les options du noyau (celui de Fedora charge SELinux, LVM, le RAID qui ralentissent le démarrage). Vérifier également si les services sont lancés nativement ou via la couche de compatibilité sysV (sous Fedora 16, tout les services loin s'en faut fournissent les unités systemd, sous Ubuntu, à priori, tout les services sont fournis avec un job upstart natif ?)

Sur une même machine, avec Ubuntu 11.10, je n'arrive pas à démarrer en moins d'une minute même en démarrant sans initramfs (sous Fedora 14 avec upstart en mode compatibilité, c'est pas moins d'une minute 40s) , avec Fedora 15, en remplaçant les scripts sysV par des unités systemd et en désactivant le chargement des modules RAID et LVM au démarrage, je suis arrivé à 37s, 24s si je démarre directement sur le noyau sans l'initramfs. Désactiver le démarrage graphique avec plymouth permet de grapiller quelques secondes mais c'est négligeable (c'est déjà pas mal optimisé cette partie, notamment grâce au KMS)
Par ailleurs systemd fournit la commande systemd-analyze qui permet de générer un rapport graphique qui précise le temps passé à chaque étape, très pratique pour optimiser son démarrage.

systemd permet des optimisations très agressif du temps de démarrage, mais ça demande un peu de configuration.

Tout ce que ce comparatif permet d'affirmer c'est que dans leur configuration par défaut, Fedora 16 et Ubuntu 11.10 se valent en temps de démarrage.

Par rapport à screen/byobu, tu devrais essayer tmux comme multiplexeur de terminal beaucoup plus fiable et qui propose des fonctionnalités sympa comme synchroniser les inputs dans plusieurs panneaux (pour faire des trucs du genre clusterssh).

C'est pas lui qui doit se tapper la maintenance de paquets qui auront deux manières de s'inscrire comme service.

les unités systemd sont normalisées -bcp plus que les scripts sysV- donc très peu de travail en perspective. Systemd qui sait également lancer des scripts sysV gére très bien ça, quant à upstart bah il s'en fout des unités systemd.
En revanche les admins système te diront merci pour leur filer un init plus performant et plus robuste.

Ces ports ont, je trouve comme grande qualité de mettre le doigts sur la portabilité ou non des solutions

La plupart des solutions sont déjà disponibles dans FreeBSD

Oui mais je m'en fou du mode de gouvernance de Fedora. C'est Lennart qui dit que Debian doit être, je cite, « professionnellement pertinent ».

Et ? Debian est une distro très utilisé dans le monde professionnel, en accord avec son motto de "système universel". Si systemd est une avancée pour les utilisateurs de Debian, on va pas priver 99.99% des utilisateurs pour les 0.01% qui utilisent Debian/KFreeBSD (dont la plupart ne l'utilisent pas comme système principal ou en production).

C'est toujours sympas à entendre pour les contributeurs qui n'ont rien demandés.

Mis à part toi, ça n'a vexé personne, il dit juste que kFreeBSD est un hobby (ce qui est le cas pour la plupart des contributeurs) sans aucun jugement de valeur.

Je remercie également Nono et les autres contributeurs pour le super boulot accompli. J'apprécie particulièrement le travail accompli sur l'éditeur collaboratif. \o/

Il dit juste que Debian doit limiter les développements "accessoires" comme le port kFreeBSD du moins, ça ne doit pas freiner les autres. Même au sein de Debian, il y a des discussions pour savoir si certains ports ne devraient pas passer au second plan ou du moins ne plus bloquer les releases. Si on re-situe ça dans le contexte, il y a une discussion sur les listes debian pour savoir si debian allait passer à systemd par défaut ou non, et un des arguments contre était la non-portabilité sur le port kFreeBSD et Lennart suggérait que rien n'empêchait d'avoir que Debian/Linux et Debian/kFreeBSD aient un init différent.
Hein, il n'a jamais dit que le projet Debian était un jouet, à la limite le port kFreeBSD (qui est loin d'être aussi fonctionnelle qu'une vraie FreeBSD ou une Debian/Linux)

une distribution managée par une société et qui a pour finalité d'être un produit qui vise à vendre du service avec.

Fedora est une distribution communautaire, l'ensemble des décisions techniques relève uniquement du Fesco qui est un comité entièrement élu par les contributeurs actifs. Par ailleurs, Lennart est un cas particulier au sein de RH, il est relativement libre de choisir ses projets.
Dans le cas de systemd, c'est une initiative 100% personnelle, c'est une autre personne qui est en charge du démarrage dans l'équipe Base OS, et c'est arrivé juste après l'intégration d'upstart dans RHEL6 (imagine la gueule des personnes chargés de la maintenance et de la formation qui devront après RHEL7 gérer 3 inits complétement différents pendant un bon moment).