Ubuntu 16.10 : une première bêta pour les déclinaisons de la distribution

Ubuntu 16.10 : une première bêta pour les déclinaisons de la distribution

Coucou systemd

Avatar de l'auteur
Vincent Hermann

Publié dans

Logiciel

26/08/2016 3 minutes
94

Ubuntu 16.10 : une première bêta pour les déclinaisons de la distribution

Les premières bêtas d’Ubuntu 16.10 sont désormais disponibles au téléchargement. Il s’agit uniquement des variantes et non de la version classique. Au programme, quelques changements sous le capot et une mise à jour générale des paquets.

Le cycle de développement d’Ubuntu ne comprend plus plusieurs bêtas depuis un moment pour la version classique de la distribution. Canonical ne propose qu’une seule bêta, nommée simplement « Finale » avant distribution générale. Par contre, toutes les variantes basées sur GNOME, KDE, Xfce ou encore Edubuntu continuent de fournir une Bêta 1, la 2 correspondant à la Finale d’Ubuntu.

Rien encore pour la version classique d'Ubuntu 

Ubuntu MATE, Kubuntu, Ubuntu GNOME, Lubuntu, Ubuntu Studio et Ubuntu Kylin reçoivent donc une première bêta pour la future 16.10 qui, comme son numéro l’indique, sortira en octobre. On reste sur le travail effectué avec la 16.04 LTS, mais en récupérant au passage de nombreuses versions récentes pour les composants et logiciels, ainsi que quelques modifications plus profondes.

Du côté du noyau, on retrouve pour l’instant la même version 4.4 LTS fourni avec Ubuntu 16.04. Cependant, la mouture 4.6.7 arrivera très bientôt dans les dépôts stables pour la 16.10 et les utilisateurs pourront donc l’installer dans la foulée. Cette version ne durera guère puisque Ubuntu 16.10, lors de sa sortie en octobre, disposera du kernel 4.8 (actuellement en Release Candidate 3).

D’autres changements sous le capot sont par contre déjà en place. Par exemple, la progression de systemd pour prendre en charge désormais l’ouverture des sessions, jusqu’ici encore réservée à Upstart. Ceux qui pestaient contre ce composant « tentaculaire » et sa propension à remplacer d’autres composants centraux du système ne risquent donc pas de se calmer. La première bêta est également l’occasion de voir débarquer le projet netplan, qui a pour objectif d’unifier et simplifier tout ce qui touche à la configuration réseau.

Mise à jour générale des paquets et GNOME 3.20 complet

Pour le reste, on retrouve l’habituelle valse des mises à jour, Ubuntu ayant le plus souvent des versions très récentes des logiciels intégrés, avec parfois quelques exceptions quand il s’agit des moutures LTS. On retrouve par exemple LibreOffice en version 5.2 et la suite de compilation GCC 6.2.0. Pour les utilisateurs de la déclinaison GNOME, il faut surtout signaler l’utilisation de la pile complète en version 3.20. Dans Ubuntu 16.04, certains composants, comme Nautilus, étaient restés à la mouture 3.14.

Comme toujours pour une bêta, il n’est pas recommandé de l’installer sur une machine de production ou chez toute personne désirant avant tout un système stable : il ne s’agit que d’une première bêta, même si deux versions alpha ont été diffusées avant. Pour ceux qui ont la dernière révision stable d’Ubuntu, on insistera sur le fait qu’il est préférable de ne pas sacrifier une installation de type LTS pour une bêta.

Ceux qui veulent récupérer les différentes images ISO pourront consulter l’annonce officielle. On trouve plus bas une liste des liens pour chaque déclinaison d’Ubuntu. La bêta finale d'Ubuntu 16.10 est quant à elle prévue pour 22 septembre.

94

Écrit par Vincent Hermann

Tiens, en parlant de ça :

Sommaire de l'article

Introduction

Rien encore pour la version classique d'Ubuntu 

Mise à jour générale des paquets et GNOME 3.20 complet

Commentaires (94)


systemd <img data-src=" />

Des recommandations de distros sans systemd?


aucune basée sur une débian &gt;= 8.x en tout cas (bien que débian utilise encore l’ancien système en parallèle de systemD le temps que les devs basculent leurs appli








thib_b a écrit :



systemd <img data-src=" />

Des recommandations de distros sans systemd?





Ben Devuan









thib_b a écrit :



systemd <img data-src=" />

Des recommandations de distros sans systemd?





Gentoo aussi (qui peut utiliser OpenRC par exemple), mais du coup c’est moins “accessible” que les debian-based, je le concède …



Il n’y a que Gentoo ou Slackware.



Vous lancez un troll sur systemd le vendredi, aucun respect…


respire



Je ne dois pas feed.

Je ne dois pas feed.

Je ne dois pas feed.

Je ne dois pas feed.



respire



C’est bon je vais bien.


Je recommande Slackware comme distro sans systemd, je l’utilise depuis plus d’un an et même si c’est pas user friendly, ça fonctionne très bien. Il y a aussi Gentoo mais je ne connais pas du tout.








thib_b a écrit :



systemd <img data-src=" />

Des recommandations de distros sans systemd?





Pourquoi ?



C’est quoi le souci avec systemd en fait ?


Je crois que windows 10 n’utilise pas systemd si tu veux…



Bah quoi on est trolldi non ?! <img data-src=" />


Les enfants, si vous aviez un lien qui expliquerait en quoi systemd est un démon maléfique mangeur d’enfant, ça m’arrangerait.

En presque 20 ans d’utilisation de GNU/Linux en mode total noob (assumé), j’en ai vu passer des changements… en quoi celui-ci est-il pire que les autres changements, mis à part le fait qu’il est casse-pieds pour les développeurs ?


Depuis que Ubuntu tourne sous Windows (avec la mise à jour Anniversary), peut-être bien que si, je vérifierai à la maison ce soir <img data-src=" />








petitevieille a écrit :



&nbsp;mis à part le fait qu’il est casse-pieds pour les développeurs ?





Même pas, il leur simplifie grandement le boulot.

&nbsp;

Ton script d’init de 99 lignes n’en fait plus que 15 avec systemd (exemple pour Nginx) et ce sont des arguments que tu lui passe car il sait se débrouiller.



Pour un noob systemd n’apporte rien. de visible



En faite si que dérange avec systemd si qu’il fait trop de chose et remplace plein de composant traditionnel.



De ce faite il devient une dépendance obligatoire sur quelque projets.



Il faut ajouté également qu’il supporte uniquement Linux et uniquement les versions assez récente de celui-ci.



Enfin systemd utilise des logs au formats binaires.


Ils sont tous incapables de dire pourquoi. C’est juste à la mode d’en dire du mal. Et non, de ce que j’ai lu jusqu’à présent, au vu de la simplicité de créer des units, tous les développeurs / admins qui devaient eux-même écrire leurs services semblaient plutôt chanter les louanges de systemd.



Je pense que c’est un peu comme les débuts de PulseAudio, dont tout le monde disait du mal, alors qu’en réalité, les pilotes audio mal écrits étaient pour beaucoup dans les problèmes rencontrés. Là, j’ai l’impression que c’est un peu la même chose. Pendant des années c’était de la bidouille dans tous les sens, certains composants tenaient sans qu’on sache trop comment, et l’arrivée de systemd a remis pas mal de choses à plat, obligeant à refaire certaines choses proprement, ce qui demande plus de travail durant cette phase de transition.



Mais je pense qu’à l’arrivée, on y sera gagnants.



* The Biggest Myths (anglais)

* systemd : l’init martyrisé, l’init bafoué, mais l’init libéré ! (français)








Okki a écrit :



Ils sont tous incapables de dire pourquoi.





Mais si c’est simple cela changes leurs habitudes.



si tu as du temps devant toi : http://linuxfr.org/news/pourquoi-les-zelateurs-et-detracteurs-de-systemd-ne-s-entendront-jamais , le tres bon http://linuxfr.org/news/systemd-l-init-martyrise-l-init-bafoue-mais-l-init-libere et l’usuel https://fr.wikipedia.org/wiki/Systemd

Débat sans fin, je trouve qu’il y a du bon et du mauvais, dans l’utilisation au final tant que ca plante pas on ne voit pas la différence, si on met les mains dedans on commence a comprendre&nbsp; !


http://linuxfr.org/news/pourquoi-les-zelateurs-et-detracteurs-de-systemd-ne-s-entendront-jamais

&nbsp;Extrait &nbsp;&nbsp;

&nbsp;” Résumé pour le lecteur pressé ou saturé :Nous assistons-là à une guerre culturelle, dans laquelle certains soutiennent que les baguettes c’est beaucoup mieux tandis que d’autres ne jurent que par couteaux et fourchettes, mais où personne ne parle en fait de la même cuisine. À la fin, ce sont ceux qui contrôlent la cantine qui vont gagner.”&nbsp;En tant que noob, cette explication me suffit !!&nbsp;<img data-src=" />


Rien a ajouter a cette comparaison cullino-scolaire ! <img data-src=" />


Je ne sais pas si j’ai tout compris au problème, mais vu la fierté de l’ignorance de certains commentaires ici au point de croire que les oppostions proviennent d’abrutis m’attristent à un tel point que je tente une explication :



Chaque fois que tu démarres ta distrubtion, tu construis une pyramide de logiciel. Chaque couche se place au dessus d’une autre, indépendamment de la couche inférieure. Par exemple, pour faire simple, noyau = n, n+1=dessinateur (àla xorg), ui (àla gnome) = n+2

En théorie, la liberté est énorme, parce que tu n’es pas obligé de terminer en forme de pyramide trianglulaire de ces cumuls d’empillages d’applications, tu peux créer toutes les formes possibles (même des instables).



Les opposants crient au drame sur le fait qu’avec le gestionnaire de démarrage systemd, tu crées une ossature prédéterminée. Du coup ton potentiel d’“empilage” d’application se trouve réduit au choix que la distribution à décidé. Tout fork devient un peu plus difficile, car les forks devraient respecter l’ossature des démarrages choisient par le comité décisionnel de ladite distribution C’est une partie de la liberté de modifier une distribution qui en serait réduite.



Ce ce que j’ai compris sans être un expert du domaine, donc attention sur la qualité de l’information (comme toujours sur internet) et merci d’avance pour les corrections si quelqu’un en sait plus.








Trollalalala a écrit :



Rien a ajouter a cette comparaison cullino-scolaire ! <img data-src=" />





Tu as aussi Tony Curtis et Roger Moore (une ou deux olives ?)<img data-src=" /> dans le premier épisode d’“Amicalement Vôtre”



On verra pour installer ça fin septembre. :)


