timid a écrit 238 commentaires

Les prix sont pourtant donnés à l'unité sur le site, c'est aussi ce qu'on m'a confirmé par mail (en tout cas c'est ce que je comprend par "in quantity 1")

Je sais pas ce que ca vaut mais ce site semble vendre des mini PC bien moins cher que ce que j'ai pu voir dans les autres liens
http://www.ewayco.com/
Je m'en prendrai bien un

Je serait bien étonné que ce genre de boites offrent un support technique pour des produits qui ne sont pas les leurs.

Je trouve aussi vraiment malhonnête le fait de cacher volontairement la provenance des logiciels.

Dirac a pour l'instant pas l'air très véloce si on en croit wikipedia
http://en.wikipedia.org/wiki/Dirac_(codec)

"17fps sur un proc à 3Ghz pour une vidéo en 720x576"
J'espère que ca s'optimise

Wine par exemple ?
Pas de millions de benef, mais le jour ou cedega a repris le code ils sont passé sous GPL

SCIM+openoffice sous linux c'est vraiment la merde.
Autant sous windows ca marche du premier coup avec l'IME autant là ...
La seule solution que j'ai trouvé c'est de spécifier la variable LANG au lancement à autre chose que fr_FR
Quand je dois taper un rapport en japonais, je le lance comme ca :
# LANG=ja_JP ooffice

Les ebuilds (pour plusieur versions du noyau) avec le correctif ont été mis à jour le 11 vers 17h (selon cvs), donc à priori +3~4h

Dans le Kansai, les gens qui s'entendent bien ont parfois tendance à s'appeler avec des -chan (même si c'est deux mecs).
Les amis s'appellent généralement par leur prénom directement ou par un surnom.
En fait la pluspart des fois ou j'entend du -kun c'est quand une personne plus agée s'adresse à un jeune.
J'ai aussi remarqué que les étrangers non asiatiques se font rarement suffixer (yobisute) et se font souvent appeler directement par leur prénom (ils doivent penser qu'on a aucune notion de politesse ...)

Je sais pas ce qu'il en est sur Tokyo, ca fait longtemps que j'ai pas fait une petite descente là bas.

Ben non justement, y a pas d'effet mêmoire sur les batteries au lithium, ca les use plus de faire des grands cycles de charge / décharge que de les recharger par petits coups

cf :
http://fr.wikipedia.org/wiki/Accumulateur_lithium#Prolonger_(...)

Pour l'instant je n'ai heureusement eu l'occasion de le tester que sur une carte SD avec des photos (mon APN ayant depuis sa douche à la bière la facheuse tendance à planter et à corrompre le FS).
J'ai toujours réussi à tout récupérer, avec les données exif ca aide à retrouver les dates.

Pour l'instant la seule alternative viable pour la production d'énergie à grande échelle ce serait de recommencer à brûler du charbon (~200 ans de réserves) alors bon ...

Ouais ! et encore 1 mois après pour le happy day, les marchands de chocolats font leurs comptes en se frottant les mains !

Heureusement que je suis pas censé savoir ce qu'on doit faire pour ce white day :)

Ici on offre rien, c'est les filles qui raquent pour nous payer des chocolats :)

Waoow
J'avoue que j'ai eu du mal à y croire tellement c'est énorme, mais en effet c'est sur leur site :

http://download.microsoft.com/documents/useterms/Money_2006_(...)
http://www.microsoft.com/about/legal/useterms/default.aspx

En même temps je ne connait pas money, mais c'est peut être uniquement pour des services de gestion de comptes avec une interface web quand on est pas chez soi ...

mais dans le cas de sites suffisamment professionnels et à très forte charge tel que Wikipédia, pourquoi ont ils fait le choix de MySQL ?

Dans le cas de wikipedia, peut être surtout pour des raisons historiques ...
http://nostalgia.wikipedia.org/wiki/Wikipedia_PHP_script

j'espère qu'ils ne comptent pas utiliser le lecteur flash de kaltura.

Je vois mal en quoi ce serait gênant de mettre la vidéo dans une balise <object> pour la faire lire par un vrai lecteur

Pour les interfaces web j'utilise quotidiennement le framework Echo2 ( http://echo.nextapp.com/site/echo2 )
Avec ça, un site web se code comme une appli swing (l'API est quasiement la même), pas une ligne de HTML ou autre méta langage de balisage à toucher, 100% objet.
Ca permet de réaliser des applications avec des interfaces complexes et interactives et des composants réutilisables en très peu de temps et sans se prendre le choux avec le javascript à débugguer, les CSS qui passent pas pareil sur tous les navigateurs, etc

En fin de compte ca ressemble un peu au google web kit

Une démo :
http://demo.nextapp.com/Demo/app

Le tout sous licence MPL, je le recommande chaudement au moins pour les applis intranet

Ce que tu me dit me fait un peu penser à ca :
http://www.cs.cmu.edu/~johnny/projects/wii/

Un mec qui utilise la caméra infrarouge de la wii pour faire plein de trucs de ce genre, regardes les vidéos !

Mon téléphone est sorti en 2006 et le lit déja ....
http://mb.softbank.jp/mb/product/3G/706sc/

Je me demande comment ils vont se débrouiller après ça pour pouvoir utiliser Qt qui est en GPLv2

http://trolltech.com/company/about/businessmodel
http://trolltech.com/products/qt/gplexception

Mais UTF-8 n'est pas significativement plus lent ...

Les chiffres donnés sur le site de ton lien me surprennent un peu.

J'ai fait par curiosité mes propres tests et je trouve des résultats bien différents.
Les performances entre ascii, utf-8, sjis et eucjp sont pour moi très similaires.

Voici les résultats (si quelqu'un a envie de s'amuser à retester, ne pas oublier de changer l'encodage de la console à sjis ou eucjp pour les tests de grep) :

Préparation des fichiers de test

# yes 隣の客はよくカキ食う客や | head -1000000>foo-utf8.txt
# yes aaaaaaaaaaaa | head -1000000>ascii.txt
# iconv -f utf8 -t sjis foo-utf8.txt >foo-sjis.txt
# iconv -f utf8 -t eucjp foo-utf8.txt >foo-eucjp.txt

test comptage des lignes (wc)

Fichier ne contenant que des caractères ASCII

# time LC_CTYPE=ja_JP.UTF-8 wc ascii.txt>/dev/null
real 0m0.220s user 0m0.173s sys 0m0.010s

# time LC_CTYPE=ja_JP.ASCII wc ascii.txt>/dev/null
real 0m0.222s user 0m0.167s sys 0m0.016s

utf-8 : 0.403 sec
ascii : 0.416 sec

Fichier ne contenant que des caractères non ASCII

# time LC_CTYPE=ja_JP.UTF-8 wc foo-utf8.txt>/dev/null
real 0m0.576s user 0m0.499s sys 0m0.039s

# time LC_CTYPE=ja_JP.SJIS wc foo-sjis.txt>/dev/null
real 0m0.492s user 0m0.432s sys 0m0.019s

# time LC_CTYPE=ja_JP.EUCJP wc foo-eucjp.txt >/dev/null
real 0m0.402s user 0m0.337s sys 0m0.027s

utf-8 : 1.114 sec
sjis : 0.943 sec
eucjp : 0.766 sec

Test grep

Fichier ASCII

# time LC_CTYPE=ja_JP.UTF-8 grep "a" ascii.txt>/dev/null
real 0m0.327s user 0m0.285s sys 0m0.009s

# time LC_CTYPE=ja_JP.ASCII grep "a" ascii.txt>/dev/null
real 0m0.323s user 0m0.277s sys 0m0.012s

utf-8 : 0.612 sec
ascii : 0.621 sec

Fichier non ASCII

# time LC_CTYPE=ja_JP.UTF-8 grep "の" foo-utf8.txt>/dev/null
real 0m0.404s user 0m0.332s sys 0m0.038s

# time LC_CTYPE=ja_JP.SJIS grep "の" foo-sjis.txt>/dev/null
real 0m0.350s user 0m0.287s sys 0m0.030s

# time LC_CTYPE=ja_JP.EUCJP grep "の" foo-eucjp.txt>/dev/null
real 0m0.347s user 0m0.298s sys 0m0.018s

utf-8 : 0.774 sec
sjis : 0.667 sec
eucjp : 0.663 sec

La machine de test est un pentium M 1.6Ghz sous gentoo

> Sinon si vous voulez déverser votre fiel à propos d'une mauvaise expérience avec utf-8
Désolé, il y a rien qui vient.

Globalement je l'utilise partout, sauf pour les mails non HTML.

Contrairement à la pluspart programmes, le outlook japonais n'aime pas l'UTF8, ca fait du mojibake.
Comme la pluspart des gens ici l'utilisent, la seule solution c'est d'envoyer en iso-2022-jp

Oui ca ne sert pas à grand chose quand tu développes "à chaud", surtout quand tu es seul sur le projet vu que tu as une vision globale de ton code.

Par contre reviens 6 mois plus tard faire des modifs sur un projet de plus de 100000 lignes qui utilise des librairies développées par d'autres gens ... là tu seras bien content d'avoir ces vérifications au lieu de devoir découvrir les plantages en testant à la main (oui on peut faire des tests unitaires mais quand on touche à la couche GUI ça devient plus chiant).

Ca limite quand même pas mal les erreurs humaines.
Honnêtement, quand tu programmes dans un langage qui n'oblige pas à catcher les exceptions, tu vas regarder pour chaque fonction des APIs que tu utilises quelles erreurs peuvent survenir ?
Si tu le fait pas ton programme est potentiellement plus facilement plantable.

Après si le mec qui pond le code est fainéant, il n'y a rien à faire.

Ca reste quand même un gros plus pour la pluspart des programmeurs et ça aide à faire des programmes plus fiables.