benja a écrit 1211 commentaires

Faudrait arrêter la fumette hein. Parce que bon les pietons qui déboulent d'où on ne sait où, c'est monnaie courrante. Fais moi croire que t'arrives à scrutter le trottoire constemment ce qui me semble bien dangereux et inutile s'il déboule en passant derrière une camionnette garée!. Alors avant de parler de cyclistes irresponsables, on ferrait mieux d'éduquer les pietons à regarder avant de traverser. Comme l'a dit dawar, les automobilistes ont l'immense avantage de se faire entendre. Alors venir dire "oui mais il suffit de ralentir dans les zones à risques" ça me fait bien marrer, surtout qu'en ville c'est un peu près partout ! (Sauf quand tu es dans la circulation dense, paradoxalement).

Personnelement et je n'en suis pas fier, il m'est déja arriver de chopper un pieton (j'ai pu freiner et l'impact fut minime) ou inversément de me faire prendre part un vélo (là ça été moins drôle pour le petit gars qui se trouvait sur le porte bagage). Je touche du bois, je n'ai pas encore goûté à la portière qui est, sans aucuns doutes, la partie la plus dangereuse d'une voiture :)

Alors venir conseiller aux cyclistes de tenir leur droite au maximum pour que les voitures puissent les frôler plus facilement., je le prends comme un encouragement au suicide.

Tellement vrai. Même sur des machines récentes, aptitude est une limace.

Heu faudrait pas exagèrer quand même... Il est peut-être "lent" mais il faut mettre cela en proportion avec le travail qu'il accompli ! À comparer avec les lancements successifs d'apt-get pour effectuer la même tâche (*) où à une instance de synaptic. Si l'on ne craint pas les guerres de religions, on peut aussi comparer avec yum(ex) et packagekit :p

Remarque, j'ai pris l'habitude de lancer aptitude pour faire la maj de mon arm (32Mo) et je n'ai jamais eu à me plaindre. Certes ce n'est pas rapide mais je n'ai jamais pensé à regarder son occupation mémoire. Je suppose aussi qu'il suffit d'avoir suffisemment de swap pour éviter l'oom killer (qui pourrait tout aussi bien killer dpkg :-/).

(*): genre contrôler les dépendances (inverses) de quelques paquets, bonjour les crampes aux doigts.

gni ?
Justement, sur ce genre de machine avec un lecteur de cd-rom antique, la net install s'avère plus rapide (pour une idée, la vitesse 1x d'un lecteur cd équivaut à 1,5 Mbps sans compter les seeks; une telle machine doit déja pouvoir utiliser une bonne partie de la bp d'une nic 100Mbps...).

Connaissez vous beaucoup de personne qui sont prêt à payer pour quelque chose qui n'existe pas encore (-> impossible d'évaluer la qualité) voir pire qui n'existera peut-être jamais (faillite) ?

Sinon, l'idée de combiner cela à une nouvelle secte/religion est intéressante et devrait être rentable. On pourrait même demander conseil à Mark S. (bien qu'il parraîtrait que ses fidèles ne soient pas si charitables). (o:

Le modèle repose forcément sur un minimum de bonne volonté, et sur une bonne qualité du produit.

On est d'accord, faisons la révolution internationale et commençons à plannifier...

NB: Merci de ne pas oublier l'autre morceaux de la négation (ne ... pas).

Sauf que sysjail se repose sur systrace dont on a découvert une bonne grosse race qui rend le bouzin inefficace...

IMPORTANT: Due to handling semantics of user/kernel memory in concurrent environments, the sysjail tools, in inheriting from systrace(4), are vulnerable to exploitation. Details available here. Many thanks to Robert Watson for discovering these issues! Until these problems have been addressed, we do not recommend using sysjail (or any systrace(4) tools, including systrace(1)) for security purposes. sysjail will continue to be updated for future releases of implementing systems.
http://sysjail.bsd.lv/

Tout à fais d'accord ;-) D'ailleurs pour quelqu'un de bonne volonté le langage ocaml est bien plus facile/rapide à apprendre que le C (et ce sans avoir fait des études d'info).

Par contre, l'effet pervers de cela (si on peut dire !) c'est qu'il devient plus facile d'implémenter des choses complexes (style un compilateur ou un algorythme savant) et donc, on a plus de chances de tomber sur un code incompréhensible pour quelqu'un qui n'a pas fait de licence en math/info (mais quand même pas aussi incompréhensible que la même chose, par ex. codée en perl...).