Sans être fan de systemd, je crois que son plus grand avantage sera que l’utilisateur aura encore moins à bidouiller des fichiers (comme ça peut être le cas encore aujourd’hui) ce qui fait qu’on verra de plus en plus de distrib réellement ‘user friendly’.








petitevieille a écrit :



Les enfants, si vous aviez un lien qui expliquerait en quoi systemd est un démon maléfique mangeur d’enfant, ça m’arrangerait.

En presque 20 ans d’utilisation de GNU/Linux en mode total noob (assumé), j’en ai vu passer des changements… en quoi celui-ci est-il pire que les autres changements, mis à part le fait qu’il est casse-pieds pour les développeurs ?





Pour l’utilisateur lambda, ça n’a aucun impact. systemd peut éventuellement accélérer le démarrage. Ca n’a vraiment d’iNpact que pour les trolleurs systeme

&nbsp;



Obidoub a écrit :



Depuis que Ubuntu tourne sous Windows (avec la mise à jour Anniversary), peut-être bien que si, je vérifierai à la maison ce soir <img data-src=" />





Normalement non Windows 10 n’a qu’une sorte de Wine inversé qui permet d’exécuter des binaires Linux en utilisant l’environnement Windows. Systemd démarrerait un système Linux en entier.



Par exemple pour gérer les programmes qui démarrent avec la bécane, plus besoin de modifier l’init pour virer apache par exemple mais entrer dans un term : “systctl disable apache2” et voila ! Niveau utilisateur c’est génial mais bon apres les puristes diront que c’est centralisé et donc contraire a la philosophie linux, ce qui est vrai aussi…


Pour apporter ma pierre au débat:



La polémique autour de systemd est surtout du à son origine et son usage.

Son auteur initial est celui de pulseaudio et systemd est pensé user-friendly pour du desktop.

Donc en gros ca permet de doucement transformer un linux en pseudo-windows avec ses avantages/inconvénients.



Le réel problème n’est pas l’usage de systemd pour des distributions desktop toutes ficelées à la ubuntu/mint/… Le problème c’est surtout en environnement serveurs, là systemd réponds à une modernisation du vieux system d’init utilisé par les grosses distributions tel que debian et centos. Mais ce n’est pas adapté à du serveur clairement.

Le pire dans l’histoire c’est qu’un alternative au vieux system d’init qui a plus de 20 ans existait déjà avec entre autre openrc qui pour l’utiliser et vraiment excellent en usage serveur.



Vas expliquer à un sysadmin qui ne peut pas lire un fichier de log (normalement en texte) d’un systeme &nbsp;à un autre s’il n’a pas le binaire qui va bien pour le decoder car sous systemd les logs sont binaire.

&nbsp;

De plus systemd remplace tout un tas de techno au final et pas uniquement le systeme d’init.

Ce qui va à l’encontre de la philosophie *nix de base: chaque outil doit faire une seule et unique chose mais doit bien le faire (au niveau systeme, pas au niveau applicatif desktop).

Donc forcément cela veut dire qu’il ne sera plus possible de remplacer une brique par une autre bien meilleure sans modifier le tout. C’est dans ce sens que systemd est un problème car sa conception monolitique force un pseudo standard mais qui empeche la liberté d’un systeme reellement modulaire.

&nbsp;


Pas necessairement, effectivement systemd a du bon comme avoir remue la merde de vieux mecanismes completement lessives.



Cependant il y a toujours plusieurs points qui genent, comme les fameux logs binaires. En cas de crash du systeme, tu te marres bien a les parser.



Edit: Par ailleurs, comme le precise mon VDD, un autre probleme est le principe fondamental d’Unix qui dit que chaque programme doit se limiter a une chose bien precise et la faire correctement. Aller a l’encontre de de la philosophie amenera a des consequences qui sont difficiles a prevoir aujourd’hui.








Uther a écrit :



Normalement non Windows 10 n’a qu’une sorte de Wine inversé qui permet d’exécuter des binaires Linux en utilisant l’environnement Windows. Systemd démarrerait un système Linux en entier.





Sans systemd ça veut dire que le sous-système Ubuntu de Windows 10 ne peut pas lancer de services (openssh-server ou apache par exemple). Ou alors ils ont mis un autre système d’init mais ça m’étonnerait. Je vérifierai <img data-src=" />









Bhou a écrit :



Vas expliquer à un sysadmin qui ne peut pas lire un fichier de log (normalement en texte) d’un systeme &nbsp;à un autre s’il n’a pas le binaire qui va bien pour le decoder car sous systemd les logs sont binaire. &nbsp;





journald peut aussi écrire les logs en texte et c’est d’ailleurs le cas par défaut dans toutes les distributions.



Je ne vois toujours pas où est le problème…








Okki a écrit :



C’est juste à la mode d’en dire du mal.





Comme pour tout ce qui peut toucher de près ou de loin à Microsoft en fait. C’est souvent lié à la communauté du penguin quand même…



A lire les commentaires j’ai l’impression que Ubuntu s’arrête à l’utilisation de SystemD.

Heureusement non et avec très peu de modif, un bon fond écran un bon thème et un beau pack d’icones, cette distribution avec UNITY est vraiment très agréable à utiliser pour le tous les jours.



Je trouve qu’avec en parrallèle le site OMGubuntu.co.uk, cela crée de la vie et une dynamique pour essayer les nouveautés.



