Larry Cow a écrit 5011 commentaires

au pire les fonds issus du travail au noir se feront plus discrets.

Ca serait déjà pas si mal. Parce que, mine de rien, les signes extérieurs de richesse mal acquise, ça contribue à miner le moral de ceux qui bossent honnêtement pour moins cher.

Bon, cela dit, si c'est le seul bénéfice qu'on en tire c'est un peu du gâchis, mais il est encore trop tôt pour analyser les résultats d'un truc pas encore appliqué.

Pour savoir chez qui un contrôle fiscal est rentable, il y a plusieurs méthodes. L'une d'entre elles consiste à comparer le train de vie apparent d'une personne donnée avec ses déclarations de revenus. Le même qui se déclare au smic et qui collectionne les BMW décapotables, on va envisager de passer lui faire un petit bonjour (dans un premier temps, on va surtout se renseigner sur son compte). C'est ce genre d'information qu'on trouve dans les dossiers du FISC et qui sont très intéressantes pour débusquer les fraudeurs de l'assurance chômage.

C'est marrant, mais "confort" n'est vraiment pas le terme qui me vient à l'esprit quand on parle de langage compilé. Sécurité, fiabilité, performances, ok (c'est sujet à discussion, mais sur le principe ça peut se défendre). Le confort d'un langage compilé par rapport à un interprété, par contre, j'ai plus de mal. Tu veux dire que tu as la grande chance d'être obligé de passer par une phase de compilation avant de pouvoir tester ton code?

D'où l'intérêt d'en avoir mis au congélateur quand c'était encore la saison. Il est prévoyant, ce petit-là...

Si le P2P est illégal le client serveur (C/S) devrait l'être aussi car c'est une extension du P2P. (Paire a paire particulier ou un des paire est un "serveur")

N'importe quoi. Si les deux pairs (sans 'e') ne sont plus sur un pied d'égalité, comme dans le cas du client-serveur, on ne peut plus parler de "pairs".

Je comprends mieux pourquoi Chirac tient tant à faire rentrer la Turquie dans l'Europe: comme ça on ne serait plus qu'avant-derniers ;)

Un truc que je me demande, au sujet de l'émulation système ARM, c'est si ça pourrait aboutir sur l'émulation d'un Zaurus ou d'un Linksys WRT (entre autres)?

Parce qu'il y a quand même pas mal de systèmes basés sur des StrongARM ou des XScale, et que ça pourrait être franchement énorme de pouvoir les émuler sur nos machines de bureau.

Mais j'ignore si la chose est envisageable ou non, et le niveau de complexité (c'est peut-être d'ailleurs déjà prévu, j'en sais rien).

Pas pour moi en tous cas...

Franchement, on s'en fout de ta définition des termes. "multi-os", ça signifie "qui tourne sur plusieurs systèmes d'exploitation". Si ça ne te plaît pas, forke l'expression et monte ta propre langue. Ce que tu voulais dire était "compatible Windows", ça ne t'aurait pas coûté plus cher de le dire comme ça. Tu n'y a pas pensé sur le coup, ce n'est pas un drame, d'autant qu'avec quelques explications on a tous compris ce que tu voulais dire, et on est d'accord.

Reste qu'insister pour que "multi-os" signifie "compatible windows", c'est un peu de l'entêtement stérile.

Ça n'a rien d'un scoop, hélas. Mais bon, si c'était limité à l'EPITA, l'avenir serait radieux...

Il y a aussi Porcupine, qui est opensource, en Python (côté serveur), et franchement prometteur.

Pour ce que j'en ai vu, il fournit un framework assez bien intégré pour la création d'applications (qui revient apparement à définir un modèle et à le laisser se démerder).

J'ai peut-être mal compris, mais il semblerait qu'ils visent une implémentation de XUL en JavaScript+DHTML. En tous cas, ils prétendent utiliser XUL, mais marchent sans problème (et de manière identique) sous Moz et IE, donc je ne vois pas d'autre explication. Par contre, sous Konqueror c'est pas encore ça.

Site: http://www.innoscript.org/
Demo: http://www.innoscript.org/content/view/21/43/

Je suis probablement con (ou alors il est tard, ce qui m'arrangerait), mais j'ai du mal à voir comment l'extrait que tu me cites peut faire du mal à d'autres logiciels libres que ceux qui ont pour but plus ou moins avoué d'échanger des données illicites.

Je veux bien croire, concrètement, qu'un tel amendement est une bien mauvaise nouvelle pour mlDonkey (sans juger de légitimité d'une telle menace pour ce soft), mais quid d'un KDE, d'un Inkscape, d'un Gimp, d'un Firefox, d'un MySQL? Ce ne sont pas de logiciels libre? Comment seraient-ils concernés par un tel amendement, sinon?

Il me semblait que "à plat" ne s'appliquait pas à SQLite, justement, qui reste une base de données relationnelle (à la différence de BDB, effectivement).

Apparemment, la propagation se fait dans les deux sens: la Sky Touch' se répand par ici.

L'intérèt? A mes yeux, il est nul, ça prend plus longtemps, mais pour la qualité, je n'ai pas vu la différence avec ou sans ces passes supplémentaires (je ne suis pas un spécialiste non plus...).

Il n'est pas nul, alors, il est négatif.

