Un gestionnaire de paquet devrait pouvoir gérer plusieurs versions d'un même logiciel. Et tout l'intérêt de SNAP est justement d'avoir une version "à jour"… donc ton gestionnaire de paquets devrait pouvoir faire ça, pas besoin d'un énième gestionnaire de paquets supplémentaire.
Exemple : tu as une version de ton OS qui est "stable" et a peu de mises à jour, mais en parallèle tu as un dépôt "plus à jour" sur lequel tu ne vas chercher QUE ton logiciel. Pas besoin de plusieurs programmes. On ne fait qu'utiliser de simples paquets.
SNAP n'est qu'un symptôme de la gestion de paquets. C'est parce qu'il est impossible avec DPKG/APT/APTITUDE de gérer simplement l'installation de plusieurs versions de logiciel qu'on en arrive à des outils comme SNAP.
Et il a fallu combien de temps ? Bah je sais pas. Il y a des solutions à ces problèmes depuis un long moment sur plein d'autres distributions. Si je dis que Debian est un problème, c'est parce que réellement c'est avant tout ce système qui a un problème (et, par extension, Ubuntu et consorts).
Tu te plains de Debian qui n'aurait que des versions anciennes des logiciels de sa logithèque… oui. Debian est mondialement connu pour ça. Rien à voir avec Linux du coup… faut te trouver une distribution qui correspond un peu mieux aux besoins.
Pour rappel, Debian c'est quand même pas top d'un point de vue de l'admin s'il doit modifier des trucs : plusieurs gestionnaires de paquets qui, non content de s'être multipliés pour de mauvaises raisons et embrouillant tous les nouveaux utilisateurs, foutent parfois la merde à la suppression d'un programme (ex: tu supprimes un paquet totalement mineur puis apt te demande dans le plus grand des calmes si tu veux supprimer dpkg, apt, ton bureau…), des incohérences absurdes dans le nommage des bibliothèques (liblibX, Ylib…), les "backports" qui sont une version archaïque du pinning… on pourrait continuer encore longtemps.
Un jour faudra apprendre à regarder plus loin que la recherche pharmaceutique gérée par de gros lobbies et comprendre que la recherche c'est aussi tout un tas de petits organismes, partout dans le monde, qui n'ont déjà pas tellement les moyens de se payer les abonnements puis les publications puis les conférences.
Et là on ne parle même pas d'un autre type de public qui pourrait vouloir avoir accès aux recherches : les citoyens.
Et la condescendance en invoquant les bisounours, merci mais non merci.
Plusieurs solutions peuvent être envisagées. Dans tous les cas je conseille fortement de chiffrer le disque dur, au cas où. Aussi, même si les serveurs en face sont récupérés, les adresses IP de connexion peuvent ne pas être enregistrées (d'autant plus si de toutes façons l'activité est illégale).
Si on parle d'un point de vue purement technique, on pourrait masquer complètement ton adresse IP (ex: avec Tor).
Cela reste une bonne question, qui mériterait sans doute d'être posée à un avocat pour l'aspect juridique. Faut partir du principe que tu peux aller en prison et avoir à payer de très lourdes compensations…
Bien belle mentalité. Penser aux profiteurs plutôt qu'à ceux qui cherchent des solutions aux problèmes de malnutrition, réchauffement climatique, économies d'énergies, fertilisation des sols, agriculture, pauvreté…
Soutenir la recherche et les chercheurs directement : sci-hub. Tu stockes les papiers chez toi, ils se font proxy vers tes fichiers. T'es invisible (il n'y a qu'eux qui te voient) et tu fournis des milliers (millions ?) d'articles aux chercheurs qui sans ça, doivent payer des fortunes pour accéder à leur propre recherche financée par l'argent public.
Merci pour la grosse blague. :-D
PS: pour ceux qui n'ont pas compris, je ne me moque pas de l'éditeur, juste du fait que cet article soit un copier/coller de celui sur Emacs (je précise, on sait jamais).
Bazel fonctionne que pour un ensemble très restreint de langages et ne fonctionne pas sur BSD (d'ailleurs il suppose par défaut que bash est installé et est dans /bin… ça a l'air bien codé ce truc) donc pour la généricité, on repassera.
Et à côté de ça, Nix, un gestionnaire de paquets. Je ne comprends pas en quoi il répond à la question. J'ai raté un truc ? :-D
J'ai demandé si quelqu'un connaissait un système de build qui se passe de Docker. Que dans ton entreprise le choix s'est porté sur Docker c'est très bien… mais hors sujet. Peu importe les arguments.
Et que veux tu mettre au lieu de Docker, ou même LXC, pour isoler tes builds ?
C'est précisément la question. :)
LXC et Docker sont des solutions très centrées sur Linux. Pour ma part je n'utilise pas (ou peu) Linux. Je préfère me renseigner sur une solution un poil plus générique qui tournerait sur tous les UNIX.
De nos jours, nous avons des systèmes de fichier qui savent gérer des snapshots (lire "une copie d'un répertoire qui coûte rien en temps et en volume de stockage occupé"), ce qui pourrait largement nous aider à créer des rootfs pour un millier de builds sans que cela n'occupe vraiment plus de place qu'avec du Docker. Du coup un "simple" chroot (ou solution équivalente) serait envisageable. Peut-être que ce ne serait pas suffisant, mais tellement plus simple et générique… Docker au fond n'est qu'une abstraction à une solution de ce type, mais en utilisant des fonctionnalités disponibles uniquement sur Linux, et un fonctionnement loin d'être intuitif. Tout ça pour pas avoir à faire un pont réseau, gérer des IP et un le DNS soit-même ?
N'y a-t-il rien de plus simple, réellement, pour faire de l'intégration continue ? Nécessiter Gitlab ou même "que" Docker me semble déjà assez complexe en soit.
Je trouve ton article intéressant. Tu expliques comment on arrive à Rust et quels sont certains de ses avantages par rapport à C, et bien que d'autres articles existent sur le sujet tu l'appliques sur ton sujet de prédilection : GStreamer. Et c'est un peu là que j'ai du mal.
GStreamer est un code conséquent, les références que tu fais sont parfois floues et le code que tu montres ne m'a pas permis de comprendre intuitivement ce que tu faisais. Et ce n'est pas vraiment un reproche que je ferai à ton article, tu n'as sans doute pas le temps de présenter tous les concepts derrière GStreamer en détail. De ce fait, dès qu'on rentre dans "Écrire des applications GStreamer avec Rust" il devient difficile de suivre sans ouvrir une dizaine d'onglets… ça me rebute un peu. Du coup, je ne sais pas si l'article est trop grand ou pas assez.
En tout cas merci, tu donnes de la visibilité à Rust et à GStreamer. Si en tant que développeur d'outils assez poussés et gourmands en ressources tu considères ce langage, cela lui donne encore plus de crédibilité.
Est-ce que Sympa est plus simple à packager ? De ce que je vois de l'installation de Sympa, il y a une création d'un utilisateur système pour y mettre des fichiers dédiés à Sympa dans le home en incluant des binaires, notamment certains qui sont générés lors de la compilation de modules Perl qui doivent être installés à la volée, ce qui nécessite des bibliothèques de développement pour l'installation…
Pour bien faire il faudrait packager les différentes bibliothèques (ne pas rejouer l'installation à chaque fois, récupérant des bibliothèques dans des versions différentes à chaque fois), ne PAS créer un utilisateur dédié dans /home (c'est juste pas normal de fonctionner de la sorte, vous voyez d'autres softs UNIX demander la même chose ? Non. Et pour cause, c'est pas comme ça que ça fonctionne)… au final il faut patcher l'upstream qui ne respecte pas les conventions, et pas tenter de patcher un gestionnaire de paquets pour qu'il accepte de faire tout un tas de choses qu'il n'est pas censé faire.
Donc finalement, tu dis que mailman est une usine à gaz… moi j'en connais un autre. :-D
Je ne vois pas en quoi "faire tourner de gros sites" implique nécessairement de consommer beaucoup de ressources. D'autant plus à froid, sans une grosse charge. Qu'est-ce qui justifie cela dans votre application ?
Posté par karchnu .
En réponse à la dépêche Actualités Sympa.
Évalué à 1.
Dernière modification le 02 novembre 2017 à 11:17.
La réponse se rapproche fortement de la différence entre un shell et une interface graphique. Tout réside dans l'extensibilité et la facilité d'usage. Étendre un webmail pour qu'en envoyant mon mail j'ai un script qui s'exécute, récupérer le résultat d'une commande, automatiser le reformatage d'un mail type pour afficher directement les informations que je recherche, faire ressortir des mots clés… bon courage.
La liste des possibilités est infinie avec un shell, sans faire de hack particulier, sans écrire du code spécifique à un webmail qui sera périmé à la prochaine version, sans réécrire le code du webmail, en ayant déjà tous les outils du shell à disposition, sans devoir modifier le code côté serveur…
Si je comprends bien, ton navigateur est pensé pour être intégré à Gnome. Donc tu as fait un logiciel qui est plutôt spécialisé… pour un besoin quand même très générique (afficher des pages web).
Ne penses-tu pas qu'il y a de fait un problème sur la conception même du logiciel ? Ne devons-nous pas faire des logiciels les plus génériques possible ? Est-ce qu'une "bonne" intégration à UN bureau justifie un développement spécifique ?
Tu n'as qu'assez peu parlé de l'existant, je ne connais pas du tout le domaine et il me paraît assez bizarre qu'aucune alternative n'existe à celles citées.
Sinon à part ça : ARRÊTE DE ME DONNER ENVIE DE FAIRE DU RUST J'AI PAS LE TEMPS. :'(
Bien que j'utilise mon terminal quotidiennement, je ne m'étais jamais trop renseigné sur les raccourcis possibles. Je connaissais quelques raccourcis présentés ici, pas plus. Ton post a au moins pour mérite de m'y faire penser. :)
PS: j'espère que ces raccourcis sont également disponibles sur d'autres interpréteurs, Bash est quand même peu répandu sur mes machines.
Je viens de regarder le document, et ce qui frappe c'est avant tout la brièveté des informations fournies, c'est écrit en mode "pense-bête". J'aime bien. Ça change des documents qui réécrivent toute l'histoire de tous les logiciels qu'ils mentionnent ! Après, c'est clairement pas pour les débutants.
Ensuite, je trouve que certaines informations sont assez obsolètes ou du moins je l'espère, parce que j'ai un peu pitié de l'administrateur qui doit encore se taper du sendmail.
Enfin, le fait que ce soit un document à part entière… me gène un peu. N'aurait-il pas mieux valu mettre tout ça dans les documents respectifs de ces programmes, comme des pages de manuel par exemple ? Plus on disperse l'information moins elle est visible.
Pour ma part je garde ce document, je vais lire les quelques parties sur les programmes que je n'ai jamais utilisé. Merci à toi !
J'héberge tout moi-même, je préfère encore ça. Du coup à part le moteur de recherche (ddg), tout est chez moi. Certes mes mails sont en partie chez Google et Microsoft puisque mes destinataires y sont, mais le jour où ils seront prêts à faire héberger leurs mails ailleurs, au revoir tout ce beau monde.
[^] # Re: Debian
Posté par karchnu . En réponse au journal Retour d'expérience d'une petite administration sous linux depuis 8 ans qui fait marche arrière. Évalué à 2.
Un gestionnaire de paquet devrait pouvoir gérer plusieurs versions d'un même logiciel. Et tout l'intérêt de SNAP est justement d'avoir une version "à jour"… donc ton gestionnaire de paquets devrait pouvoir faire ça, pas besoin d'un énième gestionnaire de paquets supplémentaire.
Exemple : tu as une version de ton OS qui est "stable" et a peu de mises à jour, mais en parallèle tu as un dépôt "plus à jour" sur lequel tu ne vas chercher QUE ton logiciel. Pas besoin de plusieurs programmes. On ne fait qu'utiliser de simples paquets.
[^] # Re: Debian
Posté par karchnu . En réponse au journal Retour d'expérience d'une petite administration sous linux depuis 8 ans qui fait marche arrière. Évalué à -2.
SNAP n'est qu'un symptôme de la gestion de paquets. C'est parce qu'il est impossible avec DPKG/APT/APTITUDE de gérer simplement l'installation de plusieurs versions de logiciel qu'on en arrive à des outils comme SNAP.
Et il a fallu combien de temps ? Bah je sais pas. Il y a des solutions à ces problèmes depuis un long moment sur plein d'autres distributions. Si je dis que Debian est un problème, c'est parce que réellement c'est avant tout ce système qui a un problème (et, par extension, Ubuntu et consorts).
# Debian
Posté par karchnu . En réponse au journal Retour d'expérience d'une petite administration sous linux depuis 8 ans qui fait marche arrière. Évalué à 2.
Tu te plains de Debian qui n'aurait que des versions anciennes des logiciels de sa logithèque… oui. Debian est mondialement connu pour ça. Rien à voir avec Linux du coup… faut te trouver une distribution qui correspond un peu mieux aux besoins.
Pour rappel, Debian c'est quand même pas top d'un point de vue de l'admin s'il doit modifier des trucs : plusieurs gestionnaires de paquets qui, non content de s'être multipliés pour de mauvaises raisons et embrouillant tous les nouveaux utilisateurs, foutent parfois la merde à la suppression d'un programme (ex: tu supprimes un paquet totalement mineur puis apt te demande dans le plus grand des calmes si tu veux supprimer dpkg, apt, ton bureau…), des incohérences absurdes dans le nommage des bibliothèques (liblibX, Ylib…), les "backports" qui sont une version archaïque du pinning… on pourrait continuer encore longtemps.
[^] # Re: Miroir des distributions GNU/Linux
Posté par karchnu . En réponse au journal disque dur qui dort. Évalué à 4.
Sauf que la plupart des papiers de recherche ne sont pas liés à des brevets. En informatique par exemple c'est même plutôt rare.
[^] # Re: Miroir des distributions GNU/Linux
Posté par karchnu . En réponse au journal disque dur qui dort. Évalué à 8.
Un jour faudra apprendre à regarder plus loin que la recherche pharmaceutique gérée par de gros lobbies et comprendre que la recherche c'est aussi tout un tas de petits organismes, partout dans le monde, qui n'ont déjà pas tellement les moyens de se payer les abonnements puis les publications puis les conférences.
Et là on ne parle même pas d'un autre type de public qui pourrait vouloir avoir accès aux recherches : les citoyens.
Et la condescendance en invoquant les bisounours, merci mais non merci.
[^] # Re: Scihub
Posté par karchnu . En réponse au journal disque dur qui dort. Évalué à 4.
Plusieurs solutions peuvent être envisagées. Dans tous les cas je conseille fortement de chiffrer le disque dur, au cas où. Aussi, même si les serveurs en face sont récupérés, les adresses IP de connexion peuvent ne pas être enregistrées (d'autant plus si de toutes façons l'activité est illégale).
Si on parle d'un point de vue purement technique, on pourrait masquer complètement ton adresse IP (ex: avec Tor).
Cela reste une bonne question, qui mériterait sans doute d'être posée à un avocat pour l'aspect juridique. Faut partir du principe que tu peux aller en prison et avoir à payer de très lourdes compensations…
On a la justice qu'on mérite je suppose…
[^] # Re: Miroir des distributions GNU/Linux
Posté par karchnu . En réponse au journal disque dur qui dort. Évalué à 5.
Bien belle mentalité. Penser aux profiteurs plutôt qu'à ceux qui cherchent des solutions aux problèmes de malnutrition, réchauffement climatique, économies d'énergies, fertilisation des sols, agriculture, pauvreté…
# Scihub
Posté par karchnu . En réponse au journal disque dur qui dort. Évalué à 10.
Soutenir la recherche et les chercheurs directement : sci-hub. Tu stockes les papiers chez toi, ils se font proxy vers tes fichiers. T'es invisible (il n'y a qu'eux qui te voient) et tu fournis des milliers (millions ?) d'articles aux chercheurs qui sans ça, doivent payer des fortunes pour accéder à leur propre recherche financée par l'argent public.
# Excellent troll
Posté par karchnu . En réponse au journal Pourquoi Vim? (Première partie). Évalué à 10.
Merci pour la grosse blague. :-D
PS: pour ceux qui n'ont pas compris, je ne me moque pas de l'éditeur, juste du fait que cet article soit un copier/coller de celui sur Emacs (je précise, on sait jamais).
[^] # Re: À l’aide !
Posté par karchnu . En réponse au journal Le Firefox nouveau est arrivé !. Évalué à 2.
Grâce à ton commentaire j'ai évité de faire cette bêtise, j'ai tout backup avant et j'ai désactivé l'extension histoire d'être sûr.
Bonne chance.
[^] # Re: Docker, Gitlab, ...
Posté par karchnu . En réponse au journal Projet DIY d'intégration continue auto-hébergée. Évalué à 2.
Bazel fonctionne que pour un ensemble très restreint de langages et ne fonctionne pas sur BSD (d'ailleurs il suppose par défaut que bash est installé et est dans /bin… ça a l'air bien codé ce truc) donc pour la généricité, on repassera.
Et à côté de ça, Nix, un gestionnaire de paquets. Je ne comprends pas en quoi il répond à la question. J'ai raté un truc ? :-D
[^] # Re: Docker, Gitlab, ...
Posté par karchnu . En réponse au journal Projet DIY d'intégration continue auto-hébergée. Évalué à 1.
J'ai demandé si quelqu'un connaissait un système de build qui se passe de Docker. Que dans ton entreprise le choix s'est porté sur Docker c'est très bien… mais hors sujet. Peu importe les arguments.
[^] # Re: Docker, Gitlab, ...
Posté par karchnu . En réponse au journal Projet DIY d'intégration continue auto-hébergée. Évalué à 1.
C'est précisément la question. :)
LXC et Docker sont des solutions très centrées sur Linux. Pour ma part je n'utilise pas (ou peu) Linux. Je préfère me renseigner sur une solution un poil plus générique qui tournerait sur tous les UNIX.
De nos jours, nous avons des systèmes de fichier qui savent gérer des snapshots (lire "une copie d'un répertoire qui coûte rien en temps et en volume de stockage occupé"), ce qui pourrait largement nous aider à créer des rootfs pour un millier de builds sans que cela n'occupe vraiment plus de place qu'avec du Docker. Du coup un "simple" chroot (ou solution équivalente) serait envisageable. Peut-être que ce ne serait pas suffisant, mais tellement plus simple et générique… Docker au fond n'est qu'une abstraction à une solution de ce type, mais en utilisant des fonctionnalités disponibles uniquement sur Linux, et un fonctionnement loin d'être intuitif. Tout ça pour pas avoir à faire un pont réseau, gérer des IP et un le DNS soit-même ?
# Docker, Gitlab, ...
Posté par karchnu . En réponse au journal Projet DIY d'intégration continue auto-hébergée. Évalué à 2.
N'y a-t-il rien de plus simple, réellement, pour faire de l'intégration continue ? Nécessiter Gitlab ou même "que" Docker me semble déjà assez complexe en soit.
[^] # Re: Rust vs. unsafe Rust
Posté par karchnu . En réponse au journal Conférence GStreamer 2017 : Oxydation de GStreamer. Évalué à 1.
Donc en résumé : ça peut casser partout dans ton code, mais le bug viendra de la partie "unsafe" (modulo les bugs dans le langage ou compilateur).
# Une ode à Rust sur un sujet assez pointu
Posté par karchnu . En réponse au journal Conférence GStreamer 2017 : Oxydation de GStreamer. Évalué à 5.
Je trouve ton article intéressant. Tu expliques comment on arrive à Rust et quels sont certains de ses avantages par rapport à C, et bien que d'autres articles existent sur le sujet tu l'appliques sur ton sujet de prédilection : GStreamer. Et c'est un peu là que j'ai du mal.
GStreamer est un code conséquent, les références que tu fais sont parfois floues et le code que tu montres ne m'a pas permis de comprendre intuitivement ce que tu faisais. Et ce n'est pas vraiment un reproche que je ferai à ton article, tu n'as sans doute pas le temps de présenter tous les concepts derrière GStreamer en détail. De ce fait, dès qu'on rentre dans "Écrire des applications GStreamer avec Rust" il devient difficile de suivre sans ouvrir une dizaine d'onglets… ça me rebute un peu. Du coup, je ne sais pas si l'article est trop grand ou pas assez.
En tout cas merci, tu donnes de la visibilité à Rust et à GStreamer. Si en tant que développeur d'outils assez poussés et gourmands en ressources tu considères ce langage, cela lui donne encore plus de crédibilité.
[^] # Re: Yunohost ?
Posté par karchnu . En réponse à la dépêche Actualités Sympa. Évalué à 1.
Est-ce que Sympa est plus simple à packager ? De ce que je vois de l'installation de Sympa, il y a une création d'un utilisateur système pour y mettre des fichiers dédiés à Sympa dans le home en incluant des binaires, notamment certains qui sont générés lors de la compilation de modules Perl qui doivent être installés à la volée, ce qui nécessite des bibliothèques de développement pour l'installation…
Pour bien faire il faudrait packager les différentes bibliothèques (ne pas rejouer l'installation à chaque fois, récupérant des bibliothèques dans des versions différentes à chaque fois), ne PAS créer un utilisateur dédié dans /home (c'est juste pas normal de fonctionner de la sorte, vous voyez d'autres softs UNIX demander la même chose ? Non. Et pour cause, c'est pas comme ça que ça fonctionne)… au final il faut patcher l'upstream qui ne respecte pas les conventions, et pas tenter de patcher un gestionnaire de paquets pour qu'il accepte de faire tout un tas de choses qu'il n'est pas censé faire.
Donc finalement, tu dis que mailman est une usine à gaz… moi j'en connais un autre. :-D
[^] # Re: Yunohost ?
Posté par karchnu . En réponse à la dépêche Actualités Sympa. Évalué à 1.
Je ne vois pas en quoi "faire tourner de gros sites" implique nécessairement de consommer beaucoup de ressources. D'autant plus à froid, sans une grosse charge. Qu'est-ce qui justifie cela dans votre application ?
[^] # Re: Actualité du courriel en 2017
Posté par karchnu . En réponse à la dépêche Actualités Sympa. Évalué à 1. Dernière modification le 02 novembre 2017 à 11:17.
La réponse se rapproche fortement de la différence entre un shell et une interface graphique. Tout réside dans l'extensibilité et la facilité d'usage. Étendre un webmail pour qu'en envoyant mon mail j'ai un script qui s'exécute, récupérer le résultat d'une commande, automatiser le reformatage d'un mail type pour afficher directement les informations que je recherche, faire ressortir des mots clés… bon courage.
La liste des possibilités est infinie avec un shell, sans faire de hack particulier, sans écrire du code spécifique à un webmail qui sera périmé à la prochaine version, sans réécrire le code du webmail, en ayant déjà tous les outils du shell à disposition, sans devoir modifier le code côté serveur…
# Intégré à Gnome
Posté par karchnu . En réponse au journal Eolie: 6 mois plus tard.. Évalué à 1.
Si je comprends bien, ton navigateur est pensé pour être intégré à Gnome. Donc tu as fait un logiciel qui est plutôt spécialisé… pour un besoin quand même très générique (afficher des pages web).
Ne penses-tu pas qu'il y a de fait un problème sur la conception même du logiciel ? Ne devons-nous pas faire des logiciels les plus génériques possible ? Est-ce qu'une "bonne" intégration à UN bureau justifie un développement spécifique ?
# Cet outil m'a l'air intéressant, quid de l'existant ?
Posté par karchnu . En réponse au journal media-toc ou un prétexte pour prendre des technologies en main. Évalué à 8.
Tu n'as qu'assez peu parlé de l'existant, je ne connais pas du tout le domaine et il me paraît assez bizarre qu'aucune alternative n'existe à celles citées.
Sinon à part ça : ARRÊTE DE ME DONNER ENVIE DE FAIRE DU RUST J'AI PAS LE TEMPS. :'(
# Je ne m'étais jamais renseigné
Posté par karchnu . En réponse au journal Bash et les raccourcis clavier. Évalué à 2. Dernière modification le 18 septembre 2017 à 13:24.
Bien que j'utilise mon terminal quotidiennement, je ne m'étais jamais trop renseigné sur les raccourcis possibles. Je connaissais quelques raccourcis présentés ici, pas plus. Ton post a au moins pour mérite de m'y faire penser. :)
PS: j'espère que ces raccourcis sont également disponibles sur d'autres interpréteurs, Bash est quand même peu répandu sur mes machines.
# Toujours aussi bluffé
Posté par karchnu . En réponse à la dépêche Blender 2.79 vient de sortir. Évalué à 10.
Blender est un logiciel avec énormément de fonctionnalité, il est excellent dans ce qu'il fait.
D'ailleurs, je sais que des gens l'utilisent pour faire du montage vidéo, et j'apprécierai grandement un article à ce sujet.
# Petit retour rapide sur le document
Posté par karchnu . En réponse au journal --== GUIDE DE L'ADMINISTRATEUR LINUX ==--. Évalué à 5.
Je viens de regarder le document, et ce qui frappe c'est avant tout la brièveté des informations fournies, c'est écrit en mode "pense-bête". J'aime bien. Ça change des documents qui réécrivent toute l'histoire de tous les logiciels qu'ils mentionnent ! Après, c'est clairement pas pour les débutants.
Ensuite, je trouve que certaines informations sont assez obsolètes ou du moins je l'espère, parce que j'ai un peu pitié de l'administrateur qui doit encore se taper du sendmail.
Enfin, le fait que ce soit un document à part entière… me gène un peu. N'aurait-il pas mieux valu mettre tout ça dans les documents respectifs de ces programmes, comme des pages de manuel par exemple ? Plus on disperse l'information moins elle est visible.
Pour ma part je garde ce document, je vais lire les quelques parties sur les programmes que je n'ai jamais utilisé. Merci à toi !
# Pas de CHATON pour moi
Posté par karchnu . En réponse au sondage Ce que je suis prêt à laisser aux GAFAM. Évalué à 3.
J'héberge tout moi-même, je préfère encore ça. Du coup à part le moteur de recherche (ddg), tout est chez moi. Certes mes mails sont en partie chez Google et Microsoft puisque mes destinataires y sont, mais le jour où ils seront prêts à faire héberger leurs mails ailleurs, au revoir tout ce beau monde.
Oh, et openbsd ftw \o/