Le blog de Seb

PassionGNU/Linux, la passion du Libre...

Jan 25, 2020

Annonce du gagnant du concours pour le logo de la conférence 2020.

Le gagnant du concours du logo de la conférence openSUSE + LibreOffice est Kukuh Syafaat d'Indonésie.

winner-300x89.png

Le logo "Fresh Community Spirit" ("Nouvel esprit communautaire") de Kukuh est le gagnant et fait partie des 10 logos soumis dans le cadre du concours. La "Mystery Box" sera envoyée à Kukuh pour le dessin gagnant.

En 2020, openSUSE et LibreOffice organiseront une conférence commune du 13 au 16 octobre à Nuremberg, en Allemagne.

Le comité d'organisation de la conférence commune de cette année a sélectionné le design gagnant lors d'une réunion le 20 janvier. Le logo représentait une adéquation idéale pour la conférence puisque openSUSE et LibreOffice combinent leurs conférences communautaires pour une seule année en 2020 pour célébrer le 10ème anniversaire de LibreOffice et le 15ème anniversaire du projet openSUSE.

Maintenant que le logo a été annoncé, des dépliants et des affiches peuvent être créés pour aider à faire la publicité de l'événement. Le site web de la conférence sera bientôt disponible sur events.opensuse.org et l'appel à communications débutera le mois prochain.

Ce logo de la conférence openSUSE + LibreOffice ne doit pas être confondu avec le logo du 10e anniversaire de LibreOffice annoncé sur le blog de LibreOffice.

Traduction de l'article publié sur openSUSE News

Source: Alionet.

Jan 23, 2020

La fausse bonne idée-des répertoires personnels d'openSUSE, un truc comme les PPA d'Ubuntu.

J'ai souvent entendu dire qu'Ubuntu n'était pas fiable, souvent ce genre de connerie venait suite à une mise-à-jour entre deux versions (exemple passage de la 14.04 vers la 16.04) et quand on y regarde de plus près, on voit les fameux répertoires personnels dits PPA d'Ubuntu. Je pense que les gars de Canonical doivent se mordre les doigts d'avoir permis de monter facilement des dépôts personnels sans gage de qualité. Combien de fois ai-je vu ces mêmes dépôts dans le source liste d'une Debian? Je ne m'en souviens plus mais malheureusement trop souvent et trop tardivement, ce qui résulte que les mecs se plaignaient d'avoir une Debian qui ne pouvait pas ou mal monter de version... L'humain n'a pas besoin d'aide et de qui que ce soit pour casser ce qu'il a, mais encore une fois Les pires choses en général sont faites des meilleures qui ont mal tourné (Victor Hugo) et les PPA sont les meilleurs exemples.

Quoique avec les nouveaux formats de paquets universels, ça sera peut être plus le cas encore longtemps...

Mais bon revenons à openSUSE, comme Ubuntu et même avant elle si mes souvenirs sont bons, celle-ci a voulu faciliter la vie de ses utilisateurs en mettant en place de quoi faire des dépôts personnels (les homes), ça partait d'un bon sentiment, du meilleur qu'on puisse avoir, du reste je m'en sers comme les PPA sous Ubuntu, mais on va dire que j'ai un petit quelque chose dans mon crane qu'on appel un cerveau. Je réfléchie donc avant de faire et surtout je n'ajoute que ceux dont je connais les personnes qui sont derrières.

J'aimerai rappeler un certain bon sens qui devrait être la base pour n'importe quel OS, mais en particulier je parlerai que de linux. Le bon sens est peu importe l'OS, on ne doit pas ajouter de programmes dont on ne sait rien. Maintenant si on retranscrit dans le monde linux, on ne rajoute des dépôts si seulement c'est nécessaire, que ce soit openSUSE, Ubuntu ou autre, si c'est seulement pour avoir une version plus récente autant resté sur la version donnée par sa distribution de manière officiel que ce soit la version des dépôts principaux ou des backports. Ne rajouter des sources que de ceux dont on connaît les personnes qui sont derrières, on ne rajoute pas les PPA ou les homes de personnes dont on ne connaît rien, c'est pas seulement une question de sécurité mais aussi de stabilité, qui vous dit que le gars qui en est la source, ait les capacités de faire un truc propre? Le packaging n'est pas facile et il serait faux de penser que ça risque rien.

