Sygne a écrit 628 commentaires

au départ il y avait un fort esprit roleplay

J'ai déjà lu ça quelque part…

Ah oui, c'était dans un livre de la bibliothèque de Grey Havens de Mume, qui doit dater de la fin des années 90…

C'était mieux à vent.

Dans mon terminal, pdf<tab> me renvoie plein de choses potentiellement utiles, dont pdftohtml et pdftotext. Pour extraire des données d'un pdf, il n'y a de toute manière pas d'autre méthode que la râche.

Plus performant, car tu verras que ça va très vite, et àmha, pas idiot pour gérer les ressources quand celles-ci sont humaines, il reste la solution de créer manuellement une fiche pour chaque CV.

Personnellement, dans ce dernier cas, je trouve bien plus efficace de ne pas utiliser de formulaire (qui oblige à donner les informations dans un ordre qui n'est pas forcément celui proposé dans le CV), mais un simple éditeur de texte et des tags qui seront ensuite parsés, par exemple:

n: nom
p: prenom
a: adresse, code postal ville
c: java, c++
o: amateur de cyclimse

il y a des nanos libres qui ont aussi un port SATA. Sinon on peut aussi brancher sur le réseau un NAS monté en NFS. […] Pourquoi préférer l'architecture x86 dans ce cas ?

Pour faire un serveur de fichiers justement, car les cartes ARM avec plusieurs ports sata ne sont pas légion, et les astuces à base de multiplexeur de ports usb alimentés ne me semblent pas très convaincantes.

Dans mon cas particulier, j'aimerais en outre partager des exécutables entre le serveur et les clients. Il est vrai que rien n'empêche le serveur d'avoir un répertoire contenant les exécutables correspondant à l'architecture des clients, mais j'aimerais éviter.

Enfin, je ne sais pas comment juger des perspectives de support à long terme des cartes arm. J'ai l'impression que souvent celles-ci sont fournies par leurs fabricants avec des patchs pour le noyau et le boot loader. Qu'en sera-t-il dans cinq ou dix ans? Je n'en sais rien. Quant au X86, je suis à peu près certain que le support s'améliorera avec le temps.

Moi aussi je réfléchis à l'installation d'un serveur personnel, et j'en suis venu à la même conclusion que toi, à savoir qu'une architecture x86 est peut-être bien plus pertinente qu'une architecture arm. Et ce, pour plusieurs raisons:

Les interfaces: il est difficile de trouver une carte arm avec plusieurs ports sata,
et si on veut en outre un minimum de connectique, cela devient vite très cher.

Le support à long terme: je doute que dans quelques années, il y ait encore des personnes de bonne volonté pour mettre à jour l'os d'une carte arm qui n'est plus commercialisée. Je ne serais pas étonné que ces cartes restent confinées à une version spécifique du noyau et du boot-loader.

La consommation: x86 fait des progrès, et sur le papier, on trouve des processeurs x86 qui consomment aussi peu que les processeurs arm.

L'uniformisation: n'avoir qu'une architecture à gérer, c'est tout de même plus simple.

Parfait alors !

Jette un coup d'œil à make, c'est pratique.

J'arrive un peu tard sur ce fil, mais j'ai néanmoins envie de commenter…

Sur le site:

Il est vrai que le choix esthétique est très radical. Mais ça a un petit côté rétro-futuriste qui peut se défendre si le projet est de se faire plaisir. Seulement, si tu tiens a toucher un large public, il faudrait effectivement trouver une esthétique un peu plus passe partout.

Sur les paquets (je n'ai pas réussi à télécharger tes logiciels, donc mes remarques sont peut-être inutiles):

Pour faire les choses bien, avant de penser aux .deb et .rpm, il faut déjà faire de belles archives, contenant: readme, license, changelog, man, makefile configurable et numéro de version. C'est à partir de ces archives que tu feras tes paquets facilement et proprement.

Oublie ton script bash appelant sudo pour l'installation. Fait un makefile avec deux commandes: make all pour compiler, make install pour installer. L'utilisateur sera content de ne pas avoir à compiler en root, et se loggera en root s'il veut installer ailleurs que dans son répertoire personnel.

Pour la page de man et le readme, tu peux utiliser des outils du genre txt2tag et markdown.

Pour le changelog et le numéro de version, tu peux utiliser une forge—mais c'est lourd à gérer—ou le faire à la main. Tu peux par exemple utiliser la date de publication comme numéro de version.

Tout ça, c'est déjà beaucoup de boulot… Et ça mériterait une documentation pour partir du bon pied, mais je n'en connais pas… Je te conseille d'étudier les archives de quelques petits logiciels que tu aimes bien pour commencer.

Après, à mon avis, un paquet pour la distribution que tu utilises personnellement est largement suffisant. Si tu veux vraiment que tes logiciels conquièrent des utilisateurs, c'est surtout de la publicité dont tu as besoin. Il sera toujours temps de faire des paquets divers et variés lorsqu'il y aura de la demande.

Et pour la pub, on revient à la question du site…

Àmha, de même qu'un bon journal bookmark devrait se contenter d'un unique lien, un bon journal diff devrait se contenter d'un unique patch.

C'était mieux à vent. J'apprécie néanmoins la nimage.

C'est probablement parce que la Bnf a reçu le document dans le cadre de sa mission de service public qu'elle considère que cette loi s'applique pour retirer des œuvres du domaine public et contrevenir ainsi à sa mission.

Mais le sens général du texte me semble assez clair: cette loi a été produite dans le but de mettre à disposition du public des documents administratifs qui sans cela resteraient inaccessibles, pas pour limiter l'accès à des œuvres d'art en droit accessibles.

Àmha, selon Kant, l'impératif catégorique est un critère parfait. C'est nous, qui, incapables que nous sommes d'être d'une absolue bonne volonté dans l'application pratique de l'impératif catégorique qui ne faisons que nous en approcher.

Par contre la morale et la notion de "mal", sont strictement personelles.

Euh…

Agis de telle sorte que la maxime de ta volonté puisse toujours valoir en même temps comme principe d’une législation universelle. Emmanuel Kant.

Cette loi morale universelle est une des thèses fondamentale de l'histoire de la philosophie. C'est aussi celle qui est à l'origine de la philosophie des lumières et des droits universels de l'homme.

Bon, alors la définition de document administratif est excessivement large dans cette loi, mais vu que les mots ont tout de même un sens intrinsèque, je serais curieux de voir ce qu'un juge penserait d'une interprétation de cette loi considérant un tableau comme un document administratif.

Je serais curieux moi-aussi de savoir ce qu'un juge penserait de cette interprétation de la loi, puisque c'est justement cette interprétation qui sert d'argument à la BNF et Gallica pour facturer la diffusion commerciale des œuvres du domaine public.

Cf ce pitoyable formulaire, publié dans cette déplorable page web.

La notion anglo-saxonne de copyright n'est pas vraiment transposable en droit français où le droit d'auteur prévaut.

Et le fait que le M. engage des frais pour faire cette copie ne change rien au fait qu'il ne fait que reproduire une œuvre sur laquelle il n'a aucun droit. L'œuvre est dans le domaine public, et en faire une copie ne lui donne pas le droit de modifier ce statut.

À toutes fins utiles, je rappelle que la simple numérisation d'œuvres bidimensionnelle, même en très haute définition, ne porte pas la marque de la créativité de son opérateur et ne crée par conséquent aucun droit d'auteur supplémentaire. Les œuvres originales de cette collection ayant été réalisées par des peintres morts il y a plus de soixante-dix ans, celles-ci ce sont élevées dans le domaine public, et leurs numérisations relèvent donc également du domaine public. [dépêche sur Éblouissants Reflets]

Je te remercie pour ce militantisme courageux. J'imagine avec joie la cohorte indignée des institutionnels privateurs de culture t'expliquant:

1. que le photographe a mis en œuvre son talent artistique pour faire cette photo.
2. que la base de donnée électronique contenant cette photo est une œuvre de l'esprit soumise au droit d'auteur.
3. qu'en vertu de la loi 78-753 sur les documents administratifs, les œuvres de l'esprit possédée par l'état peuvent être distribuées sous une licence n'autorisant la diffusion que dans certaines limites, même si elles sont dans le domaine public.

J'ai mis en ligne une nouvelle version – utroff-0.3 – corrigeant ces petits bugs.

Encore merci Fravashyo !

Merci pour ces précisions.

Concernant -eq la page de man de dash indique que cette comparaison ne concerne que les integers. Elle propose un simple = pour les strings.

Et ça marche bien aussi avec bash (du moins chez moi), qui, à mon avis, reste posix compliant, même s'il ajoute sa propre syntaxe par dessus.

Àmha, l'idéal reste le fauteuil à accoudoirs – genre ce truc – et le portable sur les genoux. Un repose-pieds n'est pas mal non plus.

Il ne fait aucun doute que tu convaincras facilement ton patron d'investir dans cet outil de travail tant ta productivité s'en trouvera améliorée.

il faut utiliser -eq plutôt que ==

Dans le même genre, on corrigera aussi le test suivant, en remplaçant == par =.

J'en perds mon latin.

Heureux de te croiser Fravashyo,

Effectivement, il y a un bashisme dans U: il faut utiliser -eq plutôt que == lors du test [ $# == 0 ] (je ne savais même pas que c'était là un bashisme…).

Il y a aussi un bug: il faut utiliser : pour séparer les répertoires de la variable UTROFFONTS et écrire UTROFFONTS=/opt/utroff/lib/font/:/usr/share/fonts/OTF// plutôt que UTROFFONTS=/opt/utroff/lib/font/,/usr/share/fonts/OTF//.

Quant à text2tag, je viens d'essayer, et le gras fonctionne correctement. Peut-être as-tu souffert du bug ci-dessus…

Mille merci !

La feuille de style imitant l'ancien style de linuxfr (kaiska), encadre en rouge les nouveaux commentaires.

Tu es génial !

Cette carte me semble tip top.

J'ai lu un peu de bien de supermicro sur la liste de discussion de plan9, car au moins l'une de leur carte est parfaitement supportée par plan9. En particulier, ils apprécient là-bas le fait que les tables MP de la dite carte sont propres. On peut peut-être espérer que le même soin soit apporté aux tables acpi.

Un ou deux ports sata en plus, et c'eut été parfait.

Merci !

quatre ports sata me semblent nécessaire pour l'évolutivité.

la possibilité de brancher quatre disques durs me semble nécéssaire pour l'évolutivité.

Il faut que tu précises également tes autres besoins.

• quatre ports sata me semblent nécessaire pour l'évolutivité.
• un port ethernet gigabit.
• la possibilité d'établir une liaison directe efficace pour partager un jour la racine du système de fichier avec une autre machine est bienvenue (autre port ethernet?).
• pas de matériel exotique (j'aime bien NetBSD, même si c'est toujours linux qui est en vue pour l'instant).
• fiable et durable.
• pas plus grand que mini-itx.
• silencieux, fanless si possible, et basse consommation.

Le dernier point est important. C'est en le considérant que je me suis tourné vers l'atom, faute de savoir quels autres processeurs x86 sont de basse consommation.

Merci !

Justement, le driver linux de l'interface réseau de la carte super micro est buggé. Mais il y a un fix. Pour le reste, d'après ce que j'ai pu lire, la dite carte super micro est reconnue pour être de bonne qualité.

Je n'ai pas encore fait de recherches pour les autres cartes à base d'Atom.

C'est plein de bon sens ce que tu dis là…

Je ne fais pas tout à fait le même calcul, puisque je trouve à peu près 1W.an = 1€. Mais effectivement, je peux assumer la différence de 8€ annuel entre 5.5€/an et 13.5€/an, surtout que la machine n'aura pas à fonctionner la nuit ni même toute la journée.

Après, il y a toute une gamme de cartes et de prix autour de l'atom, dont un large choix avec le D525. J'ai en fait donné ici en exemple les deux extrêmes.