Oui, je me suis aperçu après coup que je pouvais y écrire. La FAQ semblait indiquer quelque chose de plus "fermé". J'imagine que ça a dû évoluer depuis.
Pour la licence, j'ai complètement oublié… en fait je n'ai aucune idée de la température là-bas sur ces questions. Leur wiki est en CC-by-sa/GFDL, ce qui se comprend aisément pour ce type d'outil, mais pour le reste… je poserai la question si j'obtiens un feu vert sur le principe. Je pense que le point central sera alors de pointer sur l'original, ce qui est de toute manière indispensable pour ce genre de projet.
J'ai envoyé la demande à LQ. A priori, il est à peine 9h du matin chez le responsable du site, ça peut donc prendre un peu de temps avant d'avoir la réponse. :)
l'entretien est quand même assez long, et traduire un texte est pour moi un cran au dessus de simplement le lire;
j'ai dans l'idée, peut-être reçue, que les slackeux en général se débrouillent en anglais.
Voilà l'histoire. Maintenant, si vraiment ça intéresse, je veux bien mettre en branle le bouzin (faudra aussi que je demande un accès à l'espace rédaction, pour que tout le monde puisse donner la main non mé). :)
Je n'ai pas pu lire l'article pointé par le lien (bloqué par le filtre web du taf) mais attention à ne pas confondre les accords de Bâle et les réserves obligatoires fixées par la banque centrale!
Aucune importance, parce que le passage incriminé, en plus d'être cité très approximativement, ne parle absolument pas de ça (il n'est jamais question de la BCE dans l'article). Je graisse la citation exacte:
Ce qui est absurde, c'est de vouloir faire croire qu'il n'y a rien que création fictive d'argent comme si les crédits n'étaient jamais remboursés et qu'il n'y avait pas création de valeur dans la production réelle pour les rembourser. C'est pour cela que les banques peuvent vous prêter juste autant que vous pouvez emprunter, c'est-à-dire autant que vous pouvez rembourser (y compris les intérêts!), c'est-à-dire finalement autant que vous pouvez produire ou gagner. Il y a aussi régulièrement destruction de dettes, c'est une des raisons de l'intérêt, il n'y a donc pas une croissance exponentielle des dettes qui seraient irremboursables. C'est la véritable arnaque du film de ne parler quasiment pas d'apurement des dettes et de faire comme si la dette était complètement illimitée ! Il est aussi absurde de prétendre qu'il faudrait emprunter pour payer les intérêts ! Ce qui est escamotée derrière, c'est la question de la plus-value.
Le sens de la critique, c'est que les banques au final attendent de l'argent issu de l'économie réelle. D'où on ne peut réduire le mécanisme d'endettement à un simple jeu d'écritures arbitraires, comme le fait visiblement le film (que je n'ai pas vu).
Donc, le /dev/, vous le backupez ou pas? et comment?
Non, mais si j'avais à le faire, je regarderais du côté de cpio. Les initrd du noyau Linux sont des archives cpio compressées, et c'est comme ça que de nos jours on charge les systèmes live (un installeur par ex. ) en RAM.
Ouf merci, je n'osais avouer à personne que je trouvais cpold bien plus simple pour des micro-projets que de se forcer à gérer proprement des versions et tout le toutim, de peur de passer pour un fou. Ça me rassure de voir qu'il y a au moins une autre personne au monde qui pense aussi ça :)
Non Jeff, t'es pas tout seul… Enfin, j'essaie quand même de me tenir à une discipline : 1 cpold = 1 fonctionnalité majeure précise, et chaque version du logiciel ne doit pas avoir plus de un ou deux changements majeurs. Comme ça, une fois que c'est bouclé, sauf découverte d'un bug critique (rare) dans la version publique, je m'installe une rc privée sur mon système que j'utilise quelques semaines avant publication. Ça permet d'être sûr que tout tient à peu près debout avant de livrer et évite au mieux les livraisons-colmatages catastrophes pour les utilisateurs. :)
oh bah de rien, la plateforme est là pour être utilisée au mieux, quels que soient les besoins.
Ah bah quand même, faut le dire de temps en temps. Perso, je vous fais de la pub dès que je peux (en insistant bien pour que les gens indiquent la licence de leur projet en 4x3 dans leur requête, histoire de pas se faire doucher au premier contact ! ;)
Merci pour ton riche retour d'expérience et tes précieux conseils.
De rien, tant mieux si ça peut servir. :)
À noter que c'est aussi une bonne idée de te référencer sur fresh… euh freecode et d'y annoncer chaque release pour donner de la visibilité à ton projet. Comme c'est un index pompé par quasiment tous les autres, tu te retrouves très vite un peu partout.
J'ai également oublié un conseil sur la procédure d'installation : passe par un configure/Makefile, en copiant l'interface des autotools même si tout est maison (en particulier le support de la variable d'installation DESTDIR). Ça simplifiera beaucoup le boulot des éventuels empaqueteurs (bon, vu la teneur de ton journal, tu y as sûrement déjà pensé).
En tant qu'auteur de nano-projets, je te conseillerais de rester le plus simple possible. Pour mon premier, j'avais vu "grand" avec un site dédié (présentation, changelog, FAQ, page de téléchargement, le tout en HTML vaguement mouliné), branches stable/devel et listes de diffusion devel/annonces. Ça n'a jamais servi à rien, à part à alourdir la gestion du bouzin. C'est pour ça que très vite j'ai adopté le modèle "un projet, une branche, une page, (jawohl!)" et ai par la suite fini par grouper tous mes projets sur un seul site (au passage, merci à l'équipe de tuxfam. pour avoir toléré mes tergiversations :). J'ai même au bout du compte abandonné les contrôleurs de version. En cinq ans, je ne me souviens effet pas avoir eu besoin de revenir en arrière. D'ailleurs, même si ça se présentait, en tant qu'auteur unique je ne vois pas ce qui serait insurmontable (de fait, tout reste dans mes compétences, en plus hein! ça me fait la couenne, j'ai qu'à savoir ce que je veux), et puis il y a toujours le rustique mais efficace cpold.
Aujourd'hui je génère mon site et mes manuels à partir d'une moulinette perso qui prend des sources type Markdown (jette un œil sur l'implémentation initiale de cette syntaxe, tu verras que ce n'est pas très sorcier de bricoler quelque chose autour, y compris vers groff_man, qui est finalement assez simple). Je pousse ensuite tout ça en statique via un script de miroir basé sur lftp, et roule (autre chose appréciable chez tuxfam., tu peux gérer ton site alapapa®).
D'une manière générale, attends que les besoins soient là avant d'y répondre, tout anticiper étant le meilleur moyen de se retrouver avec une montagne accouchant d'une souris (ou plutôt l'inverse : un truc long et douloureux qui fait bien chier). Fais donc avant tout les choses pour toi, au plus simple comme ça t'arrange, et reste à l'écoute des éventuels retours pour décider des changements à apporter.
J'y travaille actuellement pour mon projet, et je m'aperçois que les enjeux sont importants, car une fois le logiciel publié, la liberté de modification sera limitée par l'exigence de rétro-compatibilité.
Sauf que l'ampleur des changements, tu ne peux jamais la prévoir. Pour le moment, j'ai trouvé deux parades :
publier un ChangeLog circonstancié, sur le modèle de ce que fait Patrick Volkerding pour Slackware. Ça permet de donner les infos de mises à niveau et d'indiquer les motivations de tel ou tel changement.
attribuer ce que j'appelle une "version totémique", qui assure la compatibilité entre les données de l'utilisateur et la version du logiciel. Par exemple pour tofu, le format de la todo est nommé "Ciboulette". Si jamais je suis amené à changer quoi que ce soit, j'aurais juste à changer ce nom pour que tofu réclame sans rien péter la mise à niveau (j'ai fait la commande dédié tofuup, mais on peut aussi faire des scripts dédiés, si on veut être moins formel). Ainsi, je peux continuer à faire ce que je veux avec un désagrément minimal pour les utilisateurs et en restant totalement libre au niveau du numéro de version (un changement de totem n'est pas forcément synonyme d'un gros changement interne ou d'interface).
Voilà, c'était mon petit retour d'expérience à deux balles… :)
Sauf que si tu lis bien, il y a forcément une partie plein-air : « En effet, en dehors de l'approvisionnement impérativement bio de l'élevage (95 % de l'aliment et des poulettes certifiées si possible) et d'une conduite sanitaire spécifique, le cahier des charges bio diffère peu de la production plein-air. »
Zéro plein-air, c'est pas différer un peu. Il suffit de chercher auprès des chambres d'agriculture, où on trouve les modalités de la production des œufs bio (PDF, dsl). Le hors-sol est explicitement interdit, et les animaux doivent pouvoir sortir.
Ce qui est "hors-sol" dans l'article (c'est vrai que c'est pas clair), àmha, c'est que toute la nourriture est amenée de l'extérieur à cause de la pauvreté des sols.
Des cartes des résultats département par département circulent, il suffit de les consulter pour se rendre compte qu’il y a des disparités énormes en fonction des lieux. Ces disparités ont toutes les chances d’être encore plus grandes si on commence à comparer en fonction de la classe sociale, de la participation active sur Internet, etc.
On peut également le voir sur le site du Ministère de l'Intérieur. Même d'une commune voisine à l'autre ça peut effectivement varier du tout au tout…
Je pense qu'il serait temps aussi que le développement de la Slackware change un peu… Ça va faire un an que la -current tourne sans très gros changement, à part des mises à jour du toolchain et de GrôKad.
Je ne retrouve pas le fil sur LQ, mais il semble que Pat ait pris quelques "vacances" (ça avait d'ailleurs aussi fait paniquer certains), d'où le cycle anormalement long…
Pour le mode de dév, c'est àmha pas près de changer, dans la mesure où c'est la source de revenus de Pat. S'il se met à déléguer, fatalement le partage du travail débouchera tôt ou tard sur la question du partage des revenus. Or, je ne suis pas sûr qu'on puisse vivre à 15.000 sur une distro comme Slackware. Tant qu'il reste seul à faire presque tout le boulot, c'est son bébé et il n'y a rien à discuter à ce niveau-là.
Si on veut signaler un bug ? Il faut envoyer un email privé à Pat. Pas de mailing-list publique, rien. Je ne compte plus les bugs que j'ai signalés, ou scripts que j'ai proposés (par exemple pour remplacer teTeX par un TeX Live à fonctionnalités/taille équivalentes) sans même recevoir la moindre réponse.
Ouais… moi, j'ai arrêté. :|
Je me dis qu'il doit avoir suffisamment de monde. C'est sûr que ce serait cool d'avoir une liste de dév. Mais là encore, ça apporterait du collégial de fait et mettrait Pat en position de chef de projet communautaire, ce qu'il a habilement évité en faisant de LQ le canal Slackware "officiel-oui-mais-non". En plus, depuis le temps, je suis sûr que plein de fois on a dû lui suggérer un forum/une ML/un canal IRC officiels. C'est donc àmha un choix tout à fait délibéré…
La seule chose qui pourrait le pousser à changer, je pense, c'est la complexité grandissante de l'écosystème Linux, qui fait que pour un homme seul c'est de plus en plus dur de tout gérer…
Lorsque MrSpackMan parle de logique il pose la question : y-a-t-il une logique intrinsèque et nécessaire aux macros LaTeX ? […]
Oui, c'est ça. Mais pas seulement pour LaTeX, pour n'importe quel langage orienté rendu. À noter qu'on prend quand même des noms pratiques (et pas logiques) pour le document courant, que ce soit "itembullet" ("de quoi ça a l'air ?") ou "guestlist" ("qu'est-ce que c'est ?"). Les macros c'est un univers où tu peux dire : tomate = clémentine rouge, ou sapin = camion vertical marron et vert à benne triangulaire. Il n'y a aucune logique, juste de la commodité de nommage par rapport à ce qu'on veut rendre.
Pour l'italique, c'est pas l'éditeur qui décide, c'est le français imprimé qui est comme ça. Le lecteur un peu habitué à cette langue saura parfaitement faire la différence entre les sens selon le contexte, autrement il y a longtemps qu'on aurait changé les conventions.
Effectivement, ça c'est de la mise en forme physique, et ça vaudrait le coup de t'interroger sur la raison pour laquelle tu veux faire cela.
Parce que j'en ai tout simplement besoin et que c'est un nom qui correspond bien pour la décrire. Dis-moi, à chaque énumération, tu renommes vraiment "enumerate" en "enumerate" juste pour être "logique"? non, tu te contentes du rendu…
Pour les numérotations, ça exploite juste un mécanisme de base qu'on appelle un compteur, créable et manipulable directement, je te laisse voir comment c'est implémenté dans article.cls, De même pour la génération du sommaire (ça te permettra de voir que ce que tu appelles "commande de base", c'est déjà de la sacrée macro)…
Si, parce que les macros, elles sont nommées et définies une fois, et utilisées plusieurs fois sans recopie de code. À toi de leur donner un nom logique, évidemment.
Je viens de te montrer qu'il n'y avait aucune logique entre les noms. Tu peux construire n'importe quoi à partir de n'importe quoi, sans problème majeur à l'usage. Ce que "signifie" ta macro, c'est son rendu, point barre. Si je crée une classe de document "reptel" pour "répertoire téléphonique" à partir de la classe "article", ça ne voudra pas dire que mes répertoires téléphoniques seront des sortes d'articles. J'utilise simplement les rendus d'une classe pour bâtir ceux d'une autre, le lien s'arrête là.
Dans un environnement français, tu utilises l'environnement logique itemize, et tu le redéfinis pour qu'il utilise des tirets semi-cadratins comme puce.
Tu détournes l'exemple (en babel french, les listes sont à tirets par défaut), c'est l'inverse que je veux : je peux vouloir mettre certaines listes en valeur avec des bulles, et donc me créer un environnement à cet effet. Il ne sera ni plus ni moins "physique" que itemize. Les fioritures, ça existe, la mise en page n'est pas purement fonctionnelle (et heureusement).
« Souligné dans le manuscrit », ce n'est pas une utilisation logique, donc je passe sur cet usage, libre à toi d'analyser cet exemple pour déterminer à quels usages logiques cela correspond. Mot étranger : c'est l'occasion de définir une macro \etranger. Insistance : il y a \emph pour ça.
Pour « souligné dans le manuscrit », c'est tout simplement « souligné dans le manuscrit », tu rends comme l'auteur l'a donné, même si tu ne comprends pas pourquoi. Pour \etranger, super, une macro inutile (quand je parlais de piston à coulisse… ) qui voudra juste dire \textit… ou \emph, parce que la différence entre \emph et \textit en LaTeX, c'est pas le sens, c'est juste que \emph se traduit en romain lorsqu'il est déjà dans un texte en italique. De plus, il y a emphase tonique (ex. "tu m'as demandé de le faire") et emphase sémantique (ex. les termes communs employés en tant que concepts philosophiques), il faudrait donc de toute urgence créer un \emphconcept et un \emphtonique pour utiliser la commande de base \emph…
Tes commandes de base ne sont ni plus ni moins "physiques" que les macros. Si dans un environnement français, je veux avoir une liste à l'anglo-saxonne avec des items à bulles au lieu de tirets, je vais me créer la macro "listbullet", dis-moi un peu en quoi ce sera moins "physique" que "itemize" ? À l'inverse, l'italique en français ("\textit" "physique" de base) c'est déjà au moins trois sens différents : souligné dans le manuscrit, mot étranger, insistance tonique.
Les macros, c'est très pratique mais ça ne crée pas de sens et donc pas de logique au-delà du rendu qu'elles encapsulent. Je peux reprendre l'environnement "guestlist" de mon paquet "wedding" et modifier la valeur de la commande \backgroundcolor à noir pour me faire une jolie liste de toutes les exécutions 2012 avec mon nouvel environnement "capitalpunishmentlist". Ce sera une parfaite exploitation des capacités de LaTeX, mais ça n'aura aucune espèce de logique à part celle du rendu.
Pour avoir du vrai orienté "logique", il faut aller chercher des trucs comme docbook, qui ne produisent rien par eux-mêmes qu'une description systématique et sémantique du document…
Posté par Ignatz Ledebur .
En réponse à la dépêche Etherpad Lite.
Évalué à 2.
Dernière modification le 18 avril 2012 à 15:49.
LaTeX, que je connais le mieux, emploie des macros que tu fais en général à partir d'autres commandes et/ou environnement. Évidemment qu'on commence d'abord par définir la fonction avant d'appliquer le rendu, mais :
on pense toujours les deux en même temps par rapport à l'ensemble du document. Tu dis d'abord "tiens, ce serait cool si la liste des invités était un peu chiadée", tu bricoles un truc avec les commandes de base, et ensuite seulement tu encapsules la mise en forme dans un truc propre "\begin{guestlist}…\end{guestlist}". Ça n'a pas de sens de faire comme en programmation des fonctions dans le vide avec juste en tête la valeur qu'elles doivent retourner, car ce que tu veux c'est un rendu.
tout reste orienté rendu (avec LaTeX, tu peux même avoir des arguments à tes commandes pour modifier facilement tel ou tel aspect). C'est le seul critère unique, il n'y a pas d'autre "logique" et donc pas de distinction physique/logique qui tienne.
Je ne suis pas en train de soutenir que structurer son document à la Rache est aussi performant que de le faire avec un minimum de bon sens en employant les fonctionnalités de son logiciel. Je dis juste qu'en définitive la seule logique est la cohérence du rendu, et que tout le reste c'est du piston à coulisse.
Comme il le dit lui même dans son Addentum I, c'est juste quelqu'un qui a paniqué pour visiblement pas grand chose. Voir le fil sur LQ , pour en savoir plus.
Le fond de tout ça, c'est que Pat a toujours été mauvais en communication, et je ne pense pas que s'améliorer soit dans ses priorités. Donc rien de bien nouveau sous le soleil (mais que ça n'empêche personne d'aller sur le store, hein ! ;)
Et bien tu emploies la même macro pour tous les éléments identiques, ce qui te permet de ne changer que la définition de la macro. C'est ton usage qui fera la logique et rendra la chose pratique. "Gros titre rose trô chou", ça ne dégage aucune logique, mais employé de manière cohérente c'est aussi puissant que "Titre de Niveau 3". Il n'y a pas de style intrinsèquement "logique" ou "physique", les deux sont du rendu complètement indépendant de la structure du document et la logique est uniquement dans (la rigueur de) leur application. Écrire le contenu de la macro "Titre de niveau 3" au lieu d'un appel à celle-ci n'est pas moins logique (la cohérence du rendu sera la même), c'est juste beaucoup moins pratique.
La vraie critique à adresser à Etherpad Lite serait donc la simple impossibilité de définir des macros, qui cantonne à une mise en page sommaire pour des "petits" documents (moins une macro est complexe, moins elle est avantageuse à mesure que le document est court). Rien à voir avec une quelconque logique.
D'un autre côté, ton opposition physique/logique n'est pas super claire. "Libertine 16, rose flashy, centré, gras, italique, souligné, petite étoile à droite, petite étoile à gauche qui clignotent", tu peux appeler ça "Titre de Niveau 3", "Gros titre rose trô chou" ça reste ce que j'appelle une macro. C'est complètement orienté rendu (je pense que c'est ce que tu appelles "physique"), et seule l'utilisation que tu en fais peut être logique (ou pas).
Donc c'est pas non plus irréaliste, même si ça ne reste qu'un sondage.
À propos de sondages, ça me rappelle ce petit sujet d'Arte Radio (vous ne rêvez pas, dispo en OGG et sous CC). J'y pense, et à chaque fois je me marre (encore plus quand j'écoute les analystes politiques reconnus brasser de l'air). :)
Effectivement, c'est ignoble (mais c'est certainement affaire de goût;). En fait, ce qui me chiffonne dans le cas présent, c'est que je ne vois pas ce qui les empêche de mettre une solution en ligne sans pré-remplissage. Un formulaire html débouchant sur un truc "standard de chez standard" à imprimer d'un clic le ferait tout pareil et serait bien plus Michu-proofed qu'un machin à télécharger, à remplir avec un bidule tiers, puis à imprimer, non ?
P-S en police taille 4. c'est normal que mes commentaires commencent avec un note de 0 ? Parce que là j'ai le droit de l'ouvrir 6 fois selon le tableau de bord, mais tout ce que je dis est visiblement considéré comme a priori sans intérêt...
Pour du compatible PDF 1.7 sous Linux, il existe au moins Mupdf, ou du moins il se déclare comme tel (edit: mince ! il ne supporte visiblement pas les formulaires... lu trop vite ;). Quant au formulaire, si je me fie à pdfinfo (commande fournie avec Mupdf), il semble que le problème n'ait rien à voir avec ça :
$ pdfinfo cerfa_13750-03.pdf
cerfa_13750-03.pdf:
PDF-1.6
Info object (42 0 R):
<<
/Author (largillierepa)
/CreationDate (D:20110908172242+02'00')
/Creator (Adobe LiveCycle Designer ES 9.0)
/ModDate (D:20110908172242+02'00')
/Producer (Adobe LiveCycle Forms 8.2)
/Title (02_Demande de CI VO.indd)
>>
Pages: 1
Retrieving info from pages 1-1...
Mediaboxes (1):
1 ( 14 0 R): [ 0 0 612 792 ]
Fonts (1):
1 ( 14 0 R): Type1 'Helvetica'(16 0 R)
Ça semble être du PDF 1.6. Je parierai donc soit pour un problème de finalisation du site, soit pour un truc moisi censé contrôler la version d'Acrobat Reader qui accède au document.
Oui, c'est sûr que pour ceux qui considèrent la gestion des dépendances comme une fonctionnalité importante, Spack n'aura que peu d'intérêt. Pour les autres (les Slackeux et ceux qui comme apostle font tourner leur propre distro) :
codé en shell POSIX au max. Je développe avec mksh, et m'efforce de systématiquement tester la bête avec dash (sh étant bash sur ma Slack, de fait je le teste quotidiennement avec ce shell). Pour les commandes utilisées, j'ai essayé de coller à la norme le plus possible (en hors norme, il doit y avoir stat et l'option -maxdepth de find). Le but est de fournir un truc solide et portable au moins sur une Busybox ;
100% de compatibilité Slackware. Les Slackeux peuvent l'installer et le tester sur leur Slack sans soucis (c'est ce que je fais depuis plus d'un an). On peut désinstaller un paquet spack avec les pkgtools (aucune différence avec un paquet orthodoxe une fois installé), et convertir facilement un paquet Slack t[xg]z en paquet Spack. Je le souligne, parce que justement le gestionnaire est né de réflexions suite à l'étude du code des pkgtools. J'avais alors plein d'idées d'optimisation et de refontes, mais jusqu'à 0linux aucune motivation à les coder à l'idée que personne ne l'utiliserait sérieusement ;
un toolkit complet et cohérent : tout est pris en charge par une commande dédiée, préparation du paquet (spackcook), génération (spackpkg), rangement des archives (spacktidy), (dés)installation (spackadd/rm), exploration des paquets installés (spacklist), et même recherche des fichiers sur l'ensemble des paquets de la distro (spackfind, qui peut donc faire office de gestionnaire de dépendances du pauvre). Le plus gros des scripts fait 573 lignes, commentaires, écran d'aide et licences compris ;
un mode d'install qui permet de cantonner Spack à la gestion de /usr/local. Pour ceux qui ont l'habitude de blinder cette arbo à la grouik, Spack peut être une bonne solution pour gérer ça proprement en restant indépendant de la distro ;
un projet ouvert au fork. C'est un peu périphérique, mais ça ne me choque absolument pas qu'on forke Spack (une distro doit avoir la main sur son gestionnaire ! ), c'est même un peu pensé pour ça en offrant une base en shell (très souple et facilement adaptable) la plus saine et la plus compacte possible.
Voilà, c'est à peu près tout, je pense. Je n'imagine pas un avenir particulièrement brillant pour le projet, mais je dois avouer que je suis pour le moment assez content du résultat, d'où quand même un gros merci à 0linux. :)
Par rapport à une station, tu gagnes quand même un encombrement très réduit (plus de meuble dédié), la possibilité de t'isoler pour bosser dans n'importe quelle pièce chez toi, et souvent une machine plus silencieuse et moins consommatrice. Ça remplace pas le confort, c'est vrai, mais c'est pas si débile, àmha.
[^] # Re: Chaud pour une traduction et un nouveau journal ?
Posté par Ignatz Ledebur . En réponse au journal Entretien avec Patrick Volkerding sur LinuxQuestions.org. Évalué à 3.
Oui, je me suis aperçu après coup que je pouvais y écrire. La FAQ semblait indiquer quelque chose de plus "fermé". J'imagine que ça a dû évoluer depuis.
Pour la licence, j'ai complètement oublié… en fait je n'ai aucune idée de la température là-bas sur ces questions. Leur wiki est en CC-by-sa/GFDL, ce qui se comprend aisément pour ce type d'outil, mais pour le reste… je poserai la question si j'obtiens un feu vert sur le principe. Je pense que le point central sera alors de pointer sur l'original, ce qui est de toute manière indispensable pour ce genre de projet.
[^] # Re: Chaud pour une traduction et un nouveau journal ?
Posté par Ignatz Ledebur . En réponse au journal Entretien avec Patrick Volkerding sur LinuxQuestions.org. Évalué à 2.
J'ai envoyé la demande à LQ. A priori, il est à peine 9h du matin chez le responsable du site, ça peut donc prendre un peu de temps avant d'avoir la réponse. :)
[^] # Re: Chaud pour une traduction et un nouveau journal ?
Posté par Ignatz Ledebur . En réponse au journal Entretien avec Patrick Volkerding sur LinuxQuestions.org. Évalué à 7.
Ça m'a bien traversé l'esprit mais :
Voilà l'histoire. Maintenant, si vraiment ça intéresse, je veux bien mettre en branle le bouzin (faudra aussi que je demande un accès à l'espace rédaction, pour que tout le monde puisse donner la main non mé). :)
[^] # Re: Courte critique à lire
Posté par Ignatz Ledebur . En réponse au journal L'argent dette. Évalué à 0.
Aucune importance, parce que le passage incriminé, en plus d'être cité très approximativement, ne parle absolument pas de ça (il n'est jamais question de la BCE dans l'article). Je graisse la citation exacte:
Le sens de la critique, c'est que les banques au final attendent de l'argent issu de l'économie réelle. D'où on ne peut réduire le mécanisme d'endettement à un simple jeu d'écritures arbitraires, comme le fait visiblement le film (que je n'ai pas vu).
[^] # Re: A propos de dev
Posté par Ignatz Ledebur . En réponse au sondage Quel logiciel libre pour vos sauvegardes ?. Évalué à 1.
Non, mais si j'avais à le faire, je regarderais du côté de cpio. Les initrd du noyau Linux sont des archives cpio compressées, et c'est comme ça que de nos jours on charge les systèmes live (un installeur par ex. ) en RAM.
[^] # Re: Keep it...
Posté par Ignatz Ledebur . En réponse au journal Publication de petits projets. Évalué à 1.
Non Jeff, t'es pas tout seul… Enfin, j'essaie quand même de me tenir à une discipline : 1 cpold = 1 fonctionnalité majeure précise, et chaque version du logiciel ne doit pas avoir plus de un ou deux changements majeurs. Comme ça, une fois que c'est bouclé, sauf découverte d'un bug critique (rare) dans la version publique, je m'installe une rc privée sur mon système que j'utilise quelques semaines avant publication. Ça permet d'être sûr que tout tient à peu près debout avant de livrer et évite au mieux les livraisons-colmatages catastrophes pour les utilisateurs. :)
[^] # Re: Keep it...
Posté par Ignatz Ledebur . En réponse au journal Publication de petits projets. Évalué à 1.
Ah bah quand même, faut le dire de temps en temps. Perso, je vous fais de la pub dès que je peux (en insistant bien pour que les gens indiquent la licence de leur projet en 4x3 dans leur requête, histoire de pas se faire doucher au premier contact ! ;)
[^] # Re: Keep it...
Posté par Ignatz Ledebur . En réponse au journal Publication de petits projets. Évalué à 1.
De rien, tant mieux si ça peut servir. :)
À noter que c'est aussi une bonne idée de te référencer sur fresh… euh freecode et d'y annoncer chaque release pour donner de la visibilité à ton projet. Comme c'est un index pompé par quasiment tous les autres, tu te retrouves très vite un peu partout.
J'ai également oublié un conseil sur la procédure d'installation : passe par un configure/Makefile, en copiant l'interface des autotools même si tout est maison (en particulier le support de la variable d'installation DESTDIR). Ça simplifiera beaucoup le boulot des éventuels empaqueteurs (bon, vu la teneur de ton journal, tu y as sûrement déjà pensé).
# Keep it...
Posté par Ignatz Ledebur . En réponse au journal Publication de petits projets. Évalué à 6.
En tant qu'auteur de nano-projets, je te conseillerais de rester le plus simple possible. Pour mon premier, j'avais vu "grand" avec un site dédié (présentation, changelog, FAQ, page de téléchargement, le tout en HTML vaguement mouliné), branches stable/devel et listes de diffusion devel/annonces. Ça n'a jamais servi à rien, à part à alourdir la gestion du bouzin. C'est pour ça que très vite j'ai adopté le modèle "un projet, une branche, une page, (jawohl!)" et ai par la suite fini par grouper tous mes projets sur un seul site (au passage, merci à l'équipe de tuxfam. pour avoir toléré mes tergiversations :). J'ai même au bout du compte abandonné les contrôleurs de version. En cinq ans, je ne me souviens effet pas avoir eu besoin de revenir en arrière. D'ailleurs, même si ça se présentait, en tant qu'auteur unique je ne vois pas ce qui serait insurmontable (de fait, tout reste dans mes compétences, en plus hein! ça me fait la couenne, j'ai qu'à savoir ce que je veux), et puis il y a toujours le rustique mais efficace cpold.
Aujourd'hui je génère mon site et mes manuels à partir d'une moulinette perso qui prend des sources type Markdown (jette un œil sur l'implémentation initiale de cette syntaxe, tu verras que ce n'est pas très sorcier de bricoler quelque chose autour, y compris vers groff_man, qui est finalement assez simple). Je pousse ensuite tout ça en statique via un script de miroir basé sur lftp, et roule (autre chose appréciable chez tuxfam., tu peux gérer ton site alapapa®).
D'une manière générale, attends que les besoins soient là avant d'y répondre, tout anticiper étant le meilleur moyen de se retrouver avec une montagne accouchant d'une souris (ou plutôt l'inverse : un truc long et douloureux qui fait bien chier). Fais donc avant tout les choses pour toi, au plus simple comme ça t'arrange, et reste à l'écoute des éventuels retours pour décider des changements à apporter.
Sauf que l'ampleur des changements, tu ne peux jamais la prévoir. Pour le moment, j'ai trouvé deux parades :
Voilà, c'était mon petit retour d'expérience à deux balles… :)
[^] # Re: Mmmh yabon
Posté par Ignatz Ledebur . En réponse à la dépêche Recherche et bricolage : fermes de fenêtres. Évalué à 4. Dernière modification le 01 mai 2012 à 17:00.
Sauf que si tu lis bien, il y a forcément une partie plein-air : « En effet, en dehors de l'approvisionnement impérativement bio de l'élevage (95 % de l'aliment et des poulettes certifiées si possible) et d'une conduite sanitaire spécifique, le cahier des charges bio diffère peu de la production plein-air. »
Zéro plein-air, c'est pas différer un peu. Il suffit de chercher auprès des chambres d'agriculture, où on trouve les modalités de la production des œufs bio (PDF, dsl). Le hors-sol est explicitement interdit, et les animaux doivent pouvoir sortir.
Ce qui est "hors-sol" dans l'article (c'est vrai que c'est pas clair), àmha, c'est que toute la nourriture est amenée de l'extérieur à cause de la pauvreté des sols.
[^] # Re: Ni l’un ni l’autre
Posté par Ignatz Ledebur . En réponse au journal Notre petit univers de geek privilégié. Évalué à 2. Dernière modification le 23 avril 2012 à 11:27.
On peut également le voir sur le site du Ministère de l'Intérieur. Même d'une commune voisine à l'autre ça peut effectivement varier du tout au tout…
[^] # Re: Don't panic
Posté par Ignatz Ledebur . En réponse au journal Aidons Slackware. Évalué à 4.
Je ne retrouve pas le fil sur LQ, mais il semble que Pat ait pris quelques "vacances" (ça avait d'ailleurs aussi fait paniquer certains), d'où le cycle anormalement long…
Pour le mode de dév, c'est àmha pas près de changer, dans la mesure où c'est la source de revenus de Pat. S'il se met à déléguer, fatalement le partage du travail débouchera tôt ou tard sur la question du partage des revenus. Or, je ne suis pas sûr qu'on puisse vivre à 15.000 sur une distro comme Slackware. Tant qu'il reste seul à faire presque tout le boulot, c'est son bébé et il n'y a rien à discuter à ce niveau-là.
Ouais… moi, j'ai arrêté. :|
Je me dis qu'il doit avoir suffisamment de monde. C'est sûr que ce serait cool d'avoir une liste de dév. Mais là encore, ça apporterait du collégial de fait et mettrait Pat en position de chef de projet communautaire, ce qu'il a habilement évité en faisant de LQ le canal Slackware "officiel-oui-mais-non". En plus, depuis le temps, je suis sûr que plein de fois on a dû lui suggérer un forum/une ML/un canal IRC officiels. C'est donc àmha un choix tout à fait délibéré…
La seule chose qui pourrait le pousser à changer, je pense, c'est la complexité grandissante de l'écosystème Linux, qui fait que pour un homme seul c'est de plus en plus dur de tout gérer…
[^] # Re: Styles
Posté par Ignatz Ledebur . En réponse à la dépêche Etherpad Lite. Évalué à 0.
Oui, c'est ça. Mais pas seulement pour LaTeX, pour n'importe quel langage orienté rendu. À noter qu'on prend quand même des noms pratiques (et pas logiques) pour le document courant, que ce soit "itembullet" ("de quoi ça a l'air ?") ou "guestlist" ("qu'est-ce que c'est ?"). Les macros c'est un univers où tu peux dire : tomate = clémentine rouge, ou sapin = camion vertical marron et vert à benne triangulaire. Il n'y a aucune logique, juste de la commodité de nommage par rapport à ce qu'on veut rendre.
[^] # Re: Styles
Posté par Ignatz Ledebur . En réponse à la dépêche Etherpad Lite. Évalué à 0.
Pour l'italique, c'est pas l'éditeur qui décide, c'est le français imprimé qui est comme ça. Le lecteur un peu habitué à cette langue saura parfaitement faire la différence entre les sens selon le contexte, autrement il y a longtemps qu'on aurait changé les conventions.
Parce que j'en ai tout simplement besoin et que c'est un nom qui correspond bien pour la décrire. Dis-moi, à chaque énumération, tu renommes vraiment "enumerate" en "enumerate" juste pour être "logique"? non, tu te contentes du rendu…
Pour les numérotations, ça exploite juste un mécanisme de base qu'on appelle un compteur, créable et manipulable directement, je te laisse voir comment c'est implémenté dans article.cls, De même pour la génération du sommaire (ça te permettra de voir que ce que tu appelles "commande de base", c'est déjà de la sacrée macro)…
[^] # Re: Styles
Posté par Ignatz Ledebur . En réponse à la dépêche Etherpad Lite. Évalué à -1.
Je viens de te montrer qu'il n'y avait aucune logique entre les noms. Tu peux construire n'importe quoi à partir de n'importe quoi, sans problème majeur à l'usage. Ce que "signifie" ta macro, c'est son rendu, point barre. Si je crée une classe de document "reptel" pour "répertoire téléphonique" à partir de la classe "article", ça ne voudra pas dire que mes répertoires téléphoniques seront des sortes d'articles. J'utilise simplement les rendus d'une classe pour bâtir ceux d'une autre, le lien s'arrête là.
Tu détournes l'exemple (en babel french, les listes sont à tirets par défaut), c'est l'inverse que je veux : je peux vouloir mettre certaines listes en valeur avec des bulles, et donc me créer un environnement à cet effet. Il ne sera ni plus ni moins "physique" que itemize. Les fioritures, ça existe, la mise en page n'est pas purement fonctionnelle (et heureusement).
Pour « souligné dans le manuscrit », c'est tout simplement « souligné dans le manuscrit », tu rends comme l'auteur l'a donné, même si tu ne comprends pas pourquoi. Pour \etranger, super, une macro inutile (quand je parlais de piston à coulisse… ) qui voudra juste dire \textit… ou \emph, parce que la différence entre \emph et \textit en LaTeX, c'est pas le sens, c'est juste que \emph se traduit en romain lorsqu'il est déjà dans un texte en italique. De plus, il y a emphase tonique (ex. "tu m'as demandé de le faire") et emphase sémantique (ex. les termes communs employés en tant que concepts philosophiques), il faudrait donc de toute urgence créer un \emphconcept et un \emphtonique pour utiliser la commande de base \emph…
[^] # Re: Styles
Posté par Ignatz Ledebur . En réponse à la dépêche Etherpad Lite. Évalué à 1.
Tes commandes de base ne sont ni plus ni moins "physiques" que les macros. Si dans un environnement français, je veux avoir une liste à l'anglo-saxonne avec des items à bulles au lieu de tirets, je vais me créer la macro "listbullet", dis-moi un peu en quoi ce sera moins "physique" que "itemize" ? À l'inverse, l'italique en français ("\textit" "physique" de base) c'est déjà au moins trois sens différents : souligné dans le manuscrit, mot étranger, insistance tonique.
Les macros, c'est très pratique mais ça ne crée pas de sens et donc pas de logique au-delà du rendu qu'elles encapsulent. Je peux reprendre l'environnement "guestlist" de mon paquet "wedding" et modifier la valeur de la commande \backgroundcolor à noir pour me faire une jolie liste de toutes les exécutions 2012 avec mon nouvel environnement "capitalpunishmentlist". Ce sera une parfaite exploitation des capacités de LaTeX, mais ça n'aura aucune espèce de logique à part celle du rendu.
Pour avoir du vrai orienté "logique", il faut aller chercher des trucs comme docbook, qui ne produisent rien par eux-mêmes qu'une description systématique et sémantique du document…
[^] # Re: Styles
Posté par Ignatz Ledebur . En réponse à la dépêche Etherpad Lite. Évalué à 2. Dernière modification le 18 avril 2012 à 15:49.
LaTeX, que je connais le mieux, emploie des macros que tu fais en général à partir d'autres commandes et/ou environnement. Évidemment qu'on commence d'abord par définir la fonction avant d'appliquer le rendu, mais :
Je ne suis pas en train de soutenir que structurer son document à la Rache est aussi performant que de le faire avec un minimum de bon sens en employant les fonctionnalités de son logiciel. Je dis juste qu'en définitive la seule logique est la cohérence du rendu, et que tout le reste c'est du piston à coulisse.
# Don't panic
Posté par Ignatz Ledebur . En réponse au journal Aidons Slackware. Évalué à 5.
Comme il le dit lui même dans son Addentum I, c'est juste quelqu'un qui a paniqué pour visiblement pas grand chose. Voir le fil sur LQ , pour en savoir plus.
Le fond de tout ça, c'est que Pat a toujours été mauvais en communication, et je ne pense pas que s'améliorer soit dans ses priorités. Donc rien de bien nouveau sous le soleil (mais que ça n'empêche personne d'aller sur le store, hein ! ;)
[^] # Re: Styles
Posté par Ignatz Ledebur . En réponse à la dépêche Etherpad Lite. Évalué à -2.
Et bien tu emploies la même macro pour tous les éléments identiques, ce qui te permet de ne changer que la définition de la macro. C'est ton usage qui fera la logique et rendra la chose pratique. "Gros titre rose trô chou", ça ne dégage aucune logique, mais employé de manière cohérente c'est aussi puissant que "Titre de Niveau 3". Il n'y a pas de style intrinsèquement "logique" ou "physique", les deux sont du rendu complètement indépendant de la structure du document et la logique est uniquement dans (la rigueur de) leur application. Écrire le contenu de la macro "Titre de niveau 3" au lieu d'un appel à celle-ci n'est pas moins logique (la cohérence du rendu sera la même), c'est juste beaucoup moins pratique.
La vraie critique à adresser à Etherpad Lite serait donc la simple impossibilité de définir des macros, qui cantonne à une mise en page sommaire pour des "petits" documents (moins une macro est complexe, moins elle est avantageuse à mesure que le document est court). Rien à voir avec une quelconque logique.
[^] # Re: Styles
Posté par Ignatz Ledebur . En réponse à la dépêche Etherpad Lite. Évalué à -2.
D'un autre côté, ton opposition physique/logique n'est pas super claire. "Libertine 16, rose flashy, centré, gras, italique, souligné, petite étoile à droite, petite étoile à gauche qui clignotent", tu peux appeler ça "Titre de Niveau 3", "Gros titre rose trô chou" ça reste ce que j'appelle une macro. C'est complètement orienté rendu (je pense que c'est ce que tu appelles "physique"), et seule l'utilisation que tu en fais peut être logique (ou pas).
[^] # Vox Populo
Posté par Ignatz Ledebur . En réponse au journal Mélenchon à 14% d'intentions de vote.... Évalué à 2.
À propos de sondages, ça me rappelle ce petit sujet d'Arte Radio (vous ne rêvez pas, dispo en OGG et sous CC). J'y pense, et à chaque fois je me marre (encore plus quand j'écoute les analystes politiques reconnus brasser de l'air). :)
[^] # Re: Ça y ressemble, mais ça n'en est pas.
Posté par Ignatz Ledebur . En réponse au journal PDF lisible qu'avec acrobat reader: bâton dans les roues?. Évalué à 4.
Effectivement, c'est ignoble (mais c'est certainement affaire de goût;). En fait, ce qui me chiffonne dans le cas présent, c'est que je ne vois pas ce qui les empêche de mettre une solution en ligne sans pré-remplissage. Un formulaire html débouchant sur un truc "standard de chez standard" à imprimer d'un clic le ferait tout pareil et serait bien plus Michu-proofed qu'un machin à télécharger, à remplir avec un bidule tiers, puis à imprimer, non ?
P-S en police taille 4. c'est normal que mes commentaires commencent avec un note de 0 ? Parce que là j'ai le droit de l'ouvrir 6 fois selon le tableau de bord, mais tout ce que je dis est visiblement considéré comme a priori sans intérêt...
[^] # Re: Ça y ressemble, mais ça n'en est pas.
Posté par Ignatz Ledebur . En réponse au journal PDF lisible qu'avec acrobat reader: bâton dans les roues?. Évalué à 4. Dernière modification le 31 janvier 2012 à 18:45.
Pour du compatible PDF 1.7 sous Linux, il existe au moins Mupdf, ou du moins il se déclare comme tel (edit: mince ! il ne supporte visiblement pas les formulaires... lu trop vite ;). Quant au formulaire, si je me fie à pdfinfo (commande fournie avec Mupdf), il semble que le problème n'ait rien à voir avec ça :
Ça semble être du PDF 1.6. Je parierai donc soit pour un problème de finalisation du site, soit pour un truc moisi censé contrôler la version d'Acrobat Reader qui accède au document.
[^] # Re: courage
Posté par Ignatz Ledebur . En réponse au journal 0 Linux epsilon. Évalué à 3.
Oui, c'est sûr que pour ceux qui considèrent la gestion des dépendances comme une fonctionnalité importante, Spack n'aura que peu d'intérêt. Pour les autres (les Slackeux et ceux qui comme apostle font tourner leur propre distro) :
Voilà, c'est à peu près tout, je pense. Je n'imagine pas un avenir particulièrement brillant pour le projet, mais je dois avouer que je suis pour le moment assez content du résultat, d'où quand même un gros merci à 0linux. :)
[^] # Re: Mort du PC de Mme Michu
Posté par Ignatz Ledebur . En réponse au journal Bientôt la fin de la ligne fixe ?. Évalué à 10.
Par rapport à une station, tu gagnes quand même un encombrement très réduit (plus de meuble dédié), la possibilité de t'isoler pour bosser dans n'importe quelle pièce chez toi, et souvent une machine plus silencieuse et moins consommatrice. Ça remplace pas le confort, c'est vrai, mais c'est pas si débile, àmha.