Michaël a écrit 2929 commentaires

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 :)

Réponse tardive... j'étais à 200% dans autre chose ces derniers temps.

Et moi 600% comme tu le vois :)

Comme éditeur, en plus de vi, j'utilise nedit car léger, souple et très rapide mais il ne supporte pas l'UTF8. Dommage car il gère les sélections carrées comme j'ai pas vu d'autres programmes le faire.

Emacs gère aussi les sélections carrées (désolé, je n'ai pas pu résister!).

impossibilité de désactiver la suggestion dans la recherche et donc d'envoyer des données à Google

Je ne comprends pas ce qui te gêne: tu n'es quand même pas en train de dire que si tu utilisais un moteur de recherche autre que Google, les suggestions de recherche proviendraient quand-même de Google? Si ton monteur de recherche est Google, il va bien falloir qu'à un moment ou l'autre tu lui envoies des données pour qu'il sache ce que tu lui veux, non?

Et les connaisseurs de TeX en rajouteront, c'est une histoire de typographie française, tout en reconnaissant qu'il n'est pas nécessaire de connaître pour TeX pour connaître un peu de typographie.

J'espère que c'est clair pour tout le monde.

Si les processus agissent a priori de concert pour mener à bien une tâche, ils entrent en concurrence pour utiliser les ressources du système.

Un processus peut occuper toutes les ressources d'un type donné sur le système, temporairement, ou de manière permanente : mémoire, temps d'exécution, nombre de fichiers ouverts (handle), appel système (par exemple DOS n'est pas réentrant, pour demander au système d'écrire dans un fichier, il faut attendre qu'il ait terminé toutes les opérations d'écriture en cours, sinon c'est l'UB), opération non atomique sur une valeur partagée, etc ...

Une vague traduction de l'article de phrack Holistic approach on intrusion detecttion (Sasha, n°57) est entre mes mains (c'est même moi qui l'ai écrite), j'aurais aimé la peaufiner un peu et l'attacher ici. Malheureusement il faudra faire une news, mais c'est plutôt inintéresant comme contenu ...