Michaël a écrit 2935 commentaires

Merci pour ces informations!

Ce que je veux dire, c'est que l'attirail des lois qui interdisent la copie et la rediffusion des œuvres numériques par tout un chacun va à l'encontre de la réalité physique, dans laquelle rien ne s'oppose à cette copie et cette rediffusion.

Peut-être que c'est un peu comme les prohibitions (parfois l'alcool, parfois d'autres choses): les lois n'ont jamais empêché les trafics, et les forces de police non plus (j'ai lu récemment, à propos de certains substances, que la police française estimait intercepter moins de 10% du trafic). Cela signifie qu'on peut s'attendre à ce qu'une société décidant d'interdire cette copie et cette redistribution dépense son énergie inefficacement. (Au détriment, pour reprendre l'exemple de la prohibition, des politiques de santé publique.)

Dans les dernières années les quelques fois où j'ai pu entendre des représentants de ces maisons d'édition de la musique s'exprimer (surtout à la radio), tous ont fait passer le message que leur industrie était en péril: j'ai la faiblesse de bien vouloir les croire, tant que rien ne me prouve le contraire (et puis le sujet ne m'intéresse pas au point que j'essaie, par exemple, de trouver les chiffres d'affaires de ces boîtes et d'autres indicateurs plus ou moins pertinents).

Pour tes deux autres questions, je n'adore pas le mot industrie: par là je voulais juste nommer tous les acteurs du secteur. Même si je n'ai pas de véritable connaissance sur le sujet, je veux bien croire que mener une carrière artistique, entreprendre des projets, comme l'élaboration d'un disque ou organiser une tournée ou d'autres choses que je n'imagine pas, sont des domaines dans lesquels on peut développer une compétence, ne serait-ce qu'une compétence sociale, et je veux bien croire aussi que cette compétence mérite d'être sauvegardée. Ensuite sur les formes exactes que peut revêtir l'activité de ces gens, je suis plutôt ouvert, et puis surtout, je n'ai pas de pouvoir de décision!

La généralisation du support numérique à de nombreux types de documents (livres, articles, images, films et enregistrements sonores) s'est accompagnée de l'apparition d'une nouvelle loi naturelle: la duplication et la diffusion de ces documents est simple et peu coûteuse.

Cette généralisation s'est amorcée il y a plusieurs années, son signe le plus tangible, le point charnière, serait probablement l'arrivée dans nos salons des platines CD il y a une petite vingtaine d'années. Cette généralisation ébranle les industries dont l'activité est la production et la diffusion de ces documents, avant elle l'achat du support était, sinon inévitable, difficile à contourner: il n'est pas très facile de dupliquer un disque vinyle, et les supports magnétiques analogiques sont trop fragiles pour présenter une alternative vraiment satisfaisant à l'achat ... Pour autant, si ancienne soit l'amorce de cette généralisation, si clairement inéluctable ait-elle été, je suis aujourd'hui porté à croire que les dirigeants de ces industries n'ont pas mesuré pleinement ses conséquences sur leur activité. Aujourd'hui, et c'est tout sauf une surprise, la duplication et la diffusion des documents numérisés est simple et peu coûteuse. Le modèle économique des producteurs et diffuseurs de documents n'est donc plus en adéquation avec les lois naturelles numériques, il est périmé et à mon avis, la seule réaction possible à cela, est de repenser complètement le modèle économique de ses sociétés.

L'idée de vendre des artefacts numériques ne va pas de soi, justement à cause de la facilité avec laquelle ils sont reproductibles et diffusables. Une fois que je possède l'un de ces artefacts, je peux le revendre indéfiniment, sans le perdre: cette réalité est naturelle. Les lois que nous avons faites, encadrant le commerce de ces artefacts, vont à l'encontre de cela, et si elle tient à les faire respecter, les sociétés vont devoir dépenser beaucoup d'énergie et d'argent à cela.

