Larry Cow a écrit 5011 commentaires

Nan je déconne, MiB c'est Mailinblack !

Toutes mes condoléances...

Tu joues à WoW et tu aimes ça. Après, imagine ce que tu pourrais faire si tu pouvais te consacrer à ça à plein temps?

Je n'ai pas vu les spécifications du code-barre utilisé, mais en 2D ça a des chances d'être du QR-Code. Si c'est le cas, c'est manipulable avec des outils libres (libqrencode pour la partie encodage, tout du moins). Et ça peut contenir bien plus que le simple identifiant produit des code-barres EAN13 de supermarché : on peut y mettre une URL, une adresse e-mail, voire une vcard complète.

Perso, je suis allé farfouiller dans le gestionnaire de scripts, j'ai viré l'ancien script de récupération de paroles, et j'en ai installé un nouveau à la place (Ultimate Lyrics, je crois). Et ça marche du tonnerre.

Bon, ça ne tranche pas la grande question de la légitimité des lyrics en ligne, mais c'est pratique.

Il y avait déjà des images "brutes", qui marchent nickel sous Qemu/KVM.

Il y a avait un logiciel libre (je n'ai plus son nom en tête), mais Bayo a tout fait pour qu'il cesse d'exister. Je crois qu'effectivement, sauf gros changement de mentalité chez Bayo, le mieux qu'il y ait à faire est de ne pas acheter leurs produits si on veut les utiliser autrement que dans CartoExplorer.

Normalement, on doit pouvoir commander des rasters de qualité directement auprès de l'IGN, via le geoportail, non? Ça permettrait d'éviter de passer par cet intermédiaire très douteux.

Tiens oui, pas con le GSM, je n'y pense jamais. Bon après, faut avoir la présence d'esprit de le sortir au bon moment. M'enfin ça contribuerait peut-être à rendre nos amis journalistes un peu plus conscients de leur pouvoir.

Je pense que quoi qu'il arrive tu peux empêcher ça puisqu'on te fait dire le contraire de ce que tu veux.

Pour faciliter les démarches, il peut être utile - et certaines personnes régulièrement interrogées ont recours à ce genre de méthode - d'enregistrer soi-même l'entretien, en plus de ce que fait le journaliste. Avec sa permission, évidemment.

Déjà, ça a un effet dissuasif évident (on "joue" moins facilement avec les paroles d'une personne quand on sait qu'il a davantage que sa mémoire pour comparer a posteriori), et en plus ça doit pouvoir permettre d'étayer les éventuelles protestations en cas de tripotage manifeste.

Bon, après, faut être une bête médiatique pour que ça vaille le coup de se promener sans cesse avec un dictaphone.

Sans le A-GPS un fix peut prendre plusieurs dizaines de minutes

Ce qui est propre à tout récepteur GPS, bon ou mauvais : un cold-fix (lorsque la puce ne peut faire appel à aucunes données antérieures, que ce soit qu'elles n'ont jamais été présentes ou qu'elles ont expiré) prendre entre 15 et 30 minutes suivant les conditions. C'est directement lié au temps qu'il faut pour transférer les données initiales depuis les satellites, et le débit est assez pourrave. Si en plus il y a trop d'interférences, ça prend d'autant plus longtemps.

# Pas besoin de build-dependecies, tous les fichiers .h ont été parsés, et le code se trouve directement dans le fichier bytecode.

Donc tu risques d'avoir des redondances fâcheuses (et lourdes). Si je télécharge des programmes KDE - par exemple - via un gestionnaire de paquets lambda, il ne téléchargera que le paquet (éventuellement les trucs nécessaires au runtime, mais seulement la première fois). Si je fais de même avec Gentoo - par exemple - il récupérera les dépendances nécessaires à la compilation, mais une sule fois.

Par contre, avec ton truc, _chaque_ programme récupéré par le gestionnaire de paquets va se trimballer une grosse partie des kdelibs (dans mon exemple) avec lui. Ce qui est bien, mais pas top.

Ce qui n'enlève rien à l'intérêt de ton concept. Une solution qui permettrait - au moins partiellement - de limiter le problème que je soulève serait de faire un diff binaire (xdelta?) entre les différents paquets "logiquement" liés en amont, pour ensuite morceler les téléchargements. Genre "tu as besoin de digikam et d'amarok, alors je te fournis d'abord la partie commune - kdelibs, qt &co - puis les parties spécifiques et tu te chargeras de tout regrouper". On peut même envisager un cache côté client pour ces mêmes parties communes. Si ta technique est vraiment aussi économe en place que tu le dis, le cache ne sera pas _très_ couteux.

Il ne _faut_ pas une connexion pour l'utiliser. Sans connexion, il fonctionne comme n'importe quelle puce GPS : il télécharge depuis les satellites les informations utiles (almanach et éphémérides) si besoin, et ensuite il se cale. Si tu as une connexion, il peut récupérer les-dites informations beaucoup plus rapidement que le débit de paraplégique des satellites GPS ne ne permet.

Le Freerunner, notamment, annonce un "AGPS" (une puce uBlox). Et ça fonctionne très bien sans connexion. Juste ça _peut_ obtenir un 'fix' plus vite avec.

Non, le FR n'est pas mort. Depuis son abandon (relatif, la production des modèles existants semble continuer) par FIC, la communauté a repris les choses en mains, et commence à se comporter de manière un peu plus rationnelle.

La profusion de distribution semble se calmer, avec maintenant quelques "socles" (SHR et Debian, essentiellement) qui permettent aux plus acharnés de construire leurs propres versions. Mais en tous cas, le choix est devenu beaucoup plus simple.

Les interfaces "téléphoniques" deviennent utilisables, le prototype qu'était Zhone ayant à peu près disparu de la circulation. Le principe même du framework "freesmartphone.org" commence à montrer son intérêt.

Ce n'est effectivement pas le téléphone de monsieur Toutlemonde, mais il fonctionne et rend bien des services. Simplement, ce n'est pas l'iPhone-killer que certains auraient voulu y voir.

Dans quel coin elle est, ta collectivité? Par pure curiosité malsaine ;)

Avec la crise du logement, ça risque de finir au crématorium. Et là, pour le frais, tu repasseras...

Rah, J&S... :')

Rien ne t'empêche d'aller aider cette implémentation-là, par exemple : http://code.google.com/p/pygowave-server/

Oui, et puis faire tourner un "blob" opaque aussi discutable que Skype sur un serveur, c'est totalement anodin.

Quake live enfin dispo sous GNU/Linux !

C'est pas comme si l'attente avait été insoutenable non plus, hein.

Quelle machine qui embarquerait un navigateur et pourrait faire tourner quake3 dans son navigateur serait tellement mal branlée qu'on ne pourrait pas le compiler directement sur la machine??

Sans compter que le plugin Firefox, il est compilé pour ta machine, non?

Des gens qui paniquent dans un bocal hermétique en équilibre instable à plusieurs kilomètres du sol, oui, ça peut être meurtrier.

Je trouve que par rapport à sa faute, la réaction subit est démesurée.

Sauf si : http://xkcd.com/534/

D'un autre côté, si l'API est la même que PyQt, il suffit d'exploiter les exemples de ce dernier. Non?

Pas cool pour Riverbank, qui ont toujours fait de l'excellent boulot. Ça sent le sapin, là.

Voire. Même sans lien entre les deux réseaux, tu peux faire beaucoup de dégâts. Un simple message (vocal et/ou écrit) sur les terminaux, pour peu qu'il soit bien choisi, peut suffire à déclencher une panique meurtrière à bord.