benoar a écrit 4244 commentaires

beaucoup vont lancer une sorte de windows media player embarqué bien plus lourd que votre plugin flash
Je demande à voir, je ne connais rien de plus lourd que le flash, notamment parce qu'il n'utilise absolument aucune fonction d'accélération de la CG, ce que fait au minimum n'importe quel player sur n'importe quelle plateforme. (oui, c'est pour des raisons de "on peut pas avoir de la transparence bling bling sinon" ...)
d'autre vont lancer un mplayer qui va tout figé (chez moi par ex)
J'en ai marre des gens qui font chier tout le monde à cause d'un bug chez eux (je ne te vise pas particulièrement, je dis juste que souvent quand ya un problème chez des gens parce qu'ils sont cons, les industriels s'adaptent à leur connerie ... certes, au final, ça marche chez eux, mais ça fait chier tous les autres)
d'autre auront une beau message "impossible de lire votre video, vous n'avez pas le codec truc" (car évidement, chaque site avait son propre codec).
Idem problème ci-dessus.

En plus, tous ces problèmes sont aujourd'hui inexistants sur n'importe quel système linux libre. Je veux bien parfois m'adapter à la masse, mais là faut pas pousser, même sous Windows tu prends VLC et c'est réglé ...

Je trouve quand même assez étonnant que quand les libristes gueulent sur Flash, c'est des extrémistes chiants, mais quand c'est Apple qui décide que c'est de la merde, tout le monde est d'accord pour dire que c'est lourd, ça pompe un max de CPU, etc ...

Bah, sur N800, on ne peut même pas utiliser de driver proprio puisqu'il n'y en a simplement pas ... Et comme c'est du proprio, impossible d'adapter un driver qu'on aurait pu chopper autre part...

Quant au DSP, c'est mignon, mais déjà la toolchain est entièrement proprio, c'est une version "basique", bref, exactement les raisons pour lesquelles je préfère le libre. Et pour l'instant, je n'ai vu _aucun_ projet utiliser le DSP (autre que ceux fournis par Nokia) qui n'est pas juste une "démo" qui ne sert à rien dans l'utilisation de la tablette.

Bref, il y a une sorte de décalage entre ce que font les constructeurs avec le libre, et les utilisateurs du libre, qui fait que ça ne marchera pas encore prochainement, selon moi.

Pour être sur que ce n'est pas un problème d'abonnement au groupe multicast, tu pourrais regarder ce que te donne tcpdump afin de voir si t'as bien les bonnes trames IGMP au moment de la "connexion" ?

Je voulais savoir ce qu'il en était de la liberté des drivers et compagnie dans cette console, car le couple ARM+DSP+PowerVR est un truc qui marche bien en ce moment (Nokia N8xx, iPhone/iPod Touch, ...) mais c'est putain de bien fermé niveau specs ... Bon, là c'est basé sur du DaVinci, et la politique de TI en général c'est "pas de problème pour les infos sur le CPU", par contre, le DSP, ça reste leur jardin secret, à moins de payer bien cher leurs grosses licences.

Quelqu'un a plus de détails ? (en particulier je m'intéresse au driver de la PowerVR, qui est la carte la plus puissante en embarqué actuellement, mais complètement fermé : on n'a même pas de driver proprio sur N800 ; rien, nada).

Oui c'est bien ce dont je parlais, pardon de la confusion.
Pour l'alignement, ça dépend de beaucoup de choses, mais je pense que pour les bitfields il les "pack" dans le plus petit entier qui les fait tenir. Pour d'autre valeurs, ça va être dépendant du processeur (qui peut avoir besoin de charger des flottants alignés contrairement aux entiers, par exemple). Pour être sûr, ajouter l'attribut __packed__ à la structure (parce que c'est pas parce qu'on met 2 short et 1 int dans une struct que le tout va faire 8 octets, gcc risque d'aligner les shorts sur 32 bits).

Et bien en C il existe la notation "int foo:4;" par exemple qui va te creer un entier sur 4 bits ... Et en mettant ca dans une struct, ca permet d'avoir la place de rajouter des flags (des entiers sur un bit) tout en tenant dans un espace "classique" de 8/16/32/64 bits.

