ribwund a écrit 1439 commentaires

Ensuite, la compilation est faite : le plus difficile et le plus lourd est la transformation des sources vers le bytecode (parsage des fichiers d'en-tête, optimisations, etc). Du côté client, il ne faut que générer le fichier assembleur, l'assembleur et le lier.

C'est faux, il reste bien évidemment toutes les optimisations archi-dépendantes (code selection, coalescing, spilling et regalloc, scheduling, etc.) et/ou les optimisations inter-procédurales. Sinon ton système n'apporterait aucun gain (pas de spécialisation).


Sinon à mon avis quitte à se taper du bitcode, autant faire de la compil dynamique et faire de l'optimisation "runtime".

Tu économises (un peu) de bande passante mais en contrepartie tu fais compiler N fois un programme alors qu'auparavant il était compilé une fois par architecture.

Sinon le bitcode llvm n'est pas toujours portable d'une architecture à l'autre.

Par contre les blocks/libdispatch de Apple 10.6 seraient intéressants à porter sous linux, des volontaires ?

http://arstechnica.com/apple/reviews/2009/08/mac-os-x-10-6.a(...)

C'est intéressant, mais ces ampoules à incandescence de nouvelle génération échapperont-elles à l'interdiction de la vente d'ampoules à incandescence en Europe ?

Si tu regardes les annexes de la directives, les tableaux 1, 2 et 3 indiquent les exigences d'efficacité à remplir. Si ils remplissent ces exigences, pas de problème.

http://eur-lex.europa.eu/LexUriServ/LexUriServ.do?uri=OJ:L:2(...)

Oui mais ça fait quelques semaines que des grands journaux confirment, et quand les concurrents qui stoppent le developpement de leurs produits, ils doivent pas le faire pour le plaisir.

(et c'est normal que ça fasse des années qu'il y a des rumeurs, d'après le wsj, ils ont developpé le concept plusieurs fois avant de l'abandonner)

La rentrée risque d'être agité sur ce marché la. A priori Apple devrait annoncer sa tablet dans les prochaines semaines/mois. Les rumeurs disent que la plupart des projet de tablet sont gelés en attendant l'annonce de Apple vu qu'ils veulent pas être completement largués.

(du coup j'ai un peu peur pour le crunchpad, qui va arriver quelques mois trop tot).

Y'a rien qui l'empeche (y'a même une démo d'un client curses dans la vidéo de la keynote). Par contre pour l'instant vu que y'a pas de tendance vers la normalisation du protocol client/serveur, y'a pas non plus de mouvement vers des clients interopérables.

Puisque tu veux lancer le débat sur xmpp/wave, ce que je trouve dommage c'est que bien que le protocole de serveur à serveur utilise xmpp et soit documenté, le protocol client/serveur est lui ad-hoc, dépendant des technologies google (protobuf). On risque donc de se retrouver avec des clients non-interopérables, sur des protocols propriétaires...

En général j'utilise mq, pour faire des patches propres. Pour les branches locales bookmarks ça doit être le plus adaptés, ou alors les "named branches" si c'est des branches qui durent longtemps et où tu veux conserver le nom dans l'historique.

Sinon des clones locaux c'est pas mal non plus, et c'est simple (et ça prend pas trop de place vu que ça utilise des hardlinks).

Dans tous les cas si t'as des problèmes, hésite pas à passer sur irc (#mercurial sur freenode) ou à demander sur la mailing list.

Pour la conversion la méthode quasi-infaillible c'est git->hg, vu que les deux systèmes sont assez proches.

Have fun!

Y'a un tableau sur ce qu'il faut faire en cas de moisissure :)

http://www.fsis.usda.gov/FactSheets/Molds_On_Food/#16

D'ailleurs, j'ai pas vraiment trouvé de réponse sur le net, est-il possible d'avoir un index comme dans git ? (obligeant de sélectionner ce qu'on commit) voir même en utilisant un plugin hein.
On peut évidemment choisir lors du commit, mais j'aime bien le fonctionnement inverse

A part l'extension record, qui permet de choisir au commit ce qu'on veut mettre, il n'y a pas de truc "persistant" qui permettrait de dire "ça c'est pour le prochain commit". C'est pas un truc dur à faire, je pense que personne n'a trop eu le besoin (et la plupart des gens aiment pas trop comme approche, vu que ça fait committer des trucs pas testé).

Sinon y'a mq qui permet de faire ça et plein d'autres choses (principalement faire des séries de patchs propres), mais c'est pour les utilisateurs avancés.

Au fait, pourquoi être dev hg (si c'est pour le "plaisir") et pas sur un autre ? (en gros pourquoi l'avoir choisit ?)

Oui, c'est pour le plaisir.
D'abord, en 2005 quand git et hg ont été crée, hg était vraiment devant (git avait pas de repack et donc les repos prenaient quelques gigas, pas d'interface utilisateur, etc.), et c'est le moment où j'ai commencé à contribuer.
Git avait pas grand chose pour lui, sauf le fait d'être crée par Linus, mais bon hg était pas en reste, Matt étant une personne très intelligente (et également respecté dans la communauté du kernel).
Ensuite c'est en python, et donc, à mon avis, plus agréable. Y'a pas besoin de 50 lignes de code pour les trucs simples de l'interface utilisateur (qui ont pas besoin d'être rapide), ou pour les accès réseaux. En général le code est plus homogène: git s'est amélioré depuis, mais entre du C+python, et du C+sh+perl, j'avais trouvé mon camp ;)