Personnellement, je n'ajoute que les PPA et les homes de contributeurs officiels donc arrêtez de nous casser les couilles si vous ne savez pas réfléchir deux secondes et ajouter ce qui ne doit pas l'être! Et surtout ne rejetez pas la faute de votre incompétence sur les distributions alors que les seules fautifs sont bien les personnes qui sont entre la chaise et le clavier.

Jan 19, 2020

Un site statique et pourquoi choisir Pelican.

J'ai eu un mail aujourd'hui qui m'a un peu surpris, la personne toute sympathique, me demande donc pourquoi s’embêter en 2020 avec un site statique, quelles sont les véritables raisons qui m'ont poussé vers ce genre de sites, puis pour finir pourquoi avoir changer pour être sur Pelican, pourquoi lui et pas un autre? Autre question, puis-je essayer de donner des raisons qui pousseraient un utilisateur de PluXml comme lui à tenter de migrer sur de tels sites... Entre autre, si ça prends pas trop de mon temps et que je peux le faire, voir pour pondre un tuto de comment ça marche, de l’installation à la mise en ligne.

Ça m'a surpris car oui, je pensais avoir déjà donner tout un tas de raisons pour passer de sites dynamiques à la Wordpress vers ce genre de sites statiques nouvelles générations. C'est comme ça, je pensais avoir bien saouler tout le monde avec ce genre de billets mais non, je vais donc redonner les raisons, les avantages, les défauts, de ce genre de sites. Mais je vais aussi faire une sorte de tuto, j'espère le faire dans ce billet même mais c'est pas sûr, ou du moins ça ferait publier ce billet plus tardivement.

On pourra lire les nombreux sites qui en causent:

https://regisphilibert.com/fr/note/pourquoi-hugo/

https://www.sylvaindurand.fr/static-website-with-jekyll/

https://www.ionos.fr/digitalguide/hebergement/blogs/jekyll/

https://blog.victor-hery.com/2017/07/passage-blog-statique.html

https://connect.ed-diamond.com/GNU-Linux-Magazine/GLMF-184/Utiliser-Pelican-comme-moteur-de-blog

https://shadoware.org/post/migration-to-pelican

https://www.bortzmeyer.org/generateurs-web-statiques.html

https://zestedesavoir.com/tutoriels/2497/creer-un-site-web-statique-avec-pelican/presentation-de-pelican/pelican-pourquoi/

Deux superbes tutos:

https://eskimon.fr/tuto-pelican-102-pelican-comment

https://zestedesavoir.com/tutoriels/2497/creer-un-site-web-statique-avec-pelican/

Pourquoi s’embêter en 2020 avec un site statique?

C'est alors que sont apparus les sites dynamiques : les langages de programmation exécutés côté serveur, tels que PHP, ont permis de voir apparaître les CMS, qui rendaient possible la création de sites et la modification de leur contenu directement depuis un navigateur, permettant ainsi l'émergence de sites, blogs, forums accessibles au plus grand nombre. C'est par exemple le cas de Spip, Dotclear ou WordPress. Pourtant, ces systèmes ne sont pas dénués d'inconvénients :

  • ils sont très sensibles aux failles de sécurité, ce qui implique de surveiller attentivement les mises à jour et les logs ;
  • ils sont consommateurs de ressources serveur, nécessitant des hébergements spécifiques pour les gros volumes de visiteurs ;
  • ils supportent mal les montées en charge, et sont ainsi très sensibles aux attaques DDoS ou aux affluences de visiteurs (il n'est pas rare qu'un site devienne indisponible, par exemple lors d'un événement important ou en raison d'un lien publié sur un site d'actualités) ;
  • ils constituent souvent de vraies usines à gaz, surdimensionnées vis-à-vis des besoins et nécessitant des bases de données.

Depuis quelques années, les sites statiques font leur retour en grâce avec l'apparition des générateurs de sites statiques. Sur la base de simples fichiers textes, un programme génère un site composé uniquement de pages statiques qu'il suffit ensuite d'héberger. Ainsi, les problèmes de sécurité sont presque inexistants, il est possible de s'héberger sur un serveur très modeste ou au contraire d'obtenir d'excellentes performances et de supporter de très fortes montées en charge

Il y a trois points où un site statique est gagnant: la rapidité, la sécurité et la fiablité.

La rapidité:

Comme expliqué parfaitement et simplement, lors d’une visite:

un site dynamique classique:

  • Le Visiteur arrive sur la page
  • Le Serveur se connecte à la base de donnée
  • Le Serveur récupère les données demandées
  • Le Serveur utilise les données reçues pour construire à la volée le fichier HTML.
  • Le navigateur du Visiteur télécharge la page HTML et l’affiche

Site statique:

  • Le Visiteur arrive sur la page
  • Le navigateur du Visiteur télécharge la page HTML et l’affiche

ou dit autrement:

En effet, puisque toutes les pages sont pré-générées, le serveur n’a rien d’autre à faire que de les envoyer. Aucun travail de traitement n’est effectué. Si Bob demande la page A, le serveur ne se pose pas de question et renvoie la page A.html. C’est tout. C’est rapide.

Ce qui en découle, c'est de la vitesse donc un site statique pour une même page et sur le même hébergement, sera bien plus rapide.

la sécurité:

Il n’y a pas de base de donnée, ni de PHP, ni de scripts, ni de code d'administration car séparation de la partie publique (visible c'est le site) de celle de l'édition (qui est sur notre PC), pas d’injection SQL possible,... le site statique n'exécutant aucun code et étant constitué de simples fichiers, n'a pas de failles de sécurité. Pas besoin de mettre à jour comme on le fait avec les CMS car pas de failles possible (exemple avec SPIP ou avec Wordpress).

