IsNotGood a écrit 5009 commentaires

C'est Ubuntu qui dès le début a dit vouloir concurrencer Microsoft !
C'est son "bug" numéro 1.
C'est Ubuntu qui n'arrête pas de rabacher qu'ils veulent faire progresser le desktop !
Ils n'y foutent pratiquement rien !

Ubuntu c'est avant tout du marketing, du marketing, du marketing, du marketing.
T'enlèves le marketing, il n'y a pratiquement plus rien.

Tu réponds à côté de la plaque.
Ubuntu ne serait rien de rien sans le développement des autres !
Ça implique une réciprocité que ne joue pas du tout Ubuntu^W Canonical.

J'avoue être assez extérieur au sujet, mais sur le plan du principe je trouve dommage de taper un peu vite sur cette distrib qui fait beaucoup de bien au monde libre (sauf à debian, mais bon debian is dying de toute façon)

Ubuntu ne fait pas avancer le logiciel.
Et ça fait depuis des années que ça dure.

D'hommes prépubères ou de ménagère de moins de 50 ans.

En même temps, le brevet est tellement ... con.
Ça utilise la dissymétrie, c'est un grand classique.

Je pense qu'il ne doit plus y avoir grand monde qui n'a pas PA ou qui veut le désactiver.
Pour moi PA est totalement indispensable (et pas que pour mixer des sons).
Consommation CPU quand il ne fait pas de rééchantillonnage : 0,2 % sur un core2 qui a presque 4 ans.

Deux trois réflexions, j'espère que ça t'inspirera pour trouver le problème.

Pourquoi /dev/hda1 ?
Ça fait depuis un moment que linux est passé à pata (/dev/sda1).

Initrd ne serait pas configuré dans le noyau ?
Si c'est le cas, il cherche /sbin/init d'inird et non de /dev/hda1.

Fais un diff du /boot/config de noyau qui marche et de celui qui ne marche pas.

Bonne chance.

Le noyau dispatch sur les 2 coeur en fonction de la charge et il fait ça bien.
Au pire on peut utiliser taskset

RHEL 6 est basée sur Fedora 12 plus des ajouts qu'on trouve aussi dans Fedora 13, mais aussi des ajouts qu'on ne trouve pour l'instant que dans RHEL 6 même si c'est du logiciel libre (je pense principalement à Spice).

Notons qu'on va dépasser les 3 ans entre deux versions majeurs de RHEL !
Cette nouvelle version était très attendue par certains car faire tourner certains programmes sur RHEL 5 devenait un casse tête.

RHEL 6 sera la premier RHEL a sortir avec EPEL ( http://fedoraproject.org/wiki/EPEL ) opérationnel. On peut donc espérer qu'il y aura beaucoup plus de paquets "extras" pour RHEL 6 que pour RHEL 5.

Les "accros" à Fedora ne doivent pas rater la doc de RHEL 6 :
http://www.redhat.com/docs/en-US/Red_Hat_Enterprise_Linux/6-(...)

C'est une mine d'information.

Perso, même si j'ai actuellement une Fedora 13 (beta), je me demande si je ne vais pas faire un passage par RHEL 6 afin d'avoir une certaine tranquilité d'esprit (les monter en version "forcées" de Fedora sont un sport passionnant mais exigeant).

pour t'énerver.

Ce n'est pas un problème avec rev, mais avec la libc.
Et en fait ce n'est pas un problème.

La libc ne bufferise pas lorsque c'est un terminal, autrement elle bufferise (le programme doit alors faire des flush() explicites si le comportenant par défaut de la libc ne convient pas).

La commande strace n'indique que les appels noyaux (il peut y avoir plusieurs appels à write() de la libc avant un write() du noyau).

Pour voir les appels de rev à la libc, il faut utiliser ltrace.

C'est très très probablement un problème de récèption de la TNT.
J'ai le même problème parfois.

Arg, c'est faux.

f() {
tab = { {do_step_1, undo_step_1}, {do_step_2, undo_step_2} ... } ;
return g (tab, tab+sizeof(tab)) ;
}

g (p_tab, p_tab_end) {
if (p_tab < p_tab_end) {
if (!p_tab[0]) { p_tab[1] ; return FALSE ; } }
else { return TRUE }
if (!g(++p_tab, p_tab_end))) {
p_tab[1] ; return FALSE ; }
return TRUE ;
}

Ou avec une fonction récursive.

f() {
tab = { {do_step_1, undo_step_1}, {do_step_2, undo_step_2} ... } ;
return g (tab, tab+sizeof(tab)) ;
}

g (p_tab, p_tab_end) {
if (p_tab < p_tab_end) {
if (!p_tab[0]) { p_tab[1] ; return FALSE ; } }
else { return TRUE }
return g(++p_tab, p_tab_end)) ;
}

