Puisque on parle beaucoup de systemd en ce moment, j'ai fait la migration quand j'ai compris que Arch allait passer à systemd, je préfère prendre un peu d'avance plutôt que de me retrouver face au mur.
Bon, pour moi, ça fonctionne bien mais je n'ai pas envie de parler de lui.
Une autre partie de systemd qui a fait faire des bonds à beaucoup de monde, c'est journald, le "remplaçant" de syslog… (ce qui n'est pas vraiment le cas).
Déjà, journald permet – pour ceux qui le souhaitent – de renvoyer les logs vers un service syslog standard, car ce dernier ne s'occupe pas de la centralisation réseau des logs, juste de leur collecte.
Ensuite, je faisais aussi partie des sceptiques sur ce journal sans fichiers de conf' texte pour un filtrage via le shell des logs.
Au final, je trouve journald très sympathique à utiliser car la commande d'extraction des logs permet de pré-filtrer ce que l'on cherche sur des critères pertinents, pour ensuite utiliser les utilitaires unix pour extraire l'information voulue.
Quelques petits exemples :
On cherche ici les logs d'un service en particulier, kdm:
[gnumdk@arch ~]$ journalctl _SYSTEMD_UNIT=kdm.service
Logs begin at Thu, 06 Sep 2012 09:00:41 +0200, end at Thu, 06 Sep 2012 11:03:12 +0200.
Sep 06 09:03:02 arch kdm_greet[405]: Cannot load /usr/share/apps/kdm/faces/.default.face: Aucun fichier ou dossi
Sep 06 09:03:04 arch kdm[404]: :0[404]: pam_unix(kde:session): session opened for user gnumdk by (uid=0)
On peut, de manière plus simple, passer directement le processus recherché :
[gnumdk@arch ~]$ journalctl /usr/sbin/sshd
Logs begin at Thu, 06 Sep 2012 09:00:41 +0200, end at Thu, 06 Sep 2012 11:03:12 +0200.
Sep 06 09:00:45 arch sshd[348]: Server listening on 0.0.0.0 port 22.
Voilà, pour continuer cette semaine Lennart inside…
# ?
Posté par Nicolas Boulay (site web personnel) . Évalué à 10.
Si des gens se mettent à collecter des faits avant de faire des analyses, comment vont faire les trolls ?
"La première sécurité est la liberté"
[^] # Re: ?
Posté par skeespin (site web personnel) . Évalué à -10.
Utilise e4rat et tu verras de l'inutilité de systemd en terme de performance au démarrage.
Sinon ma question du jour est :
Si la fonction "autorun" doit être développer dans udev ou dans gnome 3 ?
[^] # Re: ?
Posté par Nicolas Boulay (site web personnel) . Évalué à 10.
Tu as oublié le lien vers le benchmark.
"La première sécurité est la liberté"
[^] # Re: ?
Posté par Olivier (site web personnel) . Évalué à 9.
Je ne connaissais pas e4rat, et je n'ai pas installé systemd pour faire de benchmark. Cependant, ce e4rat a piqué ma curiosité, aussi je l'ai testé et en voici le retour:
Conclusions :
- pour un disque "standard/à plateaux", e4rat apport un gain indéniable en terme de temps de démarrage
- comme e4rat est basé sur la défragmentation de ext4, et sur la pré-allocation, il n'y a gère de gain à attendre pour un disque SSD
- son utilisation n'est pas transparente, dans le sens où après des mises à jours significatives de la machine, il faut repasser par les étapes "d'apprentissage" (e4rat-collect) et "d'optimisation" (e4rat-realloc). Ce n'est pas très compliqué à faire, mais pas vraiment à mettre entre les mains d'un néophyte.
[^] # Re: ?
Posté par kursus_hc . Évalué à 7.
Tu rigoles pas quand tu fais des tests toi!
Pas plus qu'avec systemd en fait. Le type qui consacre du temps à améliorer son temps de boot sur un disque ssd est un bel enc*leur de mouches.
Et même un peu plus que le démarrage, car il est possible d'y faire rentrer une ou deux applications utilisée fréquemment (browser, éditeur,..) ce qui n'est pas négligeable, surtout sur les petites machines.
[^] # Re: ?
Posté par Olivier (site web personnel) . Évalué à 2.
Ce n'est pas non plus très compliqué. D'après https://ext4.wiki.kernel.org/index.php/Ext4_Howto#Converting_an_ext3_filesystem_to_ext4 , il y a 2 commandes à taper pour les partitions non-système, et à remplacer le ext3 par ext4 dans le /etc/fstab.
Pour la partition système, j'ai rebooté la machine sur un distribution live afin de lancer les commandes. Ce n'est pas le plus simple, mais cela m'a paru plus sécurisé.
En fait, le temps de la conversion se résume grosso-modo à celui de faire un e2fsck .
L'effet collatéral est que je ne peux plus monter mes partitions qu'en ext4 . Mais ce n'est pas un problème, puisque toutes les distributions majeurs ou en live le supporte par défaut.
Oui, tout à fait, il suffit lancer ces applis lorsque le "e4rat-collect" fonctionne.
[^] # SSD
Posté par Buf (Mastodon) . Évalué à 6.
Ça m'énerve à chaque fois que je vois ou entends : parler d'un disque SSD n'a aucun sens. Un disque, c'est une galette qui tourne. Il n'y a rien de tel ici.
Donc on dit "SSD", tout court, et pas "disque SSD".
[^] # Re: SSD
Posté par navaati . Évalué à 1.
Ah tiens, wep. Mais va falloir que tu signale un gros bug chez Gnome, alors :Ah tiens, nan, ils y ont déjà pensé : https://live.gnome.org/Design/Apps/Disks#Discussion
[^] # Re: SSD
Posté par Gof (site web personnel) . Évalué à 4.
C'est le syndrome SDS
(Syndrome du Disque SSD)
Aussi appelé le syndrome PNS (PIN Number Syndrome)
Voir aussi RAS syndrome
[^] # Re: SSD
Posté par maxix . Évalué à 4.
Il est dommage que les SSD ne soient pas mous, qu'est ce qu'on rigolerait!
[^] # Re: SSD
Posté par deasy . Évalué à 1.
OS de petitmou, disque mou requis!
[^] # Re: SSD
Posté par Marotte ⛧ . Évalué à 2.
Et que penser de clé USB :)
[^] # Re: SSD
Posté par 2PetitsVerres . Évalué à 4.
Un disque n'a pas besoin de tourner pour être un disque. C'est surtout l'ensemble des points d'un plan situé à une distance inférieur à une constante donnée d'un point donné.
Tous les nombres premiers sont impairs, sauf un. Tous les nombres premiers sont impairs, sauf deux.
[^] # Re: SSD
Posté par Buf (Mastodon) . Évalué à 3.
Ok, si tu veux. Mais ça ne change rien au fait qu'un SSD n'a rien d'un disque.
[^] # Re: SSD
Posté par Antoine . Évalué à 1.
Moi ça m'énerve à chaque fois que j'entends parler d'une souris informatique. Une souris c'est un rongeur qui mange du fromage, ou bien c'est un morceau de la patte arrière de l'agneau. Il n'y a rien de tel ici.
[^] # Re: SSD
Posté par Marotte ⛧ . Évalué à 3. Dernière modification le 09 septembre 2012 à 13:46.
Parce que dispositif de pointage c'est plus vague (ça peut s'appliquer à une tablette graphique) en plus d'être lourdingue ?
Je comprends ton énervement mais tu ne proposes pas de mot pour remplacer souris. Mot qui vient j'imagine de la ressemblance avec l'animal, à cause du fil qui peut faire penser à une queue.
De plus,
Et c'est super bon braisé en cocotte ! Mais déjà là je ne vois plus trop le rapport avec le rongeur ;)
D'ailleurs saviez-vous qu'en latin tous les petits rongeurs genre souris, mulot, surmulot, etc… étaient désignés par le mot musculus qui veut dire muscle. Parce que ces rongeurs faisaient penser à de petits muscles :)
[^] # Re: SSD
Posté par gnumdk (site web personnel) . Évalué à 2.
Non, mais franchement, le mec qui a inventé le truc, il avait envie d'appeler ça une souris, y'a pas de quoi en faire un fromage! :p
[^] # Re: SSD
Posté par Marotte ⛧ . Évalué à 2.
Comme souvent c'est pas le mec qui a inventé le truc qui lui a donné son nom ! Par exemple c'est pas Thalès qui s'est dit, ça c'est le théorème de Thalès, c'est les gens après lui qui ont donné ce nom au théorème d'intersection…
[^] # Re: SSD
Posté par claudex . Évalué à 3.
Le type s'appelait M. Souris ?
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: SSD
Posté par Marotte ⛧ . Évalué à 2.
Mickey de son prénom ;)
[^] # Re: ?
Posté par zebra3 . Évalué à 6.
Ou pas. Sur un vieux portable (~2001), je n'ai vu aucune différence.
Je sais qu'un exemple perso ne fait pas la règle, mais ce n'est pas non plus une solution miracle.
Et tant que ma distribution ne le fournit pas par défaut (alors qu'elle fournit systemd), je n'ai pas vraiment envie d'installer un outil qui modifie un truc aussi vital que le filesystem.
Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
[^] # Re: ?
Posté par kursus_hc . Évalué à 3.
E4Rat ne modifie rien du tout, il réalloue.
[^] # Re: ?
Posté par zebra3 . Évalué à 1.
Parce que quand des blocs sont réalloués, rien n'est modifié ?
J'avais testé e2defrag il y a longtemps en me disant que puisqu'il déplace des blocs, rien n'est modifié. Mal m'en a pris car comme ça prenait des heures, j'ai voulu l'annuler, et j'ai perdu une partition comme ça.
Je suis bien d'accord que je suis seul responsable de ça, mais il est faux de dire que c'est sans effet.
Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
[^] # Re: ?
Posté par kursus_hc . Évalué à 2.
Ok alors, en tout cas j'utilise e4rat sur différentes machines sous différentes distro depuis un moment et je n'ai jamais eu de problème.
[^] # Re: ?
Posté par Sylvain Blandel . Évalué à 4.
D'après le site du projet, e4rat supporte uniquement les systèmes de fichiers ext4. Systemd n'a pas cette contrainte.
[^] # Re: ?
Posté par shbrol . Évalué à 1.
Il y a aussi readahead / readahead-fedora, qui fait du préchargement des fichiers utilisés au boot, sans réallocation sur le disque (pas besoin d'ext4).
Je n'ai pas essayé e4rat, parce que je ne voulais pas modifier la partition, donc je ne peux pas comparer. Mais readahead-fedora a divisé mon temps de boot par 2 (et ce n'est pas un sentiment, bootchart, toussa..)
[^] # Re: ?
Posté par modr123 . Évalué à -1.
ou sont les faits ?
pour avoir vraiment des faits il faut comparer deux choses, genre avant apres
mais la on a rien
[^] # Re: ?
Posté par Misc (site web personnel) . Évalué à 2.
Comme avant, en oubliant les faits et en ne gardant que l'émotionnel.
Voir http://youarenotsosmart.com/2010/06/23/confirmation-bias/
# Grep
Posté par MTux . Évalué à 9. Dernière modification le 06 septembre 2012 à 12:24.
Pardonnez ma remarque, mais extraire des informations d'un fichier texte ça ne se fait pas déjà avec grep ??? Et puis ça c'est standard sur quasiment tous les OS unix-like.
[^] # Re: Grep
Posté par Etienne Bagnoud (site web personnel) . Évalué à 5.
journald enregistre les logs dans des fichiers binaires, comme sous Windows. Donc les outils traditionnels ne sont plus utilisables.
"It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell
[^] # Re: Grep
Posté par khivapia . Évalué à 7.
Quelle est l'utilité d'un fichier binaire spécifique par rapport à un fichier texte gzippé ?
Je veux dire, pourquoi ont-ils fait ce choix ?
[^] # Re: Grep
Posté par gnumdk (site web personnel) . Évalué à 10.
J'aurai tendance à dire pour la même raison que MySQL ne stocke pas ses bases dans des fichiers texte gzippés ? :)
Non, en fait surtout parce que :
En fait, journalctl permet de lire ses logs dans plusieurs formats ce qui peux vraiment facilité les choses quand on veut "parser" ces derniers. Et que c'est plus simple d'avoir des objets avec toutes les informations plutôt que des lignes de texte. Sur des très gros logs, journalctl doit être beaucoup plus rapide (affirmation gratuite).
[^] # Re: Grep
Posté par Etienne Bagnoud (site web personnel) . Évalué à 8.
Et moi qui croyait que c'était pour avoir un système de log aussi utile que celui de Windows … Mince !
"It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell
[^] # Re: Grep
Posté par gnumdk (site web personnel) . Évalué à 10.
Le problème des logs sous Windows, ce n'est pas vraiment l'outil mais les logs en eux même…
Si tu veux commencer à avoir des logs utiles, il faut activer des clés de registre et ouvrir des fichiers texte de 30000 lignes absolument imbitables. Le juste milieu chez Microsoft, on connait pas.
[m - 30] avant une réaction de PBPG :)
[^] # Re: Grep
Posté par Adrien . Évalué à 1.
Il me semble qu'on peut très bien transformer du texte en json ou autre. Donc l'argument stocker en binaire pour pouvoir le sortir en plein de format est juste complètement foireux.
Après l'argument de la rapidité je n'en sais rien.
[^] # Re: Grep
Posté par gnumdk (site web personnel) . Évalué à 5.
Sauf qu'il me semble que les logiciels formatent leur logs actuellement comme ils le veulent donc ca doit être un beau bordel à convertir si il faut gérer plein d’exceptions.
[^] # Re: Grep
Posté par Zenitram (site web personnel) . Évalué à 5.
Je te prend au mot : prouve-le.
Le problème des 36 bouts de texte des logs Linux, c'est que c'est une horreur à parser à coup de regex à faire fuir des gens au cerveau normalement constitué (je n'ai rien contre les gens comprenant regex, j'en suis même jaloux). Si jamais tu y arrives sur une distro, tu peux être sûr que sur la distro voisine ton script merdera.
Et pour la vitesse, c'est le jour et la nuit (ben c'est un peu évident : tester 15 octets pour une date et en comprendre la signification, alors qu'un bête int32 suffit, c'est différent)
[^] # Re: Grep
Posté par Adrien . Évalué à 6.
Effectivement je n'avais pas vu ça comme ça. Mais là il aurait pu imposer un format texte pour systemd, du coup ce problème n'aurait pas forcément existé.
Je critiquais juste l'argument « on stocke en binaire pour générer tout type de format », qui me semble complètement stupide. Que ce soit binaire ou texte au départ, on peut générer tout type de format aussi facilement, modulo la vitesse bien sûr.
[^] # Re: Grep
Posté par Zenitram (site web personnel) . Évalué à 5. Dernière modification le 06 septembre 2012 à 14:46.
Pour reprendre l'exemple de la date, il est nettement plus simple de spécifier "le int est le nombre de jours depuis le 1/1/1970" que de prendre toute la norme ISO pour la date. Et aussi, la personne qui se plante dans l'implémentation le voit plus rapidement.
Le binaire a parfois du bon (même si tout n'est pas parfait avec du binaire, ça n'évite pas tous les problèmes d'implémentation) et pas qu'en vitesse (en vitesse, ça explose largement le texte), il ne faut pas le jeter "car c'est pas Unix on ne peux plus faire de grep", rien n'empèche de convertir le binaire en texte qu'on passe à Grep ensuite, l'avantage est qu'on peut "convertir" dans différents format bien plus facilement.
Certes HTML a gagné à coup de trucs "lisibles", mais ce n'est pas forcément ce qui est plus optimal.
PS : et pour les "conservateurs", c'est très simple de passer du binaire au vieux format texte, rien n'est perdu. L'inverse n'est pas vrai. Alors oui au journald en binaire!
[^] # Re: Grep
Posté par Adrien . Évalué à 5.
Ce problème est indépendant de texte ou binaire il me semble. On peut tout à fait définir les structures de données dans les deux cas.
Ben c'est ce point que je trouve bizarre : en quoi convertir du binaire dans divers formats est plus simple que convertir du texte dans divers formats ?
Il me semble que c'est kif kif, voire avec un léger avantage pour le texte, mais j'ai peut-être manqué un truc.
C'est sûr, l'inverse est aussi vrai. Après je n'ai pas plus d'avis que ça sur un journal binaire ou texte.
[^] # Re: Grep
Posté par Zenitram (site web personnel) . Évalué à 7. Dernière modification le 06 septembre 2012 à 15:15.
On peut. Sauf qu'en pratique, trop d'octets pour une date, les gens font un peu ce qu'ils veulent (par exemple, ils traduisent).
Alors certes, on peut spécifier lettre par lettre le format, mais pour reprendre mon exemple, un int c'est une ligne pour définir, combien de ligne pour définir un champs date?
L'avantage du binaire est surtout de rendre impossible des "adaptations", qu'on réserve à l'affichage.
L'expérience de l'analyse (c'est mon métier ;-) ) m'a appris que plus on laisse de la marge aux développeurs, plus ils font des conneries avec (du monde lisent les specs sans le lire). Limiter les possibilités pour dire la même chose rend les erreurs plus visibles (même en binaire, pour te donner un exemple une spec qui dit qu'un int est entre 1 et max(int), tu auras un gus pour commencer de compter à 0. si tu prends tout le domaine du int et surtout le début, ce genre de "compréhension de la spec" est diminué, moins d'erreur. Imagine avec 15 octets pour définir la date, combien d'erreurs et donc de merde pour "convertir" tu vas te taper… "Wed", "wed", "mer" pour mercredi? dans tous "convertisseur", vas-tu implémenter les 1000 langues du monde alors que définir en binaire un nombre de jours depuis 1970 aurait été plus simple et le convertisseur traduit dans la langue que tu veux?)
Un champs date en texte est simplement une merde absolue pour un programme (voir les clients FTP qui ont un mal fou et ont du code à plus savoir qu'en faire pour trouver de bêtes date/heure d'un fichier suivant le serveur FTP en face, FTP a ce même travers et ça pose un max de problèmes)
[^] # Re: Grep
Posté par delio . Évalué à 1.
Il dit que le int en question peut apparaitre en ascii dans un fichier texte au lieu de le stocker en binaire.
[^] # Re: Grep
Posté par Zenitram (site web personnel) . Évalué à 5. Dernière modification le 06 septembre 2012 à 16:07.
Pourquoi pas. Mais c'est pas lisible plus que ça par un être humain, et ça prend de la place (en plus de sa taille variable). En plus, tu sais si c'est en octal, décimal ou hexa?
Ca serait, de mon point de vue, les inconvénients du binaire mélangés aux inconvénient du texte, sans aucun avantage. Bref, je ne vois pas l’intérêt. Encore une fois, le binaire, il lui suffit d'un traducteur simple, tout comme il est simple de dire que 0x41 c'est "A" : c'est de l'affichage.
[^] # Re: Grep
Posté par 2PetitsVerres . Évalué à 3.
Ça prend beaucoup plus de place, et si tu veux l'afficher comme une date (lisible par un humain) ça allonge (un peu, mais il faut le faire pour chaque ligne affichée) le traitement (il faut faire ascii -> int -> date, au lieu de int -> date)
Tous les nombres premiers sont impairs, sauf un. Tous les nombres premiers sont impairs, sauf deux.
[^] # Re: Grep
Posté par Thierry Thomas (site web personnel, Mastodon) . Évalué à 1.
L'avantage d'un fichier texte, c'est sa robustesse : si après un problème il est mal fermé, on peut tout de même en lire le début, tandis qu'un fichier binaire risque d'être corrompu et inutilisable.
À ce propos, journald permet-il de faire l'équivalent d'un `tail -f' ?
[^] # Re: Grep
Posté par gnumdk (site web personnel) . Évalué à 3.
C'est aussi le cas du journal de journald, le format a été pensé pour ça
journalctl -f
[^] # Re: Grep
Posté par Zenitram (site web personnel) . Évalué à 3.
ah, c'est nouveau…
Binaire != mettre des champs "temporaires" au début.
Un fichier binaire est pareillement robuste qu'un fichier texte si il a le même principe (que des "append")
Ce sont des préjugés sur les fichiers binaires qui sont sans fondements.
[^] # Re: Grep
Posté par Alex . Évalué à 3.
Un fichier binaire corrompu, si ton outil n'a pas une certaine tolérance aux fautes, tu pourras difficilement l’exploiter.
Pour un fichier texte le problème est le même, néanmoins un oeil humain aura plus de facilité à récupérer de l'information.
Ceci dit, si journald a une sortie de type "classique", il me semble que ce troll n'a pas lieu d'être
[^] # Re: Grep
Posté par Antoine . Évalué à 3.
C'est une horreur à parser parce que c'est non-standardisé. Mais il n'y a pas de raison pour laquelle le standard (imposé par systemd) devrait être binaire (opaque) plutôt que textuel (lisible). L'IETF se débrouille très bien avec du texte.
[^] # Re: Grep
Posté par claudex . Évalué à 4.
Le texte, même standardisé, c'est coûteux en performance à parser (surtout avec l'UTF-8).
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Grep
Posté par khivapia . Évalué à 6. Dernière modification le 06 septembre 2012 à 16:02.
Merci pour ta réponse, je ne comprends toujours pas tout (un utilisateur pas vraiment admin système)…
Pour moi il y a deux aspects dans les logs d'une application :
les métadonnées des logs : date, heure, PID, état de l'OS etc. etc. : dans ce cas, que ce soit journalctl ou syslog ou autres, c'est facile de l'écrire de sorte que ce soit facile à parser, et la performance de lecture ne risque pas d'être déterminante (au doigt mouillé, on s'intéresse pas mal au contenu des logs tout de même !).
les logs proprement dits, ce que l'application a elle-même craché : à moins de modifier l'application, journalctl ne parsera pas les informations plus facilement que les scripts existants à grands coups de regex ; je veux dire, toute la complexité d'écriture des parseurs de logs pour l'appli X demeure, à la merci des moindre changements de formats de ce qu'elle loggue par l'application.
Donc grosso modo journalctl propose un format unique pour les métadonnées des logs de tous les services qu'il lance ? Ça n'était pas déjà le cas avant avec syslog ? (de ce que j'en vois mais je ne comprends pas tous les cas d'usage, dans mon daemon.log toutes les lignes commencent par la date, puis le nom de machine, puis le nom de l'application et son PID (on pourrait ajouter toutes les infos sorties par ps pour le même prix), selon un ordre immuable qui se parse en deux coups de cuiller à pot ; qu'y manque-t-il ? ) En fait ce que journalctl apporte, c'est une forme de standardisation de ces infos qui n'existe actuellement pas ?
Mis à part le gain de performance par un format binaire des logs, en fait je ne comprends toujours pas le problème que ça résout :).
[^] # Re: Grep
Posté par YBoy360 (site web personnel) . Évalué à 3.
non, l'une des raison de Journalctl c'est que les meta données sont crées par journald et non par le service (cas syslog). En cas de corruption d'un service, tes logs peuvent être corrompus.
par exemple si veux les logs d'un boot précédant je fais :
# journalctl _BOOT_ID=5cfd5397b3904a4eacfbf599bd20fa17toutes les lignes de log ont le même format pour les méta-informations, ce qui permet de faire ça simplement. Aujourd'hui c'est compliqué ce genre de requête. à mon avis ajouter toutes ces méta-informations au format texte n'aurait aucun avantage.
Le format binaire n'empêche d'utiliser des outils textes, mais je peux choisir le format texte que je veux avant de le traiter et je peux cibler très rapidement. (c'est étrange que personne n'ait cité cet avantage dans les précédentes discutions).
[^] # Re: Grep
Posté par khivapia . Évalué à 2.
Ok merci je comprends mieux.
[^] # Re: Grep
Posté par Anonyme . Évalué à 2.
C’est pas syslog qui rajoute les méta-données ?
Il me semblait que l’application faisait un truc genre (c’est sortit de mon esprit, c’est pas censé être juste) :
log(<facility>.<level>, <message>). C’est pas le cas ?[^] # Re: Grep
Posté par Alex . Évalué à 3.
La question c'est est-ce que les logs sont exploitables en cas de gros crash de la machine ?
est-ce que petites modifications du binaire rendent de grosses parties du log inexploitable ?
est-ce que si le système redémarre dans un niveau d'init bas (partoche en ro, services non lancés, lib inaccessible, pas de machines de secours), on peut toujours utilisé journalctl ?
Et est ce que çela corrige les manques de(s) syslog(s) ? (signature, authentification des machines envoyant des logs, et surement d'autres)
Ceci dit avoir des logs aisément filtrable est une bonne idée, tant que je peux avoir en même temps une sortie texte "classique", et ce même si je regrette qu'il n'utilise pas un db texte.
[^] # Re: Grep
Posté par Etienne Bagnoud (site web personnel) . Évalué à 5.
Lennart explique ses choix et les "révolutions" apportées par journald : https://docs.google.com/document/pub?id=1IC9yOXj7j6cdLLxWEBAGRL6wl97tFxgjLUEHIX3MSTs&pli=1
"It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell
[^] # Re: Grep
Posté par Kerro . Évalué à 7.
En voilà une bonne nouvelle : on a désormais les inconvénients de Windows et les inconvénients de Linux en un seul système.
Plus besoin de dual-boot, on peut s'auto-pourrir la vie juste avec Linux.
[^] # Re: Grep
Posté par Etienne Bagnoud (site web personnel) . Évalué à -2.
C'est Lennart : il créé des problèmatiques puis trouvent des solutions à ces problématiques ; solutions qui créent de nouvelles problématiques inutiles. Ça permet aux "fans" de sortir la phrase qui tue : "ben si t'es pas content de systemd/journald/…, arrête de geindre et amène TA solution". Et essayer d'expliquer que le problème solutionner par Lennart est un problème créé par lui pour être solutionné c'est impossible.
"It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell
[^] # Re: Grep
Posté par Jux (site web personnel) . Évalué à 6.
En même temps, systemd peut forwarder les logs à syslog ou à ce que tu veux d'autre, donc de ce côté-là, tu peux garder exactement la même configuration qu'avant.
[^] # Re: Grep
Posté par Anthony Jaguenaud . Évalué à 7.
Quelle est la plus value du changement ?
Les fans disent c’est vachement mieux !
Les réfractaires disent ça marchait bien, c’était lisible pourquoi changer ?
On leur répond tu peux tout changer, mais on peux formater pour que tu es l’impression que rien a changé.
Je ne comprends pas bien.
[^] # Re: Grep
Posté par gnumdk (site web personnel) . Évalué à 7.
syslog, c'est un standard et journald ne peut pas arrivé et dire je ne sais pas causer avec syslog… Même le gestionnaire d’évènement de Microsoft sait le faire!
[^] # Re: Grep
Posté par Anthony Jaguenaud . Évalué à -1.
Init sys V est un standand.
systemd peut arrivé et dire, jetez tout.
La cohérence, je ne vois pas.
[^] # Re: Grep
Posté par gnumdk (site web personnel) . Évalué à 3.
Non, syslog c'est un standard utilisé partout dans l'industrie… (switch, …).
Ton sysvinit, vu qu'il discute avec rien, on s'en fout un peu.
Et si sysvinit était vraiment un standard, alors j'aurai pas besoin de faire des trucs comme ça:
[^] # Re: Grep
Posté par Anonyme . Évalué à 2.
Si tina = TimeNavigator, alors le problème vient de lui (ce logiciel est une merde) pas de SysV.
[^] # Re: Grep
Posté par gnumdk (site web personnel) . Évalué à 2.
Non sans blague :) J'ai pas eux le choix du logiciel…
[^] # Re: Grep
Posté par SamG . Évalué à 1.
systemd est parfaitement compatible avec ton Init sys V.
C'est juste que tu ne pourras pas exploiter toutes les fonctionnalités supplémentaires qu'apporte systemd (dont tu n'as peut-être pas besoin).
Donc en quoi c'est pas cohérent ?
[^] # Re: Grep
Posté par gnumdk (site web personnel) . Évalué à 4.
Et pourquoi c'est un inconvénient ? Et me dit pas qu'on peut pas parser facilement les logs, y'a les commandes qui vont bien sous Windows pour le faire, bon ca crache que du xml par contre…
[^] # Re: Grep
Posté par rewind (Mastodon) . Évalué à 4.
Où est décrit le format binaire en question ?
À part l'API d'accès, il n'y a rien. Donc si qqn veut faire un outil qui lit le fichier en question, sans passer par l'API, il ne peut pas.
On en revient toujours à la même chose : interopérabilité, normalisation, etc.
[^] # Re: Grep
Posté par Misc (site web personnel) . Évalué à 7.
La réponse est "pour l'instant, on est encore en train de bosser sur le format de stockage, donc on va pas le documenter tant qu'on est pas sur qu'il est viable car on veut pas que des gens commencent à l'utiliser tant que c'est pas fini".
Ça ne me parait pas déconnant de d'abord avoir du feedback avant de décider "c'est bon, ça bouge plus". On le fait sans arrêt avec les APIs, donc ça me parait une approche des plus viables, si ça s’éternise pas.
Sinon, tant pis, ça va se terminer comme le format sur disque de sqlite, mysql ou postgresql, à savoir, personne ne va avoir rien à faire de le documenter. ( ou le format sur disque de svn, de la base rpm, d'openldap si les gens veulent des exemples autre que des SGDB ou assimilés ).
Ceci dit, il y a une documentation sur le format d'export :
http://www.freedesktop.org/wiki/Software/systemd/export
[^] # Re: Grep
Posté par YBoy360 (site web personnel) . Évalué à 0.
c'est exclusif à Windows le format binaire ?? syslog zip les fichiers log, c'est aussi un format binaire.
[^] # Re: Grep
Posté par zebra3 . Évalué à 2.
On peut aller plus loin en disant qu'un fichier texte est aussi un fichier binaire, puisque ça reste une suite de 0 et de 1.
Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
[^] # Re: Grep
Posté par 2PetitsVerres . Évalué à 4.
D'un autre coté, un fichier texte, c'est jamais qu'un fichier avec du texte encodé en binaire dedans.
Tous les nombres premiers sont impairs, sauf un. Tous les nombres premiers sont impairs, sauf deux.
[^] # Re: Grep
Posté par zebra3 . Évalué à 3.
Mouais, entre le grep POSIX et le grep GNU, y'a déjà un paquet de différences, alors dire que c'est standard…
Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
[^] # Re: Grep
Posté par claudex . Évalué à 7.
Dans ce cas, tu peux utiliser grep comme avant puisque tu connecte journald à syslog mais personnellement ce genre d'outil me simplifie la tâche parce que quand je cherche dans les logs, je dois d'abord passer du temps à les lire pour savoir comment identifier les lignes liées à l'application que je cherche ce qui est loin d'être pratique si l'application ne produit pas beaucoup de message.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Grep
Posté par Anthony Jaguenaud . Évalué à 1.
Moi, quand j’avais besoin de lire les logs, j’avais des filtres de coloration syntaxique. Ça permet de lire facilement les log dans ton éditeur de texte.
[^] # Re: Grep
Posté par Adrien . Évalué à 4.
D'un autre côté, un truc comme journalctl |vim - répondra sans doute à ton besoin ?
[^] # O (log (n))
Posté par Aissen . Évalué à 7.
Journal récupère les infos en O(log(n)), alors que grep nécessite de tout parser… O(n).
Va t’amuser à parser des gigas de logs avec grep… Et je ne parle même pas de les convertir dans un format utilisable ou d’utiliser des regex évoluées…
[^] # Re: O (log (n))
Posté par Misc (site web personnel) . Évalué à 7.
Y a des outils proprios pour ça, genre splunk. D'ailleurs, comme c'est un problème que personne n'a, la boite est pas du tout en train de faire des bénefs et d'avoir plus d'employés que Canonical ( pour donner un point de comparaison ). Comme c'est aussi un souci qui n'existe pas, la boite est profitable sans doute grâce au trafic de drogue.
# Autres fonction sympa
Posté par gnumdk (site web personnel) . Évalué à 6.
Pour la prochaine version du journal, il sera possible d’empêcher l'altération des logs, en gros, un attaquant pourra supprimer tous les logs (et donc être grillé) mais pas les modifier.
[^] # Re: Autres fonction sympa
Posté par khivapia . Évalué à 0.
Quelle différence de principe avec grosso modo 'gpg --generate-key new_pubkey; gpg --encrypt new_privkey with_my_master_sealing_key ; gpg --encrypt-files /var/log/* --with-key new_pubkey' dans un crontab avec périodicité toutes les 15 minutes ?
[^] # Re: Autres fonction sympa
Posté par Alex . Évalué à 3.
Le coté temps réel ?
[^] # Re: Autres fonction sympa
Posté par khivapia . Évalué à 2.
tu veux dire qu'il chiffre dès qu'il y a une ligne écrite dans le log ? C'est monstrueux si les applications sont un peu verbeuses, mais pourquoi pas. Alors avec un service qui ne lance que tailf et les commandes de chiffrement afférentes, plus le changement de clef régulièrement dans le crontab ?
[^] # Re: Autres fonction sympa
Posté par gnumdk (site web personnel) . Évalué à 2.
https://plus.google.com/104232583922197692623/posts/L1vzCnKCHMD
J'ai pas compris qu'il chiffrait les logs sur le disque, surtout que dans ton exemple, tu chiffre la modif de l'attaquant mais je vois pas ce que ca va avancer.
Dans l'idée, c'est de garantir l'intégrité du journal.
[^] # Re: Autres fonction sympa
Posté par khivapia . Évalué à 1. Dernière modification le 06 septembre 2012 à 16:46.
Dans mes exemples les opérations de chiffrement ne sont sans doutes pas les bonnes, mais s'il valide le log en temps réel, il fait forcément une opération à clef publique par modification.
M'enfin ton lien montre bien qu'il les scelle à intervalle de temps régulier, pas en temps réel, et qu'il change la clef de scellement régulièrement aussi, avec une autre périodicité.
Pour moi ça se fait avec les outils existants :
à intervalle régulier :
* bouger le fichier de log courant dans le répertoire des logs scellés (de la même façon que le gzip régulier) (genre logrotate quoi)
* sceller le nouveau fichier (de toutes façons par un chiffrement à clef publique, il ne faut pas que l'adversaire trouve la clef de descellement qui permettrait de les modifier)
à un autre intervalle : changer la clef de scellement, avec une chaîne de confiance jusqu'à la clef de descellement.
Bref un crontab, trois commandes, et zou. Bon d'accord ça ne fournit pas un QR code, mais ça se rajoute facilement…
[^] # Re: Autres fonction sympa
Posté par Prae . Évalué à 0.
Tu viens d'inventer un truc terreux, pas pro, pas pratique et franchement pas clean. Bravo, tu as ton certificat d'ingénieur certifié Epita. #trollinside
Sinon, le concept de la cryptobidule sur les logs, c'est un bon truc; On a pareil pour les logs DCI. Chaque ligne de log à un hash du précédent log. Et en toute fin, un ensemble de certif/hash/fingerprint, qui permet de certifier les logs. Certes, sur un système lambda, ca doit bouffer un peu plus de CPU, mais sur un système avec chipset crypto, ca doit avoir un impact plus réduit (et ca assure plus de sécurité : très utile sur les servs de productions)
[^] # Re: Autres fonction sympa
Posté par khivapia . Évalué à 1. Dernière modification le 06 septembre 2012 à 21:05.
Bien sûr, il faut vérifier le mode cryptographique utilisé pour le scellement des logs, mais ma remarque portait avant tout sur le fait que ça pouvait se faire simplement avec les outils existant (au pire, avec un tout petit programme pour le mode crypto, mais qui repose le plus possible sur des briques existantes genre gpg & openssl).
Pas besoin d'un truc qui soit intégré à systemd, ça pourrait très bien en être séparé si l'accès aux logs était facile. Pas très orthogonal ni modulaire tout ça ! Et encore moins réutilisable par d'autres malheureusement.
(sinon je n'ai pas fait l'Epita, désolé :-p)
[^] # Re: Autres fonction sympa
Posté par Alex . Évalué à 2.
je pensais plus à un système de chiffrement par flux
ceci dit je suis hs vu qu'il parlait plus de signature que de chiffrement
# Autre approche
Posté par needs . Évalué à 4.
journald
Journald me gêne car je ne souhaite pas avoir des logs en format binaire, je préfère parser avec des
grep,cut, et autre outils texte, cela reste infiniment plus puissant que devoir passer parjournalctl, d'autant plus qu'il s'agit ici d'une dépendance supplémentaire et systemd est une dépendance obligatoire de journald. En voici la raison :(source, 1ère question de la FAQ) Les devs de LFS vont avoir du boulot…
Le fait d'avoir un format universel est plutôt intéressant, mais dans ce cas, juste avec du texte. Il y a aussi le problème de la sécurité mais je n'en connait pas les détails.
On peut tout de même ce poser des questions sur journald, que Lennart décrit comme :
Par exemple il dit ici que l’outil doit être simple avec peu de dépendances, or
systemdn'a rien d'une petite dépendance, de plus systemd est Linux only donc journald aussi. Ce qui veut dire que les applications devront avoir 2 solutions de log pour être un minimum portable. C'est bien évidement une très mauvaise approche.Autre approche
On peut aussi prendre le problème des logs d'informations avec une autre approche :
En C, il y a 3 flux ouvert par défaut :
stdin,stdoutetstderr, le dernier est utilisé pour les erreurs. On pourrait ainsi créer un 4ème flux,stdlogoustddbgpar exemple pour prendre en charge les logs, puisque c'est essentiel pour une application de pouvoir communiquer son état et sa situation.Il y aurait ainsi une entré
/dev/stdloget a chaque ligne ajoutée, le système s'occupe de rajouter les informations de temps, le PID, le nom de la machine …On pourrait alors imaginer une utilisation tels que celle-la :
Que l'on pourrait manipuler ensuite de cette manière grâce aux redirections de flux :
Ou encore …
Puisqu'une raison d'être de journald est la non standardisation des logs, pourquoi ne pas proposer à la communauté une ébauche de standard ? Cela a en plus été déjà fait pour les logs server !
[^] # Re: Autre approche
Posté par Maclag . Évalué à 4.
J'ai installé systemd pour voir, je n'étais pas au courant pour journald, et figure-toi que je ne m'en suis même pas rendu compte!
J'ai bien accès aux logs à travers systemd-journalctl (suis sous Debian), et les logs sont toujours présents normalement dans leurs fichiers texte respectifs.
Il me semble qu'il a été dit ici qu'on pouvait très facilement convertir les logs binaires en texte, je crois que c'est ce qui a été fait.
Donc dans l'immédiat, je ne vois pas en quoi ça serait un problème pour la compatibilité entre systèmes: il suffit que les outils "communs" continuent à se baser sur les logs texte.
Quant à l'idée d'avoir un standard commun pour tout le monde dans les logs, pourquoi pas. Mais alors pourquoi en format texte plutôt qu'en format binaire?
Et du coup: pourquoi ne pas utiliser directement le format proposé par journald?
[^] # Re: Autre approche
Posté par needs . Évalué à 1. Dernière modification le 06 septembre 2012 à 20:39.
Car l'interface la plus universelle est le texte. Sinon c'est un surplus non nécessaire, surtout pour les logs qui sont avant-tout lus par des humains, et non des programme.
Le 'facilement' est un peu osé, je ne voit aucune raison valable pour utiliser le format binaire :
gzippar exemple).Si quelqu'un te fournit des logs au format journald tu fait quoi si t'es sur un BSD ou autre ? Tu ne peut pas installer le parseur journalctl car il est dans journald qui est lui-même plus ou moins inclut dans systemd que tu ne pourra pas installer. Je n'installerai pas un gestionnaire de services et de périphériques pour lire mes logs.
Bon j’exagère un peu car rien n'empêche quelqu'un de fournir un autre outils pour parser le format journald et sortir du texte, mais le truc c'est que ce format peut être modifié à tout moment, il n'est pas documenté (il le sera probablement à long-terme) et il est linux-only pour le moment.
[^] # Re: Autre approche
Posté par Zenitram (site web personnel) . Évalué à 1.
Tu as bien de la chance de comprendre les centaines de langues dans le monde. Pour info, les logs ne sont pas toujours en anglais (et pourquoi l’anglais devrait avoir la primauté d'ailleurs?)
Et d'après toi, le texte est codé comment? Je vais t'aider : un programme transforme le texte qui n'est qu'un code binaire en une suite de pixels que tu peux lire.
Si il doit faire une petite phase de traduction en plus, ça ne va pas le tuer ton programme d'affichage.
[^] # Re: Autre approche
Posté par needs . Évalué à 2.
Et si j'ai pas d'outils pour faire la traduction ? C'est totalement absurde de choisir le format binaire pour des logs, sa doit être lut par des humains ! Mais pourquoi faire compliqué alors que l'on peut faire simple, puissant et portable ?
Et la langue ce n'est pas le problème, un
grepmarchera quand même, par contre ungrepsur le format binaire c'est possible mais tout de suite moins efficace.[^] # Re: Autre approche
Posté par Zenitram (site web personnel) . Évalué à 0.
Et si tu n'as pas d'outils pour afficher 0x41 en "A" sur ton écran?
0x41 n'est pas lisible par des humains, tu as déjà des outils de traduction. un de plsu ou de moins…
Non, ce n'est pas absurde, à moins que tu trouves sympa de lire des 0 et des 1 (et encore, c'est déjà une traduction d'un été électrique)
Ce qui est absurde est plutôt de vouloir se cantonner à une format "binaire" unique pour tout même ce qui n'est pas adapté. Bientôt des flux vidéos et audio en XML?
Ah oui? Ta vie doit être chiante si tu t'amuse à implémenter un parsing grep avec les centaines de langues pour dire "mercredi"… Non, les gens ne sont pas avec une seule langue sur terre, y compris sur des serveurs. Je te défie de me faire une ligne de grep qui parsera tous les logs de la terre pour la même erreur (rien qu'avec une date, mais si je te parle de faire un grep sur un message d'erreur précis, bon courage pour trouver toutes les traductions sur toutes les machines).
Ton grep, il marche pour toi, mais n'est pas maintenable à plusieurs.
[^] # Re: Autre approche
Posté par Alex . Évalué à 4.
Ca devient ridicule comme argument
Qu'est ce qu'on se fout de ce troll
je croyais que journald pouvait sortir du texte et du binaire, l'admin fera comme il veut et le gars qui fait du forensic priera pour qu'il ait activé l'option texte
[^] # Re: Autre approche
Posté par Zenitram (site web personnel) . Évalué à 1. Dernière modification le 07 septembre 2012 à 18:04.
Le binaire pas lisible par l'être humain n'en est pas moins ridicule. Il s'agit d'une simple conversion, ça ne tue personne. parait même que c'est déjà disponible, donc du coup tu peux greper dessus.
Bref, ce qui est ridicule est d'arriver à de tels "arguments" contre journald. C'est que finalement il ne doit pas y avoir trop de raisons d'être contre…
[^] # Re: Autre approche
Posté par Alex . Évalué à 5.
j'y cois tout de même un point important (que j'avais déjà cité je crois)
il faut pouvoir effectuer cette conversion, en cas de corruption, avec du binaire, il faut espérer que la corruption ne soit pas sur des éléments de structures. Avec du texte tu pourras au moins lire à l'oeil nu une bonne partie des infos
Par contre je t'accorde que de faire un grep fichierDeLog pattern, ou un journalctl optionDeFiltrgage | grep pattern, ça ne change pas grand chose
et franchement, vu que journald peut avoir les mêmes sorties que syslog, je ne vois vraiment pas le problème
[^] # Re: Autre approche
Posté par skeespin (site web personnel) . Évalué à -2.
Je vais expliquer pourquoi syslogd à l'époque le choix c'est fait sur le format texte et sur pas le format binaire :
C'est juste pour éviter un bon /dev/random sur ton fichier sur ton journal.
Dans ce cas, tu n'as plus aucune chance de savoir facilement si c'est journald qui a planté ton journal ou si tu viens de te faire hacker. C'est d'ailleurs un des problèmes des journaux d'events windows.
Les gens à l'époque sur des systèmes aussi low perf, on bien réfléchit à utiliser le format binaire, ils étaient pas c… quand même !
[^] # Re: Autre approche
Posté par Maclag . Évalué à 3.
Je ne suis pas expert sécurité, mais un bon coup de script sur un journal au format texte ne pourrait pas rendre l'intrusion encore plus discrète en enlevant uniquement les entrées suspectes?
"A l'époque", peut-être qu'appliquer ce genre de script aurait pris trop de temps face à un bon /dev/random quasi instantanée, mais aujourd'hui, je pense que même sur de gros fichiers de journaux, ça prendrait quelques secondes au plus.
[^] # Re: Autre approche
Posté par gnumdk (site web personnel) . Évalué à 3.
Garde tes explications pour toi parce que Le format texte est plus sensible à modification…
Et l'argument "tu n'as plus aucune chance de savoir facilement si c'est journald qui a planté ton journal ou si tu viens de te faire hacker" je te répondrais:
"tu n'as plus aucune chance de savoir facilement si c'est gzip/logrotate qui a planté ton journal ou si tu viens de te faire hacker", ca tiens aussi peu la route que le tiens.
[^] # Re: Autre approche
Posté par Marotte ⛧ . Évalué à 3.
Oui quand même, mais avant de lire les commentaires déjà postés je me permettrait cette réponse. Y'a des limites hein ! Chacun les situe où ça lui plaît mais elles existent ! Entre lire (en tant qu'humain) du binaire, de l'hexadécimal, de l'ASCII, de l'Unicode, il y a une différence sensible.
[^] # Re: Autre approche
Posté par Zenitram (site web personnel) . Évalué à 1.
Les logs textes ne sont ni simples (amuses toi à automatiser le bordel…), ni puissant (les grep sur du texte, c'est d'une lenteur, sponsorisé par Intel?), ni portable (format non précis, traductions).
On est donc bien d'accord : il faut virer ces formats pas simples pas puissant pas portable, donc virer les logs "texte" tels qu'ils sont fait maintenant.
Après, je sais, c'est dur de perdre son boulot, quand l'outil qui remplace permet de diviser par deux le nombre d'admins qui n'ont plus besoin de faire des scripts à la con… Si RedHat fait ça, tu crois que c'est pour le plaisir, ou ça va devenir un argument de vente sur le nombre d'admin par machine?
[^] # Re: Autre approche
Posté par oinkoink_daotter . Évalué à 2.
En même temps, "journal", quelque soit le format de sortie, loggue toujours une chaîne de caractères produite par l'application qui demande une journalisation, non, et ce avec qqs métadonnées autour (c'est une vraie question) ? Du coup les problèmes autour du texte dont tu parles ne sont pas résolus, même si qqn code un journal_grep, non ?
[^] # Re: Autre approche
Posté par zebra3 . Évalué à 9.
D'ailleurs il n'y a qu'un seul encodage. Oh wait…
Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
[^] # Re: Autre approche
Posté par Misc (site web personnel) . Évalué à 6.
Non mais par contre, tu as qu'un seul format de sérialisation.
Enfin un seul par lettre de l'alphabet.
Enfin pour ceux qui ont un nom bien sur.
[^] # Re: Autre approche
Posté par Antoine . Évalué à 3.
UTF-8 devient peu à peu le standard universel, oui (tu peux toujours coder en EBCDIC ou en CP1252 ou en UTF-16BE si ça t'amuse).
[^] # Re: Autre approche
Posté par navaati . Évalué à 3.
En Occident. Ya des endroits où c'est moins coûteux d'utiliser UTF-16, genre tous les gens à l'Est, là.
[^] # Re: Autre approche
Posté par Benoît Sibaud (site web personnel) . Évalué à 2.
Sans avoir spécialement de chiffres, je présume qu'UTF-16 est fortement utilisé aussi.
(source http://fr.wikipedia.org/wiki/UTF-16 )
« L'UTF-16 est en particulier utilisé dans les environnements windows. Dans ce système, les API dites unicode utilisent ce standard. Il en va de même du système NTFS.
UTF-16 est le standard de chaînes de caractères utilisé par l'UEFI. »
(source http://en.wikipedia.org/wiki/UTF-16 )
« The Python language environment officially only uses UCS-2 internally since version 2.0, but the UTF-8 decoder to "Unicode" produces correct UTF-16. »
« Java originally used UCS-2, and added UTF-16 supplementary character support in J2SE 5.0. »
etc.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.