Pour l'histoire de la perte des données, il existe s2both qui est bien pratique : ça enregistre l'état actuel de la RAM sur le disque, comme un suspend to disk, mais au lieu d'éteindre la machine ça la "suspend to RAM". Comme ça on sort de veille super rapidement, et en cas de coupure de courant / fin de batterie, on peut quand même retrouver son boulot. On perd juste un peu de temps au moment de la mise en veille.

Ou sinon un petit dpkg-buildpackage -us -uc pour les paquets déja "debianisés", qu'on peut aussi debianiser à la bourrin si ça a déjà été fait pour une version précédente : recopier le répertoire debian/ dans le répertoire fraîchement téléchargé.

Ha, ça a été un bon apéro encore une fois !
Pas mal de "nouveaux" cette année, des novices aux devs chevronnés (pas mal d'OpenBSDistes d'ailleurs), plein de monde différent, c'est toujours aussi sympa.
N'hésitez pas à venir, on en fait un chaque mois !

Complètement d'accord. Dire que tous les ordis aujourd'hui sont censés gérer le suspend to RAM, mais combien marchent en pratique sous linux ? Une très faible minorité. Franchement, ça mériterait plus de boulot. Et pas que sur les portables ! Sur les fixes aussi c'est super pratique (j'utilisais le suspend to disk au boulot, parce que le S2R ne marchait pas ; c'était quand même super pratique de retrouver tout son environnement de travail et ses documents super rapidement).

J'avais entendu parler des histoires d'ACPI faites pour s'adapter aux bugs de windows, c'est vraiment chiant. C'est vrai que sur PPC, tout a été fait pour gérer la mise en veille de manière tip top (je parle bien de linux, hein). Quelqu'un aurait des infos sur les matos gérant bien le S2R ? J'ai une nouvelle carte mère et j'aimerais bien qu'elle le gère bien ...

Tiens d'ailleurs, ton exemple de publicité par voie postale, moi aussi je voulais aller gueuler un coup car j'étais tranquille depuis 1 an et depuis quelques mois je reçois des courriers adressés à mon nom, qui ont commencé juste après que je me soit abonné chez France Télécom (bizarre ....). J'hésite entre aller blâmer celui qui m'a envoyé le courrier, mais comme c'en est un différent à chaque fois, ça ne va pas changer grand chose. Soit aller voir direct chez FT, mais je n'ai pas de preuve que ça vient d'eux. Comment peut-on savoir qui est la "source" ? A-t-on le droit de demander de quelle liste mon nom provient ? (je suppose que FT vend ça à un vendeur de liste ...) Parce que sinon ça ne finira jamais.

Je ne comptais pas aller jusqu'au tribunal, mais déjà envoyer des lettres recommandées pour me "renseigner" un peu plus.

Oui enfin là il va falloir justifier sévère, car mine de rien, la justice, c'est pas rien. Je pense qu'il disait ça rapport au fait qu'il y a des tas de cas "plus graves" à traiter, et que donc, tu n'aurais pas forcément grand chose au final.

Souvent, les gens que j'ai vu porter plainte c'était pour des choses qui leur ont fait perdre "directement" de l'argent (i.e. c'était quantifiable avec un papier qui avait été signé), et tout ce qu'ils ont eu, c'est le remboursement des sommes dues : le temps qu'ils y ont passé ne compte pas. Quand on parle de "préjudice", c'est vraiment le tort que ça t'a fait si t'as vraiment une raison valable, genre tu peux justifier, dans ton cas, d'une perte de temps au niveau professionnel si c'est dans le cadre de ton email professionnel. Mais bon, je n'ai jamais entendu parler de précédent, donc va falloir batailler dur. Le temps que tu passes sur le dossier n'est pas vraiment compté comme préjudice. Bizarre, mais bon ...

Je ne dis pas ça pour te décourager, au contraire, s'il y avait un précédent, ça motiverait surement d'autres gens, c'est juste qu'il faut qu'il y ait un premier qui se lance :-)

Oui effectivement, c'est une sacrée régression. Mon commentaire précisait l'avis des devs, que je ne partage pas forcément.

