Stibb a écrit 759 commentaires

Ma pensée, c'est soit le gouvernement et les agences américaines de contre espionnage ne sont pas si fort que ça (on a vu des bruce willis se faire poursuivre par la moitier du FBI pour moins que ca dans la plupars des films américains ces 15 dernières années) et ne peuvent empecher ce genre de divulgation ?
- ils ne savent pas où sont les serveurs?
- leur CIA est capable de destituer des dictateurs en amérique du sud mais pas d'identifier et d'abattre les responsables du site?
- la NSA n'est pas capable, (ou n'importe quel CTU comme dans 24), de retracer n'importe quelle communication, remonter tous les serveurs?
- dite moi pas qu'ils ne peuvent pas couper les DNS du serveur?

A mon avis, techniquement, ils seraient capable d'empecher de tel divulgation, mais ils ne le font pas:
- soit parce que ça les arrangent in finé
- soit parce que la volonté politique pour bloquer wikileaks n'est pas assez forte (sous entendu ça soulèverait un tolé dans les médias, ...

Perso, je pense que c'est une tempete dans un verre d'eau, diplomatiquement, la suite risque d'être intéressante. Faire connaitre au grand publique ce que ce milieu connait déjà, ça fera avancer les choses.

ah oui, non, on veut pas 50 gui inutiles.

