Philippe F a écrit 2214 commentaires

C'est sur qu'ils auraient eu moins de boulot, ils n'auraient tout simplement jamais pu faire leur application !

Et oui, on est vendredi !

J'aime bien Redmine mais un point faible je trouve, c'est qu'il n'est pas possible d'éditer le wiki offline. Sur google code par exemple, le wiki est géré via un gestionnaire de sources et c'est bien pratique pour les gens comme moi qui passent beaucoup de temps dans le train.

Sinon, globalement, c'est un projet qui assure !

Et lisaac ?

Merci à Francesco car la dépêche n'indique pas que ce machin ne sert que pour du java.

Sur le site web, rien dans la page "features" ou dans la FAQ à propos d'un ou de plusieurs autres types de langages. A croire que C#, C++, C, Objective C, Python, Ruby sont des langages tellement mineurs dans l'industrie qu'ils ne méritent pas une mention pour dire qu'on les supporte pas !

M. Gaudin voudra bien j'espère une prochaine fois indiquer cette restriction dans le corps de la dépêche, pour tout ceux qui ont la chance de ne pas programmer en Java.

Un certain nombre de pays non encore contrôlés par Visa / Mastercard mettent en place des réseaux alternatifs de paiement justement pour ce type de raison.

En Pologne, il est plus courant de payer par internet par un système de virement compte à compe un peu évolué que par carte bancaire.

A Singapour, la carte fait-maison pour le paiement marche très bien et résiste vaille que vaille aux pressions du cartel Visa Mastercard American Express.

Bossant dans la carte à puce, on a plusieurs fois été contacté par des pays souhaitant faire ce genre de chose. La plupart cependant n'ont pas le niveau technique pour le faire. Il faut vraiment être calé en sécurité pour faire ça. Mais au final, c'est un investissement national qui paye pour le pays.

Mercurial a été lancé a la même seconde que git : le jour où la licence Bitkeeper a été supprimée.

Un concept sympa, un nom original, un site en redmine, du code en Python et un Qt. Ce logiciel a vraiment tout pour me plaire !

Dommage que je n'y vois pas d'utilité personnelle, ça aurait été avec plaisir.

hint: PyQt

Ce que j'aime bien avec webboob, c'est tripoter les fichiers de config.

( bon, ça vole pas très haut mais pour un lundi, ça fait du bien ).

J'ai constaté quand même des inconvénients au principe du DVCS. Dans une petite équipe, avec svn et les mails de commits, on sait assez bien ce qui se passe.

Avec un DVCS, les membres ont tendance à garder pour eux leurs développement en cours, et à faire des push moins souvent qu'ils ne faisaient de commits. Du coup, on a des périodes où tout le monde bosse sur un truc, mais ce n'est pas visible sur le dépot principal.

Autre facteur, chaque opérateur a sa petite technologie d'antenne. Pas de grandes révolutions dans la partie analogique de l'antenne elle-même, mais dès qu'on passe dans la partie numérique, il y a des protocoles, ca discute, ça se met à jour, ça s'authentifie et tout le toutim.

Free espère d'ailleurs avoir des coût d'exploitations des antennes inférieurs à ses concurrents, et des services nettement supérieur en utilisant les dernières techno hard et soft sur leurs équipements antennes et noeuds de leur réseau mobile.

Je me posais exactement la même question. De mon point de vue naïf, j'ai pas l'impression que ce serveur soit prêt pour gérer une montée en charge significative.

Le Design a l'air simple, c'est un atout, mais ça va pas plus loin. Des gens maîtrisant un peu plus la technique pourraient-ils nous éclairer ?

Parce que côté serveur web, on commence à avoir pas mal de compétition à apache, mais les autres projets que j'avais survolé m'avaient l'air mieux pensés que celui-ci.

Quick, ca semble de la bombe !

J'ai pas eu l'occasion de jouer avec l'interface mais si j'ai bien compris les démos et les exemples, ça permet de décrire une interface graphique de façon déclarative avec les notions suivantes :

- description de tous les items de l'interface, leur placement respectifs, leur propriété de base. Jusque là, rien d'extraordinaire.

- description d'un automate d'état, qui décrit les transitions avec pour chaque transition, l'évènement qui la déclenche, une condition de validation, les propriétés des objets à faire changer, signaux éventuels à émettre et des algo pour rendre les transitions fluides.

Ça permet vraiment de décrire des effets complexes de façon déclarative, c'est vraiment très fort. Pour le mobiles, c'est parfait, toutes les transitions à la iPhone se feront hyper simplement.

On peut trouver pas mal d'exemples et de video en cherchant Qt Quick sur google on regardant le blog de Qt. Quelques une comme ça :

http://jryannel.wordpress.com/ pour des mini exemples concrets
http://labs.qt.nokia.com/2009/05/13/qt-declarative-ui/

Justement, est-ce que t'as des nouvelles de PySide ? Est-ce que ça marche aujourd'hui ?

La dernière fois que j'ai regardé, ça avait l'air d'un projet de loser. A part proposer d'avoir à la fois les méthodes en MixedCase et underscore (genre avoir toString() et to_string() ), il y avait pas grand chose de concret sur le développement.