Ou utiliser un tableau de pointeurs de fonction
En pseudo code
tab = { {do_step_1, undo_step_1}, {do_step_2, undo_step_2} ... } ;

for (i=0 ; i < sizeof(tab) ; i++) {
if (!tab[i][0]) {
do { tab[i][1] ; } while (i--) ;
return FALSE
}
}
return TRUE

Je n'ai pas codé en C depuis des lustres :-)

Pour le driver proprio ATI, j'espère qu'ils arriveront enfin à nous pondre un truc qui marche

NVidia fait tout en proprio / "close source". Ils remplacent Mesa, etc, c'est une boucherie. Peut-être que ça rocks (du moins pour la 3D, le reste...), mais ça n'apporte rien au libre.
L'objectif d'ATI à long terme, bien loin de celui de NVidia, est de virer le driver proprio sous Linux (sauf pour quelques fonctions pour problème NDA, brevet, etc).
Bref, il me semble qu'il faut plus attendre de la qualité du côté du driver libre que du driver proprio avec ATI.
Les performances 3D de driver libre ne sont pas terribles. Mais cette question n'a pas encore été regardée. De ce que j'ai lu, ça ne devrait plus tarder.

Ca serait bien aussi qu'ils supportent les versions récentes du serveur X (nvidia le fait).

C'est supporter pour ça marche avec leur solution seulement. Ils ne cherchent pas à suivre les développements de Xorg. Du moins c'est mon impression. Mais par exemple Nouveau colle plus au dernier développement que le driver proprio.

Pour info, une semaine de test de la partie graphique de Fedora est prévue :
http://lwn.net/Articles/383156/

C'est pour NVidia (driver Nouveau, évidemment), ATI/AMD et Intel.

C'est facile, des procédures sont données.

Attendez que la beta de F13 sorte (dans quelques jours).

Je croix tu as raison.
Dommage.

va-api pour Intel et ATI, voir ici :
http://www.splitted-desktop.com/~gbeauchesne/mplayer-vaapi/

Je n'ai pas encore testé, mais ça ne va tarder.

C'est une HD 4350 avec une Fedora 13 (beta) qui a Xorg 1.8.
Et oui, tout marche.
Utilisation de Compiz, vidéo sur texture, jeux en 3D en même temps, bi-écran, ça marche. Peu de consommation CPU.
Il n'y a que les performances 3D qui ne sont pas terribles. M'enfin, hors certains jeux, ce n'est pas un problème.
Les perfs 3D sont l'un des prochains gros chantier des développeurs.

J'ai une carte ATI Radeon HD (que j'ai acheté ce weekend), tout marche nickel, la 3D comprise.

Non.

(Debian !)

Sauf que Debian pour son support dépend de ... Red Hat. Par exemple, kernel-xen de la dernirère Debian est resté à 2.6.18 car Red Hat utilise un 2.6.18.

Toutes les prochaines distributions (sauf Fedora qui aura un 2.6.33) auront un 2.6.32 car ... Red Hat (et Novell aussi pour ce coup).

D'abord, il y a très peu de paquet fourni sur le depot officiel.

Le "problème" est que Red Hat supporte VRAIMENT tout ce qui est forni (sauf ce qui est en "aperçu technologique").
Red Hat n'aurait aucun problème à fournir des tonnes de paquets (il suffit de piocher dans Fedora et RHEL est un fork de Fedora).
Il y a le dépot EPEL (supporté par le projet Fedora ; pas de support payant) mais il a été créé après RHEL 5. Pour RHEL 6 ça devrait être nettement mieux je pense (beaucoup vont "copier" de F12 à RHEL6).

Je me rappelle que lorsque Novell avait signé avec MS un accord sur les brevets, Red Hat avait dit, de façon un peu arrogante, "on a gagné".
Novell a fait beaucoup de conneries depuis. Investi dans Mono sans avoir de grands retours, en même temps abandonné Java alors que Red Hat cartonne avec (JBoss dépasse RHEL en CA maintenant). Puis Novell s'est "ridiculisé" avec AppArmor en voulant se différencier de Red Hat (quand on cible les grosses entreprises et les gouvernement ça craint).
Maintenant l'erreur de Novell est de trainer les pieds pour passer à KVM. IBM passe à KVM, et donc Red Hat :
http://www.redhat.com/about/news/prarchive/2010/ibm-cloud.ht(...)
Novell avait de solides atouts alors qu'il est arrivé dans le logiciel libre (à moitier car Novell a encore plein de produits proprios). Il en a perdu beaucoup, ça va être très difficile de redresser la situation.