Je me demande dans quelle mesure le local storage proposé par HTML5 peut être utilisé pour les mêmes choses, et si ça fonctionne avec les javascripts venant d'autres domaines?
Comme IRL, ton bosse te demande, tres innocement "Au fait comment vas ta femme ? Pas de probleme de sante chez vous ?"
Cela ne le regarde pas. La réponse est "elle va bien, merci".
Ou meme la surveillance des historiques...
En même temps tu es au bureau. Tu es censé bosser. Ton boss ne peut pas vérifier ce que tu fais depuis chez toi, et d'ailleurs cela ne le regarde pas.
Avec les réseaux sociaux, la possibilité est donnée de vérifier les relations, les problèmes. Ah tiens Josiane commence à causer de bébés va falloir la foutre à la porte avant qu'elle tombe enceinte. Ah tiens Jean-Paul fréquente des communistes à la solde des écolos vert-pomme, ça cadre pas trop avec l'activité de la banque. Ah tiens Michel semble avoir du mal, ça sent les congés maladie à répétition, prenons les devants.
Que fait tu pour eviter la pub que tu voit dans la rue ? Tu sort avec des oeilleres ? Comme adblock c'est une solution tout a fait viable :P
La pub que tu vois dans la rue ne consigne pas ton identité, l'endroit auquel tu es passé pour la voir et combien de temps tu es resté sur place.
Si tu cherches des informations sur une maladie quelconque ou une opération ou whatnot, c'est ce concept de "vie privée" qui garantit que tu le fasses en toute discrétion. Sans cela, facebook ou google pourrait très bien monnayer cette information à ton employeur ou consigner dans un dossier publiquement accessible que Bactisme a passé quatre jours à faire des recherches sur la chtouille.
Après, vu le peu de cas que font les entreprises américaines de la vie privée, c'est peut-être parfois déjà le cas.
Je prolonge la discussion sur les reseaux sociaux, [...] la plus part des personnes (comprendre, "sauf les cons") ont l'instinc assez developpe pour comprendre que c'est un endroit public et agir en concequence.
Oui, les photos de gens bourrés (au propre comme au figuré) sont légion sur les réseaux sociaux, et les informations potentiellement dommageable aussi. Le fisc enquête sur facebook, et si les assurances s'y mettent ça va être joli tiens.
C'est trop génial pour les domaines à la "del.icio.us" dont la totalité est nécessaire pour comprendre le jeu de mot. Ça leur fera les pieds.
En général, c'est génial pour tous les sous-sites, genre produit.firme.com par exemple. Ils ont qu'à enregistrer un nom de domaine pour chaque produit.
La racine carrée de 7776 est un peu au dessus de 88 (88² == 7744).
Cela signifie que si tu as 8 caractères parmi 88, c'est strictement identique à 4 caractères parmi 7744.
Si tu as des mots de passes de 8 caractères sensibles à la casse, ça te fait un set de 62 éléments. Combien y a-t-il de caractères spéciaux que l'on peut utiliser dans un mot de passe ?
Après, si tu utilises un mot de passe de dix caractères (chiffres, lettres minuscules et majuscules), tu as 229 fois plus de combinaisons possibles qu'avec les quatre mots.
Après, si tu considères le fait que tu peux avoir des mots qui commencent par une majuscule pour tes quatre mots, ou que tu t'autorises à "oublier" un espace parmis les trois espaces possibles, le nombre de combinaisons possibles s'envole...
Effectivement, pour la RFC 2822 une année doit compter 4 chiffres et être supérieure à 1900. Donc on a droit aux dates comprises entre 1970 et 9999. Mon côté marseillais a peut-être pris le dessus.
Ceci n'enlève cependant rien à l'argument, vu qu'un timestamp non signé n'est pas capable de représenter une date avant 1970, alors que le format le permet.
Le mail (tant SMTP que IMAP) se repose sur une représentation textuelle des dates, donc tu pourrais même théoriquement envoyer un e-mail daté de l'an 1, de l'ère préhistorique ou du cinquième millénaire sans émouvoir le protocole.
Après la question c'est plutôt de savoir comment les différents programmes en présence vont réagir à une date non représentable par un timestamp. Tout dépend de s'ils se préoccupent de la date en question et de la façon dont ils vont la représenter en interne.
Moui, après, les spécifications du matos ont suivi le passage vers les 64 bits, et le lien du journal semble indiquer qu'il n'y a pas vraiment de gain et qu'on met une tonne d'indirections dans tous les sens.
Oui, alors on peut déjà installer des programmes i386 avec un noyau x64. Je ne pense pas que le fait de gagner des clopinettes dans des cas très rares justifie le fait de maintenir une nouvelle infrastructure au sein du noyau et d'installer une troisième copie de tout le système.
Je peux voir l'intérêt théorique (se faire travailler les méninges sur quelque chose que personne d'autre n'a fait) mais pour qu'une infra se développe, soit maintenue et soit correctement supportée, il faut également qu'elle ait un intérêt pratique évident, ce qui aurait probablement été davantage le cas si l'infra x32 remplaçait "au vol" l'infra x86 en étant compatible avec les anciens programmes.
Je peux parfaitement comprendre qu'un programme compilé sur une archi i686 puisse toujours fonctionner si on rajoute des nouveaux registres, ils seront juste pas utilisés.
Par contre, si on change la taille du type time_t, on casse l'ABI et un programme compilé pour i686 (avec un time_t de 32 bits) ne pourra pas interragir avec une lib x32 (avec un time_t de 64 bits) et inversement.
Donc, vous emballez pas les gars, x32 ne sera pas plus compatible avec x86 que x84 ne l'est, et cela ne vous permettra pas d'utiliser tout le potentiel de votre core 2 duo installé du temps où x64 était réservé aux téméraires sans le réinstaller...
Du coup l'intérêt est relativement limité. Tant qu'à réinstaller, autant réinstaller du x64 directement...
Autrement dit, ce que j'attendrais ce n'est pas une façon d'aller vers le haut de l'arborescence car on lit habituellement les réponses après avoir lu les questions.
Ce que j'attendrais, c'est une façon d'aller vers le bas.
Je ne sais pas trop pour les jeux, mais la plupart des programmes qui supportent de fonctionner en mode "pas installé" le font de la façon suivante:
D'abord tu as une fonction qui te retourne le chemin de base pour les données, qui en temps normal va retourner DATADIR "/monprog" (c'est toujours utile, et ça laisse le code propre)
Si tu buildes avec une option spécifique (genre --enable-uninstalled-build si je prends le cas de totem), alors la fonction est altérée pour aussi chercher dans . si ce n'est pas installé.
Alternativement tu peux te baser sur une variable d'environnement ou quelque chose du genre. Peut-être même que quand tu lances le programme sans l'installer il est en fait remplacé par un script shell qui exporte plein de trucs comme avec les autotools.
Ou alors tu t'en moques, et vu que de toute façon les données ne changent pas si souvent tu ne supportes pas le fait que ton programme soit lancé sans être installé. Si quelqu'un veut builder ton jeu sous windows par exemple, libre à lui de changer ton get_data_path() pour correspondre à ce qui est attendu par son système.
Oui, c'est vrai qu'on peut trouver le parent d'un commentaire précis, mais il reste quand même extrêmement difficile de pouvoir trouver les réponses directes à un commentaire donné quand on a des sujets trollifères qui s'épandent.
Cas classique, après cinq niveaux d'arborescence un mec commence à troller sur un détail sans intérêt, ce qui immanquablement génère 150 réactions. Il est extrêmement difficile en l'état d'ignorer totalement ce sous-thread, sauf en prenant une latte et en mesurant le nombre de centimètres entre le bord gauche de l'écran et le niveau de réponse désiré, et de scroller jusqu'à retrouver un commentaire du même niveau mesuré à la latte.
On a fait mieux à l'ère de l'informatique de masse, non ? ;-)
Avec les autotools ce genre de chose est triviale. La moindre des choses serait de pouvoir gérer un préfixe de compilation et aller y chercher les librairies (càd tester si libfoo.so existe et éventuellement s'il contient un symbole donné)
Ça serait cool de supporter CMAKE_INSTALL_PREFIX pour les gens qui veulent builder sans polluer leur /usr/local... Si j'en crois la doc avec cmake c'est utilisé tout seul si tu utilises les macros FIND_*()
Tu peux aussi avoir plusieurs threads: un pour la GUI et d'autres pour le reste. Tu peux même avoir plusieurs process pour être sûr, mais c'est peut-être plus chiant à gérer.
# Threads
Posté par nud . En réponse à la dépêche Roundcube webmail 0.6 est disponible. Évalué à 3.
Je laggue peut-être, mais est-ce que la version actuelle de roundcube sait enfin afficher les mails sous forme de thread ?
Ça semble faire partie du nouveau thème sur flickr, mais je ne vois pas cela dans les screenshots.
# HTML5 Local Storage ?
Posté par nud . En réponse au journal Brouteurs, cookie et données personnelles. Évalué à 2.
Je me demande dans quelle mesure le local storage proposé par HTML5 peut être utilisé pour les mêmes choses, et si ça fonctionne avec les javascripts venant d'autres domaines?
[^] # Re: Attention avis disruptif
Posté par nud . En réponse au journal Brouteurs, cookie et données personnelles. Évalué à 5.
Cela ne le regarde pas. La réponse est "elle va bien, merci".
En même temps tu es au bureau. Tu es censé bosser. Ton boss ne peut pas vérifier ce que tu fais depuis chez toi, et d'ailleurs cela ne le regarde pas.
Avec les réseaux sociaux, la possibilité est donnée de vérifier les relations, les problèmes. Ah tiens Josiane commence à causer de bébés va falloir la foutre à la porte avant qu'elle tombe enceinte. Ah tiens Jean-Paul fréquente des communistes à la solde des écolos vert-pomme, ça cadre pas trop avec l'activité de la banque. Ah tiens Michel semble avoir du mal, ça sent les congés maladie à répétition, prenons les devants.
[^] # Re: Attention avis disruptif
Posté par nud . En réponse au journal Brouteurs, cookie et données personnelles. Évalué à 6.
La pub que tu vois dans la rue ne consigne pas ton identité, l'endroit auquel tu es passé pour la voir et combien de temps tu es resté sur place.
Si tu cherches des informations sur une maladie quelconque ou une opération ou whatnot, c'est ce concept de "vie privée" qui garantit que tu le fasses en toute discrétion. Sans cela, facebook ou google pourrait très bien monnayer cette information à ton employeur ou consigner dans un dossier publiquement accessible que Bactisme a passé quatre jours à faire des recherches sur la chtouille.
Après, vu le peu de cas que font les entreprises américaines de la vie privée, c'est peut-être parfois déjà le cas.
Oui, les photos de gens bourrés (au propre comme au figuré) sont légion sur les réseaux sociaux, et les informations potentiellement dommageable aussi. Le fisc enquête sur facebook, et si les assurances s'y mettent ça va être joli tiens.
[^] # Re: XKCD
Posté par nud . En réponse au message Mots de passe - diceware. Évalué à 2.
Oui, c'est pour ça qu'il a mis le lien dans son post ;-)
[^] # Re: « Domaine »
Posté par nud . En réponse à la dépêche Firefox Sept : consommation mémoire nettement améliorée. Évalué à 0.
C'est trop génial pour les domaines à la "del.icio.us" dont la totalité est nécessaire pour comprendre le jeu de mot. Ça leur fera les pieds.
En général, c'est génial pour tous les sous-sites, genre produit.firme.com par exemple. Ils ont qu'à enregistrer un nom de domaine pour chaque produit.
# Un peu de combinatoire
Posté par nud . En réponse au message Mots de passe - diceware. Évalué à 1.
La racine carrée de 7776 est un peu au dessus de 88 (88² == 7744).
Cela signifie que si tu as 8 caractères parmi 88, c'est strictement identique à 4 caractères parmi 7744.
Si tu as des mots de passes de 8 caractères sensibles à la casse, ça te fait un set de 62 éléments. Combien y a-t-il de caractères spéciaux que l'on peut utiliser dans un mot de passe ?
Après, si tu utilises un mot de passe de dix caractères (chiffres, lettres minuscules et majuscules), tu as 229 fois plus de combinaisons possibles qu'avec les quatre mots.
Après, si tu considères le fait que tu peux avoir des mots qui commencent par une majuscule pour tes quatre mots, ou que tu t'autorises à "oublier" un espace parmis les trois espaces possibles, le nombre de combinaisons possibles s'envole...
[^] # Re: génial !
Posté par nud . En réponse à la dépêche Facebook f8 : timeline, musique/vidéo, ticker, boutons (et les conséquences pour le web). Évalué à 5.
Non, pour en faire de grosses légumes.
[^] # Re: SQLite
Posté par nud . En réponse au journal Mysql, je t'aime un peu, à la folie, mais pas trop libre. Évalué à 1.
Resistance is futile
[^] # Re: J'approuve
Posté par nud . En réponse au journal x32: Une nouvelle ABI Linux '32 bits' pour les CPU x86-64. Évalué à 2.
Effectivement, pour la RFC 2822 une année doit compter 4 chiffres et être supérieure à 1900. Donc on a droit aux dates comprises entre 1970 et 9999. Mon côté marseillais a peut-être pris le dessus.
Ceci n'enlève cependant rien à l'argument, vu qu'un timestamp non signé n'est pas capable de représenter une date avant 1970, alors que le format le permet.
[^] # Re: J'approuve
Posté par nud . En réponse au journal x32: Une nouvelle ABI Linux '32 bits' pour les CPU x86-64. Évalué à 2.
Le mail (tant SMTP que IMAP) se repose sur une représentation textuelle des dates, donc tu pourrais même théoriquement envoyer un e-mail daté de l'an 1, de l'ère préhistorique ou du cinquième millénaire sans émouvoir le protocole.
Après la question c'est plutôt de savoir comment les différents programmes en présence vont réagir à une date non représentable par un timestamp. Tout dépend de s'ils se préoccupent de la date en question et de la façon dont ils vont la représenter en interne.
[^] # Re: ABI 32 bits et time_t
Posté par nud . En réponse au journal x32: Une nouvelle ABI Linux '32 bits' pour les CPU x86-64. Évalué à 1.
Moui, après, les spécifications du matos ont suivi le passage vers les 64 bits, et le lien du journal semble indiquer qu'il n'y a pas vraiment de gain et qu'on met une tonne d'indirections dans tous les sens.
[^] # Re: ABI 32 bits et time_t
Posté par nud . En réponse au journal x32: Une nouvelle ABI Linux '32 bits' pour les CPU x86-64. Évalué à 2.
Oui, alors on peut déjà installer des programmes i386 avec un noyau x64. Je ne pense pas que le fait de gagner des clopinettes dans des cas très rares justifie le fait de maintenir une nouvelle infrastructure au sein du noyau et d'installer une troisième copie de tout le système.
Je peux voir l'intérêt théorique (se faire travailler les méninges sur quelque chose que personne d'autre n'a fait) mais pour qu'une infra se développe, soit maintenue et soit correctement supportée, il faut également qu'elle ait un intérêt pratique évident, ce qui aurait probablement été davantage le cas si l'infra x32 remplaçait "au vol" l'infra x86 en étant compatible avec les anciens programmes.
# ABI 32 bits et time_t
Posté par nud . En réponse au journal x32: Une nouvelle ABI Linux '32 bits' pour les CPU x86-64. Évalué à 3.
Je peux parfaitement comprendre qu'un programme compilé sur une archi i686 puisse toujours fonctionner si on rajoute des nouveaux registres, ils seront juste pas utilisés.
Par contre, si on change la taille du type time_t, on casse l'ABI et un programme compilé pour i686 (avec un time_t de 32 bits) ne pourra pas interragir avec une lib x32 (avec un time_t de 64 bits) et inversement.
Donc, vous emballez pas les gars, x32 ne sera pas plus compatible avec x86 que x84 ne l'est, et cela ne vous permettra pas d'utiliser tout le potentiel de votre core 2 duo installé du temps où x64 était réservé aux téméraires sans le réinstaller...
Du coup l'intérêt est relativement limité. Tant qu'à réinstaller, autant réinstaller du x64 directement...
[^] # Re: Ça existe en partie
Posté par nud . En réponse à l’entrée du suivi Difficile de visualiser l'arborescence des commentaires. Évalué à 1 (+0/-0).
Autrement dit, ce que j'attendrais ce n'est pas une façon d'aller vers le haut de l'arborescence car on lit habituellement les réponses après avoir lu les questions.
Ce que j'attendrais, c'est une façon d'aller vers le bas.
[^] # Re: Hum...
Posté par nud . En réponse à l’entrée du suivi Feed Atom pour le tableau de bord. Évalué à 1 (+0/-0).
Déjà ça permettrait de savoir que quelqu'un a répondu à l'un de ses commentaires ou à l'une de ses entrées de suivi.
# La foire au hack
Posté par nud . En réponse au message Savoir où chercher les données utilisées après un make install. Évalué à 1.
Je ne sais pas trop pour les jeux, mais la plupart des programmes qui supportent de fonctionner en mode "pas installé" le font de la façon suivante:
D'abord tu as une fonction qui te retourne le chemin de base pour les données, qui en temps normal va retourner DATADIR "/monprog" (c'est toujours utile, et ça laisse le code propre)
Si tu buildes avec une option spécifique (genre --enable-uninstalled-build si je prends le cas de totem), alors la fonction est altérée pour aussi chercher dans . si ce n'est pas installé.
Alternativement tu peux te baser sur une variable d'environnement ou quelque chose du genre. Peut-être même que quand tu lances le programme sans l'installer il est en fait remplacé par un script shell qui exporte plein de trucs comme avec les autotools.
Ou alors tu t'en moques, et vu que de toute façon les données ne changent pas si souvent tu ne supportes pas le fait que ton programme soit lancé sans être installé. Si quelqu'un veut builder ton jeu sous windows par exemple, libre à lui de changer ton get_data_path() pour correspondre à ce qui est attendu par son système.
[^] # Re: Ça existe en partie
Posté par nud . En réponse à l’entrée du suivi Difficile de visualiser l'arborescence des commentaires. Évalué à 1 (+0/-0).
Oui, c'est vrai qu'on peut trouver le parent d'un commentaire précis, mais il reste quand même extrêmement difficile de pouvoir trouver les réponses directes à un commentaire donné quand on a des sujets trollifères qui s'épandent.
Cas classique, après cinq niveaux d'arborescence un mec commence à troller sur un détail sans intérêt, ce qui immanquablement génère 150 réactions. Il est extrêmement difficile en l'état d'ignorer totalement ce sous-thread, sauf en prenant une latte et en mesurant le nombre de centimètres entre le bord gauche de l'écran et le niveau de réponse désiré, et de scroller jusqu'à retrouver un commentaire du même niveau mesuré à la latte.
On a fait mieux à l'ère de l'informatique de masse, non ? ;-)
[^] # Re: préfixe de compilation
Posté par nud . En réponse à la dépêche GeneticInvasion : des algorithmes évolutionnaires pour un meilleur jeu. Évalué à 1.
Il n'y a pas d'équivalent à AC_CHECK_LIBRARY?
Avec les autotools ce genre de chose est triviale. La moindre des choses serait de pouvoir gérer un préfixe de compilation et aller y chercher les librairies (càd tester si libfoo.so existe et éventuellement s'il contient un symbole donné)
[^] # Re: Nouveautés ?
Posté par nud . En réponse à la dépêche Thunderbird 5 est sorti. Évalué à 1.
Ah, je sais pas, je n'ai jamais encore vu d'outlook 2010 chez mes clients. Seulement du 2007...
[^] # Re: préfixe de compilation
Posté par nud . En réponse à la dépêche GeneticInvasion : des algorithmes évolutionnaires pour un meilleur jeu. Évalué à 1.
JE suis une quiche en cmake, mais j'ai dû ajouter les lignes suivantes pour que cela fonctionne:
Évidemment c'est tout pourri. Ou alors j'ai foiré quelque chose?
Ceci dit, sympa le jeu, même si ça a tendance à faire crasher nouveau.
# préfixe de compilation
Posté par nud . En réponse à la dépêche GeneticInvasion : des algorithmes évolutionnaires pour un meilleur jeu. Évalué à 1.
Ça serait cool de supporter CMAKE_INSTALL_PREFIX pour les gens qui veulent builder sans polluer leur /usr/local... Si j'en crois la doc avec cmake c'est utilisé tout seul si tu utilises les macros FIND_*()
[^] # Re: Exemple concret de line(1)
Posté par nud . En réponse au journal Line meurt. Évalué à 1.
Pour ce genre d'usage il vaut mieux utiliser read...
Ça permet de diminuer le nombre de processes à forker, donc c'est plus rapide, efficace, bref, plus mieux.
[^] # Re: Commentaire pinailleur sur les unités
Posté par nud . En réponse au journal Trucs pour consommer moins et éteindre plus sur Intel. Évalué à 2.
Et la puissance est la mesure de l'énergie produite/consommée/transformée dans une période donnée...
[^] # Re: Il y a bien longtemps...
Posté par nud . En réponse au journal Une info sur KDE on Wayland. Évalué à 2.
Tu peux aussi avoir plusieurs threads: un pour la GUI et d'autres pour le reste. Tu peux même avoir plusieurs process pour être sûr, mais c'est peut-être plus chiant à gérer.