Sûrement, le plus raisonnable serait de conformer notre droit à cette nouvelle loi naturelle, mais comment faire alors pour permettre à ces industries produisant et diffusant des documents numériques, de poursuivre leur activité? À cette question je n'ai pas de réponse, seulement la certitude que la voie que nous suivons aujourd'hui est mauvaise, car la duplication et la diffusion des documents numériques est simple et peu coûteuse: à cela il n'y a décidément rien à faire.

Oui ils ont abandonné Python pour passer à OCaml et rebaptisé Django en Ocsigen.

Bravo, c'est un de mes préférés!

C'est super, merci pour l'info! Pourtant, la description du produit ne le mentionne pas!

Il est en effet regrettable que certains compromettent la sécurité de leurs données en appliquant, par zèle, un double ROT13 alors que le ROT13 simple est réputé inviolable.

Tu es rude! Tu aurais du attendre le 15 septembre à 7 heures pour poster ton commentaire :)

Ce que tu écris me rappelle l'introduction du chapitre de TAoCP (Knuth) consacré aux nombres pseudo aléatoires: Knuth y raconte ses erreurs de jeunesse, il souhaitait construire un générateur de nombres aléatoires 'hachtement bien en empilant des méthodes apparemment toutes plus ingénieuses les unes que les autres qui poussaient les bits de la graine aléatoire dans une danse virevoltante, et surtout vers un cycle suffisamment court pour être visible à l'œil nu!

La morale de son histoire est que plus un système est complexe, moins on est capable de l'analyser et d'en énoncer des propriétés intéressantes. En cryptographie on veut avoir confiance dans le fait qu'un système est difficile à casser, techniquement on démontre des théorèmes du genre «Victor décrypte le message de Alice à Bob» équivaut à «Victor sait résoudre telle problème de maths» et on monte un cryptosystème dont la casse équivaut à un problème de maths réputé insoluble.

Un deuxième point est que si tu empiles deux cryptosystèmes S et T pour coder ton message m, le message codé est donc S(T(m)), le petit Victor peut utiliser tout ce qu'il sait sur la forme des messages générés par T pour casser S.

Mais bon, je le concède, ma réponse est celle d'un néophyte.

DjVu is an open standard. The file format specification, as well as an open source implementations of the decoder (and part of the encoder) are available.

Je ne suis pas très au fait des histoires de licence pour les formats comme DjVu et PDF, mais ils ont en commun l'ouverture de la spécification du format.

J'avais oublié, mais tu me le rappelles, il fallait effectivement à l'époque envoyer son fichier sur un serveur ... mais maintenant on peut faire ça à la maison avec djvulibre.

-1s/dit/dis/

Peut-être que farvardin est un interprèteur GW-Basic de 1983?

En plus d'ajouter dire que David a complètement raison, je voulais ajouter que le seul mode d'organisation pertinent des fenêtres est le tiling. Et puis avec le temps qu'on gagne à ne pas retailler et redimensionner ses fenêtres, on peut poster sur linuxfr!

(J'ai honte d'être aussi fayot!)

L'intérêt du tiling se ressent dans la situation suivante: plusieurs applications communiquent avec toi par une ou plusieurs fenêtres et tu souhaites que toutes ces fenêtres soient simultanément complètement visibles. Dans cette situation tu organises tes fenêtres de sorte qu'elles ne se recouvrent pas. Si tu retires l'espace séparant une fenêtre de ses voisines, tu arrives à une disposition de type tiling. En un mot, tu organises tes fenêtres selon deux contraintes: deux fenêtres ne se recouvrent pas, et tous l'espace est recouvert par des fenêtres.

Pendant plusieurs années j'ai utilisé un WM tiling (ion 1) mais comme je n'utilise presque'exclusivement que quatre programmes (seamonkey, emacs, terminal X et visionneur de document) chacun en mode plein-écran sur son bureau --- configuration tiling que tout gestionnaire de fenêtres digne de ce nom permet de réaliser facilement --- je suis repassé à un gestionnaire de fenêtre ordinaire qui permet à mes amis de passage chez moi, d'aussi utiliser mon ordinateur :)