Trève de pinaillage, l'intérêt est (si je ne m'abuse) sur la taille du fichier obtenu. En relisant les informations glanées lors des précédentes passes, on arrive à déterminer comment augmenter la compression sur certaines parties du flux. Ou bien?

Ou des masochistes.

Tu veux forcément des clients lourds? Parce que sinon, Horde est assez sympa. L'installation n'est pas des plus légères, mais ça se fait bien, et ça ferait presque le café, pour un peu.

je trouve que ce bouquin tient la route mais il n'y a pas de fin... et qu'on reste un peu sur sa faim...

Parce que dans "Extension", il y avait une fin. Mouarf :)

Faut quand même arréter avec ce mythe que "quand le code-source est dispo, on peut pas (ou moins) cacher de merde dedans". Pour que cela soit vrai, il faut que l'outil qui transforme ce source en binaire n'ait pas de merde cachée dedans. Ce qu'on peut vérifier en lisant les sources du-dit compilateur, certes, mais comme il faut bien commencer avec un binaire...

Il y a bien d'autres raisons de refuser le "tout binaire", et cet article nous en donne assez comme ça. Pas la peine de ressortir des raisons douteuses en plus.

Pour revenir au fond du problème, la solution "optimale" pour tolérer les drivers binaires serait de leur donner un statut particulier. Ne plus les intégrer dans le noyau, mais les faire dialoguer avec un module (libre, celui-là), d'interface stable et contrôlant autant que faire se peut que les drivers "fermés" ne fassent pas d'âneries.

WorldWind est comparable à Google Earth, pas Google Maps. Ce dernier n'est, en effet, accessible que via le web.

Le futur s'appellerais kdemm, et serait une abstraction entre KDE et les différents système multimedias bas niveau (ALSA, OSS, WIN32, ...)

Comme visualisateur d'image "pur" (pas une base de données d'image comme digikam ou kimdaba) et complet, on trouve Gwenview. Malgré l'absence de "K" dans le nom, il est très bien intégré à KDE, et - bien que sans fioritures ni excès de zèle - fait bien son boulot.

Les autres choses qui, dans KDE, me simplifient la vie au quotidien:

- Yakuake - le nouvel avatar de la console à la Quake - très pratique, simple et discret. Franchement impayable.

- KGet - le download manager intégré à Konqui - on en viendrait à regretter qu'il ne soit pas utilisé pour le copies de fichiers, presque :)

- Les ioslaves, notamment le fait de pouvoir uploader une image d'un site vers un autre sans la récupérer explicitement en local.

- Les ioslaves, encore, et notamment le fait de pouvoir riper un cd audio sans autre application que konqueror.

- Alt+F2. Surtout avant d'avoir découvert Yakuake. Ca ouvre la fenêtre "Exécuter une commande". Ca a l'air con, mais c'est devenu un réflexe (un peu comme Meta-X sous Emacs).

- DCOP. Pour scripter son environnement tout en réutilisant les bonnes vieilles connaissances du shell, c'est tout bon.

Bon, pour être objectif et juste, je vais aussi lister les petites crispations régulières:

- Comme tu dis, ça plante. Franchement, par moment, c'est lourd. J'en viendrais presque à le compiler en mode debug (je suis sous gentoo) pour pouvoir soumettre un backtrace complet à chaque fois, mais ça m'ennuie un peu de ralentir la bête...

- Quelques bugs _très_ chiants qui durent d'une version à l'autre (peut-être liés au fait que je traine une config qui date de KDE 3.2, aussi, mais j'ai la flemme de tester). Je pense particulièrement à celui qui fait que Kicker (le panel/bureau) se gèle, parfois. Il continue à répondre à la souris et au clavier, mais il ne représente plus du tout la réalité (éléments présents dans la barre des tâches mais fermés depuis longtemps, et reciproquement, barre de menu "à la macos" qui ne correspond plus à l'application en cours, ...). Un simple appel à DCOP remet tout d'applomb, mais ça fait tache. Et à en croire le bugtracker, je suis le seul à avoir ça. Snif.

- KHTML un peu à la traîne. Autant il se démerde bien en matière de respect des standards (cf. le test ACID2), autant il a un peu de mal à être à jour sur certains trucs "hype" (AJAX & co). Globalement, oubliez les Netvibes/Porcupine/Writely/... Idem pour le site de la société générale: ils ont récemment fait des modifs à la con qui le rendent inutilisable avec autre chose que FF ou IE.

- L'absence d'architecture multimédia "forte". Il y a bien arts, que je désactive toujours à la compilation (peut-être un mauvais réflexe, mais j'ai des souvenirs désagréables). En principe, le problème sera résolu avec KDE4.

M'enfin en définitive, j'arrive plus trop à m'en passer, et je regrette juste de pas avoir trop le temps de contribuer.

Un menu en Java, comment c'est la classe...

Euh, je sais pas chez toi, mais le driver Ralink GPL actuel il est un peu limité. Pas de scanning, notamment. Ou bien faut m'expliquer.

Moi je préfère faire du MSN sous mon Linux que d'être sans ami quand je m'embête le soir derrière mon écran. LOL !

Tu peux aussi lacher ton écran, dans ces cas-là. Rester derrière son ordinateur alors qu'on n'a rien à faire dessus, c'est pas le meilleur moyen pour avoir des amis ailleurs que sur MSN (dans la vraie vie, par exemple).