Un autre atout : La maintenance. Une fois votre site en ligne, rien d’autre à faire si ce n’est de le faire vivre en ajoutant de nouveaux articles / nouvelles pages de temps en temps. Pas de base de données à gérer, peu de risque de sécurité, voire même pas de serveur tout court à gérer si vous optez pour une offre d’hébergement mutualisée (nous y reviendrons).

La fiabilité:

Contrairement à un site dynamique, le serveur ne travaille pas lors d’une visite. Il sert juste des fichiers HTML qui seront téléchargés comme de simples images. En cas de forte affluence, pas de risque de ralentissement ni de surchauffe des serveurs.

Le principal est de performance et de résistance à la charge : un site Web dépendant d'un CMS doit exécuter des milliers de lignes de PHP ou de Java à chaque requête. Cela le rend lent et, surtout, une attaque par déni de service, même modérée (par exemple avec un outil primitif comme LOIC) suffit à le rendre inutilisable. Même pas besoin d'attaque, d'ailleurs, parfois, une simple utilisation un peu intense (une mention sur Mastodon, par exemple) peut le rendre inaccessible. Un site Web dynamique doit donc être hébergé sur de grosses machines coûteuses, alors qu'un site statique peut tenir une charge bien plus élevée. Tous les serveurs HTTP savent servir des fichiers statiques très rapidement.

Un deuxième avantage est de dépendance. Le site statique ne dépend que du serveur HTTP. Au contraire, un site dynamique dépend de plusieurs logiciels supplémentaires (comme par exemple MariaDB) dont la panne peut le rendre inutilisable, souvent avec des messages d'erreur incompréhensibles.

Pas de base de donnée, pas de scripts, pas de PHP, on a juste besoin d'un serveur HTTP et rien d'autre. En fait, même pas besoin d'un serveur HTTP, il suffit d'héberger son site sur Github.

Résumons:

Avantages:

  • temps de charge court,
  • pas besoin gérer le CMS ou les bases de données,
  • aucun moyen d’attaque,
  • pas besoin d’effectuer des mises à jour,
  • choix d'utiliser les outils qu'on veut utiliser (éditeur, langage, ...),
  • juste besoin d'un serveur HTTP, pas de bases de données, pas besoin de PHP, pas besoin de formats ou d’outils supplémentaires,
  • Hébergement sur GitHub possible,
  • mini serveur de développement pour voir en direct les changements.

Défauts:

  • il n'y a pas d'interface utilisateur graphique, quoique certains en proposent comme Publii et Lektor,
  • commentaires ou formulaires impossible en standard.

Pourquoi pas PluXml ou tout autre CMS Flat-Files ?

PluXml est un excellent moteur de blog sans base de donnée, il est léger, rapide, avec une interface admin simple, rapide et efficace, mais ça reste un CMS qui à sur le même serveur sa partie publique et sa partie admin... Il nécessite PHP qui apporte son lot de failles. On dit sans base de donnée mais c'est simplement faux, c'est sûr qu'il n'a pas de BDD à la MYSQL ou SQLite mais sa base est simplement la somme des fichiers XML contenue dans un dossier. Il y a une interface admin donc possibilité de cracker le site.

