PCMan et les autres dév. de LXDE se plaignent de la lourdeur et des bugs de GTK3.
Cela me fait penser que, l'usage mémoire inquiétant (au début) de GTK3 et le manque de force de travail a fait que le projet Xfce a retardé le passage à GTK3 à après la version 4.12 (qui préparera le terrain, en plus d'apporter des améliorations).
Sur la ML, le passage aux bibliothèques EFL a été envisagé, mais comme GTK3 a fini par s'améliorer du point de vue de l'usage mémoire, et comme passer à ELF (ou Qt) impliquerait une ré-écriture de tout le code de Xfce, il a été décidé de rester sur GTK et les technologies "associées" (Gvfs, …).
Pour ma part j'espère qu'on va arrêter d'avoir des thèmes GTK3 pour chaque version de GTK3 (GTK 3.2, GTK 3.4, GTK 3.6, …), c'est d'un ridicule…
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
Avec un gestionnaire de presse-papiers, je n'ai plus aucun problème (notamment celui du contenu copié qui disparait quand on ferme l'application source !).
Je peux même revenir en arrière et garder un historique (truc impossible de base sous Windows)
Sans ça, je serais resté sous Windows.
Ça existe au moins pour KDE et Xfce.
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
J'ai réitéré sans soucis en Physique, en Anglais et en Italien. Je commençai à être confiant, trop confiant peut-être. L'illusion était parfaite, la mention très bien était proche.
Même sans la sonnerie "fatale", t'étais déjà fait comme un rat.
Les profs/surveillants ont aussi un cerveau.
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
Je ne comprends pas. Qu'est-ce que ça peut faire ? N'importe quelle touche va arrêter l'écran de veille et tu retrouves tes raccourcis.
J'préfère qu'il demande un mot de passe pour déverrouiller après que je me sois absenté, c'est le seul intérêt d'un écran de veille sur un écran non-CRT.
Tu voudrais pouvoir lancer une tâche avec un raccourci clavier sans arrêter l'écran de veille ?
J'aimerais pouvoir arrêter la musique qui pète les écouteurs à l'aide des touches multimédia sans devoir rentrer mon mot de passe en paniquant parce que c'est trop fort.
Il n'est pas obligé de prendre toutes les touches du clavier pour lui pour bien verrouiller, je devrais au moins pouvoir lui dire "ne prends pas les touches multimédia X et Y".
Au pire, si un intrus arrive, il pourra (avec de la chance) :
- deviner le raccourci clavier pour éteindre la musique ou la remettre.
- deviner mon mot de passe à force de ré-essayer (je lui souhaites bon courage)
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
H.265 est une norme…quel est le rapport avec le libre ?
Ça va être pourri de brevets comme tout ce qui est MPEG/ITU-T ?
C'est quoi le rapport avec la lenteur du compresseur ??? Je teste le VP9 depuis 3 mois, donc, oui, c'est testable. Loin d’être utilisable mais testable.
Quand une vidéo de 5 minutes prends 20 heures à encoder, comment veux tu donner quoi que ce soit d'utile comme retour (surtout qu'un retour sur une seule vidéo ne sert pas à grand chose) dans un temps raisonnable ?
Edit : en plus, tu postes un lien de + de 3 mois…il y a eu des commits depuis ce temps.
Merci Captain Obvious. Mais je doute que les performances se soit drastiquement améliorées en 3 mois.
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
D'abord c'est H.265, et ensuite ce n'est pas libre.
Click me
Bah non :
As I said, it creates a very practical problem for BETA testers. For example, if a 5-minute video clips takes 20 hours to encode, there is no way for me to help you with testing. Let alone full-length 2-hour movies…
La force est faible avec celle là. Utiliser un terminal X (plutôt que les VT), ne t'empêche aucunement d'utiliser sed ou autre…
Ben c'est pas ce que j'ai dit. J'ai dit qu'utiliser une TTY, à moins de spécifier $DISPLAY à la commande, te force plus ou moins à utiliser que des outils non-graphiques, ce qui est sympa quand tu apprends à te démerder sans.
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
Ça t'arrive souvent ? Je veux dire, sur ta moulestation ?
C'est plutôt occasionnel, mais ça reste pratique pour lancer une tâche de fond ou une mise à jour sans attendre.
Comme ?
Comme lancer file-roller parce que ça fait 30 fois qu'on lance tar n'importe comment pour décompresser/compresser une archive.
Comme lancer Mousepad pour faire un chercher/remplacer au lieu d'utiliser sed.
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
Non mais ça va quoi. Tu fais bien d'utiliser une émulation de terminal sous X. Les quelques secondes nécessaires au basculement il faut bien comprendre que c'est le passage d'un système de gestion de l'écran à un autre, totalement différent.
Ça reste pourtant instantané avec nouveau, et super lent avec nvidia.
skoi ta machine pour que ça prenne 4s ?
Une machine de 2008. Asus X71SL, Core 2 Duo T5800, 4Go de RAM, nvidia GeForce 9300 M GS, SSD (sdb, /), disque dur 5400 RPM (sda, /home).
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
un shell en vrai plein écran directement sans s'embêter avec le terminal
pas de combinaisons claviers qui sont prises par le terminal alors que c'était pour le programme en cours
ne pas avoir à attendre le démarrage de xorg, et de l'environnement de bureau, pour avoir un shell
quand tu t'entraines à n'utiliser que des programmes shell, le fait que les applications ne trouvent pas le $DISPLAY permet d'éviter la tentation de lancer ou outil graphique dont finalement tu deviens dépendant
quand Xorg est cassé, c'est sympa
Mais surtout :
- pour geeker ;-)
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
Bof, il faut l'expérimenter pour voir à quel point c'est gênant, mais je vais tenter d'expliciter : c'est 4 secondes à chaque fois. A l'aller, et au retour. Constamment.
Ça tue toute idée d'utiliser Xorg et une TTY en même temps, car dans ces cas là j'ai tendance à faire un aller retour constant.
Avec nouveau, il n'y a pas d'attente, et l'expérience utilisateur est alors tout autre.
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
Pour le VP8, il est mauvais, à la fois dans la forme (la spec c'est du code C, donc les bugs font partie du standard !), et dans le fond (c'est un mauvais copié/collé du H.264 Baseline).
Et le problème, c'est qu'il faudrait un nouveau standard pour avoir quelque chose de potable (d'où sûrement VP9, qui n'est même pas testable).
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
En fait c'est ~30 Mo pour le paquet nvidia, ~70 Mo pour le paquet nvidia-utils. Sans oublier la variante 32 bits de nvidia-utils.
Nouveau fait beaucoup plus léger :
sudo pacman -S xf86-video-nouveau nouveau-dri mesa-libgl lib32-mesa-libgl
résolution des dépendances…
recherche des conflits entre paquets…
Paquets (4): lib32-mesa-libgl-9.1.4-1 mesa-libgl-9.1.4-1 nouveau-dri-9.1.4-1
xf86-video-nouveau-1.0.8-1
Taille totale de téléchargement : 1,95 MiB
Taille totale installé : 12,36 MiB
:)
J’ai pas regardé mais vu qu’ils utilisent leur truc à eux et pas les trucs de Linux ça m’étonnerais pas que ça fasse du bousin à charger effectivement.
nouveau avec l'early KMS (c'est à dire le module nouveau inclus dans l'image initrd) reste pourtant plus rapide pour arriver à LXDM que nvidia, même si je mets le module nvidia dans l'image initrd. :/
Quel rapport avec le pilote de carte graphique? Ça m’intéresse quand même de savoir comment un pilote qui à priori n’a rien à voir peut foutre la merde ici (et dans ce cas-là c’est pas un bug de Linux?)
Mettons un dossier de >= 15 éléments. Ctrl-A va prendre 3 secondes à sélectionner tout. Le menu contextuel va prendre 3 secondes à s'afficher. Copier/Coller/Supprimer/etc va mettre 3 secondes à se faire ou à afficher une demande de confirmation, etc…
Je crois que c'est le pilote nvidia qui a décidé de haïr GTK2.
C’est vrai, j’avais complètement zappé la lecture de vidéos… C’est vrai que les vidéos sur Youtube sont moins fluides si on les mets en HD et peut-être même en 480p mais faudrait que je revérifie (Linux 3.10 n’échapperas pas à mon test de nouveau).
Je peux utiliser vdpau qu'avec SMPlayer ou VLC. Si j'active l'accélération matérielle de Flash, tout le monde est en bleu.
Je rajouterais juste que quand je met Flash en plein écran j’ai un immonde Flash vert que je n’avais pas avant et que je n’ai pas avec Nouveau. Ainsi que divers autres clignotements en plein écran…
Erf, j'avais oublié ça aussi;
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
Perso j'en ai juste marre du pilote nvidia, et je suis de plus en plus impatient de passer à nouveau.
1.C'est un centaine de Mio à télécharger
2.Faut des patchs pour que le module pour le noyau compile
3.Ça remplace mesa-libgl par nvidia-utils. Encore une centaine de Mio à télécharger.
4.Pour aller en TTY ou revenir sur Xorg faut attendre 4 secondes à chaque fois (avec nouveau c'est instantané). Du coup, je n'utilise jamais les TTY.
5.Le démarrage est largement moins rapide qu'avec nouveau
6.Obligé de passer par /etc/xorg.d/20-nvidia.conf pour éviter d'avoir le logo nvidia en plein écran pendant une seconde (c'est bon je sais que j'ai une nvidia, peux-tu m'afficher LXDM S'IL TE PLAÎT ?!)
7.Depuis un an, j'ai perdu l'affichage en plein écran des jeux sur DOSBox (j'ai essayé plein de paramètres), même si 320x200 ou 640x400 c'est le même ratio que mon écran en 1440x900 (pas ce problème avec nouveau, ni sous Windows)
8.Dans Thunar et PCMANFM, toute opération sur les fichiers est très lente depuis quelques mois. Source : le pilote nvidia (pas ce problème avec nouveau).
J'ai essayé récemment nouveau lorsque Archlinux est passé à linux 3.9 (j'ai une
GeForce 9300M GS). J'ai été surpris de voir DarkPlaces (Quake) tourner aussi bien. Avant (linux < 3.9) ça atteignait même pas 1 image par seconde. Par contre Aquaria (un jeu 2D) est injouable. Amnesia : The Dark Descent aussi mais bon il a déjà un peu de mal avec les pilotes nvidia (ce n'est pas vraiment une CG faite pour jouer)
Bref, ça avance dans le bon sens, continuez comme ça (et si nouveau pouvait être compatible avec vdpau, ça serait super!)
En tout cas la prochaine carte graphique que j’achète ça seras pas une nvidia je pense, me font trop chier avec leur pilotes à la con.
Chez ATI ce n'est guère mieux. Une Intel HD me semble plus fiable, à défaut d'avoir des perfs pour hardcore gamer.
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
Aah, oups, on me dit dans l'oreillette qu'il est devancé par d'autres compresseurs a un même niveau de débit.
Dans son domaine, Vorbis est l'un des meilleurs si ce n'est le meilleur (à bas débit seul l'encodeur HE-AACv2 de Coding Technologies donne un résultat comparable, et à moyen/haut débit il n'a rien à envier aux meilleurs encodeurs LC-AAC ou MP3)
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
init -> peu de dépendances
systemd -> plus de dépendances.
Certes. Mais il n'y a pas que ça qui rentre dans la balance. Surtout que les dépendances peuvent se choisir lors de la compilation, et que toutes ne sont pas obligatoires.
SysV -> pas de standard entre les distributions. Langage de script qui est difficile à maitriser (notamment au niveau de la sécurité), bavard, et qui est inadapté. Inefficace : pour chaque script d'init, une instance de sh est lancée. N'est pas compatible BSD mais ne tire pour autant pas partie des fonctionnalités du kernel linux (cgroups, notamment). On est jamais sûr de tuer un service proprement (processus zombie, fichier PID à effacer à la main parce que le service n'a pas pu le faire, etc…). Pas de parallélisation. Pas moyen de lancer/arrêter un service à la demande (exemple : pas besoin de CUPS lorsque l'imprimante a été débranchée)…
systemd -> un seul fichier unit par service pour toutes les distributions. Moins de code, moins de chances d'erreurs, moins d'usage mémoire, meilleure maintenabilité. Utilisation mémoire comparable à celle de SysV. Fichier à-la-ini standardisé et documenté et facile à remplir. API entièrement documentée, aussi. Tire partie des capacités du kernel qui sont présentes depuis des années. On est sûr de tuer un service quand il y a besoin sans devoir redémarrer la machine. Le PID 1 n'est pas plus bloated que celui de SysV, vu que systemd est livré avec une soixantaine de binaires, remplaçables, indépendant les uns des autres (penser aux base-utils GNU : on est loin de toutes les utiliser, c'est pas pour autant que c'est bloated). Est compatible avec les shell scripts (et les quelques incompatibilités sont documentées). Est scriptable via DBus (qui a des bindings avec beaucoup de langages). Offre un journal centralisé, standardisé (par exemple au niveau des dates). Tout est fichier (cgroupfs). On peut réduire les fonctionnalités de systemd à la compilation (on peut faire en sorte que ce soit juste un système d'init et rien de plus : c'est prévu)…
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: Temps
Posté par xcomcmdr . En réponse au journal LXDE, Razor-qt et Qt (et GTK+). Évalué à 10. Dernière modification le 06 juillet 2013 à 23:57.
Cela me fait penser que, l'usage mémoire inquiétant (au début) de GTK3 et le manque de force de travail a fait que le projet Xfce a retardé le passage à GTK3 à après la version 4.12 (qui préparera le terrain, en plus d'apporter des améliorations).
Sur la ML, le passage aux bibliothèques EFL a été envisagé, mais comme GTK3 a fini par s'améliorer du point de vue de l'usage mémoire, et comme passer à ELF (ou Qt) impliquerait une ré-écriture de tout le code de Xfce, il a été décidé de rester sur GTK et les technologies "associées" (Gvfs, …).
Pour ma part j'espère qu'on va arrêter d'avoir des thèmes GTK3 pour chaque version de GTK3 (GTK 3.2, GTK 3.4, GTK 3.6, …), c'est d'un ridicule…
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
# gestionnaire de presse papiers
Posté par xcomcmdr . En réponse au journal Mais qui a mangé mon presse-papier?. Évalué à 1.
Avec un gestionnaire de presse-papiers, je n'ai plus aucun problème (notamment celui du contenu copié qui disparait quand on ferme l'application source !).
Je peux même revenir en arrière et garder un historique (truc impossible de base sous Windows)
Sans ça, je serais resté sous Windows.
Ça existe au moins pour KDE et Xfce.
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
# illusion, vraiment ?
Posté par xcomcmdr . En réponse au journal Privé de bac à cause d'un logiciel propriétaire. Évalué à -1.
Même sans la sonnerie "fatale", t'étais déjà fait comme un rat.
Les profs/surveillants ont aussi un cerveau.
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: Que du bon
Posté par xcomcmdr . En réponse à la dépêche Le noyau Linux 3.10 est sorti. Évalué à 4.
J'préfère qu'il demande un mot de passe pour déverrouiller après que je me sois absenté, c'est le seul intérêt d'un écran de veille sur un écran non-CRT.
J'aimerais pouvoir arrêter la musique qui pète les écouteurs à l'aide des touches multimédia sans devoir rentrer mon mot de passe en paniquant parce que c'est trop fort.
Il n'est pas obligé de prendre toutes les touches du clavier pour lui pour bien verrouiller, je devrais au moins pouvoir lui dire "ne prends pas les touches multimédia X et Y".
Au pire, si un intrus arrive, il pourra (avec de la chance) :
- deviner le raccourci clavier pour éteindre la musique ou la remettre.
- deviner mon mot de passe à force de ré-essayer (je lui souhaites bon courage)
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: Que du bon
Posté par xcomcmdr . En réponse à la dépêche Le noyau Linux 3.10 est sorti. Évalué à 2. Dernière modification le 05 juillet 2013 à 14:01.
Et même les écrans de veille en plein écran font pareil.
Merci Xorg, j'adore rentrer mon mot de passe en 4ème vitesse pour pouvoir enfin couper le son (à l'aide d'un raccourci clavier).
L'adrénaline, y'a que ça de vrai !
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: Pour le succès
Posté par xcomcmdr . En réponse à la dépêche Daala, le codec vidéo du futur, par Xiph. Évalué à 0. Dernière modification le 05 juillet 2013 à 10:42.
Ça va être pourri de brevets comme tout ce qui est MPEG/ITU-T ?
Quand une vidéo de 5 minutes prends 20 heures à encoder, comment veux tu donner quoi que ce soit d'utile comme retour (surtout qu'un retour sur une seule vidéo ne sert pas à grand chose) dans un temps raisonnable ?
Merci Captain Obvious. Mais je doute que les performances se soit drastiquement améliorées en 3 mois.
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
# nerdgasm !
Posté par xcomcmdr . En réponse à la dépêche Où vont les supercalculateurs ? D’où on vient, quels sont les problèmes, où l’on va (1re partie). Évalué à 10. Dernière modification le 05 juillet 2013 à 10:08.
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: Pour le succès
Posté par xcomcmdr . En réponse à la dépêche Daala, le codec vidéo du futur, par Xiph. Évalué à 2.
D'abord c'est H.265, et ensuite ce n'est pas libre.
Bah non :
https://groups.google.com/a/webmproject.org/forum/#!msg/codec-devel/P5je-wvcs60/9BwRyxye9zEJ
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: Que du bon
Posté par xcomcmdr . En réponse à la dépêche Le noyau Linux 3.10 est sorti. Évalué à -1.
Quoi qu'est-ce ?
Je n'ai pas de variable d'environnement $DISPLAY et je ne m'en souviens jamais.
M'en fiche. Les TTY c'est LE bien, na !
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: Que du bon
Posté par xcomcmdr . En réponse à la dépêche Le noyau Linux 3.10 est sorti. Évalué à 1.
??
Ben c'est pas ce que j'ai dit. J'ai dit qu'utiliser une TTY, à moins de spécifier $DISPLAY à la commande, te force plus ou moins à utiliser que des outils non-graphiques, ce qui est sympa quand tu apprends à te démerder sans.
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: Que du bon
Posté par xcomcmdr . En réponse à la dépêche Le noyau Linux 3.10 est sorti. Évalué à 2.
C'est plutôt occasionnel, mais ça reste pratique pour lancer une tâche de fond ou une mise à jour sans attendre.
Comme lancer file-roller parce que ça fait 30 fois qu'on lance tar n'importe comment pour décompresser/compresser une archive.
Comme lancer Mousepad pour faire un chercher/remplacer au lieu d'utiliser sed.
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: Que du bon
Posté par xcomcmdr . En réponse à la dépêche Le noyau Linux 3.10 est sorti. Évalué à 2. Dernière modification le 04 juillet 2013 à 23:42.
Ça reste pourtant instantané avec nouveau, et super lent avec nvidia.
Une machine de 2008. Asus X71SL, Core 2 Duo T5800, 4Go de RAM, nvidia GeForce 9300 M GS, SSD (sdb, /), disque dur 5400 RPM (sda, /home).
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: Que du bon
Posté par xcomcmdr . En réponse à la dépêche Le noyau Linux 3.10 est sorti. Évalué à 3.
Mais surtout :
- pour geeker ;-)
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: Que du bon
Posté par xcomcmdr . En réponse à la dépêche Le noyau Linux 3.10 est sorti. Évalué à 4.
Bof, il faut l'expérimenter pour voir à quel point c'est gênant, mais je vais tenter d'expliciter : c'est 4 secondes à chaque fois. A l'aller, et au retour. Constamment.
Ça tue toute idée d'utiliser Xorg et une TTY en même temps, car dans ces cas là j'ai tendance à faire un aller retour constant.
Avec nouveau, il n'y a pas d'attente, et l'expérience utilisateur est alors tout autre.
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: En avant pour la 3.11
Posté par xcomcmdr . En réponse à la dépêche Le noyau Linux 3.10 est sorti. Évalué à 2. Dernière modification le 04 juillet 2013 à 23:09.
"for workgroups" -> fonctionnalités réseau.
C'était peut-être pour éviter le nom alternatif : "Windows 3.11 for LAN Parties". ;-)
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: RTF pourris...
Posté par xcomcmdr . En réponse à la dépêche Deux ministères français communiquent leur usage du libre. Évalué à 1.
J'ai eu ce même genre de RTF, seul Word (Office XP) a su s'en sortir…
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: Pour le succès
Posté par xcomcmdr . En réponse à la dépêche Daala, le codec vidéo du futur, par Xiph. Évalué à 3.
Je parlais du x264.
Pour le VP8, il est mauvais, à la fois dans la forme (la spec c'est du code C, donc les bugs font partie du standard !), et dans le fond (c'est un mauvais copié/collé du H.264 Baseline).
Et le problème, c'est qu'il faudrait un nouveau standard pour avoir quelque chose de potable (d'où sûrement VP9, qui n'est même pas testable).
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: Pour le succès
Posté par xcomcmdr . En réponse à la dépêche Daala, le codec vidéo du futur, par Xiph. Évalué à 3.
C'est la meilleure implémentation, en fait. Et de loin.
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: Que du bon
Posté par xcomcmdr . En réponse à la dépêche Le noyau Linux 3.10 est sorti. Évalué à 5.
Le ratio bugs/fonctionnalités apportées est encore en faveur du pilote proprio, mais heureusement l'écart avec nouveau se réduit de plus en plus.
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: Que du bon
Posté par xcomcmdr . En réponse à la dépêche Le noyau Linux 3.10 est sorti. Évalué à 2.
En fait c'est ~30 Mo pour le paquet nvidia, ~70 Mo pour le paquet nvidia-utils. Sans oublier la variante 32 bits de nvidia-utils.
Nouveau fait beaucoup plus léger :
:)
nouveau avec l'early KMS (c'est à dire le module nouveau inclus dans l'image initrd) reste pourtant plus rapide pour arriver à LXDM que nvidia, même si je mets le module nvidia dans l'image initrd. :/
Mettons un dossier de >= 15 éléments. Ctrl-A va prendre 3 secondes à sélectionner tout. Le menu contextuel va prendre 3 secondes à s'afficher. Copier/Coller/Supprimer/etc va mettre 3 secondes à se faire ou à afficher une demande de confirmation, etc…
Je crois que c'est le pilote nvidia qui a décidé de haïr GTK2.
Je peux utiliser vdpau qu'avec SMPlayer ou VLC. Si j'active l'accélération matérielle de Flash, tout le monde est en bleu.
Erf, j'avais oublié ça aussi;
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: Que du bon
Posté par xcomcmdr . En réponse à la dépêche Le noyau Linux 3.10 est sorti. Évalué à 6.
Perso j'en ai juste marre du pilote nvidia, et je suis de plus en plus impatient de passer à nouveau.
1.C'est un centaine de Mio à télécharger
2.Faut des patchs pour que le module pour le noyau compile
3.Ça remplace mesa-libgl par nvidia-utils. Encore une centaine de Mio à télécharger.
4.Pour aller en TTY ou revenir sur Xorg faut attendre 4 secondes à chaque fois (avec nouveau c'est instantané). Du coup, je n'utilise jamais les TTY.
5.Le démarrage est largement moins rapide qu'avec nouveau
6.Obligé de passer par /etc/xorg.d/20-nvidia.conf pour éviter d'avoir le logo nvidia en plein écran pendant une seconde (c'est bon je sais que j'ai une nvidia, peux-tu m'afficher LXDM S'IL TE PLAÎT ?!)
7.Depuis un an, j'ai perdu l'affichage en plein écran des jeux sur DOSBox (j'ai essayé plein de paramètres), même si 320x200 ou 640x400 c'est le même ratio que mon écran en 1440x900 (pas ce problème avec nouveau, ni sous Windows)
8.Dans Thunar et PCMANFM, toute opération sur les fichiers est très lente depuis quelques mois. Source : le pilote nvidia (pas ce problème avec nouveau).
J'ai essayé récemment nouveau lorsque Archlinux est passé à linux 3.9 (j'ai une
GeForce 9300M GS). J'ai été surpris de voir DarkPlaces (Quake) tourner aussi bien. Avant (linux < 3.9) ça atteignait même pas 1 image par seconde. Par contre Aquaria (un jeu 2D) est injouable. Amnesia : The Dark Descent aussi mais bon il a déjà un peu de mal avec les pilotes nvidia (ce n'est pas vraiment une CG faite pour jouer)
Bref, ça avance dans le bon sens, continuez comme ça (et si nouveau pouvait être compatible avec vdpau, ça serait super!)
Chez ATI ce n'est guère mieux. Une Intel HD me semble plus fiable, à défaut d'avoir des perfs pour hardcore gamer.
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: Pour le succès
Posté par xcomcmdr . En réponse à la dépêche Daala, le codec vidéo du futur, par Xiph. Évalué à 1.
Effectivement je n'étais pas à jour. J'en étais resté à Vorbis aoTuV VS CT HE-AACv2 @ 48 kbps. ;)
C'est quel encodeur AAC ? Quelle version ?
Quelle version de l'encodeur Vorbis ?
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: Pour le succès
Posté par xcomcmdr . En réponse à la dépêche Daala, le codec vidéo du futur, par Xiph. Évalué à 3.
Dans son domaine, Vorbis est l'un des meilleurs si ce n'est le meilleur (à bas débit seul l'encodeur HE-AACv2 de Coding Technologies donne un résultat comparable, et à moyen/haut débit il n'a rien à envier aux meilleurs encodeurs LC-AAC ou MP3)
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: Pour le succès
Posté par xcomcmdr . En réponse à la dépêche Daala, le codec vidéo du futur, par Xiph. Évalué à 6.
Je suis aussi pessimiste quant au taux de compression, vu les blagues que sont de ce point de vue Theora, VP8, et VP9.
Je suis aussi pessimiste quant à l'aspect "royalt-free", vu que le VC-1 et VP8 n'y ont pas échappé (et non, un accord de non-agression entre Google et la MPEG-LA ne fait pas un codec vraiment libre… Et vu comment le VP8 copiait/collait le H.264 Baseline à 90% c'était inévitable)
Seul Theora y a échappé, mais qui veut l'utiliser de nos jours ?
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: C'est plus facile de travailler salement…
Posté par xcomcmdr . En réponse à la dépêche Un nouveau format de paquets logiciels utilisateurs pour Ubuntu. Évalué à 5.
Certes. Mais il n'y a pas que ça qui rentre dans la balance. Surtout que les dépendances peuvent se choisir lors de la compilation, et que toutes ne sont pas obligatoires.
SysV -> pas de standard entre les distributions. Langage de script qui est difficile à maitriser (notamment au niveau de la sécurité), bavard, et qui est inadapté. Inefficace : pour chaque script d'init, une instance de sh est lancée. N'est pas compatible BSD mais ne tire pour autant pas partie des fonctionnalités du kernel linux (cgroups, notamment). On est jamais sûr de tuer un service proprement (processus zombie, fichier PID à effacer à la main parce que le service n'a pas pu le faire, etc…). Pas de parallélisation. Pas moyen de lancer/arrêter un service à la demande (exemple : pas besoin de CUPS lorsque l'imprimante a été débranchée)…
systemd -> un seul fichier unit par service pour toutes les distributions. Moins de code, moins de chances d'erreurs, moins d'usage mémoire, meilleure maintenabilité. Utilisation mémoire comparable à celle de SysV. Fichier à-la-ini standardisé et documenté et facile à remplir. API entièrement documentée, aussi. Tire partie des capacités du kernel qui sont présentes depuis des années. On est sûr de tuer un service quand il y a besoin sans devoir redémarrer la machine. Le PID 1 n'est pas plus bloated que celui de SysV, vu que systemd est livré avec une soixantaine de binaires, remplaçables, indépendant les uns des autres (penser aux base-utils GNU : on est loin de toutes les utiliser, c'est pas pour autant que c'est bloated). Est compatible avec les shell scripts (et les quelques incompatibilités sont documentées). Est scriptable via DBus (qui a des bindings avec beaucoup de langages). Offre un journal centralisé, standardisé (par exemple au niveau des dates). Tout est fichier (cgroupfs). On peut réduire les fonctionnalités de systemd à la compilation (on peut faire en sorte que ce soit juste un système d'init et rien de plus : c'est prévu)…
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)