Etant à la base un pro opensuse, j’adore vraiment cette distribution qui s’installe facilement sur mon DELL XPS 15, comparé à opensuse…








Trollalalala a écrit :



Par exemple pour gérer les programmes qui démarrent avec la bécane, plus besoin de modifier l’init pour virer apache par exemple mais entrer dans un term : “systctl disable apache2” et voila ! .







Alors que sous open-rc (gentoo) il faut faire “rc-update disable apache2”

Heureusement que systemD arrive, ca remplacera ma commande par … une commande.



Ce ci est un commentaire trollesque. <img data-src=" />



Perso j’ai pas grand chose contre systemd ^^” mais il y a surement de meilleur argument que la ligne de commande <img data-src=" />









Bhou a écrit :



Pour apporter ma pierre au débat:



La polémique autour de systemd est surtout du à son origine et son usage.

Son auteur initial est celui de pulseaudio et systemd est pensé user-friendly pour du desktop.

Donc en gros ca permet de doucement transformer un linux en pseudo-windows avec ses avantages/inconvénients.



Le réel problème n’est pas l’usage de systemd pour des distributions desktop toutes ficelées à la ubuntu/mint/… Le problème c’est surtout en environnement serveurs, là systemd réponds à une modernisation du vieux system d’init utilisé par les grosses distributions tel que debian et centos. Mais ce n’est pas adapté à du serveur clairement.

Le pire dans l’histoire c’est qu’un alternative au vieux system d’init qui a plus de 20 ans existait déjà avec entre autre openrc qui pour l’utiliser et vraiment excellent en usage serveur.



Vas expliquer à un sysadmin qui ne peut pas lire un fichier de log (normalement en texte) d’un systeme &nbsp;à un autre s’il n’a pas le binaire qui va bien pour le decoder car sous systemd les logs sont binaire.

&nbsp;

De plus systemd remplace tout un tas de techno au final et pas uniquement le systeme d’init.

Ce qui va à l’encontre de la philosophie *nix de base: chaque outil doit faire une seule et unique chose mais doit bien le faire (au niveau systeme, pas au niveau applicatif desktop).

Donc forcément cela veut dire qu’il ne sera plus possible de remplacer une brique par une autre bien meilleure sans modifier le tout. C’est dans ce sens que systemd est un problème car sa conception monolitique force un pseudo standard mais qui empeche la liberté d’un systeme reellement modulaire.

&nbsp;





Valà. D’ailleurs même pour l’utilisateur normal ça peut être chiant, dès lors qu’il a un usage un peu avancé de sa machine (serveur web perso par exemple).

Et rien que les logs en binaire, je serais vraiment curieux de connaître la justification technique d’une aberration aussi monstrueuse. Rien ne saurait le justifier à mes yeux en tout cas, et certainement pas une pseudo-question de performances (et pourtant je suis sûr que c’est ce qu’on va me dire).



C’était un exemple parmis d’autres !! Je t’absous, on est trolldi et en plus ça m’a fait bien marré !!&nbsp; <img data-src=" />








Bhou a écrit :



Mais ce n’est pas adapté à du serveur clairement.






Ah ah j'ai ri. On peut savoir pourquoi ?! En tout cas je suis sysadmin et je préfère administrer mes CentOS 7 que les 6.     



&nbsp;





Bhou a écrit :



Le pire dans l’histoire c’est qu’un alternative au vieux system d’init

qui a plus de 20 ans existait déjà avec entre autre openrc qui pour

l’utiliser et vraiment excellent en usage serveur.





Tu n’as pas du saisir le fait que systemd n’était pas là juste pour remplacer initd.

&nbsp;





Bhou a écrit :



Ce qui va à l’encontre de la philosophie *nix de base: chaque outil doit faire une

seule et unique chose mais doit bien le faire (au niveau systeme, pas au



niveau applicatif desktop).







Et il faut arrêter d’être psycho-rigide parfois et se poser des questions. Cette soi-disant philosophie est-telle pertinente pour tous les systèmes ?



Au fait Linux est bien plus monolithique que systemd, et ça bizarrement ça ne gène pas les anti-systemd…



Pourtant c’est simple.



initd (initialization daemon) = s’occupe de l’initialisation = lancer des scripts au démarrage de l’OS



systemd (system daemon) = s’occupe du système = gestion d’énergie, montage des disques, journaux et lancement des process (avec gestion des dépendances).





Argument des 2 camps:

systemd c’est bien: ca standardise la plomberie système (powermgt, …), ca allège le dev des distributions.

systemd c’est mal: ca s’occupe de trop de choses à l afois et ca impose une dépendance à tout le monde.


Les logs seraient binaires car cryptés, pour éviter les modifications par des hackeurs








seb2411 a écrit :



Pourquoi ?





Heu, parce que le nom est pourri, t’a l’impression qu’ils ont codé ça à la va vite car toutes les autres solutions avaient foiré.




  • “j’ai un décapsuleur”



    • “non, je préfère ouvrir la bouteille avec les dents”



      <img data-src=" />



rigole pas, les dentistes vont faire la tronche<img data-src=" />








Jungledede a écrit :



rigole pas, les dentistes vont faire la tronche<img data-src=" />





Il fallait bien un moyen pour disserter sur le SystemD(ents)<img data-src=" />









Bhou a écrit :



Pour apporter ma pierre au débat:



La polémique autour de systemd est surtout du à son origine et son usage.

Son auteur initial est celui de pulseaudio et systemd est pensé user-friendly pour du desktop.

Donc en gros ca permet de doucement transformer un linux en pseudo-windows avec ses avantages/inconvénients.

&nbsp;





&nbsp; Le réel problème n’est pas l’usage de systemd pour des distributions desktop toutes ficelées à la ubuntu/mint/… Le problème c’est surtout en environnement serveurs, là systemd réponds à une modernisation du vieux system d’init utilisé par les grosses distributions tel que debian et centos. Mais ce n’est pas adapté à du serveur clairement.

Pas du tout d’accord.

La gestion des services et des dépendances entre eux est grandement simplifié.

Tu peux créer avec une syntaxe déclarative un nouveau service en 1 minutes, c’est vraiment simple quand tu as compris comment cela fonctionnait

&nbsp; Le pire dans l’histoire c’est qu’un alternative au vieux system d’init qui a plus de 20 ans existait déjà avec entre autre openrc qui pour l’utiliser et vraiment excellent en usage serveur. En même temps le monde open source a toujours fonctionné sur une diversité de techno et la sélection “naturelle” fait le choix. Si openrc n’a pas percé, il y a probablement des raisons. Si systemd est adopté en standard par Debian, RedHat et toutes les distributions majeures, il y a également des raisons.



Vas expliquer à un sysadmin qui ne peut pas lire un fichier de log (normalement en texte) d’un systeme &nbsp;à un autre s’il n’a pas le binaire qui va bien pour le decoder car sous systemd les logs sont binaire. Journalctl -xf est grepable. Et tu peux également décoder tes logs sur une autre serveur.

&nbsp;

De plus systemd remplace tout un tas de techno au final et pas uniquement le systeme d’init. Ce qui va à l’encontre de la philosophie *nix de base: chaque outil doit faire une seule et unique chose mais doit bien le faire (au niveau systeme, pas au niveau applicatif desktop). Donc forcément cela veut dire qu’il ne sera plus possible de remplacer une brique par une autre bien meilleure sans modifier le tout. C’est dans ce sens que systemd est un problème car sa conception monolitique force un pseudo standard mais qui empeche la liberté d’un systeme reellement modulaire.

&nbsp;

Sur ce point je suis d’accord.&nbsp; Notamment pour le binding entre les versions récentes de Gnome et systemd, qui empêche de l’utiliser.



Pour ceux qui veulent lire une présentation sur le fonctionnement et se faire une idée, voici quelques slides :

http://www.slideshare.net/nussbauml/systemd-46731240

&nbsp;









petitevieille a écrit :



Les enfants, si vous aviez un lien qui expliquerait en quoi systemd est un démon maléfique mangeur d’enfant, ça m’arrangerait.

