xcomcmdr a écrit 3537 commentaires

Sous Xfce aussi. En fait, la question pour confirmer l'extinction/redémarrage/etc n'est pas activée par défaut.

"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)

Talk is cheap, show the money !

"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)

La lourdeur de Firefox à ce que j'ai compris c'était surtout dû à ses fuites de mémoire, et à celles, très fréquentes, des extensions.

"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)

Bof, c'est suffisamment joli, et surtout ça tourne à peu près partout. Pour des jeux en réseau, ça tue le jeu si seulement ceux qui ont une config un minimum musclée peuvent jouer avec un nombre d'images par seconde décent.

"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)

Rien que pour (dé)coder de l'audio/vidéo on a droit à 4 frameworks Microsoft au sein de Windows, et leurs propres codecs :
Video For Windows (remplacé par DirectShow mais toujours assez utilisé)
DirectShow (remplacé par WMF, mais toujours très utilisé)
DirectMedia (mort)
Windows Media Foundation (remplace tous les précédents, mais j'ai pas encore vu de codec WMF…)

Youpi (et j'ai pas parlé du fait que DirectShow offre de multiples renderers différents: overlay, VMR7 (basé sur DirectDraw 7), VMR9, … !)

"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)

Hum, le message "hello world" n'est pas séparée entre les deux threads, mauvaise réponse…

"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)

Ruby (http://ruby-doc.org/stdlib-1.8.7/libdoc/monitor/rdoc/monitor_rb.html) :

require 'monitor.rb'

buf = []
buf.extend(MonitorMixin)
empty_cond = buf.new_cond

# consumer
Thread.start do
  loop do
    buf.synchronize do
      empty_cond.wait_while { buf.empty? }
      print buf.shift
    end
  end
end

# producer
while line = "hello world!\n"
  buf.synchronize do
    buf.push(line)
    empty_cond.signal
  end
end

Output:

hello world!
hello world!
hello world!
hello world!
hello world!
hello world!
hello world!
hello world!
hello world!
hello world!
hello world!
hello world!
hello world!
hello world!
…

Usage CPU : mes deux cores à ~66% chacun dans htop :o
(j'aurais peut-être atteint 100% avec deux processus à l'aide de IO.popen, par exemple ?)

Bref, qui se dévoue pour Python ?

"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)

systemd, udev, polkit, consolekit, gio…

"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)

Ah, celui fonctionne. :)

J'avais essayé aur/weboob-git

"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)

Ou Archlinux.

Sauf que le PKGBUILD de weboob sur l'AUR a des dépendances que pacman ne trouve pas… :/

"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)

Le 0 c'est un boob de face.
le d, c'est de côté.

De rien.

"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)

graver les morceaux sur un CD, et les re-numériser avec un format sans perte (FLAC, par exemple) ne ferait pas perdre de qualité, sauf si le format des originaux va au delà d'un codage sur 16 bits, et un échantillonnage de 44.1 KHz.

"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)

Surtout que maintenant même sous Windows c'est automatique…

Sous GNU/Linux, ça n'a jamais posé problème grâce au gestionnaires de paquets.

Quant aux extensions, c'est rare qu'elles soient devenus incompatibles. En tout cas pour les miennes, et j'en utilise pas mal.

"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)

Hum, je vois. Donc, l'usage des threads natifs n'empêche pas le GIL, cette page le confirme : http://essenceandartifact.blogspot.fr/2011/09/sad-state-of-concurrency-in-ruby-192.html

Pour la 2.0, la roadmap est pour le moins difficile à lire, et il n'y a rien sur le GIL on dirait :
http://bugs.ruby-lang.org/projects/ruby-trunk/roadmap

Je pensais qu'il y avait un wiki avec une roadmap claire, mais impossible de le trouver.

"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)

Ruby 1.9 est passé (pour la VM) de MRI à YARV, ce qui a permis d'avoir des kernel threads, qui semblent correspondre à de "vrais" threads (plutôt que les green threads des versions <= 1.8) selon wikipedia, et a apporté pas mal d'améliorations des performances.

La VM de Ruby 2.0 devrait aussi apporter une amélioration des perfs : http://www.h-online.com/open/news/item/Ruby-2-0-feature-freeze-heads-for-February-release-1736526.html

Du coup, l'intérêt de JRuby sera nettement moindre quand Ruby 2.0 sera largement adopté (oui ce n'est même pas sûr d'arriver un jour, mais bon), non ?

Aussi, en quoi Ruby (et les autres) sont "implémentés avec les pieds" exactement ? Je suis curieux. :)

"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)

C'est bien tordu comme bidule.

Du coup, je me demande si le gain d'économie d'énérgie (plutôt que de passer par le CPU centrale) est bien réel..

"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)

Tu peux désactiver les trucs Amazon dans les paramètres système. Même pas besoin de Ubuntu Tweak.

"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)

Si si il était bien installé lors de mon test. :)