On en veut un qui fonctionne. Comme TortoiseGIT par exemple, il n'est pas mal du out, pas encore parfait, mais c'est déjà bien (j'ai meme l'impression que sous linux on n'a pas aussi efficace).

c'est une blague, la géolocalisation par wifi. Ca marche a peu pres à new york ou dans les grandes villes, mais ailleurs, hormis dans les gares, ça ne marche pas.

Par contre, le eyefi ne donne envie pour décharger les photo automatiquement les photo en studio sans sortir la carte. Reste à voir la rapidité

c'est celui que je visais effectivement... merci !

c'est lequel ton apn étanche? J'avais le panasonic ft1, il est parti 2 fois en réparation pour défaut d'étanchéité...

attend, les images sont toutes petites! il faut des crop à 100%.

Et puis, il faut qu'un test soit reproductible pour etre considéré comme valable, tous les parametres doivent etre donné. Bon, si on est incapable de trouver un test reproductible et inconstestable (ou mieux, plusieurs indépendant), c'est que le format est pourri.

théorie des gaz parfait. Gagne 10% et tes webmasters rajouteront 10% de flash/autre connerie en plus.

Bullshit.

On voit rien, les photo sont trop petites pour apprécier les différences. Faudrait utiliser des outils de comparaisons, notament PNSR, pour mesure la différence de qualité.

Evidement, il ne faut pas utiliser une source en JPG.

Ensuite, un meilleurs taux de compression ne suffit pas. On s'en contre fiche de gagner 10%, on a tous des connexions ADSL et on télécharge des applets flash bcp plus gros sur les pages web. Des formats de compressions meilleurs que le mp3 existent, mais n'ont jamais percé (sauf AAC) pour le grand public. Celui-ci est stupide et ne change que pour un truc qui marche, apporte quelque chose de vraiment signifiant pour lui, ou corrige un défaut vraiment flagrant (c'est par pour les brevets que le gif a disparu pour le png, mais pour les 256 couleurs et le canal alpha).

Quant au JPEG2000, effectivement personne ne l'utilisent, parce que personne n'a d'intéret à l'utiliser. Qu'apporte-t-il par rapport au jpeg? On veut du sans perte => png. On accepte de la perte => jpeg est tres bien. Le jpeg2000 est utilisé au ciné pour les diffusions du cinéma numériques parce que les constructeurs et diffuseurs veulent avant tout la qualité de diffusion, mais pour le grand publique, le jpeg2000, il n'en veut pas. En tout cas, tant que les constructeurs d'appareil photo et de logiciel de retouche ne le supporteront pas comme le jpeg.

Et croire que sortir un codec image suffit à remplacer des formats existant, c'est ignorer que les images sont retoucher dans des logiciels, affichés dans d'autres, traité, redimensionner. C'est toute la chaine qui doit changer. Et pour force à changer, il faut apporter une VRAI valeur ajouter. Avec les bandes passantes actuelles, gagner 5-10% n'intéresse personne. Si on parlait de 50-60% alors là oui l'intéret serait flagrant.

punaise, pensez à ceux qui n'ont pas (par obligation) une distribution avec un apt ou yum... je peux vous assurez qu'installer python sur un vieux RHES c'est franchement long et chiant...

ah non, l'outil idéale... mais en python.... arhggggg

punaise, pour un outil tel que ça, c'est en C/C++ avec le moins de dépendance possible qu'il faut l'écrire. Voit-on un tar, bzip, cp, scp, rsync, ..., écrit en python qui requiert un gros runtime, des dépendances python à tir la rigaux? non, et c'est pour de bonne raison.

Franchement, y a des claques qui se perdent. Alors, oui, python, c'est super, c'est génial, on code rapidement, c'est à la mode, (c'est aussi terriblement moche, cette histoire d'indentation me sort par les trous du nez, mais bon, ça c'est pour le FUD), mais si l'auteur souhaite que son outil termine utilisé par tout le monde en remplaçant de ce bon vieux cp ou scp, qu'il le réécrive en C ou c++ avec qque dépendances sur des bibliothèques que tout le monde a (libstd, glib, ..) et pis c'est tout!

Quel est donc cette manie de toujours vouloir écrire en langage haut niveau une brique logicielle qui peut s'avérer aussi essentielle... ????

heu, avoir un labo de R&B ne veut strictement rien dire. FT comme plein d'autre boite ne sont bons qu'à prendre ce que les autres font (intégrateurs) ou même exiger des dev envers ses constructeurs (j'ai bosser pour motorola avant, et les exigeantes Orange étaient... stupides!)

Leur plus gros probleme, c'est qu'ils s'en contre fiche de l'utilisateur. Là où Apple fait du super boulot c'est en plaisant à la fois aux utilisateurs et a son propre porte monnaie (en marchant sur Orange, par exemple). Les opérateurs ont les boules car ils ne veulent pas finir comme les FAI, ie, juste des fournisseur de tuyaux. Mais ils n'ont pas compris que les utilisateurs ne veulent PAS de l'application Orange TV, le Orange Store, etc. Bref, le branding de chaque marque sur les téléphones portables est absolument contre productif, et ce n'est pas faute d'avoir tenter de le leur expliquer. Ils sont encore à vouloir une interface propre (et absolument inutilisable), car evidement ils veulent une image de marque mais ne comprennent pas que les utilisateurs n'en veulent pas !

Bref, tant qu'ils ne réfléchiront pas "utilisateurs" avant "mon contenu chéri", ils ne trouveront jamais comme faire pour que l'utilisateur soit rentable (et il l'est, l'app store marche terriblement bien, le consommateur est prêt à payer un max pour un service hors du commun)....

aucune chance que ça aboutisse. Orange n'est pas un développeur de logiciel, comme Google (dont la plupart de ses outils sont maison) et apple (qui a fait sa réputation sur la qualité technique de ses logiciels). Ils ne savent pas faire du soft. Au pire ils embaucheront des stagières.

Le but du systeme d'exploitation byOrange est clairement de regagner le leadership sur l'évolution des produits (et imposer des feature payante) en tentant de récupérer des part de marché sur android market ou appstore. Mais c'est perdu d'avance. Ils ne PEUVENT pas y arriver. Ils sont avant tous les tecos (infrastructures,...), pas des développeur soft. La division logicielle d'orange n'a jamais briller par ses réalisations. Même Microsoft n'y arrive pas!

M'enfin, s'ils bousculent un peu Apple ou Google, ça ne peut que faire du bien.

décentralisé comme inutilisable ou décentralisé comme jabber?

Franchement, ok face de bouc capture une quantité de donnée personnelles. Mais le gros intéret c'est que c'est achement simple.

Déjà, quand je vois décentralisé, je vois "chacun pourra herbergé son propre serveur chez soit". Bravo, comme ça si je ne peux plus envoyer de message c'est que la passerelle (ou l'équivalent) sera morte. Super!
Ensuite, comment me connecte-je à mes parents sans avoir à leur installer un serveur connecté en permanence? Ils se connectent chez moi? Mais j'ai pas que ça à foutre d'avoir un PC allumé tous le temps (en plus je reboot sous windows, je l'éteind, etc).

Ou alors on va avoir une myriade de noeuds primaires à qui se connecter (comme jabber). Déjà, j'espère que c'est mieux foutu au niveau du load balancing, parce que jabber, quand ma passerelle est tombée, je ne peux plus m'y connecter. Se connecter à une autre signifie faire un long processus de migration des contacts. Inacceptable pour un service que l'on veut "simple".

La seule solution à mon avis est la mise en place d'une fondation qui développe le code source ET l'hébergement des serveurs, fondation qui publie les codes sources et qui donne, par quelconque moyen, la possibilité de vérifier que les données perso ne sont pas stockée ni revendue. Mais là il faut encore trouver un business modele fort si on veut concurence facebook.
Du coup, le coté décentralisé, on s'en contrefiche. Ou alors VRAIMENT décentralisé, ie, quelque soit le noeud auquel tu te connectes tu as toujours accès au réseau. Mais où serait stockée ton mur/messages/photo? en P2P perdu dans la longtrail?

Vaste programme. Bref, tout ça pour dire, je préfèrerais un équivalent facebook centralisé mais s'engageant à respecter la vie privée maintenant ET plus tard (mais financièrement ça sera très difficile voir impossible) qu'à une solution décentralisée qui, in finé, ne pourra PAS être aussi simple et efficace que FB.

Je dis fb, mais tous les autres réseaux sociaux sont pareils.

Pourquoi utilise-je facebook? J'adore recevoir des vidéo à la con, les status des amis, et surtout, un compte facebook (d'expérience) est plus stable qu'un compte Email. Combien de mail j'ai en double, je ne sais plus lequel est le bon, combien de personne je connais ont changé d'adresse sans me le dire, ... Un compte FB, ça existe et c'est nominatif (ok, y en a qui mette leur pseudo, mais Mr Michou est Mr Michou point barre). Néanmoins, si demain arrive un service plus efficace ou une gestion des mail plus efficace, on pourra s'en passer sans état d'ame.

heu pardon, mais c'est le but de toute entreprise. Faire des sous.

Sauf qu'apple réussi la où bcp d'autres échoue. MS cherche dans tous les coins et sortent des trucs pas fini, pas stable, et surtout, n'arrivent pas à cultiver l'image d'une entreprise aux produits bien finis, polissés, innovant. Apple le fait.

Dire que tout ce que fait Apple n'est que du Marketing, c'est terriblement stupide. Ils savent très bien faire les trois choses suivantes : innover, intégrer les technologies existantes mais pas exploiter "comme il faut" par les concurents (les téléphones portables existaient bien avant l'iphone, mais au niveau de l'interface et surtout de l'utilisation, apple à foutu une grosse claque avec leur paradygme d'interaction où l'on sort du sacrosaint "souris/menu/fenetre") ET le mettre en valeur par un marketing bien rôder.


Travaillant dans l'IHM aujourd'hui (sur tel portable, web,...), je peux vous dire qu'il y a un "avant" iphone, et un "après". Apple n'a certe pas inventer la roue, mais l'a faite parfaitement ronde alors que les autres s'obstinaient à la vouloir carrée.

eclipse marche tres bien pour du c++, il parse proprement la sortie de gcc et t'affiche les erreurs inline.

Le top c'est quand meme visual studio, qui peut le faire quasiment en tache de fond, et pourtant il lance bien un executable distinct. Donc c'est possible de faire un environnement détaché du compilo tout en étant très bien intégré.

Souvent dans les grosses boites, ce genre de décision n'est pas pris par l'admin, il faut réunir une tornioles de personne pour décider d'ouvrir tel port, qui évaluera les risques, etc. Ca prend du temps. Beaucoup trop de temps.

Résultat tout passe sur HTTP.

branche perso = le dev fait ce qu'il veut
branche de maitnenance, trunk => ca doit compiler, voir meme (celon politique de la boite) ça doit passer un certain nombre de test automatiques.

pas s'il est chez le copain.

tu créé tes branches en local. Tres bien. Mais il faut rajouter une étape, "push" pour envoyer ta branche sur le repo "centrale". Ou alors il faut que ton collegue configure un "remote" pour acceder à ta branche local.

git j'adore, mais j'apprécie aussi la centralisation de SVN (tout sur le même serveur, tu n'as qu'a connaitre le nom de la branche de dev du pote et tu peux travailler dessus).

Bien séparé son travail est stupide, quand on touche du code en profondeur on impactera forcément le travail du copain. Le tout c'est de résoudre les conflits rapidement, efficacement, et surtout, une seule fois.

Ce qui m'énerve avec SVN ou CVS, c'est parfois, ma branche diverge, je me mets à jour avec le trunk, il y a des conflit, je gère je règle. Puis je continue. Je me remet à jour. Et tous mes conflits déjà résolu réapparaissent. Parce que je n'ai pas le bon nombre de commit, parce que je n'ai pas telle extension SVN ou pour une raison X ou Y, le truc ne se fait pas comme il faut et il faut recommencer. C'est inadmissible.

Je suis habitué à développer dans ma branche pour effectué des petits tags intérmédiaire (tel truc fonctionne maintenant, etc) avant de commiter. Le développement incrémentiel est indispensable. Mais je ne VEUX pas perdre du temps dans un merge alors que le logiciel a toutes les informations (ou devrait l'avoir) pour le faire comme il faut.

Le coté décentralisé ne m'attire pas plus que ça au final, on reproduira un comportement centralisé (un golden repository chez qui tout le monde commit). Et ça me gene même un peu, le fait qu'une personne ne puisse pas facilement prendre ta branche comme du dit "prend ma branche de dév truc_machin, il faut configurer un "remote, ...". Complexe.
Mais le merge de git, j'ai gouter, j'ai vu, et je veux la même chose à la maison !

effectivement, bazaar semble avoir une approche un peu plus conviviale et centrer sur le développement.

merci pour vos deux commentaires constructifs


Hg, c'est surtout 2 caractères proches sur le clavier ;)

Je pense effectivement qu'il y a une notion de "culture" dans les projets : un projet qui a une culture de simplicité et de courbe d'apprentissage pas trop dûr engendrera un écosysteme d'outils avec la même approche. Git est hardcore et tous les projets autour le sont, malheureusement j'ai l'impression.

je connais. Mais ce n'est pas pratique d'aller dans un menu constament alors que ça devrait être fait par défaut. C'est toujours la question d'ergonomie : une option cachées dans un menu/sous menu qui est constament utilisée n'a rien à faire dans un endroit aussi innaccessible.

Et gitk/git gui sont pas mal pour faire du commit simple, mais dès que tu veux aller un peu plus loin tu retombes dans la ligne de commande.

Et surtout, une interface graphique avec des bouton et des champs partout n'a aucun intéret par rapport à la ligne de commande. Il faut une interface propre, orientée processessus (quand je pars dans une session de merge, je ne veux pas voir tout ce qui concerne la création de tag).

pas trouvé de merge dans egit 0.8 que j'ai sous helios. Manque beaucoup d'autre chose, comme l'historique sur le dossier (je l'avait à un moment, puis plus rien).

sinon, effectivement, l'idéal sera un repo SVN avec un client git-svn ou hg_svn. Mais avec une interface graphique propre pour faire des pull/push ;)

CVS n'est qu'un gestion de version de fichier, pas de révision de l'arbre de code.
SVN est un gestionnaire de version de dossier, pas de résition de l'arbre de code dans le sens le plus pûr.

SVN est presque idéal néanmoins:
- renomme un fichier et tu es mort lors des merges (rien que ça ça décridibilise la notion de gestionnaire de code)
- les merges demandent trop d'effort (je suis faignant). Je dois faire attention de ne pas oublier un commit lors d'un merge, alors que ce que je veux c'est "branche A => Branche B". Merci au revoir. C'est possible de le faire, l'ancètre commun est facile à trouver. Git et Hg le font très bien. Collabnet et son merge utility permet de simplifier le truc, néanmoins ce n'est pas idéale.

Maintenir une branche de dev et une branche de production doit être le plus simple possible, avec une vue claire de ce qui est appliquée ou pas. Et surtout une vue efficace des merges. Sur les projets SVN, j'utilise le plugin revision history de trac, qui est pas mal (mais il manque des svn:info.... pourquoi il y a des "extensions" (loi de murphy, qui dit extention dit forcément "manquante") comme ça, alors que ça devrait être obligatoire.