En presque 20 ans d’utilisation de GNU/Linux en mode total noob (assumé), j’en ai vu passer des changements… en quoi celui-ci est-il pire que les autres changements, mis à part le fait qu’il est casse-pieds pour les développeurs ?





Toujours pas compris où est le problème. Comme beaucoup. D’ailleurs le commun des utilisateurs Linux se contrefoutent royalement de l’intérieur du capot dans la mesure où l’ensemble fonctionne en restant stable. Des querelles stériles de clochers !









Bhou a écrit :



Vas expliquer à un sysadmin qui ne peut pas lire un fichier de log (normalement en texte) d’un systeme à un autre s’il n’a pas le binaire qui va bien pour le decoder car sous systemd les logs sont binaire.











Carpette a écrit :



Cependant il y a toujours plusieurs points qui genent, comme les fameux logs binaires. En cas de crash du systeme, tu te marres bien a les parser.







systemd peut utiliser le traditionnel syslog et des journaux au format texte si on le souhaite.







Citan666 a écrit :



Et rien que les logs en binaire, je serais vraiment curieux de connaître la justification technique d’une aberration aussi monstrueuse. Rien ne saurait le justifier à mes yeux en tout cas, et certainement pas une pseudo-question de performances (et pourtant je suis sûr que c’est ce qu’on va me dire).







Il faut voir toutes les possibilités offertes par journald / journalctl. Et ce, par défaut et simplement, sans avoir à s’embêter avec grep, awk…



Par exemple, on peut facilement voir les logs d’un service en particulier avec journalctl -u service, d’un PID donné avec journalctl _PID=ton_pid, d’un exécutable donné avec journalctl /usr/sbin/exécutable…



On peut également facilement filtrer par date avec –since et –until : journalctl –since “2016-02-10 21:00:00”. Et bien évidemment, on peut combiner les deux, journalctl –since “2016-02-10 21:00:00” –until “2016-02-10 22:00:00”. Il y a bien évidemment des raccourcis, genre journalctl –since yesterday ou journalctl –since “10 minutes ago”



Ou depuis le dernier boot, journalctl -b voir l’avant dernier, journalctl -b -1



Il est également simple d’afficher les messages d’erreur du noyau sur le dernier boot, journalctl -p err -b



On peut également sortir tout ça dans différents formats. Par exemple, pour une sortie JSON, suffit d’utiliser -o json



Tout comme on peut nettoyer plus facilement les vieux logs sur une taille donnée. Par exemple, si on ne souhaite garder que le dernier giga de logs, on utilisera journalctl –vacuum-size=1G ou si on souhaite garder uniquement la dernière année, journalctl –vacuum-time=1years



Alors oui, en sortant de longues commandes avec grep, sed, awk et compagnie on pouvait éventuellement obtenir des résultats similaires, mais là, tout est grandement simplifié et donc à la portée du plus grand nombre. Puis que ce soit ainsi standardisé et aussi simple d’utilisation offre bien plus de possibilités aux applications graphiques fournies par les différents environnements de bureau. Par exemple, dans l’outil GNOME, il est bien plus simple de proposer graphiquement l’accès aux logs des cinq ou dix derniers boot système, ou de pouvoir afficher les logs d’un processus donné depuis le moniteur système.









Okki a écrit :



Il faut voir toutes les possibilités offertes […]



on peut facilement voir les logs d’un service en particulier, d’un PID donné […] d’un exécutable donné […]



filtrer par date […]



sortir tout ça dans différents formats. Par exemple, pour une sortie JSON



[…]







Et ? On peut avoir des outils hauts niveaux faciles, simples et puissants qui se basent sur du texte et non du binaire.



Le binaire c’est rarement une bonne idée.

.doc vs .docx/.odf

SIP vs H323…



&gt; Mais ce n’est pas adapté à du serveur clairement.



C’est pas ce que les gens qui font des distributions orientés serveuront l’air de penser








tanguy_k a écrit :



Et ? On peut avoir des outils hauts niveaux faciles, simples et puissants qui se basent sur du texte et non du binaire.







Ca nécessite d’avoir un format standard des logs texte (genre “csv”) + les outils/scripts adaptés au standard + espérer que tout le monde utilise ce standard. A part imposer ce standard a tout le monde (via la “Linux Standard Base”), on pouvait juste prier pour une convergence spontanée… et bien sur, ca n’arrive jamais.



Il est clair que systemd est une “inversion du contrôle” par rapport a initd. Mais l’avantage c’est que la standardisation est garantie par construction, et pas par la bonne volonté des développeurs.



Cinquante commentaires, et pas un pour dire que Windows 10 c’est mieux que systemd ?



Les bonnes traditions se perdent…








Quiproquo a écrit :



Cinquante commentaires, et pas un pour dire que Windows 10 c’est mieux que systemd&nbsp;?



Les bonnes traditions se perdent…





On parle pas d’OS, mais de SystemD&nbsp;<img data-src=" /> (pour votre sécurité)<img data-src=" />









Quiproquo a écrit :



Cinquante commentaires, et pas un pour dire que Windows 10 services.exe (SCM) c’est mieux que systemd ?







Type mismatch error.



<img data-src=" />




Oui mais non, là c’est plus assez HS ça fait petit bras.








127.0.0.1 a écrit :



A part imposer ce standard a tout le monde





C’est la meme problematique pour le binaire hein…



Que ca soit binaire ou ascii t’as les memes besoins :




  • standardisation du format

  • outils haut niveau pour faciliter l’utilisation

    Sauf que dans le cas de l’ascii c’est en plus lisible et modifiable par un humain sans outil.



    (On arrive a standardiser plein de choses, pourquoi pas le format des logs ?

    Pourquoi contourner un probleme et arriver a une solution bancale quand on le connait et qu’on peut le resoudre directement de facon propre ?

    Au pire s’il y a plusieurs “standards”, les outils peuvent les prendre en compte)



Le concept de plusieurs standards me fait penser à ceci :

https://xkcd.com/927/


J’ajouterai que l’ascii, ou l’UTF-8, sont également des formats binaires, où par convention on interdit des valeurs d’octets, ou des combinaisons de valeurs d’octets, une sorte de standard :)

Et sans outil, l’humain ne verrait rien, ou à la rigueur des zéros et des uns.

&nbsp;

J’adore mes “grep”, “awk”, “cat” et autres “more/less”, etc…

Mais

l’essentiel est d’avoir un format contenant l’info, et lisible d’une

façon relativement universelle, et surtout d’avoir l’info de comment

faire pour obtenir cette info (grrrr! journalctl, comment je pouvais

deviner ?)

&nbsp;

Avec Kubuntu en mode rescue, j’ai pesté contre systemd (sa mère à pris chère, …je regrette, …un peu).

Puis en lisant la bannière du shell (ou peut-être en faisant une recherche DuckDuckGo ? Je sais plus trop) j’ai commencé à comprendre ce qu’il fallait faire pour enfin avoir de l’info sur mon problème.



Donc, si suffisamment de gens pensent que systemd peut améliorer des choses. Qu’il fonctionne suffisamment bien (kubuntu 16.04, je ne m’en plein pas), et qu’il n’a pas d’inconvénient majeur. Ça ne me dérange pas de changer mes habitudes.

&nbsp;

Passer de ext4 à btrfs, ça change aussi, mais c’est plutôt pas mal.








Chocolat-du-mendiant a écrit :



J’ajouterai que l’ascii, ou l’UTF-8, sont également des formats binaires, où par convention on interdit des valeurs d’octets, ou des combinaisons de valeurs d’octets, une sorte de standard :)





Euh, pas du tout, car par définition le format binaire c’est ce qui n’est pas du texte… <img data-src=" />









Chocolat-du-mendiant a écrit :



Avec Kubuntu en mode rescue, j’ai pesté contre systemd (sa mère à pris chère, …je regrette, …un peu).

Puis en lisant la bannière du shell (ou peut-être en faisant une recherche DuckDuckGo ? Je sais plus trop) j’ai commencé à comprendre ce qu’il fallait faire pour enfin avoir de l’info sur mon problème.