Le support de Python avait l'air quand même assez ridicule, l'utilisation de boost allait bouffer des tonnes de mémoire, et j'en passe.

Perso, je suis pas prêt de lacher l'excellent travail de Phil Thompson pour ça.

Et en plus, ils ont choisi une licence qui favorise le développement proprio !

Moi, ce qui m'inquiète pour Gnome, c'est Gtk.


Parce que Gtk a beau être plus ou moins libre (la LGPL, ça vaut quand même pas une bonne GPL), RedHat (principal contributeur de Gtk) pourrait bien l'orienter principalement vers l'embarqué. Voire même l'orienter exclusivement vers l'embarqué.


En plus, autant pour Qt, on a la FreeQt Foundation ( http://www.kde.org/community/whatiskde/kdefreeqtfoundation.p(...) ) qui garantit que Qt sera toujours GPL si Nokia abandonne le projet, autant pour Gtk, on a pas du tout ce type de garantie. Si Redhat décide un jour d'arrêter son investissement dans Gtk, la bibliothèque va sérieusement se retrouver au ralenti.

Euh, ce que tu dis tends plutôt à prouver qu'ils ne savaient pas ce qu'il faisaient, non ? Sinon, ils n'auraient pas laisser cette image 3 jours de suite. Et ils ne t'auraient pas accusé d'avoir piraté leur site web.

J'aurai au moins mentionné dans l'image qu'elle est utilisée illégalement par le site en question. Ca fait toujours plus réagir quand tous les utilisateurs voient qu'on fait quelque chose d'illégal.

Moi je pense plutôt que c'est la faute à Martine Aubry avec les 35 heures, et surtout à Linux qu'un tout pourrite.

Kate permet d'utiliser quelques commandes vim, mais pas tant que ça. Et tout les scripts ne sont pas supportés.

Vim a encore de longues années devant lui !

Unladen Swallow qui est d'ailleurs au point mort depuis plusieurs mois. Les seuls contributeurs encore actifs sont un stagiaire et un mec extérieur à google, visiblement bénévole...

Après avoir essayé mercurial puis git, je trouve mercurial mieux. Même si il y a qqes fonctionnalités qu'on ne retrouve pas dans mercurial par rapport à git, je trouve le projet beaucoup plus simple d'approche :
- les commandes ont des noms relativement intuitifs
- il y a moins de commandes
- la doc et le tutorial sont très bien foutus
- ca marche nickel sous windows, alors que j'ai eu des problèmes avec git
- au niveau GUI, ceux que j'ai eu l'occasion d'utiliser pour git me donnait l'impression d'être dans les années 80. Alors que avec TortoiseHg ou hgtk, j'ai plus l'impression d'être au 21e siècle.

A mon sens, git, même s'il est très puissant souffre d'un côté hardcore developer qu'on ne retrouve pas sous mercurial. Et ça s'en ressent, dans les doc, dans le tutoriaux, dans les GUI, dans les messages d'erreurs, dans l'aide des commandes, etc.

git a quand même été développé par un mec qui gérait des milliers de patch avec l'email comme seul outil.

Il est d'ailleurs significatif que des gens qui apprécient git se permettent de t'expliquer que tu as tort de ne pas utiliser la ligne de commande.

Sinon, hg, c'est quand même un caractère de moins à taper que git, faut surtout pas l'oublier.

Skype optimise à mort et fait du PC à PC si les deux PC sont sur le même réseau. Et si jamais ton PC est sur une IP publique, il servira même de relai à d'autres PC skype et donc la comme ne passera pas par les serveurs skype. D'un point de vue architecture, ils assurent !

Mon Dell XPS M1330 (pas sous ubuntu, certe) se porte comme un charme. Pourtant je l'ouvre et le ferme plusieurs fois par jour :
- ouverture/fermeture sur le quai de la gare en attendant mon train
- ouverture/fermeture dans le train pendant les 15 minutes de trajet
- ouverture/fermeture dans le RER pendant 5 minutes (pour finir de taper mes documents)
- utilisation au boulot avec branchage de prise USB, RJ75, VGA
- départ du boulot ou j'arrache toutes les prises comme un sauvage
- ouverture/fermeture sur le quai de la gare en attendant mon train
- ouverture/fermeture dans le train pendant les 15 minutes de trajet
- pafois rebranchage à la maison

Malgré toutes ces ouvertures / fermetures et branchage / débranchage intempestifs, il tourne toujours aussi bien. Meme pas encore vu de fragilité sur les divers connecteurs.

Comme quoi, parfois, le matos resiste.

L'article semble surtout dire que les failles seraient plus facilement exploitables par la disponibilité du code source, ce qui me semble assez cohérent. De fait, entre trouver une faille dans un logiciel dont on a le code et dans un dont on ne l'a pas, il semble évident que ce sera plus facile dans le premier cas.

J'ai souvenir d'un concours d'il y a une dizaine d'année sur slashdot pour craquer un site web commerçant. Le gagnant avait fait une analyse très poussée du code pour trouver au moins 3 vecteurs d'attaques. Deux s'étaient révélés inexploitables mais le 3e avait fini par lui donné l'accès root.

L'exploit n'aurait pas été possible dans ce cas sans les sources. Ou aurait pris beaucoup beaucoup plus de temps.