Eliom (en fait le module XHTML.M) ne permet pas de faire un "typage XML" à propremment parler, mais il utilise les types polyvariants d'ocaml qui permettent de construire une représentation d'une structure hierarchique "à la xml", tout en empêchant l'imbrication d'éléments incompatibles. Donc il est impossible de construire des documents non valides (sans tricher). Mais est-ce qu'il est possible de constuire tous les documents valides ou la structure de XHTML.M est plus rigide que la norme xhtml ? (Vincent ?).

Par contre, si l'on désire un "vrai" typage xml, ocsigen (ou plutot Eliom) permet de s'interfacer avec ocamlduce* qui permet alors de tirer parti d'un typage xml. Il devient alors super facile de générer, lire ou transformer n'importe quel type de document xml, avec la sûreté d'un typage statique à la compilation ! Ce point est peu mis en avant mais c'est un "must" à mon sens.

*: ocamlduce est une fusion du compilateur ocaml avec CDuce qui est une implémentation du langage XDuce en ocaml. Cela augmente le language ocaml "d'expressions XML" tout en restant pleinement compatible avec ocaml. cf. http://www.cduce.org/ocaml.html

Selon la roadmap, ils vont changer de parseur xmpp a la version 2.2 et utiliser une librairie dénommée exmpp qui devra augmenter sensiblement les perfs.

... et un "Beer Event" !
http://fosdem.org/2008/beerevent_practical

s/reterning/returning