Je peux continuer, il n'a pas d'éditeur par défaut autre que le HTML, un truc super lisible... Les plugins d'éditeurs sont merdiques. Je suis pas là pour dégommer quoique ce soit, surtout que je tiens en haute estime ce projet, je finirai donc par juste rappeler que PluXml c'est avant tout un développeur, qu'il faut que ça soit mit à jour en amont et appliquer les dites mises-à-jour...

Pelican, pourquoi lui et pas un autre?

logo Pelican SVG

Pourquoi Pelican et pas un autre ? C’est une bonne question, à laquelle j'ai une réponse possible. Les goûts et les couleurs sont dans la nature. Je vais rester le plus impartial possible... Pour en choisir un, mon cahier des charges était logiciel libre, prévu pour des blogs, avec une chronologie et disponible dans la version stable de Debian/Ubuntu et openSUSE.

Parce que python

Python est un langage que j’aime beaucoup et qui du reste, m'attire de plus en plus, au point que je m'y mettrai bien. C’est donc évidemment vers ce langage que je me suis tourné. Python est le langage que je comprends le mieux, je ne touche pas encore mais je pense m'y investir prochainement, ce qui me permettra de faire des modifications ou des plugins au besoin.

Ruby est un langage que je trouve bien trop lent. Go est vraiment rapide, mais je le trouve assez complexe et trop récent. Quant à JavaScript, je trouve que ça prends beaucoup de ressources pour pas grand chose, en plus d'être lourdingue.

Pelican est écrit en Python (utile pour étendre les fonctions, même les fichiers de configuration et de fabrication du site sont en Python).

Parce que Pelican!

Hugo, Jekyll, Pelican, Publii et bien d'autres, j'en ai essayé et je les ai testé sur le long terme, mais celui qui me sembla le plus simple, performant et complet, a été Pelican.

A la lecture de sa documentation, ça m’a semblé simple (comme la rédaction des métadonnées des articles). Le support du markdown a été primordiale étant très fan de ce langage de rédaction.

hugo-logo

Pour commencer, Hugo ne vient avec aucun thème, il faut en choisir un, de plus si on change de thème il faut aussi changer pratiquement 80% de son fichier config. Je trouve aussi que les templates sont bordéliques. Pour finir, il est vraiment complet mais si il manque des choses on ne peut rajouter de plugin dû à sa nature. De plus je trouve qu'il ne donne pas de liberté, c'est assez carré, on a les mains liées, exemple si vous prenez un thème, n'allez pas penser qu'on pourra faire n'importe quoi avec, on ne peut pas aller à l'encontre de ce que le thème à été prévu sans passer par une grosse part de modifications du thème. Un thème pensé pour faire des pages uniques, ne pourra pas faire un blog sans faire au préalable des changements dessus, si le thème n'a pas été prévu pour avoir une page archives, il faudra la créer (page, layout, ect,...). Tout est carré, ou sinon j'ai vraiment mal regardé, par exemple, il faut dater les articles d'une certaines manière (pas de 2020-01-20 18:16 ou inversement) sans quoi la date sera pas prit en charge. Toujours dans la datation, si on ne met pas de date, Hugo n'est pas assez géniale pour prendre comme date, la datation de la création du fichier. Obligé d'indiquer les pages dans le fichier de configuration pour qu'elles apparaissent dans la barre de menu, selon le thème utilisé la façon de les indiquer change ce qui est assez chiant... Il reste qu'il est le plus rapide lors de la compilation du site.

Indication de pages dans le fichier de conf d'Hugo (menu.main):

baseURL = "https://passiongnulinux.tuxfamily.org/"
languageCode = "fr"
title = "Seb's blog"
theme = "twentynineteen-hugo"

# Pagination
paginate = 10

# Output formats (for search index)
[outputs]
Home = ["HTML", "RSS", "JSON"]

# Site params
[params]
privacy_link = "/mentions-legales/" # Relative URL to privacy page, if there is one. This enables a Privacy Policy link in the footer. The link doesn't display if this isn't specified.
description = "PassionGNU/Linux, la passion du Libre..." # Adds tagline next to the site title.
accent_color = "#C70136" ##649600 pour mon vert openSUSE Set a custom accent color for links and image filters, if enabled. Defaults to blue.
disable_image_filters = true # Setting to true disables the color filter feature on images. Defaults to false.

