GeneralZod a écrit 2316 commentaires

Les contrôleurs RAID matériels ne sont pas forcément compatibles entre eux

Pour le matériel grand public, c'est effectivement un problème, pour le matériel pro, c'est le problème de ton fournisseur. Néanmoins, t'as des perfs bien meilleures et une sûreté de fonctionnement nettement supérieure (cache non volatile, contrôle des erreurs etc ...)

Faudrait savoir, je croyais que ça devait se situer au niveau du matériel ?

Je veux bien voir du LVM au niveau matériel ... Un système de fichiers moderne se doit d'intégrer des fonctionnalités de RAID logiciel et de LVM (du moins le sous-ensemble de fonctionnalités le plus usité, pas forcément les plus sioux)

Je dois donc faire partie des 5 % des utilisateurs plus avancés qui ne peuvent être satisfaits par Btrfs

Pas satisfait des fonctionnalités RAID logiciel et LVM de Btrfs, derrière, tu gagnes un système de fichiers plus fiable à terme (COW, transactions etc...), plus performant (fsck), compression à la volée.

C’est bizarre, je n’avais pas réalisé à quel point mes besoins sortaient de l’ordinaire.

C'est pas une tare ...

1. btrfs ne t'empêche pas d'utiliser le RAID logiciel et/ou LVM2. Par ailleurs, quitte à faire du RAID, autant que ce soit du RAID matériel, quand à LVM2, c'est une rustine qui apporte un poil de souplesse mais aussi son lot d'emmerdes.
2. personnellement, j'estime que ce sont des fonctionnalités qui ont vocation à être intégré dans le système de fichiers, pour diverses raisons:
3. simplicité d'administration
4. fiabilité et performance: multiplier les couches au niveau de la gestion des disques n'a jamais amélioré ces deux points, bien au contraire.
5. interopérabilité: chaque OS développe sa couche de gestion de volumes logiques et se débrouille pour qu'elles soient toutes incompatibles entre elles. btrfs réponds à 95% des besoins des utilisateurs plus ou moins avancés en étant plus fiable, plus performant et plus simple, pour les 5% restant, LVM2 et mdam sont toujours là.

PS: le RAID intégré à Btrfs est un poil plus performant principalement à cause du Copy-On-Write, en se donnant le luxe d'être plus fiable si on fait du mirroring. Supposons que j'ai deux disques dont l'un est malade, avec le mirroring classique, aucun moyen de deviner si mes données sont bonnes ou pas, Btrfs est capable de vérifier si les données et le checksum enregistré correspondent et te renvoyer la bonne donnée.

Pour la plupart des usages, oui. Dans le cas du RAID, btrfs ne supporte que les modes 0/1/10, Chris Mason bosse sur les modes 5/6 mais c'est en basse priorité. Si Btrfs arrive au même niveau de fonctionnalité que ZFS, à priori, plus besoin de LVM.

Ça va encore pour SL6, mais ils n'ont toujours pas pris l'habitude de bosser avec EPEL, le dépôt Entreprise Linux commun à RHEL & clone maintenu par Fedora et dans les gruikeries, ils prennent des paquets d'un peu partout comme rpmforge (pas compatible avec EPEL) et atrpms (dépôt extrêmement intrusif et avec des paquets d'une qualité lamentable pour la plupart).
Reste que SL est suffisamment proche de son parent pour être utilisable sans problème en production.

D'où vient cette plus forte popularité de centos

Parce que CentOS colle au plus près de RHEL alors que SL se donne le droit de s'en écarter significativement (et le fait allégrement). Sans compter qu'historiquement parlant, CentOS est très lié à Fedora.

En revanche, CentOS a pas mal merdé ces derniers temps et son enfermement pourrait lui couter cette popularité. Un nouveau clone de RHEL est en train de naitre pour justement pallier aux insuffisance de CentOS (ouverture vers la communauté, infrastructure basé sur les outils fedora, mutualiser les efforts des différents clones etc ...)
http://www.ascendos.org/