Cf. la doc, c'est une extension (apparut dans la 8.2 je crois) qui n'est pas recommandée. La méthode plébiscitée consite à faire un 'select nextval(seq)/curval(seq)' où seq est le nom de la séquence utilisée (p.e. nomtable_champ_seq dans le cas d'une déclaration 'serial').

À noter que le framework lift se base sur le language Scala qui est un langage fonctionnel conçu pour la jvm. Apparemment (je ne me suis pas encore penché dessu) l'intégration des concepts FP<->OOP est vraiment excellente, pas un truc batard à la F#. Bref, à surveiller de très près...

Il y a des lois qui mériteraient d'être abrogées...

À part cela, féllicitations pour tous les pourvoyeurs de l'auto-censure. Dans les médias d'information, on a aussi que ce que l'on mérite.

> je tiens à signaler que je n'ai pas trouvé un seul lecteur digne de ce nom dans le monde proprio,

Il paraît que foobar2000 se défend pas mal, win only.

À un click ("Presto trac") du lien donné plus haut, il y a ceci : [https://fedorahosted.org/presto].
Dommage qu'il n'y aie pas encore de repo test pour ppc; je n'ai plus qu'à attendre F9.

Plan9 fait cela depuis +15 ans... En gros, le $PATH n'existe pas. Il n'y a qu'une arborescence pour les binaire, /bin. Les librairies restent dans /$objtype/lib, le loader les trouvera tout seul. Les scripts de demarrage s'occupent de monter en union les bon répertoires aux bon endroits, par exemple /$cputype/bin sur /bin. Idem pour les scripts de connexion, un utilisateur peut personnaliser son système en ajoutant des "union-mount" à son ".profile". Cf. http://www.cs.bell-labs.com/magic/man2html/1/0intro

Cela est très pratique quand on a un serveur de fichiers avec le système installé et que l'on se connecte depuis des terminaux "diskless" qui ne sont pas toujours de la même architecture. Tout fonctionne de manière transparente et sans gros hack (comme peuvent l'être le ld_preload et autres joyeusetés).

Il devrait être possible de faire pareil avec un gestionnaire de paquets modifié et une bonne dose voodoo d'union-mounts*. Cela aurait pas mal d'avantages, comme restreindre les paquets disponibles par rapport à un utilisateur. Maintenant, je ne sais pas quelle mesure cela est réalisable: j'imagine qu'avoir 8000 répertoires - un par paquet - attachés à son namespace entraînerait une certaine pénalité au regard des performances d'accès au système de fichiers.

*: cf. les shared subtrees, private namespace et autres joyeusetés qui nécessitent un linux pas trop vieux.

Un intérêt que je vois c'est que la personne qui débarque sans connaître unix, [...]

Peut-on encore appeller cela un unix ?

Je ne cherche pas à dénigrer le livre électronique. Au contraire, je ne peux qu'encourrager toute initiative qui promeut le partage de la culture. J'essaye juste de dénnoncer des arguments qui m'ont l'air fallacieux et montrer que certaines personnes peuvent y perdre de leur indépendance. Je ne te souhaite donc que du bonheur avec ton nouveau joujou.

Tu n'es pas obligé de croire cela, néanmoins une recherche sur 'Intel anti-trust', j'espère, te montrera que cette menace n'est pas qu'hypothétique (et pas qu'en UE).

Je n'ai pas dit qu'AMD était en difficulté, je n'en sais rien et j'ai d'autres choses à faire que suivre la santé économique des multinationnales. Cependant, il me semble qu'AMD est passsé par une période assez morose et qu'Intel a toujours maintenu ses prix au dessus d'AMD alors qu'ils auraient pu les couler facilement.

En ce qui concerme IBM, je suppose que c'est, encore ;-), une pure spéculation de ta part. Personnelement, je ne vois pas pourquoi IBM aiderait un de ses concurrent mais je suis currieux de savoir ce qui peut te faire penser cela.

En ce qui concerne le merge amd-ati, je ne m'exciterai pas trop vite. Des annonces de la part d'Ati (maintenant amd) cela fait un bon moment qu'on les subi. Pour en revenir à Intel, ils font eux aussi des GPU intégrés et dans ce domaine, ils ont une longueure d'avance sur AMD. Certes, ils ne visent pas le marché des hardcore gamers mais je ne pense pas que ce marché est le plus rentable.

Pour finir, je suis de tout coeur avec toi dans cette bataille contre les monopoles. Mon dernier cpu acheté était un ppc, celui d'avant un k6 et je n'ai fais que conseiller des amd à mes connaissances.

Tout à fait on peut duplique facilement, etc.. Donc en théorie, oui, la pérennité est assurée. Maintenant, que celui qui n'est jamais tombé sur un cd gravé qu'il n'arrivait plus à lire me jette la première pierre. Certes, la contrainte du volume de cet archivage est moindre mais il entraîne néanmoins d'autres inconvénients: une certaine fragilité du médium, un entretient (recopie, évolution des formats, stratégie de sauvegardes, ...) indispensable, etc. Je doute que tous les particuliers soient capables/disposés à supporter ces nouvelles contraintes. Dans un contexte de mutualisation, c'est sans doute supportable (quoique, mis à part l'Église, je ne connais peu d'organisation qui perdurent au travers des siècles) mais tu y perds alors ton autonomie.

Aussi, du point de vue économique/écologique, entre acheter une bibliothèque et la remplire au fur et à mesure de ses lectures et devoir renouveller son matériel numérique tous les x ans, le calcul est vite fait...

Pour prendre un exemple, si demain tu achète une bd électronique à tes enfant, je ne pense pas que leurs futurs petits enfants puissent en profiter comme toi tu as peut-être pu lire les livres de tes parents/grands parents.

Après chaque support a son utilisation.
Tout à fait. Je ne suis point du tout contre ces ebook reader; comme on l'a déja fait remaquer, pour lire une doc ça à l'air idéal. Mais comme on dit: il ne faut pas mettre tous ses oeufs dans le même panier.

ps: rien ne t'empêche de donner les livres que tu ne lis qu'une fois...

Bah les ordinnateurs ça peut aussi brûler hein ! Et la duré de vie d'un appareil électronique est bien moindre que celle d'un livre, même avec la piètre qualité du papier d'aujourd'hui. Il ne moisit pas, mais il s'oxyde et bien plus vite.
Je pense aussi que tu serais surpris de l'état des livres anciens (d'avant 1800) qui n'ont pas toujours été conservés dans des conditions optimales mais qui restent toujours dans un état tout à fait respectable (certes, on ne fait plus le même papier)...

2008, année du grand retour des trolls sur les (utilisateurs de) distributions ?

Si Intel a un monopole (comprendre si AMD meurt),

C'est justement dans l'intérêt d'Intel qu'AMD survive, étant donné la lourde menace de procès anti-thrust qui pèse sur eux (dixit une employée de chez Intel).

Parce que le lien donnée est avare en informations (à part faire de la pub pour un bouquin), voici celui de l'article Wikipedia: http://en.wikipedia.org/wiki/Active_record_pattern .

Bah cela dépend du style de gc utilisé mais il est tout à fait possible de compacter la mémoire après un cycle du gc (p.e. stop-and-copy). Aussi, à partir du moment où l'on utilise un gc, on ne peut pas vraiment dire que c'est «une couche au dessus» étant donné le couplage fort qu'il peut y avoir entre l'allocateur et le gc. Ceci dit, il est plus probable qu'ils ne se concentrent qu'à changer d'allocateur (comme l'explique l'auteur de ce blog) afin d'éviter les fragmentations en amont, à l'instar des devs de la glib avec leur slice allocator.

Secondo, ce que dit le gars c'est qu'une partie de la fragmentation due aux très petites allocations (dans le tas) peut être justement évitée en faisant des allocations sur la pile. Effectivement, un gc se fout des allocs sur la pile mais il est hors de question de tout allouer sur la pile ! Je ne t'apprends sans doute rien mais je n'arrivais pas à comprendre le sens de ta remarque...