# Menus
[menu]
[[menu.main]]
    name = "Accueil"
    url = "/"
    weight = 1
#  [[menu.main]]
#    name = "Posts"
#    weight = 2
#    identifier = "post"
#    url = "/post/"
[[menu.main]]
    name = "Tags"
    identifier = "tag"
    url = "/tags/"
    weight = 3
[[menu.main]]
    name = "Forum"
    weight = 4
    identifier = "forum"
    url = "/forum/"
[[menu.main]]
    name = "À propos"
    identifier = "about"
    url = "/about/"
    weight = 5
[[menu.main]]
    name = "Contact"
    weight = 6
    identifier = "contact"
    url = "/contact/"
[[menu.main]]
    name = "Licence"
    weight = 7
    identifier = "licence"
    url = "/licence/"
[[menu.main]]
    name = "Liens"
    weight = 8
    identifier = "liens"
    url = "/liens/"
[[menu.main]]
    name = "Mentions légales"
    weight = 9
    identifier = "mentions-legales"
    url = "/mentions-legales/"
#[[menu.main]]
    #name = "Archive-Jekyll"
    #weight = 10
    #url = "https://passiongnulinux.tuxfamily.org/jekyll/"

[[menu.social]]
    identifier = "github"
    name = "Github"
    url = "https://github.com/passionlinux"
[[menu.social]]
    identifier = "rss"
    name = "rss"
    url = "index.xml"

Publii, est un programme graphique qu'on lance sur notre machine, c'est comme si on avait une interface à la Wordpress en application JavaScript, c'est bien, c'est chouette, c'est accessible, mais pour être franc c'est du JavaScript donc c'est bien plus lourd, l'éditeur n'est pas markdown, ça plante, ça enregistre nos fichiers sources dans une base de donnée SQLite et donc on a aucun contrôle des fichiers en dehors du programme...

Lecktor

Un autre projet très intéressant en Python est celui de Lecktor qui lui aussi possède une interface graphique, tout en permettant de l'utiliser classiquement comme Pelican. Je ne l'ai pas testé, n'aimant pas la hiérarchie du dossier de travail.

Lecktor-admin

Jekyll, il vient avec un thème par défaut minimaliste mais suffisant et est donc opérationnel de suite sans rien faire.

jekyll-logo

thème-defaut

A part la nomination obligatoire à sa façon, il nous laisse la main mise sur le reste. Dans son installation de base, on n'a pas le droit à grand chose comme la pagination manquante, tout n'est que plugin, sauf que c'est moins simple de charger des plugins ou des thèmes. C'est aussi du Ruby, donc assez lent pour la compilation du site, il met facilement deux fois le temps que Pelican demande sans cache pour faire la compilation et trois à six fois ce que Pelican met comme temps avec le cache d’activé. Seul point vraiment positif, son fichier de conf qui pour produire un site demande peu de chose, une adresse, un auteur, et rien d'autre...

Voila en exemple, mon fichier entier de configuration pour mon site sous Jekyll:

# Site settings
title: Seb's blog / PassionGNU/Linux, la passion du Libre...
email: passiongnulinux/@/gmail/./com
description: Le site d'un passionné contributeur/testeur/emmerdeur du Libre et de l'OpenSource
baseurl: "/jekyll" # the subpath of your site, e.g. /blog
url: "https://passiongnulinux.tuxfamily.org/" # the base hostname & protocol for your site
twitter_username:
github_username: Passionlinux

# Build settings
markdown: kramdown

#plugins:
#  - jekyll-feed

Autre bon point, on créé une page, on l'enregistre à la racine de notre dossier /mon_site et la page sera visible dans le menu, pas besoin de remplir un fichier pour les annoncer, comme sur la capture qui suit, les pages about.md, contact.md, forum.md, licence.md, liens.md, mentions-legales.md, tuto.md sont à la racine de mon dossier Jekyll et seront prises en considération dès la prochaine compilation.

mon_site et les pages

logo-pelican.png