Je ne comprends pas cet avènement des «applications web»: si on en croit les promoteurs du très très haut débit il suffit d'attendre quelques années avant qu'on puisse tous raisonnablement travailler en session graphique distante à travers le monde entier (ssh -Y) ... cela arrivera probablement certainement bien avant que quelqu'un ait écrit une suite bureautique potable en Javascript: déjà que celles écrites dans des langages biens plus pratiques pour des plate-formes mieux définies sont toutes plus pourries les unes que les autres ...

Je prends aussi mes notes sur des feuilles de papier, que je passe ensuite dans le scanner à bac en face de mon bureau, je passe le résultat dans une moulinette DJVU et en quelques instants --- pif, paf, pouf --- j'ai une version électronique de mes notes que je peux donc emmener partout avec moi sans transporter un wagon.

L'idée de prendre des notes avec un ordinateur me paraît des plus inadaptées: un traitement de texte cela sert à produire un document imprimé (ne serait-ce qu'électroniquement). Au papier on a un rapport simple et intuitif, écrire c'est dessiner, et dès qu'on veut rompre la linéarité de la prise de notes ou recopier un petit croquis de l'orateur, on va plus vite avec un stylo qu'avec un clavier ou un trackpad.

En plus le combo stylo-bille plus bloc de papier démolit en terme de poids le plus aérien de tous les netbooks!

Merci pour ta réponse, qui (pour archive) concerne la partie annotation et marque-page de ma question: cette liseuse ne semble pas permettre d'afficher des DJVU (je viens de zyeuter les spécifications sur le site du constructeur).

Je suis navré de ce manque de popularité de DJVU, pourtant j'ai pu observer sur mes documents des rapports de taille de 1 à 10 en faveur de DJVU (par exemple, pour des notes manuscrites scannées). Je viens de jeter un coup d'œil à numdam.org (au passage, je me suis fait mal à l'œil) et sur cinq documents pris au pif, les fichiers DJVU sont tous environ deux fois plus petits que les fichiers PDF. Mettre deux fois plus de fichiers dans sa liseuse, c'est quand-même une perspective alléchante, d'autant que plus la mémoire de ces objets semble relativement limitée (la sony dont tu parles a 2GB de mémoire, ma bibliothèque fait dans les 4GB).

Non seulement les PDF mais aussi (en ce qui me concerne, surtout) les DJVU!

Au passage quelqu'un connaît-il une liseuse (je crois que c'est le terme générique pour les produits de type kindle) qui supporte les DJVU ou qui a des bonnes fonctions d'annotations et de marque-page?

Si en plus de répondre oui à chacune de ces deux questions, vous savez le faire avec un seul produit, vous me rendrez heureux pour plusieurs jours!

Je crois que /bin/sh est plus portable! (Déjà, c'était bien essayé de pas mettre bash, bravo!)

Salut, ta version me plaît beaucoup. J'ai une version plus portable qui nous permettra d'augmenter considérablement les nombre de plate-formes visées :)

#include <stdlib.h>
int main(void)
{
    return EXIT_SUCCESS;
}

Longtemps je n'ai pas utilisé d'environnement «desktop» mais me suis baladé entre ION, WMAKER et quelques autres WM. La seule fonctionnalité des «desktop» qui me manquait, c'est la petite magie des fichiers DESKTOP qui permettent au «file manager» de proposer quelques alternatives pertinentes lorsqu'on veut maniper un fichier: le luxe quoi! Le point qui m'a définitivement séduit dans XFCE, outre la légèreté, c'est quelques thèmes bien rétros et la petite horloge «so XCLOCK» qu'on peut mettre dans leur PANEL. Ça paraît un peu «cheap» comme liste de «killer features» mais vu que dans une session typique je lance un terminal, un EMACS et un SEAMONKEY point barre (chacun maximisé, avec une police DVJU MONOTYPE 18 pour ne pas trop me fatiguer à lire) ...

