IsNotGood a écrit 5009 commentaires

> on avait un scheduler out-of-tree (-ck), et ingo l'avait réécrit pour le mettre dans la branche principale.

Mouaif. Ingo avait les mêmes objectifs, mais la réalisation n'a rien à voir. J'ai entendu qu'il y a des matheux qui ont bossé sur l'algo d'Ingo.

Oracle propose une version repackagée de RedHat Enterprise, donc le coût du support est inférieur à RedHat.

Waaoooo.
Centos est gratuit s'il faut aller dans ce registre.

Après je ne suis absolument pas un expert avec les repos sous yum, il y a peut être des mirroirs que l'on peut sélectionner.

Si on utilise RHEL, on utilise RHN pour les mises à jour, et il n'y a pas mirroirs.
Je n'ai jamais fait attention au débit au RHN et 300 ko/s me semble correcte.

Côté gestionnaire de fenêtre, puisque quelqu'un en a parlé, sur les serveurs on s'en fiche.

Sur les serveurs on s'en fout. Mais pour une entreprise qui vend pour les serveurs nettement moins. Par exemple, sur quoi est développement le "truc" JBoss qui tourne sur le serveur ? Que vont utiliser les admin ? Du Windows ?

Autant ext4 je le vois, autant XFS non.

Le support d'XFS est limité à certains fonctionnalités et est donné au cas par cas. Red Hat a n'a qu'un développeur XFS.

Lors du passage 5.3 à 5.4 yum m'a réinstallé kde ...

Réinstallé ou mise à jour ?

Je ne me rappelle même pas l'avoir installé un jour

Et tu es sûr qu'il t'a installé KDE ?
Tu n'as peut-être que les librairies.
C'est peut-être les dépendances qui ont ajouté Kdelibs, qt, etc.

Je profite également, pour savoir si vous avez vous aussi des taux de téléchargements assez bas sur les serveurs ftp redhat pour les mises à jour ?

Ça dépend. Red Hat a dit que la sortie d'une version, même mineur (5.4 ici), est une forte montée en charge de ses serveurs. N'oublions pas ceux qui downloadent les ISO.

J'oubliais un "détail", RHEL est beaucoup utilisé en station de travail.

Oui et non.
Passer de Gnome 2 à Gnome 3 est un changement d'API et peut justifier une version majeur de RHEL.
Par contre, passer de Xen à KVM ou ajouter ext4 à RHEL 5 ne change pas grand chose.
N'oublions pas que Red Hat garantit la compatibilité source et BINAIRE pour toutes les RHEL 5.x, mais Red Hat ne le fait pas entre version majeur de RHEL.

Nostradamus n'est pas en forme.

1) la 5 va faire "court feu"

Pas sûr du tout (et on dit "faire long feu").
Il faut remarquer que la nouvelle stratégie de Red Hat pour la virtualisation (qui est une 'grosse affaire' sans vouloir rentrer dans les détails) est appliquée avec RHEL 5 et pas avec RHEL 6.
Des évolutions majeurs et critiquent comme le passage à ext4 se trouvent aussi dans RHEL 5. KVM a été intégré à RHEL 5 et est la virtualisation par défaut.
Donc il est bien probable que RHEL 6 va se fasse désirer.

D'où également l'arborescence particulière de 5

Ce n'est pas nouveau, c'est comme ça depuis la sortie de RHEL 5. En passant, ces deux branche sont à 99,999 % identiques et il n'y a que ce qui est lié à la sélection des paquets qui change.

d'où aussi le calendrier (toujours 'officieux/clients" d'une sortie de la 6 pour le printemps 2010)

Je pense que ça sera (encore) repoussé. RHEL 6 devait être basé sur F9, puis F10, puis F11, puis F12, je ne crois pas qu'elle sera basée sur F13 ni F14.
Je voix bien Red Hat attendre la sortie de Gnome 3 (+ quelques mois).

Le principal argument retenu étant que Ingo était un employé de Redhat et à ce titre on pouvait compter sur ses contributions de manière permanente.

Je ne crois que l'argument était là.
Linus n'était pas que Kolivas refuse toute critique. Linus a donc dit un truc du genre : "je ne veux pas d'un développeur avec qui je ne peux discuter".
Le scheduler de kolivas a donc été refusé et peut-être même avant la proposition d'Ingo.

Ton argument ne tient pas car si le boulot de Kolivas était "fabuleux", d'autres (peut-être des employés de Red Hat ou autre) l'aurait maintenu/développé.
Toute contribution, si elle est bonne, si elle va dans la bonne voie, est accèptée.