Si la seule critique contre systemd c’est qu’il faut lire ce qu’il y a marqué à l’écran, c’est pas trop grave…





Welcome to emergency mode! After logging in, type “journalctl -xb” to view system logs, “ststemctl reboot” to reboot, “systemctl default” to try again to boot into default mode.

Give root password for maintenance

(or type Control-D to continue)





<img data-src=" />



Les gens qui critiquent le systemd ne travaillent pas dans l’informatique.



Sinon ils sauraient que c’est ce sur quoi reposent toutes les DSI.








Mihashi a écrit :



Euh, pas du tout, car par définition le format binaire c’est ce qui n’est pas du texte… <img data-src=" />





Oui! en général j’utilise aussi cette définition erroné pour faire simple. ;)

&nbsp;Mais c’est faux.

A ton avis il est codé comment ton texte, avec des 2, 3, 4, 5, … dont le système ne se servirait pas pour les fichiers binaires ? <img data-src=" />

&nbsp;A moins que tu ais un ordianteur ternaire et n’utilise le 2 que pour les fichiers textes ?

&nbsp;

Ouvre un fichier texte avec un éditeur binaire/hexa et tu verra que ça ressemble furieusement à du binaire. Pour la simple et bonne raison que ça en est ^^

Un fichier texte, est juste un fichier binaire qui doit être conforme à un certain codage (ASCII, UTF-8, etc…)et que l’on affiche en utilisant un codage que l’on espère être le bon, et si oui, ça marche. Mais avec le mauvais codage (genre du japonnais en UTF-8 ouvert en ISO_8859-15) c’est une autre histoire.

&nbsp;





127.0.0.1 a écrit :



Si la seule critique contre systemd c’est qu’il faut lire ce qu’il y a marqué à l’écran, c’est pas trop grave…







<img data-src=" />





Oui, bon! ce jour là j’étais énervé, je me souvenais plus que (k)ubuntu était passé à systemd, je retrouvais plus mes petits et c’était pas le moment. J’ai quand même l’impression que c’était moins clair que ça (kubuntu 15.04, il me semble). Mais j’essaie peut-être de me trouver des excuses ^_^;



N’en déplaise aux puristes, je suis content de l’apparition de systemd, même si ça demande de changer quelques habitudes bien ancrées…



Par contre Unity c’est vraiment pas ma tasse de thé, mais je n’utilise de toute façon ubuntu plus que pour une utilisation serveur, pour le desktop je suis sur une distribution basée sur ArchLinux, nommée Manjaro, c’est un peu ce qu’était Mint pour Ubuntu.



Néanmoins je continue de proposer Ubuntu Gnome LTS chez les gens, plus stable, moins de soucis en théorie, pour plusieurs années.


Ce n’est pas une définition erronée, c’est la définition d’un fichier binaire et d’un fichier texte !



La différence entre les deux est le codage utilisé.

En binaire, il n’y en a pas de spécifique, les données sont écrites directement en… binaire. Par exemple, la valeur 34 se traduira par la suite suivante dans le fichier : 100010.

Pour le texte, un codage est utilisé (ASCII, UTF-8, etc.), chaque octet correspond à un symbole. La valeur 34 donnera avec un codage ASCII : 01100110110100.



La même valeur, deux écritures différentes, car pas le même type de fichiers.



Dans les deux cas la valeur est bien traduite en valeurs binaires (des 0 et des 1) comme tous les fichiers informatiques. Mais ce qui différencie le type de fichier, c’est le codage utilisé pour faire cette traduction.








ComesFuxii a écrit :



Toujours pas compris où est le problème. Comme beaucoup. D’ailleurs le commun des utilisateurs Linux se contrefoutent royalement de l’intérieur du capot dans la mesure où l’ensemble fonctionne en restant stable. Des querelles stériles de clochers !





Non: linux propose une approche qui lui est propre, et qui faut justement qu’au bout de 25 ans, son succès dans ses domaines de prédilection (l’ouverture, l’interopérabilité, la modularité, l’adaptabilité et l’automatisation) ne se dément pas, au contraire. Typiquement, avoir une base légère et modulable, adaptable, sachant communiquer avec le monde qu’il entoure, et capable d’être ultra automatisée, ce sont les besoins fondamebtaux de l’IoT qui se répand actuellemebt comme une trainée de poudre.

L’alpga et l’oméga d’un système n’est pas d’avoir un système kikoolol zoli et facile pour les utilisateurs les plus noob. Ça c’est UN besoin, que d’autres solutions (windows par exemple) peuvent adresser au mieux. Et tant mieux pour eux.

Là on touche à un fondamental de ce qui fait l’adn de linux (faire une chose, le faire bien, etc…) sans que les avantages globaux soient si tangibles.










tanguy_k a écrit :



C’est la meme problematique pour le binaire hein…



Que ca soit binaire ou ascii t’as les memes besoins :




  • standardisation du format

  • outils haut niveau pour faciliter l’utilisation

    Sauf que dans le cas de l’ascii c’est en plus lisible et modifiable par un humain sans outil.



    (On arrive a standardiser plein de choses, pourquoi pas le format des logs ?

    Pourquoi contourner un probleme et arriver a une solution bancale quand on le connait et qu’on peut le resoudre directement de facon propre ?

    Au pire s’il y a plusieurs “standards”, les outils peuvent les prendre en compte)





    Le binaire est une connerie, avant tout parce que tout l’existant et les fameux outils tiers se basent sur ce qui est devenu un standard d’interopérabilité entre outils: le format texte.



    Si ton mécano a absolument tous les outils depuis 20ans pour bosser avec des boulons de 10 et que demain, tu lui amène un truc à réparer qui ne comporte que des boulons de 12, a ton avis, et même si les clefs plates de 12 existent, ça va lui simplifier le boulot au quotidien?





    Mihashi a écrit :



    En binaire, il n’y en a pas de spécifique, les données sont écrites directement en… binaire. Par exemple, la valeur 34 se traduira par la suite suivante dans le fichier : 100010.





    Raté: big endian ou little endian? <img data-src=" />



Non, tu te trompe. Les deux sont des fichiers binaires.

&nbsp;Tu admet toi-même qu’ils sont fait de zéros et de uns. Et si ça c’est pas la définition d’un fichier binaire. :)

&nbsp;

Ce que tu appel “type”, ne change pas la nature binaire du fichier.

C’est comme si tu disais qu’un jpeg n’est pas un binaire, puisque c’est une image.

Si tu te place à ce niveau, dans ce cas ce n’est pas deux types de fichiers (texte et binaire) qu’il faut prendre en compte, mais une infinité (texte, image, son, programme, etc…)



Si je prend ton exemple, avec 34. Pour moi tu as écris 2 fichiers binaires contenant l’un “0010 0010”, et l’autre “0011 0011 0011 0100”. (*)

Et d’après ta définition, tu as écrit 2 fichiers texte, en ascii l’un contenant le caractère guillemets (“), l’autre les caractères “3” et “4”. :b

&nbsp;(j’ai de la chance pour ma démo, tu n’as pas choisi une valeur de caractère non-imprimable ;) )

&nbsp;

Pour le système, ou le système de fichier, ça ne change rien du tout.

&nbsp;Et surtout pas la nature binaire du fichier.

Si tu pense que je fait erreur, s’il te plaît indique moi où tu spécifie

le type du fichier dans un système ? Au niveau de l’inode ? () Dans les propriété du fichier dans Windows, y a une case à cocher ?

&nbsp;

Sous unix/linux, les fichier (binaires) contenant uniquement du texte peuvent être facilement manipulés et transformés, par une foultitude de commande. C’est très pratique.

Mais ce sont juste des commandes qui savent ouvrir un fichier (toujours binaire) et s’il contient un codage qu’ils savent manipuler,&nbsp; peuvent afficher et transformer ce texte.



La distinction entre fichier texte et fichier binaire, c’est du pipeau.

J’utilise moi aussi couramment cet “abus de langage”, mais ça n’en reste pas moins faux.