Beaucoup de bla-bla pour dire que les fonctionnalités des environnements «desktop», je ne m'en sers tellement pas que je n'en connais même pas la liste! Si on sait un tant soit peu se servir d'un système UNIX, un WM et un FM potables, c'est tout ce qui compte, non? Et à la rigueur le FM n'est pas indispensable!

Il me semble que l'intérêt principal des environnements «desktop» est de rendre la machine facile à utiliser pour celui qui veut en savoir le moins possible. Avoir un tel système sous la main permet de l'utiliser comme base pour déployer une solution logicielle sophistiquée dans une entreprise. Par exemple, on peut proposer à un cabinet d'avocats d'affaires le déploiement de stations de travail, intégrant une suite de bureautique, des méthodes de sauvegarde, quelques mesure de sécurité et encore quelques outils spécifiques. En disposant d'un environnement «desktop» à la GNOME, KDE ou XFCE pour relier entre eux tous ces éléments on se libère de la contrainte culturelle obligeant les avocats, pour continuer sur cet exemple, à travailler sous MS-Windows: le temps d'adaptation au nouveau système devrait être rapide.

À mon sens, pour être le plus utile, un environnement «desktop» doit-être, dans son mode «sortie d'usine», aussi banal, consensuel et peu innovant que possible. C'est pas folichon, mais dans ce type de projet, la place des paris risqués est à l'horizon de ce que l'utilisateur flemmard et pas très formé peu voir, pas sur le devant de la scène.

Merci pour tes précisions!

Make est fait pour les compilations. L'utiliser pour installer des fichiers, c'est déjà un détournement de sa fonction, alors à partir de là, ça ou un script, c'est kif-kif, je dirais.

Je ne suis pas tout à fait d'accord avec l'idée de ``détournement''. C'est peut-être une utilisation inattendue, si on a commencé par apprendre que Make sert à compiler des programmes. Mais finalement, la différence conceptuelle entre décrire une tâche dans le langage de Make et dans le langage du shell réside dans l'organisation du programme. Au lieu de l'approche découpant la tâche à accomplir en procédures et sous-procédures, etc., Make impose de penser en terme d'étapes et de transitions et se débrouille pour combiner entre eux ces éléments de description de la tâche pour arriver au résultat escompté, si celui-ci peut-être atteint. Un des intérêts de ce cette approche est qu'on peut enrichir une liste d'étapes et de transitions, ce qui du point de vue procédural du shell revient à éditer le cœur d'une procédure.

Par exemple, si notre procédure d'installation générique ressemble à

# shell
install() {
 do-preinstall
 do-install
 do-postinstall
}

# Makefile
install: do-preinstall do-install do-postinstall

on l'adapte à nos besoins particuliers, dans le monde de Make en ajoutant des dépendance aux étapes do-preinstall do-install et do-postinstall là où le shell nous obligerait à trouver, copier et modifier le code des procédure do-preinstall etc.

En clair, par rapport au shell, l'approche de Make montre sa force dans la facilité qu'elle confère aux solutions générales à s'adapter aux cas particuliers. (On peut certes utiliser la méthodologies objet avec le shell, mais je ne connais pas de proof of concept à part quelques exemples que j'ai écrits pour m'amuser.)

Ceci dit, comme méthode d'installation, un script est très bien!

Je reconnais sans peine que les manipulations de sélections carrées dans Emacs ne sont pas forcément très pratiques: on peut couper et coller, en gros. Par curiosité, il y a plus de fonctions dans `nedit'? En me demandant à quoi servent les sélections carrées, je pense spontanément à l'édition de tableaux présentés dans des colonnes de largeur constante, est-ce qu'il y a autre chose?

Malgré mes efforts je n'arrive jamais à taper: less file, mais je tape toujours: cat file | less.

Pour que ala période de transition soit moins dure, tu passer par `less < file' qui semble un bon compromis :)