Une image ça permet quand même de repérer vachement plus vite un album : le cerveau (enfin, le mien au moins) va "connecter" beaucoup plus vite une image qu'un titre, si je fais défiler une liste d'album (d'où le mode "cover flow" sur les iTunes/iPod, je pense).

Oui, j'ai aussi une R200 avec randr1.2 qui marche depuis quelques temps, mais pendant la transition les deux systèmes peuvent coexister, c'est juste que "l'ancien" va disparaître bientôt.

Merci pour les liens.

Il est assez drôle de voir que, dans le premier pdf par exemple, il utilise cygwin et emacs pour le développement sur le kernel de windows ...

J'ai oublié d'ajouter : la différence de comportement, c'est que les drivers intel doivent déjà être passés au nouveau système, mais pas encore complètement les ati.

Avec la nouvelle archi de Xorg, et xrandr 1.2, il ne sera plus possible a terme d'avoir deux sous-écrans comme ça. Comme on dit "it's not a bug, it's a feature". L'argument des devs, c'est que c'est le boulot du WM de placer les fenêtres où il faut, mais les "sous-displays" vont tendre à disparaître.

Merci pour ces précisions, je n'utilise pas Xmonad mais je connais un peu Haskell, c'est pour ça que je suis allé voir à quoi ça ressemblait.

L'article sera accessible jeudi à ceux qui ne sont pas abonnés, mais sinon, vous pouvez vous abonner afin de soutenir ce très bon site/journal ! C'est pas cher avec la parité €/$ actuelle ...

Oui enfin avoir la possibilité d'avoir un forfait sans portable serait bien aussi. Je veux dire, on peut actuellement le faire en France, mais on paye le même prix que si on prend un portable avec pour 1€, donc forcément ... Donc ce qu'on a, c'est que des forfaits avec crédit intégré. Moi, je voudrais un forfait sans payer de crédit pour quelque chose que je ne prend pas !

le fichier de configuration d'Awesome est très compréhensible, et tant qu'on ne veut pas trop personnaliser, ça reste simple.
Extraits de du code de Xmonad (Config.hs), qui est typé, donc ça fait une ligne de code en plus à chaque fois mais au moins on est sûr que c'est bon puisque le compilo le vérifie (oui, faut le recompiler ...) :
defaultModMask :: KeyMask
defaultModMask = mod1Mask

normalBorderColor :: String
normalBorderColor = "gray" -- "#dddddd"

manageHook :: ManageHook
manageHook = composeAll
[ className =? "MPlayer" --> doFloat
, className =? "Gimp" --> doFloat ]

layout = tiled ||| Mirror tiled ||| Full
where
tiled = Tall nmaster delta ratio
nmaster = 1
ratio = 1/2
delta = 3/100

terminal :: String
terminal = "xterm"

focusFollowsMouse :: Bool
focusFollowsMouse = True

keys :: XConfig Layout -> M.Map (KeyMask, KeySym) (X ())
keys conf@(XConfig {XMonad.modMask = modMask}) = M.fromList $
[ ((modMask .|. shiftMask, xK_Return), spawn $ XMonad.terminal conf) -- %! Launch terminal
, ((modMask, xK_p ), spawn "exe=`dmenu_path | dmenu` && eval \"exec $exe\"") -- %! Launch dmenu
, ((modMask .|. shiftMask, xK_p ), spawn "gmrun") -- %! Launch gmrun
, ((modMask .|. shiftMask, xK_c ), kill) -- %! Close the focused window


J'ai même enlevé les commentaires, mais je pense que ça reste lisible et compréhensible.

Question : pourquoi ne pas supprimer la dépêche alors ? Ou alors ne pas l'avoir publié tout simplement ?

Je remarque que c'est Christophe qui l'a modérée, et j'ai souvenir d'avoir laissé un commentaire sur une autre dépêche "inutile" ya pas longtemps modérée par lui : qu'est-ce que tu branles Christophe ? Au prochain apéro je vais venir t'engueuler !

Ha tiens, on pourrais t'avoir à ton propre jeu :
Il y a plein d'universites qui enseignent le dev. systeme a leurs etudiants avec les sources du kernel NT, et un des boulots courrament faits notamment est de le modifier de differentes manieres.
C'est vachement super factuel.
On veut des sources.
Et si la réponse c'est "on peut pas le dire", je vois pas l'intérêt d'en parler.