De nouveau sous nouveau (heu…) :

$glxinfo | grep "OpenGL vendor string"
OpenGL vendor string: nouveau

En fait, warsow tourne entre 10 et 16 FPS (entre 30 FPS - beaucoup d'action - et 60 FPS - on regarde le sol - pour le pilote nvidia), avec le son qui est très très haché et lent. M'enfin pour un pilote qui est tout nouveau (heu…), c'est très impressionnant ! J'avais aussi absolument aucun bug graphique.

"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)

j'oubliais dans les paquets installés : libgl, et xf86-video-nouveau

"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)

En regardant la Feature Matrix, je savais que c'était risqué, mais la curiosité l'a emporté.

(Linux 3.6.3-1 sous Archlinux 64 bits).

J'ai donc installé nouveau, nouveau-dri, et activé [Option "GLXVBlank" "true"] dans la config de Xorg, ainsi que [options nouveau msi=1] dans /etc/modprobe.d/nouveau.conf, viré le pilote proprio, activé nouveau dans /etc/mkinitcpio.conf et refait mon image initrd, et redémarré en priant. :p

Résultat :
- VDPAU ne fonctionne plus (c'était plus ou moins attendu)
- Une 2D qui plante moins (en tout cas j'ai bien les jeux en 320x200 de DOSBox qui prennent toute la largeur de l'écran en 1440x900 en mode plein écran, alors que le pilote nvidia a décidé de foutre le plein écran de DOSBox en 4:3 dernièrement. Et de ne même plus maximiser le plein-écran si j'utilise output=opengl au lieu de output=surface (une surface SDL) dans la config de dosbox. Juste WTF nvidia ? 1440x900 et 320x200 c'est le même rapport hauteur/largeur!)
- warsow qui tourne à 1 FPS - même pas le jeu en fait, juste l'écran de présentation de la dernière version qui a un arrière-plan en 3D (là aussi c'était plus ou moins attendu)
- Pas eu de plantage, si ce n'est un redémarrage qui a bloqué (en même temps j'utilise systemd en plus, j'suis un peu fou)

Finalement, ça s'est beaucoup mieux passé.

Rien que pour la 2D qui fonctionne mieux, je suis très tenté le garder (la 3D n'est pas le point fort de cette carte de toute façon). Par contre, VDPAU me sert beaucoup pour les films en HD (qui passent souvent mal sur le Core2Duo T5800…)

"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)

l'homme n'écrit pas en binaire mais avec des lettres de l'alphabet.

Non pas forcément, ça peut être en sinogrammes ou un alphabet qui t'es inconnu. Et puis les chiffres, ça aide aussi.

Même sans les histoires de CRLF, ou d'UTF-8, ou de dates, ça fait déjà un sacré bordel pas universel du tout.

"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)

J'ai utilisé pour la première fois Ubuntu One… sur une interface Web sur le site de Canonical.

https://one.ubuntu.com/dashboard/

Sur le même site, on peut se faire un compte Ubuntu One. Donc, aucun besoin du client dédié.

"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)

n'empêche que systemd est pour l'instant la seule implémentation)

Non, upstart l'implémente aussi dans Ubuntu.

"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)

Vu comment le CPU est sous-dimensionné et que le Rasberry Pi est censé consommer peu (c'était quoi déjà le buzz dessus ? Un ordi qui consomme que 2W ?), l'explication reposant sur l'économie d'énergie me semble plus que plausible.

"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)

Réponds à cette question: le codage du retour à la ligne t'empêche-t'il de lire le fichier?

Quand le fichier de plusieurs milliers de lignes se transforme en une seule ligne, oui. Ça ne m'empêche pas de chercher dedans, mais c'est clairement pas lisible.

Quand le texte est en ISO-2022-JP, et qu'il devient uniquement des points d'interrogations sous Windows parce que y'a pas la police pour, amuse toi à le lire. ;-)

Bref, pour en revenir à journald, j'ai syslog-ng qui tourne en parallèle, et qui est écouté par journald (c'est même requis par journald au démarrage d'avoir syslog-ng sur ma Arch sinon j'ai une belle ligne du genre "[FAILED] Cannot connect to syslog-ng" au boot), donc y'a le binaire et le texte, tout le monde est content.

"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)