(*) j’ai ajouté des “0” car tu avais concaténé 2 points de code ascii sur 7 bits, ça ne fait pas “3” et “4”, mais le caractère non-imprimable “EM” (0001 1001), suivit d’un caractère non-valide en ascii, ou UTF-8, mais qui donne ça “Ž” (1011 0100) en ISO 8859-15. A moins que ton système enregistre des fichiers avec des octets de 7 bits ? Ou un truc lié à l’endianess que j’ai loupé ?



(
) bon j’imagine qu’en cherchant bien on doit pouvoir trouver un truc qui le fait, ou l’a fait. Mais sur les systèmes unix/linux/windows courant et leur file system attitrés, je connais pas.

&nbsp;Mais je suis évidement loin de tout connaître … très, très loin, y a cas voir systemd ;)








brazomyna a écrit :



Le binaire est une connerie, avant tout parce que tout l’existant et les fameux outils tiers se basent sur ce qui est devenu un standard d’interopérabilité entre outils: le format texte.





Le binaire a ses avantages (taille des fichiers, vitesse d’accès aux données, etc.)







brazomyna a écrit :



Raté: big endian ou little endian? <img data-src=" />





Big endian <img data-src=" />. Et on s’en fout, c’est pour illustrer…







Chocolat-du-mendiant a écrit :



Non, tu te trompe. Les deux sont des fichiers binaires.

 Tu admet toi-même qu’ils sont fait de zéros et de uns. Et si ça c’est pas la définition d’un fichier binaire. :)





Non justement, c’est pas du tout ça la définition d’un fichier binaire !

Fichier informatique qui n’est pas assimilable à un fichier texte, dont les données sont enregistrées en codage binaire, comme les programmes, les fichiers sons, les vidéos, les images, etc. (wiktionnaire).

En informatique, un fichier binaire est un fichier qui n’est pas un fichier texte (wikipédia).







Chocolat-du-mendiant a écrit :



Ce que tu appel “type”, ne change pas la nature binaire du fichier.

C’est comme si tu disais qu’un jpeg n’est pas un binaire, puisque c’est une image.





Ça change complètement la nature des données qui sont dans le fichier.







Chocolat-du-mendiant a écrit :



Si tu te place à ce niveau, dans ce cas ce n’est pas deux types de fichiers (texte et binaire) qu’il faut prendre en compte, mais une infinité (texte, image, son, programme, etc…)





Non, c’est un choix qui a été fait : pour distinguer les fichiers textes des autres, c’est tout.

Après tu peux argumenter que c’est pas forcément très judicieux, mais c’est comme ça et pas autrement.







Chocolat-du-mendiant a écrit :



Pour le système, ou le système de fichier, ça ne change rien du tout.

Et surtout pas la nature binaire du fichier.

Si tu pense que je fait erreur, s’il te plaît indique moi où tu spécifie

le type du fichier dans un système ? Au niveau de l’inode ? () Dans les propriété du fichier dans Windows, y a une case à cocher ?





Pour le système de fichier ça ne change rien, parce qu’il s’en fout de l’agencement des données qui sont dedans.

Le type de fichier ne le concerne pas, il concerne uniquement l’interprétation des données et donc du codage utilisé.







Chocolat-du-mendiant a écrit :



(*) j’ai ajouté des “0” car tu avais concaténé 2 points de code ascii sur 7 bits, ça ne fait pas “3” et “4”, mais le caractère non-imprimable “EM” (0001 1001), suivit d’un caractère non-valide en ascii, ou UTF-8, mais qui donne ça “Ž” (1011 0100) en ISO 8859-15. A moins que ton système enregistre des fichiers avec des octets de 7 bits ? Ou un truc lié à l’endianess que j’ai loupé ?





Non, j’ai juste oublié le zéro du huitième bit vu qu’il n’est pas utilisé par l’ASCII.

Et au passage, certains systèmes qui utilisent l’ASCII travaillent avec des multiplets de 7 bits uniquement (certains systèmes de SMS par exemple).









Mihashi a écrit :



Non justement, c’est pas du tout ça la définition d’un fichier binaire !

Fichier informatique qui n’est pas assimilable à un fichier texte, dont les données sont enregistrées en codage binaire, comme les programmes, les fichiers sons, les vidéos, les images, etc. (wiktionnaire).

En informatique, un fichier binaire est un fichier qui n’est pas un fichier texte (wikipédia).



&nbsp;



&nbsp;Oui, je les avais vu. Mais, c’est faux.

&nbsp;Pas impossible que ce soit pour ça que Wikipédia tag l’article FR à recycler, et l’anglais comme devant citer ses sources.

&nbsp;C’est un usage de vocabulaire, mais techniquement c’est complètement faux.









Mihashi a écrit :



Ça change complètement la nature des données qui sont dans le fichier.



Non, je t’ai démontré qu’en essayant de créer un fichier binaire (0010 0010) tu avais créé un fichier texte (“), tout simplement parce que les données sont identiques, c’est du binaire. Ou pire tu as créé un fichier qui est à la fois binaire et texte. Mais comment c’est possible ? Comment ta définition résout ce problème ?

On l’appel un “textaire”, ou peut-être un “binexte”, à toi de choisir.

&nbsp;

Ignore mes exemple si ça t’arrange. Pourtant ils sont simples.

&nbsp;

&nbsp;



Mihashi a écrit :



Non, c’est un choix qui a été fait : pour distinguer les fichiers textes des autres, c’est tout.



Après tu peux argumenter que c'est pas forcément très judicieux, mais c'est comme ça et pas autrement.





Je dit pas le contraire sur l’usage de vocabulaire. J’utilise la formulation régulièrement, mais c’est une erreur.

&nbsp;Je dit juste que techniquement il n’y a aucune différence entre les deux types de fichier, puisque un fichier texte EST un fichier binaire.

&nbsp;Et du reste à l’époque ou cet usage a été décrété, je pense que s’ils avaient vu des fichiers contenant du texte avec des codages sur 8 bits (ISO 8859-xx, UTF-8, etc…) ils auraient dit “Ha! ça c’est du binaire.” Alors que c’est bien du texte sans formatage. La définition du fichier texte change dans le temps, c’est pratique…



&nbsp;



Mihashi a écrit :



Pour le système de fichier ça ne change rien, parce qu’il s’en fout de l’agencement des données qui sont dedans.



Le type de fichier ne le concerne pas, il concerne uniquement l'interprétation des données et donc du codage utilisé.







&nbsp;Ben c’est ce que je dit depuis le début, tes fichiers texte et binaires n’ont aucune différences, c’est la façon dont on interprète les données. Le codage.&nbsp;

Les fichiers eux sont en binaire, sans rien qui les distingues.

&nbsp;







Mihashi a écrit :



Non, j’ai juste oublié le zéro du huitième bit vu qu’il n’est pas utilisé par l’ASCII.



Et au passage, certains systèmes qui utilisent l'ASCII travaillent avec des multiplets de 7 bits uniquement (certains systèmes de SMS par exemple).





Tu oublie souvent le 8éme bit des octets dans tes fichiers ? 8-o

Parce qu’ y a un gros risque que ton fichier texte se transforme par magie en fichier binaire sur la plupart des systèmes, suivant ta définition ;)



En gros, tu es d’accord avec la définition qui dit que si une fois décodé c’est du texte (suite de caractère sans formatage, …en-dehors de ceux qui sont admis : fin de ligne, espace, tabulation, etc…), c’est pas du binaire.

&nbsp;Même si à la base ce sont aussi des zéros et des uns. Et même si pour un second système, ne connaissant pas le codage utilisé par le premier, ce fichier texte deviendra par magie un fichier binaire.

&nbsp;OK, pourquoi pas.



Perso, ma définition est simple et moins fluctuante, un fichier binaire a un contenu codé avec des zéros et des uns.

&nbsp;

Un fichier texte est un fichier binaire, dont le codage permet à un programme sachant interpréter ce codage d’afficher le texte du fichier. On peut distinguer les formats texte bruts et ceux plus ou moins “enrichit”.