on pourra se demander ce que vont décider les diverses distributions proposant des solutions "desktop" toutes prêtes.

Elles ne vont rien "décider". Elles veulent le même ordonnanceur pour la grande majorité des cas d'utilisation (et donc desktop et serveur).

Serveur cracké, pas hacké.

Mettre à -10 ce commentaire, est du n'importe quoi.
Je ne soutiens à fond manatlan ! A bas la censure !

que signifie une clée SSH compromise?

Ça peut être une clé générée sur Debian...

Est-ce que dpkg supporte enfin les triggers ?
Peut-on signer un paquet avec dpkg et pas tout un dépôt ?
Il y a-t-il le support multi-arch ?
Peut-on faire un rollback ?
Etc.

Qu'importe, c'est le plus rapide dirons certains.

Pour info la ps3 a 256Mo de RAM et je pense que le souci vient de ça.

Pour la mémoire Yum (en fait rpm) était un peu glouton.
Ça a été corrigé dans F10 ou F11 (j'ai oublié). Quelle version de Fedora as-tu installé sur PS3 ?

Bof...

En passant, yum est utilisé à l'installation de Fedora.
Il y a-t-il des tests qui disent que l'installation est abominablement lente ?

Honnêtement, 30 secondes pour installer ntpd ou dhcpd (sans compilation)

Où t'as vu ça ?
Peut-être que lors du test ils sont sur des mirroirs lents. Ça arrive.

Bref, en gros je m'en fous.
Le pire comme gestionnaire de paquet, le plus lent et de loin, est celui de Windows. Ben les utilisateurs de Windows n'en font pas un fromage.

Ici c'est un journal uniquement pour casser Yum et dire que Apt roxe. Sur quoi ? Car yum est plus lent. Est-ce vraiment un gène ? Pas vraiment. Mais si Yum est 10 secondes plus lent, ça devient toute une histoire. Comme si Yum était utilisé 10 fois par jours. C'est une blague.

C'est comme les problèmes de dépendance où on veut nous faire croire qu'il n'y a aucun problème avec Debian/Ubuntu mais plein avec Fedora :
http://www.googlefight.com/index.php?lang=en_GB&word1=&q(...)

Très bien, Yum est plus lent, profitez en bien dans votre propagande.

Pour moi ces algos ont une qualité suffisante pour la vie de tous les jours

Il y a aussi des algo "pourris" avec PA, tu peux les selectionner pour gagner en cpu.

En passant, combien consomme OSS pour mixer et avec quel algo ?
On ne sait toujours pas...

le the One Sound System to Rule Them All...

PA n'a jamais été présenté comme ça. Il demande Alsa et "pousse alsa dans ses limites". La majorité des problèmes avec PA sont avec .... Alsa. Mais ça se corrige.
PA n'a jamais non plus prétendu remplacé jack pas exemple. Idem, PA ne remplace pas gstreamer. Il ne fait que serveur de son.

et pire, le mixage de base devenait du coup moins efficace qu'avec l'existant

Tu peux argumenter ?
PA est pire que esd ? que arts ? que dmix ?
En passant, dmix était un mixer en userland (comme PA).

ce n'est pas étonnant que PA ait plutôt mauvaise presse aujourd'hui.

PA a mauvaise presse pour quelqu'un.
PA est maintenant par défaut dans pratiquement toutes les distributions et la tendance ne va pas s'inverser.
OSS, du moins son service de serveur son, n'est pas une solution à long terme. À peine sorti et déjà sans avenir.

Euuh... Tu as vu ou qu'il peut y avoir des IPC sans context-switch ?

Les IPC, du moins la mémoire partagée, ne demande pas de context-switch.
Il ne faut pas oublier que les thread demandent des context-switch (sauf si multi-cpu).

Les applis sons vont "plus vite que la musique" et donc passe en sommeil. C'est systématiquement un context switch. Ce "problème", tu l'as avec un serveur de son en userland ou en noyau.
Si lors de l'écriture dans le serveur de son au niveau noyau la carte son n'est pas disponible, c'est aussi un context switch.
Bref, ça change pratiquement rien.

Juste un petit comparatif Yum vs APT pour se conforter dans l'idée que Debian, ça devrait être la base de toutes les distribution GNU/Linux ;)

C'est-à-dire ?
Il existait apt pour Fedora. Mais comme presque personne est motivé pour maintenir le truc, il a disparu. Bref, pas si indispensable que ça.

c'est juste que Yum à l'air de suxer pas mal.

Mouaif...
On est vraiment dans un concours à celui qui a la plus grosse...
Toutes les manips prennent moins de 30 secondes. Yum n'est pas utilisé toutes les heures ni tous les jours et encore moins que ça.

Pour info, yum est écrit en python et apt en C. Normal que Yum soit plus lent. Apt serait-il aussi rapide que Yum s'il était écrit en python ? Pas sûr. Donc yum sucks ou c'est python ?

Les plus gros consommateurs de Yum sont les développeurs/testeurs de Fedora et la vitesse de yum est satisfaisante.

Le jour où Windows passe à apt, Windows va devenir un OS formidable.

Ça fait depuis très longtemps que Red Hat est loin devant Novell.
Mais Novell est aussi loin devant tous les autres.
Notons que Red Hat fait autant d'argent (et peut-être plus maintenant) avec Jboss qu'avec RHEL.

Il risque plus de perdre ses données suite à son erreur qu'à une inondation.

> C'est bien gentil, oui, sur le papier, PulseAudio est idéal. En pratique les performances sont assez misérables

Des faits svp ?
Personne ne compare à algo de mixage équivalent. Par défaut PA prend un bon algo de mixage.
Combien consomme OSS pour le mixage et avec quel algo ?
On ne sait pas, c'est dans le noyau.

> Pourquoi ne pas commencer plutôt par améliorer les fonctionnalités de base ?

C-à-d ?
Pas de mixage, pas de support de périphérique branché à chaud (ce ne sait pas faire OSS), pas de redirection de son, pas de "switch user", etc.
Bref, améliorer ce que faisait déjà Linux il y a plus de 10 ans. Et pour quoi ? Pour gagner 0,001 % de cpu ? La grande affaire.

Les cartes sons vont de moins en moins avoir de mixeur intégré (sauf les très chères).

Je donne juste un petit exemple. J'ai un casque audio USB (avec micro). Avec PulseAudio (et alsa), je le branche à mon PC et basta tout marche. Je peux rediriger le son des enceintes vers le casque, le micro marche, etc.
Est-ce que OSS fait ça ? Pas sûr. Et pourtant c'est une fonctionnalité évidante à avoir. Ce genre de truc marche nickel sous Windows depuis des années, afin avec PulseAudio ça marche aussi sous Linux.

> De plus, le noyau possède les informations nécessaires sur l'ordonnancement pour assurer les meilleurs délais pour l'audio.

???
Ce n'est pas un argument valable. Le boulot du noyau est aussi d'ordonnancer les l'applis et le faire bien.
Et pourquoi pas mettre les lecteurs vidéos voire le serveur X11 dans le noyau tant qu'on y est ?

> Un autre problème avec les serveurs de son est que ça ajoute des changement de contexte, ajoutant encore du délais si le processeur est chargé.

Je ne vois pas pourquoi.
Sans serveur de son : 3 applis qui envoient du son, 3 applis qui demande des changements de contexte obligatoirement.
Avec serveur de son (en user space) : ces 5 applis seront peut-être (en fait probablement) des changements de contexte (l'écriture en IPC ne demande pas de changement de contexte) mais il n'y a pas de raison qu'il y en est plus.
Au final, pas facile à dire quelle configuration fera le plus de changement de contexte.

Ils ont dû le renommer.

Ça doit être ça.
Le .spec de yum-utils :

%package -n yum-plugin-security
Summary: Yum plugin to enable security filters
Group: System Environment/Base
Provides: yum-security = %{version}-%{release}
Obsoletes: yum-security < 1.1.20-0
Conflicts: yum-security < 1.1.20-0

J'ai beaucoup apprécié le fait de stipuler que si un brevet n'était pas révélé dans les 30 jours, il deviendrait caduc.

J'imagine que tous les participants ont signé un engagement qui donne les droits d'utiliser leur brevet s'ils ne les ont pas révélés.
Le brevet n'est alors pas rendu caduc, il est accordé pour OpenGL.

La page parle de caractères unicode, pas d'UTF-8.

Il y a aussi UTF-16 et UTF-32...

UTF-8, UTF-16 et UTF-32 sont des façons de coder unicode. Donc ça représente la même chose.

Les codes 0x27D7 et 0x27D8 sont définis (*), s'ils s'affiche mal, c'est très très probablement un problème de police de caractère. Notons que la norme unicode évolue, il y a des caractères qui sont ajoutés et les polices ne suivent pas toujours.

(*)
http://www.fileformat.info/info/unicode/char/27d7/index.htm
http://www.fileformat.info/info/unicode/char/27d8/index.htm