Troy McClure a écrit 2213 commentaires

c'est exactement ça :) quand une nouvelle version de gimp sort, les binaires sont fournis pour windows et je peux l'utiliser directement sous wine (ou bien sous windows mais saimal). Par contre si je veux utiliser la version native sur ma vieille ubuntu... faut compiler ou patienter..

je dis juste que dans ces cas là, et quand on s'appelle google, qu'est gros riche et tout puissant, on prend ses precautions "avant" et on arrete de developper des merdes windows only (dernier exemple: google chrome)

Quitte a faire un portage autant le faire pour de bon, si c'est pour faire les choses à moitié je vois pas trop l'interet de faire un binaire linux (avec plein de dependances sur des libs wine, x11, libc etc), plutot que de distribuer directement un exe (qui lui fonctionnera out-of-the-box sur toutes les distribs, pas de probleme de dependances sur 3 go de libs), en plus pas besoin de se casser les pieds à cross-compiler une version linux bref c'est plus facile à tout point de vue

(oui je trouve que ce que google a fait avec picasa c'est juste sale et moche et indigne d'eux)

pour bien faire faudrait une grosse toulbarre avec plein d'icones moches au dessus de chaque commentaire

et une syntaxe qui n'a rien a envier à ed (The standard UNIX editor)

attention quand même , il explique que les NFA permettent de faire des regexp qui ne peuvent pas exploser leur temps de calcul exponentiellement, mais dans la pratique, sur des regexp non pathologiques, l'implementation à base de NFA sera entre 3 et 10x plus lente qu'une implementation classique, du genre pcre. Tout en étant *beaucoup* moins puissante. ( http://gruntthepeon.free.fr/blog/index.php/2008/05/18/26-les(...) )

En gros y'a pas de miracle.

Merci pour ce journal.

--
Cordialement

je kiffe la sncf

Qu'en pense RMS ? N'est-ce pas plutot une mauvaise nouvelle pour tous les purs à durs à poil long du Logiciel Libre ?

effectivement y'a plein de choses interessantes dans ce thread.

En particulier le dernier paragraphe de http://article.gmane.org/gmane.comp.version-control.mercuria(...) (sur le non-merge de mercurial avec bzr) est assez instructif

J'ai peur que les temps soient durs pour les DVCS alternatifs, git est en train d'occuper tout l'espace et de monopoliser l'attention. ça m'embete un peu parce que j'ai choisi mercurial (après avoir utilisé darcs 1.x un certain temps) et ça serait dommage de le voir progressivement tomber dans l'oubli et être laissé de coté. Pareil pour darcs.

En plus j'ai moyennement confiance dans les kernel hackers pour faire des outils simples et ergonomiques, git est certainement le plus performant, mais l'approche "couteau suisse" linux-centric, avec 10000 options pour power users ne m'enchante pas plus que ça.

Pas de multi-tâche et multithread avec séparation concrète de l'espace utilisateur du noyau pour les processus nativement comme expliqué dans le chapitre 3 : le noyau linux, Éditions O'Reilly)

tu peux développer un peu, qu'est ce qui n'est pas séparé du noyau comme il faudrait ?

Il progresse bien, mais ne gère pas encore la couche orientée objet que les bon développeur matlab utilisent.

ou plutot ceux qui ne sont pas trop dégoutés, parce qu'avec 1 repertoire par classe et un fichier par méthode, faut aimer decouper son code en confettis.

Alors, quelles nouvelles features va-t-on bientot retrouver dans gnome et kde ?

pour Webkit il a fallu legerement leur rappeler leurs obligations de respecter la licence de khtml tout de meme

Une petite url pour appuyer tes dires et montrer que ce n'est pas du FUD ? Pour autant que je m'en souvienne, le seul probleme etait sur la forme des patchs, pas sur un non respect de license.

ras le bol des barbus aigris jamais contents

j'ai pas envie de perdre la matûrité des autotools.

à ce stade là on ne parle plus de maturité mais de putréfaction (qui sent le vieux pied moisi)

eh bien voila un commentaire a peu près aussi subtil que http://membres.lycos.fr/rocco75escp/ingenieurs.html !

j'adore

Moi ce qui me gene le plus c'est le memorisation des champs de formulaires pour certaines données sensibles. Exemple typique: le numero de carte banquaire , bien souvent firefox l'a mémorisé lors d'un achat precedent et le propose à la completion.. Je sais c'est plus la faute des sites de vente en ligne merdiques (mais nombreux voire majoritaires) que du pauvre firefox mais ça reste ennuyeux.
J'espère au moins que quand on met un "master password" sur les mots de passe de firefox, il s'en sert aussi pour chiffrer ces informations là ?

> Et ça veut dire qu'on peut faire des malware parce que ? Je ne vois pas le lien de cause à effet.

ça veut dire que les auteurs de malwares, et les auteurs de solutions de protection pourraient effectivement s'y interesser si ça permet de faire tourner certains bouts de code "sensible" dessus. Comme il n'y a pas (encore) d'outils de reverse engineering c'est forcement assez tentant comme solution d'obfuscation

il y a un compilateur dans l'api. Si j'ai bien compris, il accepte trois types d'entrées differentes: soit du code source (clCreateProgramWithSource) , soit du bytecode, soit du code déjà compilé pour une liste de cibles spécifiques (clCreateProgramWithBinary)

avec un peu de chance ils vont décider de le réécrire from scrach (ça ne sera que la quatrième fois)

c'est surement pour les DRM qu'ils faut tout l'artillerie , histoire qu'on s'évade pas

enorme