&nbsp;Voila c’est tout.









Chocolat-du-mendiant a écrit :



Perso, ma définition est simple et moins fluctuante, un fichier binaire a un contenu codé avec des zéros et des uns.





Bah tu peux avoir ta propre définition, mais elle ne va pas te servir à grand chose vu que tu seras le seul à l’utiliser…



La tienne étant fluctuante dans le temps et en fonction du contexte, tu ne sera pas le seul à l’utiliser, mais vous ne vous comprendrez pas.

Ou mieux, vous croirez vous comprendre, mais, ne parlerez pas de la même chose, en fait.



Ce qui me fait penser que cette histoire de fichier texte, vient peut-être d’une époque où un fichier contenant uniquement du texte ASCII. pouvait être transféré par un protocole sur 7 bits (comme tes SMS).

Ce qui n’est plus vrai du tout avec des codages sur 8 bits. Qui sont pourtant pour toi des fichiers textes et pas binaires.


Non, elle ne fluctue pas. Le type du fichier dépends uniquement du codage utilisé et il ne change pas dans le temps.

Et évidemment, si tu n’utilises pas le bon codage tu n’obtiens pas les bonnes données, c’est tout.








Mihashi a écrit :



Le binaire a ses avantages (taille des fichiers, vitesse d’accès aux données, etc)





avantages qui sont totalement et définitivement inutiles dans ce contexte là, et en contrepartie on rend lesdits fichiers totalement inutilisables avec 25 ans de pratiques et d’outils habituellement utilisés pour manipuler l’information utile qu’il contient.



Superbe choix.



Parce que même avec ta branlette intellectuelle du “fichier texte qui est un binaire comme un autre”, la réalité n’en reste pas moins la même: le codage utilisé doit être interprété avant de pouvoir en manipuler le contenu.



Et si on compare les deux, on s’aperçoit de quoi?

eh ben que d’un côté tu as un codage reconnu que par son outil qui le génère (ou qui va demander une dépendance spécifique pour chaque entité qui voudra s’en servir), et de l’autre le codage le plus standard et le plus répandu qui soit, intégré absolument partout, et ne nécéssitant pas la moindre dépendance tierce et encore moins spécifique à un truc en particulier.



Heu.. je me permet de te rappeler que selon ta définition, si ce n’est pas du texte - et avec le mauvais codage, tu n’as pas obtenu du texte - c’est donc du binaire. Et si c’est du binaire, ça ne peut pas être du texte, si ?



Il y aurai un troisième type de fichier ? Les fichiers pas binaire, et pas texte, tant que l’on a pas tenté tous les codages possibles ? Une sorte de fichier de Schrödinger ;)

&nbsp;








brazomyna a écrit :



Parce que même avec ta branlette intellectuelle du “fichier texte qui est un binaire comme un autre”, la réalité n’en reste pas moins la même: le codage utilisé doit être interprété avant de pouvoir en manipuler le contenu.





Heu, c’est pas la mienne, mais celle de Chocolat-du-mendiant, moi je suis de l’avis contraire <img data-src=" />.









Chocolat-du-mendiant a écrit :



Heu.. je me permet de te rappeler que selon ta définition, si ce n’est pas du texte - et avec le mauvais codage, tu n’as pas obtenu du texte - c’est donc du binaire. Et si c’est du binaire, ça ne peut pas être du texte, si ?



Il y aurai un troisième type de fichier ? Les fichiers pas binaire, et pas texte, tant que l’on a pas tenté tous les codages possibles ? Une sorte de fichier de Schrödinger ;)





Bah non, il y a les fichiers textes et les fichiers binaires, c’est toi qui inventes un troisième type de fichiers.

C’est encodé avec un codage texte, c’est un fichier texte.

C’est pas encodé avec un codage texte, c’est un fichier binaire.

Rien de bien compliqué à comprendre, non ?



Le “fichier texte qui est un binaire comme un autre” ça c’est moi.

&nbsp;Pour lui le fichier texte ne peut pas être du binaire… par définition :/

&nbsp;

Sinon sur les problèmes que pose les log dans un format différent de ce qu’on a l’habitude, je suis d’accord.

Mais les gens de systemd ont aussi quelques arguments

Pas sûr d’avoir tout pigé. Et le doc est tout de même très ancien.

&nbsp;

&nbsp;Je comprend l’intérêt d’avoir une indexation, une meilleur authentification de qui log quoi, de meilleurs perfs.

Mais est-ce que cela devait absolument passer par un nouveau format ? Pas encore convaincu.



Je ne sais plus qui indiquait dans les commentaires que toutes les grosses distrib continuaient à tous loguer en format texte.

&nbsp;S’il y a la possibilité de le faire, c’est sans doute que ça n’enthousiasmait pas tout le monde.


tu devrait tout lire…

Comment sais-tu qu’un fichier est “encodé avec un codage texte” ?


Tu le sais ou tu le sais pas, peu importe, ça ne change pas la nature du fichier. La nature du fichier elle est déterminée au moment où tu choisis l’encodage et donc quand tu crées le fichier.











Chocolat-du-mendiant a écrit :



Le “fichier texte qui est un binaire comme un autre” ça c’est moi.

 Pour lui le fichier texte ne peut pas être du binaire… par définition :/





J’ai pas dis que c’était pas du binaire, j’ai dis que ça n’est pas un « fichier binaire. »









Mihashi a écrit :



Euh, pas du tout, car par définition le format binaire c’est ce qui n’est pas du texte… <img data-src=" />





Là! y a quelqu’un qui est pas d’accord, je te laisse lui répondre ?



Et sinon hésite pas à détailler ton “binaire” qui n’est pas un “fichier binaire”, peut-être qu’il me faudrait ta définition de “fichier” aussi, par ce que je sens qu’on a pas la même.



Pour l’instant j’en suis a :

Un fichier texte c’est pas un fichier binaire, mais c’est un binaire, j’ai bon ?









Chocolat-du-mendiant a écrit :



Mais les gens de systemd ont aussi quelques arguments





Ce sont des arguments valables pour faire évoluer le système de logging. Ce ne sont pas des arguments valables pour autant en ce qui concerne le choix d’un format binaire.









Bhou a écrit :



Vas expliquer à un sysadmin qui ne peut pas lire un fichier de log (normalement en texte) d’un systeme &nbsp;à un autre s’il n’a pas le binaire qui va bien pour le decoder car sous systemd les logs sont binaire.

&nbsp;

De plus systemd remplace tout un tas de techno au final et pas uniquement le systeme d’init.

Ce qui va à l’encontre de la philosophie *nix de base: chaque outil doit faire une seule et unique chose mais doit bien le faire (au niveau systeme, pas au niveau applicatif desktop).

Donc forcément cela veut dire qu’il ne sera plus possible de remplacer une brique par une autre bien meilleure sans modifier le tout. C’est dans ce sens que systemd est un problème car sa conception monolitique force un pseudo standard mais qui empeche la liberté d’un systeme reellement modulaire.





Le format de log ça se configure.&nbsp;



Ouais, c’est ce que je dit après le passage que tu cite.



Même le passage qui parle d’inclure des champs binaires (commandes ATA, dump mémoire/firmware), n’est pas très convainquant, le binaire sa s’encode dans du texte…

&nbsp;

A moins que je sous-estime la difficulté (complexité/overhead) pour le faire ?








Chocolat-du-mendiant a écrit :



Ouais, c’est ce que je dit après le passage que tu cite.




Même le passage qui parle d'inclure des champs binaires (commandes ATA, dump mémoire/firmware), n'est pas très convainquant, le binaire sa s'encode dans du texte...      

&nbsp;

A moins que je sous-estime la difficulté (complexité/overhead) pour le faire ?







Il y a même des outils de base pour le faire (genre uu(en|de)code, mais ce n’est qu’un exemple), qui ont le bonheur d’exister depuis des lustres, d’être dispo partout, et devenus des standards de fait.

Le seul point négatif potentiel est l’efficience en matière de codage et la taille des fichiers générés, mais rien n’empêche pour ces points hautement particuliers de les séparer du reste des logs.