Si, tu as les branches nommés (pas d'équivalent dans Git) et les bookmarks (équivalent des branches git) qui jusqu'à la version 1.8 était une extension officielle.

Ce qui lui faudrait c'est une fonctionnalité ala git stash (le plus proche c'est l'extension shelve non-officielle)

C'est soit un bogue grave, soit tu as fait une mauvais manipulation quelque part (checkout ? plugin foireux ? etc...)
Est-ce que ça arrive sur un clone propre et sans plugin actif ?

C'est déjà plus facile avec une application KDE.

En pratique, je constate plutôt le contraire (mais avec l'arrivée de GNOME3, ça risque d'être blanc bonnet et bonnet blanc). T'as déjà essayé de changer le moteur de thème d'une appli KDE sans le bouzin de conf KDE (hint: il ne tient pas compte de l'utilitaire fourni avec Qt)

Je connais aucune applications GNOME qui ne placent pas correctement les labels dans les menus par exemple ... Et ne pouvant pas répondre à une question qui ne m'était pas posé, je te répondrais maintenant que oui, ça me choque.

Une bonne conception, tu sépares le coeur de l'application de son interface utilisateur.

ça dépends pour quelle utilisation, pour des petits utilitaires avec des UX génériques, ça permet de développer rapidement les IHM et de se concentrer sur la partie métier. Tu développeras évidemment pas {Open,Libre,Star}Office avec ce genre de couche d'abstraction (ironie inside) !

En plus, QT est nettement plus portable que GTK

C'est pas intrinsèque à Gtk+, le problème c'est que les ports windows et mac intéressent peu de monde (enfin, peu de monde qui a envie de contribuer à ces ports)

c'est assez l'horreur niveau ergonomie alors qu'une application QT ressemble à quelque chose sous Windows ou OSX.

Ouais, sauf qu'avant Qt4.4, une application Qt ça ressemblait à rien du tout sous GNOME et que c'est toujours pas conforme aux HIG actuellement (des broutilles certes mais suffisamment perturbant à mon oeil de développeur d'IHM)

Les mecs d'opensuse ont développé une bibliotheque similaire pour les besoins de YAST

http://gitorious.org/libyui

O.O ? C'est quoi l'intérêt ?

de démarrer des services uniquement à la demande, comment tu géres le hotplug ? tu fais tourner tout les services que tu pourrais éventuellement utiliser ? c'est bon pour les ressources ça ...

Et pourquoi pas gérer les sessions utilisateurs tant qu'à faire ?

C'est prévu ;)

et moi, quand mon système est cassé et que je dois mettre les mains dans du Bash, pas de souci.

C'est un trade-off, tu utilises un shell tu gagnes en souplesse ce que tu perds en performances, tu utilises C, l'inverse pour résumer. (Enfin, tu peux également switcher d'init au démarrage, rien n'interdit d'avoir upstart ou autre en //)

Personnellement, je pense que systemd est un bon outil, et il y a toujours la possibilité de basculer à un système d'init en //. Faut arrêter le faux débat avec BSD, historiquement tu as l'init BSD et l'init sysV (et encore, c'est bien balkanisé si on gratte bien), la différence, c'est que t'as plusieurs distros GNU/linux qui se regroupent autour de systemd au lieu d'upstart. Gueuler que "Lennart c'est un gros connard qui veut pas porter son bouzin sur BSD d'ailleurs il le hurle sur tout les toits", OK mais dans les faits, est-ce que ça intéresse vraiment les gens de BSD de changer de système d'init (d'ailleurs pourquoi changer ? ça marche bien et les BSD ont déjà pas mal rénové leur init, upstart/systemd répondent surtout aux défaillances d'init sysV). Si systemd, ça les intéresse, suffit de participer, et si Lennart est un vrai connard, on peut toujours forker ou proposer une alternative. Upstart ne supporte pas plus les BSD que systemd et personne ne gueule dessus, la différence, c'est que Lennart est une grande gueule.

Le truc qui m'inquiéterait, c'est la volonté de Lennart de pousser l'intégration un peu plus dans le bureau (remplacer ConsoleKit, en faire une dépendance de GNOME, etc...), je vois pas trop l'intérêt et les inconvénients sont bien réels eux.

C'est même le contraire tiens, ils ont carrément refait la libc, une JVM, forké le kernel, refait une bonne partie du système, et ça a marché. Hmm.

C'est surtout pour permettre des versions propriétaires d'Android ...je pourrais te retourner l'argument en soulignant qu'ils n'ont pas repris un noyau BSD, pourtant ça leur aurait simplifié la vie: perfide, efficace et sans aucun fondement comme l'insinuation ci-dessus à propos de la supposée mauvaise qualité des API linux.

c'est une question de configuration/intégration (comme Avahi, aussi).

Justement, l'argument avancé par Lennart c'est qu'Avahi le fait de base sans configuration/intégration. En résumé, je compile/installe/lance Avahi et c'est chrooté sans les mains !

Je reste convaincu que le buzz + le forcing qu'il fait est appuyé par son employeur, qui veut fédérer à lui les efforts communautaires sur ses solutions

Systemd est et reste un projet personnel de Lennart.
Avoir un init différent n'apporte rien du tout sur le plan commercial (ça fait chier les admins de devoir réapprendre un nouvel outil, d'avoir encore plus d'hétérogénéité pour pas grand chose etc ...). Quand Harald Hoyer (mainteneur d'init chez RH) a importé Upstart dans Fedora, il avait envisagé de réécrire son propre framework entre autre et ne l'a pas fait parce que le mainteneur d'Upstart était actif dessus et que Canonical avait promis de faire évoluer rapidement le soft.
Au moment où Lennart s'intéresse à l'init, il se rends compte que plus personne bosse sur Upstart (entre temps, James Scott Remnant a même changé d'employeur), que tout le monde est bloqué sur la couche de compatibilité sysV (en gros, on a un init plus complexe, tout aussi abandonné que son prédécesseur et sans aucun gain).

Désolé de te décevoir, il n'y a pas de complot du grand méchant RedHat pour impose SA solution, ça serait très con de démarrer une nouvelle implémentation alors que RHEL6.x a été publiée avec Upstart (et qu'ils devront le maintenir pendant 10 ans)

De E à F, il n'y a qu'un pas ...

intégré à GNOME

Clementine ne respecte pas les HIG ...

Ou bien que les mecs prennent le temps de réfléchir, parce que selon le contexte, je m'attends pas à la même action.
* delete dans la bibliothèque ===> suppression de la bibliothèque
* delete dans une liste de lecture ===> suppression de la liste
À vu de nez, le patch proposé est un peu trop simpliste pour cela.

Pour la suite, il est prévu de développer un moyen de synchroniser les instances de Thunderbird (qui a dit IMAP ?)

Aucun rapport avec IMAP, on parle de synchroniser les préférences, le carnet d'adresses et les comptes configurés.

PS: un artefact est passé a travers la relecture en bas de la dépêche.

Le port de Qt sur Android date de bien plus longtemps que ça (au moins un an).

débuté en 2009, mise en production en 2011, do the math !

dans silicon.fr, il y a surtout "con"

Il permet de réaliser des applications temps réel

Node.js temps-réel ? c'est la meilleure blague que j'ai entendu ce mois-ci.
Tu fais bien de préciser que Node.js utilise V8 qui utilise un garbage collector de type "stop-the-world" et incompatible avec le critère déterministe d'une application temps-réel (et ça ne qualifie pas pour autant le système sous-jacent).

d'ailleurs, nous avons implanté Opa en OCaml (probablement le plus gros projet jamais développé dans ce langage)

C'est le genre d'affirmations bancales qui a tendance à me rendre méfiant sur un projet.

C'est marrant de mentionner qu'Opa est en OCaml, parce que justement un projet concurrent en l'occurence haXe l'est aussi. Quelles sont les différences entre les deux frameworks (au sens large) ? Pourquoi ne pas avoir collaboré avec haXe ?

http://haxe.org/

Par contre le choix de c++ m'étonne un peu, j'aime bien et j'utilise souvent ce langage, mais pour de la dev web ça me parait lourd.

Wt est destiné principalement au marche de l'embarqué donc sur des machines où les ressources sont très limités (puissance de calculs, mémoire etc ...) et l'intégration avec du code existant natif. On peut même dire que la cible de Wt sont surtout des développeurs C et C++ qui ont très peu l'habitude de travailler sur des applications web et donc Wt leur propose un environnement familier pour développer des applications web complexe et un tant soit peu robuste.

il peut toujours apprécier le chocolat blanc.

Hérésie, le "chocolat blanc" n'est pas du chocolat !