Enfin bzr c'était juste un truc très très lent à l'époque, avec du python over-engineeré (du xml, etc.), donc j'ai jamais sérieusement considéré. D'ailleurs canonical a failli abandonné bzr pour hg à un moment tellement ils avaient du mal, ça n'a pas eu lieu pour des problèmes de licence (ils voulaient le pouvoir sur le copyright, pour launchpad qui était pas libre).

Et aussi, la communauté de mercurial est super sympa, les gens sont aimables sur irc et la mailing list, ça compte aussi quand on contribue à un projet.

Non c'est le document qui est mauvais, il n'y a pas de différence (d'autres gens le disent dans les commentaires). D'ailleurs le O(patch) pour le stockage de git c'est un peu un mensonge, vu que ce n'est vrai que après le repack (c'était un des problèmes initiaux de git).

Disclaimer: je suis dev hg, et je connais bien le fonctionnement interne de git, et un peu celui de bzr, je suis plutôt certain de ce que je raconte ;)

Ben en fait c'est surtout, je crois (mais me trompe peut-être), qu'il utilise aussi des snapshots pour stocker les modifs et non des changesets (bzr utilise aussi des snapshots, hg des changesets) ce qui doit simplifier un peu les choses.

Non, tu te trompes. Ils font tous pareils, ils stockent un snapshot de repo à un instant donné. Après, par défaut git n'optimise rien (il stocke une nouvelle copie de tous les fichiers modifiés), mais lorsqu'on repack il va construire un paquet de delta pour optimiser la taille.

Au contraire hg va directement construire des deltas (plus simples que ceux de git après repack) tout en faisant attention à limiter la taille totale: si la version de base + les deltas sont plus gros que deux fois le texte, alors il stocke une version entière, il peut donc toujours récuperer la version en O(taille du texte), la complexité est bornée !

Mais tout ça c'est des optimisations de format de stockage, en pratique on pourrait utiliser le format de git pour hg et vice-versa.

En fait, je pensais qu'un jour un système arriverait enfin à trouver ces changements sans problème et sans intervention manuelle. Je crois que git en est pas très loin, avec l'histoire d'index venant perturber un poil aussi.

En fait git ne fait *rien*. Il ne stocke aucune information sur le mouvement du code ou du fichier mais essaie de le découvrir lors d'un merge avec des heuristiques.

Le similarity, ça dépend des usages, si t'as l'habitude de faire des mv+edit (c'est pas vraiment une bonne idée), ou pas.

Pour les branches, oui c'est mieux d'utiliser les bookmarks, mais activer une extension c'est pas très compliqué non plus :)
J'avais trouvé cet article pas mal pour expliquer les différentes branches de hg:http://nubyonrails.com/articles/five-features-from-mercurial(...)

D'un autre coté si on parle du milieu des années 90, quand beamer n'existait pas (et je sais pas si prosper existait), il a peut être pas eu tort. ;)

Et il utilise ALSA+Jack comme c'est recommandé pour les usages pro.

C'est pas un phénomène inévitable quand 90% de ce qu'on lit sur son ordi/sur le net est en anglais, ce qui doit être le cas de pas mal de personnes ?

Je commentais ton discours sur les "pirates" pas celui sur les artistes.

Les partis pirates ont plutôt comme discours "Vos licences elles puent donc on ne les respecte pas."

C'est un peu simpliste quand même. Si tu te plonges dans l'historique du copyright, tu vois que c'est un droit très récent (et donc pas forcement quelque chose de "naturel", en tout cas si on le compare au droit de propriété) et qui a souvent fait l'objet de débat (Beaumarchais vs. Condorcet par exemple) notamment sur l'opposition entre les droits du public et les droits des auteurs.
On retrouve le même genre de chose derrière les débats originaux des brevets (qui étaient fait pour favoriser la diffusion de la connaissance).

De la lecture:
Carla Hesse - "The rise of intellectual property, 700 B.C. - A.D. 2000: an idea in the balance"
http://www.amacad.org/publications/spring2002/hesse.pdf
http://scinfolex.wordpress.com/2009/08/13/saint-finnian-et-l(...)

Une vidéo qui part un peu dans le n'importe quoi, mais qui apporte des éléments interessants sur la création artistique:
http://www.ted.com/index.php/talks/elizabeth_gilbert_on_geni(...)

Du côté "pirate", maitenant, pour aller plus loin on peut y voir aussi beaucoup d'hypocrisie : t'as des tas d'opportunistes qui tentent de profiter du système non pour le libérer mais pour faire de l'argent par tout les moyens possible. Le côté très lié au milieu du porno, les systèmes comme rapidshare dont le but est de fournir du contenu pirate contre rémunération, les cracks virussés, et j'en passe, pas forcément besoin de détailler.

Je pense que c'est la pénalisation du partage d'œuvres qui fait vivre ces gens là. Et plus les politiques s'attaqueront au système, plus ce sera intéressant pour eux (sachant que un certain nombre de gens sont prêt à mettre jusqu'à 20 EUR par mois). À mon avis l'étape ultime sera le jour où des pays qui ne suivent pas l'OMPI, annonceront publiquement leur statut de paradis digital.

Reste le viol de la loi, grosse différence fondamentale.

Qui ne contourne pas la DADVSI pour lire des fichiers avec DRM, des DVD, etc. ?

En France, y'a surtout 3 partis pirate. Et j'ai pas l'impression qu'ils aient une légitimité, c'est pas des gens qu'on a vu dans les derniers combats, je doute qu'on les croise à l'Assemblée pendant HADOPI...

Et /proc/sys/vm/mmap_min_addr ça donne quoi ?

Y'a Ksplice: http://lwn.net/Articles/340477/

Sachant que le mec qui a publié l'exploit est un dev de grsec, y'a des chances.