Et entre nous, binaire ou pas, à titre perso je préfère trèèèès largement un système de log qui est capable de me générer un fichier distinct quand il me fait un dump de 16Go de RAM plutôt qu’un système qui va me produire un monstre de logs avec ce dump mélangé aux logs ‘classiques’. Surtout depuis une machine distante et une bande passante pas infinie, si je dois retracer quelque chose dans les logs, ou les rapatrier, au moins, ça ma laisse le choix entre reprendre le tout ou seulement la partie qui m’intéresse (typiquement, le reste en dehors des dump).

&nbsp;

&nbsp;



Tout fichier est binaire.&nbsp; Un fichier texte est un couple: constitué de deux éléments:





  • un fichier binaire

  • un système de codage (permettant d’associer bijectivement une séquence de bits de longueur fixe à un caractère)



    Un fichier texte est donc un fichier binaire particulier qui ne prendra le sens voulu par son créateur que s’il est lu avec le système de codage prévu par le créateur du fichier. Malheureusement, le fichier texte n’embarque pas la donnée du système de codage prévu par le créateur du fichier ce qui peut poser le problème classique du choix de l’encodage pour interpréter le fichier binaire censé représenter un fichier texte.


Il découle de ce que je viens de dire qu’un fichier (nécessairement binaire comme tous les fichiers informatiques) peut être interprété comme un fichier texte



Exemple en Ada

with ada.Sequential_io;



procedure carac is

&nbsp; type mon_carac is mod 28;

&nbsp; – on déclare un type entier sur 8 bits

&nbsp;

&nbsp; package byte_file is new Ada.Sequential_io (carac); use byte_file;

&nbsp; – on charge une bibliothèque permettant d’écrire des fichiers écrivant des valeurs de type mon_carac

&nbsp;

&nbsp; fichier : File_Type;&nbsp;

begin

&nbsp; Create (fichier, Out_File, “fichier”);

&nbsp; Write (fichier,2#0100_0010#); – On écrit la séquence binaire de 8 bits: 01000010

&nbsp; Close (fichier);

end carac;



Question: ce programme a t-il créé un fichier binaire ou bien un fichier texte ?

Réponse: il a écrit un fichier binaire (puisque tout fichier est binaire). Si tu donnes ce fichier binaire à un éditeur de texte (configuré probablement pour lire de l’UTF8), il va le voir comme un fichier texte (affichera le caractère “B”) avec un autre encodage il écrira (peut être) autre chose que “B”.



Est-ce plus clair ?

&nbsp;


Hmm. Je peux comprendre l’intérêt de chiffrer des logs (enfin, chiffrer de manière générale), mais pourquoi mettre ça en dur ? Ne peut-on pas faire exactement pareil avec ses propres outils ?

À mon sens c’est une fausse bonne idée de forcer, alors que les pratiques des sysadmin sont différentes et que tout bon sysadmin aura probablement déjà un outil de chiffrage en place auquel il pourrait également affecter les logs de systemd…


Arrrgh l’édit m’a baisé une fois de plus ça m’éneeerve ! XD

Bref, je rattrape les commentaires pour constater que c’est le coeur de la discussion… ^^

&nbsp;







Okki a écrit :



systemd peut utiliser le traditionnel syslog et des journaux au format texte si on le souhaite.






Il faut voir toutes les possibilités offertes par journald / journalctl. Et ce, par défaut et simplement, sans avoir à s'embêter avec grep, awk...







Dans ce cas effectivement, si on n’est pas forcé, je ne vois pas de problème.&nbsp;

Cela dit, je comprends tout à fait tes points sur ce qu’on peut faire avec des logs binaires, mais il faut voir aussi l’envers : un admin sys expérimenté aura probablement pris la peine de maîtriser awk et compagnie depuis belle lurette, considérant la masse d’outils à gérer qui produisent des logs en texte brut.&nbsp;

Du coup, il est compréhensible que l’idée de devoir réapprendre pour UN outil en particulier soit soûlant.&nbsp;



Et inversement, un apprenti sysadmin aura plus l’utilité de l’apprentissage d’outils comme awk et sed qu’il peut utiliser de milliards de façon, plutôt qu’un ensemble de commandes dédié à un outil en particulier.&nbsp; Le système de logs binaire est juste moins rentable en termes d’investissement quoi. :)



Mais puisqu’on peut utiliser systemd avec syslog, effectivement, tout va bien. <img data-src=" />









Citan666 a écrit :



Et inversement, un apprenti sysadmin aura plus l’utilité de l’apprentissage d’outils comme awk et sed qu’il peut utiliser de milliards de façon, plutôt qu’un ensemble de commandes dédié à un outil en particulier.











man journalctl a écrit :



journalctl –no-pager | grep toto







Ha ben en fait ça marche comme avant, on peut utiliser les outils comme awk et sed, de milliards de façon.



Quelle plaie ce systemd ! <img data-src=" />









Quiproquo a écrit :



Ha ben en fait ça marche comme avant





T’as “juste” besoin d’un programme spécifique pour extraire tes logs avant de pouvoir commencer à en lire une ligne…



Mis à part ça c’est “comme avant” <img data-src=" />



Si tu as configuré ton système de telle sorte que journalctl soit la seule méthode d’accès aux logs, c’est en effet le cas.



Cependant, la configuration par défaut de journald fait qu’en cas de cohabitation avec un démon syslog traditionnel récent (syslog-ng ou rsyslog), les messages sont traités en cascade par les deux systèmes (cf man journald.conf). Tu as le choix du mode d’accès en fonction des circonstances et de tes préférences.



journald n’enlève rien, il ajoute un syslog enrichi pour ceux qui le souhaitent. Il est toutefois possible que certains responsables de distribution aient fait des choix de configuration douteux, en désactivant sans préavis les logs texte, et c’est à eux qu’il faut demander des comptes.








Quiproquo a écrit :



journald n’enlève rien, il ajoute un syslog enrichi pour ceux qui le souhaitent.





Il ajoute surtout une couche supplémentaire, soit-disant destinée à proposer plus, censé être pensé pour interaction et la cohabitation avec des outils tiers, mais:

&nbsp;




  • 1) qui n’a aucune raison d’être quelque chose d’aussi couplé (et d’imposé).



  • 2) avec exactement l’inverse des bonnes pratiques habituelles en matière de cohabitation et d’interaction en ce qui concerne le formattage des données utiles, alors que jsutement c’est censé être un maillon dans une chaine, pas une fin en soit.

    &nbsp;



Justement, c’est le fond des critiques sur SystemD



Qu’elle est la différence entre un bon admin et un mauvais admin linux?



Le mauvais admin, lorsqu’il voit une application, il regarde ce qu’elle fait et les options de configuration. Et s’il voit une autre application qui fait la même chose mais avec plus de fonctionnalités, il choisira la seconde.



Le bon admin, lui, lorsqu’il voit une application, il regarde qu’est-ce qu’il peut en faire (merci les Pipes), et si elle en fait trop, il s’en méfie.



Les Pipes sont à la base de la puissance de Linux, c’est dommage d’en perdre une partie.








Delqvs a écrit :



Les Pipes sont à la base de la puissance de Linux, c’est dommage d’en perdre une partie.



Pas d’avis sur le bon et le mauvais admin (n’étant qu’un amateur probablement même pas éclairé moi-même ^^) mais je ne peux que plussoyer grandement cette parole de sagesse. <img data-src=" />









Delqvs a écrit :



Le bon admin, lui, lorsqu’il voit une application, il regarde qu’est-ce qu’il peut en faire (merci les Pipes), et si elle en fait trop, il s’en méfie.



+1.

&nbsp;



Sinon, c’est prévu que des distrib permettent d’installer les dernières Appimages fournies directement par les éditeurs depuis la logithèque?



Faute de standards permettant à tous les logiciels de tourner sur n’importe quel distrib, c’est peut-être le moyen à venir pour permettre à tous de profiter des dernières versions de logiciel sans avoir à attendre leur portage par la distrib.