Quand je dis que la classe doit être bien faite, je dis que c'est à elle d'inclure les paquets utiles. Donc si la conf ne veut pas de figure, ben non, pas de pfg. Si elle ne veut pas d'algorithmes, pas de paquets pour ça…
Au hasard, un 'grep RequirePackage' sur le style d'une conf me donne:
La force de LaTeX, c'est la cohérence visuelle. Donc pour les proceedings, il FAUT que tous les papiers utilisent les même réglages. De mon côté, justement pour les proceedings, j'ai toujours aussi envoyé les sources. Et les journaux, notamment Elsevier (et arxiv qui n'est pas vraiment un journal), il faut aussi les sources.
Après, les histoires d'orphelines, ce n'est pas TON boulot, c'est celui de l'éditeur. Après, si pour la soumission, ça te fait perdre une ligne bêtement, ben reformule ta phrase.
Pour le coup, ces réglages me semblent très bon. Le principe est que, pour avoir un confort de lecture optimal, il faut éviter les lignes de plus de 50/60 caractères.
D'ailleurs, puisqu'il y a certains scientifiques par ici, Elsevier joue à mettre des lignes super longues pour avoir moins de papier à imprimer. Et je n'arrive pas à bosser avec les rendu finaux. Soit je bosse avec les versions arxiv, soit j'écris à l'auteur pour qu'il m'envoie une version compilée avec LaTeX.
Quand j'écris un article, je ne joue JAMAIS avec les \vspace et autre \kern.
D'ailleurs, pour soumettre un article à un conf, je pense que la bonne démarche est de fournir une classe bien faite et d'interdire
\usepackage
\def
\newcommand
\renewcommand
\hspace
\vspace
\kern
\enlargethispage
et autre joyeusetée de ce genre.
En plus, c'est super facile. Un bête grep et on refuse la soumission.
Et comme je suis un gros théoricien, je vais faire une analogie.
Dire si un programme va planter au bout d'un moment est indécidable: on n'a pas d'algorithme pour décider en temps fini si oui ou non ça plante. La seule chose qu'on puisse faire, c'est lancer le programme et voir si ça plante.
Avec les effets nocifs, c'est la même chose. On ne peut pas montrer que quelque chose n'a pas d'effet. La seule chose qu'on puisse prouver c'est qu'il y a un effet.
Exemple. Mange de la ciguë, tu vas vite te rendre compte que c'est nocif. Pour d'autres choses (amiante), il faut attendre un peu plus. Pour l'instant, en ce qui concerne les OEM, on a attendu un certain temps et on a rien vu de gênant. Ça ne veut pas dire que si on attend plus longtemps, on ne verra pas des problèmes mais on ne sait pas. À l'heure actuelle, on ne sait pas si les OEM sont dangereuses ou pas.
Maintenant, compte tenu du temps d'exposition (avec la télé et la radio), on peut quand même penser que les OEM en général ne sont pas trop dangereuse. Et pour les OEM liée au téléphones cellulaires et au wifi, on commence à avoir un certain nombre d'année de recul sans problèmes.
À partir du moment où tu peux écrire dans un langage foo un interpréteur pour un langage bar, tu peux faire du bar avec du foo. Donc tu peux faire du fonctionnel pur en C et de la programmation logique en Ada.
C'est un peu tiré par les cheveux mais ça marche. Attention, je n'ai pas dit que c'était naturel ou efficace.
Je sens que tu vas dire qu'implémenter de façon objet un interpréteur pour un langage fondé sur des entités et d'interpréter ton « vrai » programme n'est pas non plus une bonne solution.
À mon avis, il y a de très bonnes raisons de parler de ce logiciel sur linuxfr.
Ce n'est pas en se regardant le nombril et en refusant de regarder ce qui se fait de bien dans le monde propriétaire que le libre va avancer.
L'exemple du crash indolore est un très bon exemple.
D'ailleurs, je ne sais plus où, j'avais lu un type qui implémentait la fonction quitter de ses logiciels par « kill -9 $pid ». L'idée étant que de toute façon, en cas de crash, il FAUT perdre le moins de chose possibles. Et si on quitte autrement, on ne testera jamais bien les méthodes de récupérations en cas de crash. Alors que là, s'il y a un bug dans la récupération, ça se voit très vite.
J'arrive un peu après la bataille mais un certain nombre de choses que tu décris dont le fait de pouvoir modifier la vue qu'a un processus du FS me font penser à plan 9 et à son modèle de sécurité.
Je pense qu'il aurait été plus simple de simplement dire qu'à part certaines bibliothèques qui font partie du système (typiquement pour les toolkits genre QT), on fait une appli compilée en static. Comme ça pas de dépendances et tout reste géré avec des .deb.
Et ne me dites pas que si on fait, ça, on va gaspiller beaucoup de place. Je viens de compter. Sur ma debian, j'ai environ 1800 paquets installés et environ 900 paquets libtruc. Par exemple, ne me dites pas que libmetacity-private0a est utilisé par 1000 paquets différents.
Juste comme ça, je ne fais pas la différence mais au bout d'une heure de lecture, dans un cas, j'ai mal aux yeux et pas dans l'autre. Ça fait parti des détails qu'on ne remarque pas mais qui font toute la différence. Si je me souviens bien, le journal Le monde a utilisé au moins à un moment une font spécifiquement développé pour lui pour rendre la lecture plus agréable.
Ton affirmation sur la résolution des impression pro m'étonne. Au labo, j'ai la possibilité d'imprimer sur des imprimantes laser en 300 ou 600dpi et je fais clairement la différence.
Je connais au moins un bouquin qui a été imprimé à 2400dpi pour éviter des effets de moirage sur certaines figures.
Juste pour faire un essai, prend un article quelconque et imprimes-le en 90dpi, 200dpi et 600dpi et essaye de les lire.
De plus l'argument qui dit que ça fait plus de calcul est peut-être vrai mais à 600dpi, il n'y aurait plus besoin de faire de l'aliasing sur les fonts et ça gagnerait des cycles.
Pour jack, c'est temps réel et latence faible à tout prix même si ça bouffe 100% du processeur.
Pour PA, c'est plus orienté desktop avec dans l'idée quelque chose de pas trop mauvais le plus souvent mais sans aucune garantie de latence mais avec une charge machine plus faible.
Le système de tags suffisamment évolué permet de faire tout ce qu'on peut faire avec du relationnel.
Première remarque, si on a beaucoup de tags, on va vouloir les organiser. Pour cela, on ne va pas utiliser de structure hiérarchique mais on va permettre de taguer des tags.
À partir du moment où on peut faire ça, c'est possible de simuler une ligne d'une table. On a un identifiant l par ligne et c par colonne. On tague l'élément e de la colonne c à la ligne l par c et l. Après, à coup d'opération ensembliste, on peut retrouver tous les éléments d'une colonne (tous deux qui ont le tag c) ou ceux d'une ligne (ceux qui ont le tag l).
Après, on peut imagine que cd toto sélectionne les éléments qui on le tag toto. Dans ce cas là, on peut très facilement faire une requête conjonctive: cd toto/titi. Il suffirait d'ajouter 4 caractères supplémentaires interdit dans les noms de tag (, ), !, | et on pourrait faire une requête cd toto|(!titi/tata)
Déjà avec ça, on peut faire des trucs assez sympa. Après, on peut vouloir des tags associés à des dates. C'est un peu plus compliqué mais pas beaucoup.
Le seul vrai problème que ça poserait, c'est qu'un répertoire pourrait contenir plusieurs fichiers ayant le même nom.
C'est quelque chose que j'ai déjà du dire sur linuxfr mais bon, je vais me répéter.
On sait depuis les années 70 que les bases de données hiérarchiques, c'est la merde. C'est pour cela qu'on a inventé les bases de données relationnelles. Mais 40 ans après, on se traîne encore et toujours des bases hiérarchiques (dans les mailers, dans les systèmes de fichiers…).
Je rêve d'un monde où les systèmes de fichiers seraient relationnels. On pourrait taguer les fichiers et faire des requêtes. Et on pourrait imagine créer des vues pour les requêtes fréquentes. On pourrait même appeler ces vues des répertoires. Ça permettrait de virer toutes ces bases faites à la main dans plein de logiciels et d'éviter que tout le monde réinvente la roue de son côté.
Pourquoi acheter devrait-il être forcément rentable ?
J'ai acheté un appartement dans l'une des villes ou « il ne faut surtout pas acheter non non non ! » Et j'en suis très content. Je n'aurais jamais pu louer un appartement équivalent.
L'argent, c'est aussi fait pour se faire plaisir de temps en temps.
On gueule sur la SNCF mais j'ai aussi pratiqué les trains en Angleterre et Allemagne et depuis, j'aime la SNCF.
De mon expérience, les trains allemands sont beaucoup moins à l'heure et ont plus de problèmes que les trains français. Dernière histoire en date, je devais prendre un ICE Frankfurt -> Saarbrücken. Comme il serait parti avec 30 minutes de retard, ils l'ont purement et simplement supprimé. Démerdez-vous. Ce genre de chose arrive aussi en France mais c'est exceptionnel sur les grandes lignes. Pas en Allemagne.
Et si on parle du site bahn.de. Je ne sais pas si vous avez essayé d'acheter un billet (et pas seulement consulté les horaires) mais ça peut aussi être folklorique. J'ai peut-être plus l'habitude de voyages-sncf.com mais je trouve qu'il s'est beaucoup amélioré et pour prendre des billets, je le trouve très supérieur au site Allemand.
Pour le lien cassé, c'est dans http://utroff.org/doc.html
après « Software documentation » le lien refer.pdf
Pour le bug report, tu peux mettre « Frédéric Mazoit ».
Comme je l'ai dis, les goûts personnels sont importants. Mais je vais tenter de justifier un peu plus mon histoire d'espaces entre les items.
Il faut vraiment un papier fin ou lire en transparence pour voir le décalage. Je pense que le désagrément est minime en comparaison du gain.
Tu considères qu'il faut ajouter des espaces pour les (sous-)sections. Pourtant, ça participe aussi au décalage. Et puis augmenter la taille des polices pour mettre en valeur des titres décale aussi le texte.
Cette remarque me rappelle un commentaire d'une connaissance à propos du bio.
Énervé par les arguments des « pros-bio » du type « Le bio, c'est mieux, y a pas plein de trucs pas naturel », il répondait truc du genre « Ouai, beaucoup d'huiles essentielles sont tératogènes. Sans parler de la ciguë dont tout le monde sait que c'est pas dangereux. » J'ai toujours trouvé cet argument débile. Ce n'est pas parce que certains produits naturels sont dangereux que cela justifie d'utiliser d'autres produits potentiellement dangereux sans discernement. Avec ce genre de raisonnement, on peut dire que la vie est une MST mortelle à 100%. Donc se préoccuper de santé publique est inutile.
Oui le soleil est dangereux. Ce n'est pas pour autant que c'est ridicule d'essayer de limiter l'exposition aux radiations.
C'est donc parti pour plus de commentaires.
N'ayant aucune idée de la logique derrière la mise en forme, je vais me contenter de remarques sur les documents.
Pour rester concis, je fais des commentaires à l'emporte pièce mais bien évidemment, la typographie est pour beaucoup une question de goûts. Merci de rajouter des « À mon avis… » et des « Je trouve que… » un peu partout.
Marges et entête
Pour un document conçu pour être imprimé comme un pdf, le numéro de page doit être à gauche sur les pages paires et la marge intérieure doit être légèrement plus importante.
Espaces verticales
Il en manque. Notamment pour écarter les items des listes et après les titres des (sous-)sections. Il n'y a pas besoin de grand chose, voir même il ne faut pas que ces espaces soient trop grand. En LaTeX, je mettrais un \smallskip. Pour les listes, j'en ai déjà parlé mais pour les sections, je trouve par exemple que la page 10 Section 3. et sous-section 3.1 du fichier ugrind.pdf illustrent bien cela.
La première de couverture
Elle ne doit pas avoir de numéro de page, d'entête et de pied de page.
Pieds de page
Il faut retirer les traits en bas de page.
Ceux du haut se justifient pour séparer le numéro de page et le titre du document mais ceux du bas sont gratuits et alourdissent inutilement le document. C'est particulièrement moche avec les « petites fleurs » qui servent de séparateurs.
Les titres et sous-titres
Ils doivent être légèrement plus gros pour être plus mis en valeur.
C'est d'autant plus important que le gras est beaucoup (trop) utilisé et donc simplement graisser ces titres n'est pas suffisant. C'est particulièrement flagrant sur les pages 4 et 5 du fichier utmac.pdf.
Utilisation du gras
Trop de choses sont graissées.
Si j'ai bien compris, c'est notamment le cas des switchs et des options de la ligne de commande. Ça entre en collision avec le gras des titres et des (sous-)sections et ça donne une impression un peu fouillis. De plus, c'est une mise en valeur trop importante. C'est flagrant page 3. du fichier ugrind.pdf dans le paragraphe juste avant la section « Programming style ». Pour cette utilisation, j'utiliserais une police « type writer ».
[^] # Re: Langage
Posté par fmaz fmaz . En réponse au journal Le HTML (epub3) peut il détrôner latex (surtout beamer) ?. Évalué à 1.
Quand je dis que la classe doit être bien faite, je dis que c'est à elle d'inclure les paquets utiles. Donc si la conf ne veut pas de figure, ben non, pas de pfg. Si elle ne veut pas d'algorithmes, pas de paquets pour ça…
Au hasard, un 'grep RequirePackage' sur le style d'une conf me donne:
La force de LaTeX, c'est la cohérence visuelle. Donc pour les proceedings, il FAUT que tous les papiers utilisent les même réglages. De mon côté, justement pour les proceedings, j'ai toujours aussi envoyé les sources. Et les journaux, notamment Elsevier (et arxiv qui n'est pas vraiment un journal), il faut aussi les sources.
Après, les histoires d'orphelines, ce n'est pas TON boulot, c'est celui de l'éditeur. Après, si pour la soumission, ça te fait perdre une ligne bêtement, ben reformule ta phrase.
[^] # Re: Langage
Posté par fmaz fmaz . En réponse au journal Le HTML (epub3) peut il détrôner latex (surtout beamer) ?. Évalué à 1.
Pour le coup, ces réglages me semblent très bon. Le principe est que, pour avoir un confort de lecture optimal, il faut éviter les lignes de plus de 50/60 caractères.
D'ailleurs, puisqu'il y a certains scientifiques par ici, Elsevier joue à mettre des lignes super longues pour avoir moins de papier à imprimer. Et je n'arrive pas à bosser avec les rendu finaux. Soit je bosse avec les versions arxiv, soit j'écris à l'auteur pour qu'il m'envoie une version compilée avec LaTeX.
[^] # Re: Langage
Posté par fmaz fmaz . En réponse au journal Le HTML (epub3) peut il détrôner latex (surtout beamer) ?. Évalué à 0.
Quand j'écris un article, je ne joue JAMAIS avec les \vspace et autre \kern.
D'ailleurs, pour soumettre un article à un conf, je pense que la bonne démarche est de fournir une classe bien faite et d'interdire
\usepackage
\def
\newcommand
\renewcommand
\hspace
\vspace
\kern
\enlargethispage
et autre joyeusetée de ce genre.
En plus, c'est super facile. Un bête grep et on refuse la soumission.
[^] # Re: rien de neuf ?
Posté par fmaz fmaz . En réponse au journal Rapport Anses sur les effets des OEM sur la santé. Évalué à 3.
Et comme je suis un gros théoricien, je vais faire une analogie.
Dire si un programme va planter au bout d'un moment est indécidable: on n'a pas d'algorithme pour décider en temps fini si oui ou non ça plante. La seule chose qu'on puisse faire, c'est lancer le programme et voir si ça plante.
Avec les effets nocifs, c'est la même chose. On ne peut pas montrer que quelque chose n'a pas d'effet. La seule chose qu'on puisse prouver c'est qu'il y a un effet.
Exemple. Mange de la ciguë, tu vas vite te rendre compte que c'est nocif. Pour d'autres choses (amiante), il faut attendre un peu plus. Pour l'instant, en ce qui concerne les OEM, on a attendu un certain temps et on a rien vu de gênant. Ça ne veut pas dire que si on attend plus longtemps, on ne verra pas des problèmes mais on ne sait pas. À l'heure actuelle, on ne sait pas si les OEM sont dangereuses ou pas.
Maintenant, compte tenu du temps d'exposition (avec la télé et la radio), on peut quand même penser que les OEM en général ne sont pas trop dangereuse. Et pour les OEM liée au téléphones cellulaires et au wifi, on commence à avoir un certain nombre d'année de recul sans problèmes.
[^] # Re: rien de neuf ?
Posté par fmaz fmaz . En réponse au journal Rapport Anses sur les effets des OEM sur la santé. Évalué à 2.
Arrête de respirer tout de suite! L'oxygène c'est dangereux.
[^] # Re: Et les traits ?
Posté par fmaz fmaz . En réponse à la dépêche Je crée mon jeu vidéo E01 : les systèmes à entités. Évalué à 2.
Cf mon commentaire précédent.
À partir du moment où tu peux écrire dans un langage foo un interpréteur pour un langage bar, tu peux faire du bar avec du foo. Donc tu peux faire du fonctionnel pur en C et de la programmation logique en Ada.
C'est un peu tiré par les cheveux mais ça marche. Attention, je n'ai pas dit que c'était naturel ou efficace.
[^] # Re: « préférer la composition à l’héritage »
Posté par fmaz fmaz . En réponse à la dépêche Je crée mon jeu vidéo E01 : les systèmes à entités. Évalué à 1.
Je sens que tu vas dire qu'implémenter de façon objet un interpréteur pour un langage fondé sur des entités et d'interpréter ton « vrai » programme n'est pas non plus une bonne solution.
Pffff
[^] # Re: Cloud & SAAS
Posté par fmaz fmaz . En réponse au journal LucidChart - deux mois après. Évalué à 9.
À mon avis, il y a de très bonnes raisons de parler de ce logiciel sur linuxfr.
Ce n'est pas en se regardant le nombril et en refusant de regarder ce qui se fait de bien dans le monde propriétaire que le libre va avancer.
L'exemple du crash indolore est un très bon exemple.
D'ailleurs, je ne sais plus où, j'avais lu un type qui implémentait la fonction quitter de ses logiciels par « kill -9 $pid ». L'idée étant que de toute façon, en cas de crash, il FAUT perdre le moins de chose possibles. Et si on quitte autrement, on ne testera jamais bien les méthodes de récupérations en cas de crash. Alors que là, s'il y a un bug dans la récupération, ça se voit très vite.
# Plan 9
Posté par fmaz fmaz . En réponse au journal Annonce : Manux 0.0.1. Évalué à 4.
J'arrive un peu après la bataille mais un certain nombre de choses que tu décris dont le fait de pouvoir modifier la vue qu'a un processus du FS me font penser à plan 9 et à son modèle de sécurité.
Qu'en est-il ?
[^] # Re: quoi faire
Posté par fmaz fmaz . En réponse à la dépêche OLinuXino, la RaspBerry Pi version Open Source. Évalué à 1.
Un autre classique est de faire 10 mesures, de retirer les 2 plus basses et les 2 plus hautes et de prendre la moyenne du reste.
[^] # Re: C'est plus facile de travailler salement…
Posté par fmaz fmaz . En réponse à la dépêche Un nouveau format de paquets logiciels utilisateurs pour Ubuntu. Évalué à 1.
Je pense qu'il aurait été plus simple de simplement dire qu'à part certaines bibliothèques qui font partie du système (typiquement pour les toolkits genre QT), on fait une appli compilée en static. Comme ça pas de dépendances et tout reste géré avec des .deb.
Et ne me dites pas que si on fait, ça, on va gaspiller beaucoup de place. Je viens de compter. Sur ma debian, j'ai environ 1800 paquets installés et environ 900 paquets libtruc. Par exemple, ne me dites pas que libmetacity-private0a est utilisé par 1000 paquets différents.
[^] # Re: question un peu idiote
Posté par fmaz fmaz . En réponse au journal L'avenement des écrans haute-résolution. Évalué à 3.
Juste comme ça, je ne fais pas la différence mais au bout d'une heure de lecture, dans un cas, j'ai mal aux yeux et pas dans l'autre. Ça fait parti des détails qu'on ne remarque pas mais qui font toute la différence. Si je me souviens bien, le journal Le monde a utilisé au moins à un moment une font spécifiquement développé pour lui pour rendre la lecture plus agréable.
Ton affirmation sur la résolution des impression pro m'étonne. Au labo, j'ai la possibilité d'imprimer sur des imprimantes laser en 300 ou 600dpi et je fais clairement la différence.
Je connais au moins un bouquin qui a été imprimé à 2400dpi pour éviter des effets de moirage sur certaines figures.
[^] # Re: question un peu idiote
Posté par fmaz fmaz . En réponse au journal L'avenement des écrans haute-résolution. Évalué à 4.
C'est juste du confort.
Juste pour faire un essai, prend un article quelconque et imprimes-le en 90dpi, 200dpi et 600dpi et essaye de les lire.
De plus l'argument qui dit que ça fait plus de calcul est peut-être vrai mais à 600dpi, il n'y aurait plus besoin de faire de l'aliasing sur les fonts et ça gagnerait des cycles.
[^] # Re: Liens matériel-ALSA-PulseAudio
Posté par fmaz fmaz . En réponse à la dépêche Sortie de PulseAudio 4.0. Évalué à 2.
Le but de jack et de PA sont très différents.
Pour jack, c'est temps réel et latence faible à tout prix même si ça bouffe 100% du processeur.
Pour PA, c'est plus orienté desktop avec dans l'idée quelque chose de pas trop mauvais le plus souvent mais sans aucune garantie de latence mais avec une charge machine plus faible.
C'est un peu la différence en linux et linuxRT.
[^] # Re: Mixeur
Posté par fmaz fmaz . En réponse au journal La glace au blender. Évalué à 2.
Au passage, les professionnels parlent de girafe et pas de mixeur plongeant.
[^] # Re: 0 folder = inbox 0
Posté par fmaz fmaz . En réponse au journal La gestion de courriels est-elle adulte ou encore au stade de l'enfance ?. Évalué à 2.
Le système de tags suffisamment évolué permet de faire tout ce qu'on peut faire avec du relationnel.
Première remarque, si on a beaucoup de tags, on va vouloir les organiser. Pour cela, on ne va pas utiliser de structure hiérarchique mais on va permettre de taguer des tags.
À partir du moment où on peut faire ça, c'est possible de simuler une ligne d'une table. On a un identifiant l par ligne et c par colonne. On tague l'élément e de la colonne c à la ligne l par c et l. Après, à coup d'opération ensembliste, on peut retrouver tous les éléments d'une colonne (tous deux qui ont le tag c) ou ceux d'une ligne (ceux qui ont le tag l).
Après, on peut imagine que cd toto sélectionne les éléments qui on le tag toto. Dans ce cas là, on peut très facilement faire une requête conjonctive: cd toto/titi. Il suffirait d'ajouter 4 caractères supplémentaires interdit dans les noms de tag (, ), !, | et on pourrait faire une requête cd toto|(!titi/tata)
Déjà avec ça, on peut faire des trucs assez sympa. Après, on peut vouloir des tags associés à des dates. C'est un peu plus compliqué mais pas beaucoup.
Le seul vrai problème que ça poserait, c'est qu'un répertoire pourrait contenir plusieurs fichiers ayant le même nom.
[^] # Re: 0 folder = inbox 0
Posté par fmaz fmaz . En réponse au journal La gestion de courriels est-elle adulte ou encore au stade de l'enfance ?. Évalué à 6.
J'adore ta règle 3: pas de dossier mais des tags.
C'est quelque chose que j'ai déjà du dire sur linuxfr mais bon, je vais me répéter.
On sait depuis les années 70 que les bases de données hiérarchiques, c'est la merde. C'est pour cela qu'on a inventé les bases de données relationnelles. Mais 40 ans après, on se traîne encore et toujours des bases hiérarchiques (dans les mailers, dans les systèmes de fichiers…).
Je rêve d'un monde où les systèmes de fichiers seraient relationnels. On pourrait taguer les fichiers et faire des requêtes. Et on pourrait imagine créer des vues pour les requêtes fréquentes. On pourrait même appeler ces vues des répertoires. Ça permettrait de virer toutes ces bases faites à la main dans plein de logiciels et d'éviter que tout le monde réinvente la roue de son côté.
[^] # Re: Conservatisme
Posté par fmaz fmaz . En réponse à la dépêche Debian : Épisode VII. Évalué à 1.
En même temps, si c'était un bug qui arrivait systématiquement, on peut quand même imaginer qu'il aurait été corrigé.
Donc le fait que sur deux exemples, la migration se soit bien passé n'est pas forcément une preuve du fait qu'il n'y a pas de problème.
# ???
Posté par fmaz fmaz . En réponse au journal L'immobilier, c'était mieux avant !. Évalué à 10.
Pourquoi acheter devrait-il être forcément rentable ?
J'ai acheté un appartement dans l'une des villes ou « il ne faut surtout pas acheter non non non ! » Et j'en suis très content. Je n'aurais jamais pu louer un appartement équivalent.
L'argent, c'est aussi fait pour se faire plaisir de temps en temps.
[^] # Re: Bahn
Posté par fmaz fmaz . En réponse au journal Ça faisait longtemps : SNCF mon amour. Évalué à 3.
Pour consulter les horaires il est très bien mais pour acheter les billets, c'est la merde. À chaque fois, j'abandonne et je vais à un guichet.
# Bahn
Posté par fmaz fmaz . En réponse au journal Ça faisait longtemps : SNCF mon amour. Évalué à 8.
On gueule sur la SNCF mais j'ai aussi pratiqué les trains en Angleterre et Allemagne et depuis, j'aime la SNCF.
De mon expérience, les trains allemands sont beaucoup moins à l'heure et ont plus de problèmes que les trains français. Dernière histoire en date, je devais prendre un ICE Frankfurt -> Saarbrücken. Comme il serait parti avec 30 minutes de retard, ils l'ont purement et simplement supprimé. Démerdez-vous. Ce genre de chose arrive aussi en France mais c'est exceptionnel sur les grandes lignes. Pas en Allemagne.
Et si on parle du site bahn.de. Je ne sais pas si vous avez essayé d'acheter un billet (et pas seulement consulté les horaires) mais ça peut aussi être folklorique. J'ai peut-être plus l'habitude de voyages-sncf.com mais je trouve qu'il s'est beaucoup amélioré et pour prendre des billets, je le trouve très supérieur au site Allemand.
[^] # Re: Quelques commentaires en passant.
Posté par fmaz fmaz . En réponse au journal Utroff est publié. Évalué à 2.
Pour le lien cassé, c'est dans http://utroff.org/doc.html
après « Software documentation » le lien refer.pdf
Pour le bug report, tu peux mettre « Frédéric Mazoit ».
Comme je l'ai dis, les goûts personnels sont importants. Mais je vais tenter de justifier un peu plus mon histoire d'espaces entre les items.
Bref. Je t'ai donné mon avis.
En tout cas, beau boulot.
[^] # Re: Parce que
Posté par fmaz fmaz . En réponse au journal Une tablette avec RJ45 ?. Évalué à 4.
Cette remarque me rappelle un commentaire d'une connaissance à propos du bio.
Énervé par les arguments des « pros-bio » du type « Le bio, c'est mieux, y a pas plein de trucs pas naturel », il répondait truc du genre « Ouai, beaucoup d'huiles essentielles sont tératogènes. Sans parler de la ciguë dont tout le monde sait que c'est pas dangereux. » J'ai toujours trouvé cet argument débile. Ce n'est pas parce que certains produits naturels sont dangereux que cela justifie d'utiliser d'autres produits potentiellement dangereux sans discernement. Avec ce genre de raisonnement, on peut dire que la vie est une MST mortelle à 100%. Donc se préoccuper de santé publique est inutile.
Oui le soleil est dangereux. Ce n'est pas pour autant que c'est ridicule d'essayer de limiter l'exposition aux radiations.
[^] # Re: Quelques commentaires en passant.
Posté par fmaz fmaz . En réponse au journal Utroff est publié. Évalué à 1.
Ça me paraît sans doute pas mal.
[^] # Re: Quelques commentaires en passant.
Posté par fmaz fmaz . En réponse au journal Utroff est publié. Évalué à 3.
C'est donc parti pour plus de commentaires.
N'ayant aucune idée de la logique derrière la mise en forme, je vais me contenter de remarques sur les documents.
Pour rester concis, je fais des commentaires à l'emporte pièce mais bien évidemment, la typographie est pour beaucoup une question de goûts. Merci de rajouter des « À mon avis… » et des « Je trouve que… » un peu partout.
Marges et entête
Pour un document conçu pour être imprimé comme un pdf, le numéro de page doit être à gauche sur les pages paires et la marge intérieure doit être légèrement plus importante.
Espaces verticales
Il en manque. Notamment pour écarter les items des listes et après les titres des (sous-)sections. Il n'y a pas besoin de grand chose, voir même il ne faut pas que ces espaces soient trop grand. En LaTeX, je mettrais un \smallskip. Pour les listes, j'en ai déjà parlé mais pour les sections, je trouve par exemple que la page 10 Section 3. et sous-section 3.1 du fichier ugrind.pdf illustrent bien cela.
La première de couverture
Elle ne doit pas avoir de numéro de page, d'entête et de pied de page.
Pieds de page
Il faut retirer les traits en bas de page.
Ceux du haut se justifient pour séparer le numéro de page et le titre du document mais ceux du bas sont gratuits et alourdissent inutilement le document. C'est particulièrement moche avec les « petites fleurs » qui servent de séparateurs.
Les titres et sous-titres
Ils doivent être légèrement plus gros pour être plus mis en valeur.
C'est d'autant plus important que le gras est beaucoup (trop) utilisé et donc simplement graisser ces titres n'est pas suffisant. C'est particulièrement flagrant sur les pages 4 et 5 du fichier utmac.pdf.
Utilisation du gras
Trop de choses sont graissées.
Si j'ai bien compris, c'est notamment le cas des switchs et des options de la ligne de commande. Ça entre en collision avec le gras des titres et des (sous-)sections et ça donne une impression un peu fouillis. De plus, c'est une mise en valeur trop importante. C'est flagrant page 3. du fichier ugrind.pdf dans le paragraphe juste avant la section « Programming style ». Pour cette utilisation, j'utiliserais une police « type writer ».
Le lien sur refer.pdf est cassé