Pelican est facile à personnaliser et il est simple d'avoir le rendu voulu. Tout n'est que paramètre dans notre fichier de conf, que ce soit les URL, les tags, les pages, les archives, la façon d'enregistrer notre site (sa hiérarchie),... Tout se contrôle depuis ce simple fichier. Il a un système de cache qui évite de recompiler tout les fichiers à chaque build donc gain de temps vis-à-vis d'autres GSS...

Il vient de base avec deux thèmes très simples, notmyidea et simple, le premier qu'on peut voir sur le site du projet et le second comme son nom l'indique est un minimaliste sans CSS. Il est comme Jekyll, de suite opérationnel, pas besoin d'aller chercher un thème pour commencer contrairement à Hugo.

Je trouve qu'a part sa configuration très complète, c'est le plus simple à prendre en main, il vient avec au minimum un thème (en faite deux mais bon) donc pas besoin d'en chercher un, les pages sont comme avec Jekyll, c'est-à-dire qu'on les met dans un dossier /page et pas besoin de les annoncer dans le fichier de conf (contrairement à Hugo), sa config de base est simpliste mais fonctionnelle...

Voila, je sais pas si j'ai répondu en partie ou totalement à la demande qui m'a été faite mais je vois pas ou peu ce que je peux dire de plus. Prochainement je ferai un tuto sur comment installer Pelican (ou Hugo ou bien Jekyll), son utilisation et ma config.

Jan 18, 2020

les flux Atom sont HS avec Firefox (et peut être d'autres navigateurs).

Merci à Guillaume pour me l'avoir fait remarqué, j'ai en effet les flux Atom qui sont dans les choux avec Firefox, sûrement avec d'autres navigateurs. Par contre, pas de soucis depuis un lecteur de flux comme Akregator, liferea, voir même avec les courrielleurs de type Claws-mail...

bug Atom sur Passiongnulinux

Alors il y a plusieurs choses à faire, soit je vire les flux Atom puisque celui du RSS fonctionne bien et que je ne sais pas si c'est vraiment utile d'avoir les deux(?), soit je garde en état puisque ça fonctionne quand même dans les lecteurs prévus, soit je tape dedans et cherche ce qui ne va pas (à priori la ligne qui fout le boxon est indiquée).

Le flux Atom dans Akregator:

flux-atom-conf flux-atom

Jan 17, 2020

Basblog, le script bash pour faire un site.

Basblog est un script bash de 1000 lignes environs et pesant 46 ko, capable de faire un site statique. C'est en fouillant un peu ce qu'il se faisait d'ultra simple pour un petit projet assez simpliste que je suis tombé sur lui, en faite j'avais sans le savoir été sur un site fabriqué par ce petit bout de script, notamment en allant voir le blog de notre admin d'Alionet. C'est vraiment simpliste mais suffisant pour un blog.

Voila comment créer et rédiger un billet:

Je l'ai testé et il tient ses promesses, ça va pas très loin mais honnêtement pour un gars comme moi c'est vraiment ultra suffisant, il y a les posts, les commentaires (via twitter ou Disqus), l'archive, les tags, les catégories, les pages, sauvegarde automatique à chaque fabrication... Seul bémol et encore c'est peut être que je n'ai pas été plus loin ni chercher, c'est qu'à première vu et sans aller plus loin dans la recherche, je n'ai pas pu ajouter tous les fichiers de mes billets du site actuelle, il faut lancer la commande /bb.sh post pour vraiment créer le billet. Un autre manque pour moi, c'est qu'il n'y a pas de serveur live pour voir le rendu du site mais je pense qu'on en demande trop, dans le pire des cas si un tel manque se fait sentir, pourquoi ne pas se monter un serveur maison qui servirait de test. Par contre, je pense qu'il faut pas chercher un projet très vivace, je pense que ça fonctionne comme le gars voulait et que ça ne va plus trop bouger, maintenant c'est un seul script et c'est assez compréhensible pour toucher.

Bashblog

Le vrai plus, c'est qu'il ne nécessite rien, pas comme Jekyll qui a besoin de tout un tas de truc Ruby ou bien mon Pelican qui vient avec un tas de trucs python, non là c'est juste un script qui utilise des commandes standards sous linux dont date, basename, grep, sed, head, etc...

Édite: J'ai oublié de parler de l'édition des billets, par défaut si rien n'est installer ça sera en HTML, sinon si markdown ou discount est installé, on pourra éditer dans ce format.

Next → Page 1 of 98