Si tu souhaites découvrir linux, je te conseillerais d'abord d'utiliser une distrib très grand public (ubuntu, mint, fedora, debian) pour t'éviter le genre d'écueil que tu viens de vivre, et de l'utiliser un petit moment.
Dans un second temps, tu peut passer sur arch ou sur gentoo. Leurs wiki respectifs sont extrêmement bien fait, mais suppose que le lecteur à un niveau technique élevé. Je suis pour ma part sous arch, et j'en suis très content, mais je ne le conseille vraiment pas comme premier système linux. La raison est très simple, il ne te mâche pas la tache. Il fait ce que tu lui dis de faire, et rien de plus. Par exemple lors de l'installation (en mode texte), par défaut, si tu veux une interface graphique, il faut l'installer à la main (mais si tu veux un système minimaliste au petit oignons, c'est normal de passer par là).
Je vais regarder. Il semble que garder android n'est pas quelque chose qui l'intéresse, ce qu'il veux au final, c'est un pc vraiment pas lourd et vraiment pas grand avec une bonne autonomie, pas exemple pour partir en rando (il est accompagnateur en montagne, donc ça peut lui permettre de montrer des trucs à ses clients.
Ça à l'air plutôt sympas. Est ce que tu l'as déjà fait ? Comment ça se passe au boot (cette partie n'est pas super clair), tu te retrouve sur l'interface Debian (gnome3, kde, …) ou celle d'Android ?
J'ai aussi du mal à voir pourquoi les gens ne se fabriquent pas des interfaces dédiées qui forgent facilement les requêtes grep/sed/awk de barbus pour eux (typiquement les dates).Quitte à finir avec grep/sed/awk à la main, une fois que le résultat est pré-maché.
Je suis tout à fait d'accord. D'ailleurs ça serait le même problème en binaire, avec une montée de version ayant des changements incompatible. :) La normalisation du format de donnée, c'est surtout pour que les ordis arrivent à les lire sans s'arracher les transistors ;)
Certes le mode texte est lisible par un humain, mais au final c'est la machine qui lit les logs, donc il faut faire en sorte que les logs soit lisibles par la machine, sous peine d'avoir un truc bancal.
Tout le monde s'arrache les cheveux dans ce thread sur la distinction binaire/texte. Je propose une définition, ditessmoi ce que vous en pensez.
Le fait que ce soit binaire ou texte est une question d'encodage, la façon dont on va enregistrer les données. La structure des données n'a rien à voir (on peut avoir une structure très flat en texte comme en binaire, des arbres en texte comme en binaire, …). De même la normalisation est orthogonale (on peut normaliser du texte et du binaire, ou faire n'importe quoi).
Un format texte est un format d'encodage générique, partagé par de nombreux types de donnés différents, dans de nombreux contextes, et de multiples applications, et ne sont pas liés à des contraintes matérielles. Il existe de nombreux types de format texte, mais ils partagent tous la caractéristique d'être agnostiques de la structure de données qu'ils encodent.
Un format binaire est un format d'encodage spécialisé dédié à un type de donnée, dédié à un contexte, ou un type d'application. Les formats binaires peuvent être liés à des contraintes matérielle (tels que l'endianess). Il existe de nombreux types de format binaire, chacun dédiés à un format de donnés.
edit: Je ne tiens à faire l'apologie ni de l'un ni de l'autre, ces deux formats d'encodage sont tous les deux valables dans un contexte donné.
Et qu'on soit clair. Quand on parle de log en texte, on parle uniquement de la partie stockage (le modèle). Il est bien évidemment pertinent de fabriquer un outil dédié (pour la vue) spécifique aux informations que l'on stocke dans nos logs (avec pourquoi pas un langage de requête).
Je n'ai pas bien compris dans les différentes discussions pourquoi est ce que les gens qui parlent du stockage binaire opposent forcément stockage texte à interface dédié. Ça me semble totalement orthogonal.
Tant que j'y suis dans les avantages longue durée du texte, il y a aussi celui-ci.
Supposons que l'on a beaucoup de log, et que l'on veut les conserver très longtemps. Il faut donc les compresser, la question ne se pose pas.
Choix 1 : log binaire, avec une structure de donnée efficace. On a un bon taux de compression.
Choix 2 : du texte. C'est verbeux, donc ça prend de la place. Mais, par ce qu'il y a un « mais », il y a une astuce. On manipule toujours les logs décompressé, comme ça on a besoin d'un seul outil (ou suite d'outils) pour les manipuler. En revanche pour le stockage, on les compresse. L'avantage, c'est que l'on peut avoir plusieurs types de compression. Je m'explique. Pour les logs récents ou récemment consultés, on utilise une compression très rapide (tel que lz4). On a donc un léger gain de place, et une faible perte de vitesse. Pour les logs anciens, et non récemment consultés, on peut utiliser un autre algo, avec des paramètres qui favorise le taux de compression. On a donc un très bon taux de compression en moyenne (la majorité des logs sont fortement voir très fortement compressé), tout en ayant en moyenne une très bonne vitesse de lecture (les logs récents sont en texte brut ou en lz4). De plus, les outils de compressions possèdent plusieurs implémentations documentées, et on possède des outils génériques en cas de corruption des archives.
Le double effet kiss cool, c'est que le jour ou on invente un nouvel algo de compression, avec les logs binaires, il faut tout mettre à jour : le format, et les outils pour les utiliser, ainsi qu'un convertisseur. Avec les logs textes, pas besoin de réinventer la roue. On utilise toujours les mêmes outils (ils ne savent lire que du texte décompressé de toute façon), et pour la migration, il suffit d'utiliser le décompresseur (qui existait déjà, vu que c'est celui que l'on utilisait avec l'ancien format de compression), puis de recompresser avec le nouvel algo (dans son implémentation standard). On n'a donc presque rien rajouté de spécifique dans notre code (seul les appels de fonctions compresse() et decompresse()), malgré une mise à jour significative de l'outil de stockage. Donc sur le très long terme (plus de 10 ans), ça peux être un avantage.
D'ailleurs un autre avantage du texte c'est de prendre en compte de manière transparente et native des changements considéré comme majeur en binaire.
Par exemple, si pour la date, on stocke un timestamp. Actuellement, il est « 1431114318 ». En binaire, on utilise 32bits pour stocker cette information. Le jour où on va passer en 64 bits, on va tout casser. En texte, on va stocke une chaîne : "1431114318", suivit d'un délimiteur (espace, deux points, …). Le jour ou on aura besoin d'un timestamp plus long, et b'en on va écrire un timestamp plus long. C'est tout.
Le gros avantage du texte, c'est la stabilité très longue durée (Unix à plus de 40 ans). Un format binaire est incapable de vivre aussi longtemps. Par exemple du C de 1990 est toujours compilable à l'heure actuelle, même s'il peut être difficile de l'exécuter (problème de librairie). Un binaire, c'est quasiment impossible d'en tirer encore quoi que ce soit.
Je manque encore clairement de recul pour pouvoir troller allégrement dans la bataille binaire vs texte, mais j'ai presque finis de lire ce livre disponible librement sur Internet qui explique les principes fondamentaux d'UNIX. Il date de 2003, mais malgré ça il reste encore d'actualité. C'est en le lisant que j'ai notamment compris pourquoi le it's all text est quelque-chose d'intéressant. Je vous le recommande chaudement.
Merci pour le journal, c'est très intéressant, et j'espère qu'il va apporter son lot de question.
En parlant de question, comment ça se passe pour les portails captifs ? Il me semble que je n'arrive pas à m'y connecter quand les sites que j'essaie de voir sont en https. (donc le premier onglet que je charge est toujours en http, pour me connecter et ensuite je surf normalement).
Est-ce que c'est une limitation inhérente aux portails captifs, et donc le passage au tout https pourrait poser problème, où est ce qu'il « suffirait » que les admins mettent à jour leur portails ?
Est-ce qu'il y en a parmi vous qui ont installé et testé unity ailleurs que sur Ubuntu. Ça m'arrive de temps en temps d'installer d'autres gestionnaires de fenêtres/de bureau pour voir comment ils évoluent, mais la dernière fois que j'ai essayé de le faire pour unity (sous arch), j'ai eu de gros avertissement qui disait qu'en gros je risquais de casser tout mon système.
Aux dernières JDLL à Lyon, j'avais discuté avec un dev gnome, et on avais remarqué qu'il y avait une clé dans gconf qui permet de lancer les extensions sans vérifier la version de gnome-shell requise. Je ne sais pas si un bouton à été ajouté depuis dans gnome-tweak-tool, c'est à vérifier.
# Titre
Posté par robin . En réponse au journal Grammalecte : plus que presque du tout !. Évalué à 1.
Le titre du journal nécessite l'utilisation de Grammalecte :)
bépo powered
[^] # Re: installer iceCat
Posté par robin . En réponse au message les commandes.. Évalué à 2.
Si tu souhaites découvrir linux, je te conseillerais d'abord d'utiliser une distrib très grand public (ubuntu, mint, fedora, debian) pour t'éviter le genre d'écueil que tu viens de vivre, et de l'utiliser un petit moment.
Dans un second temps, tu peut passer sur arch ou sur gentoo. Leurs wiki respectifs sont extrêmement bien fait, mais suppose que le lecteur à un niveau technique élevé. Je suis pour ma part sous arch, et j'en suis très content, mais je ne le conseille vraiment pas comme premier système linux. La raison est très simple, il ne te mâche pas la tache. Il fait ce que tu lui dis de faire, et rien de plus. Par exemple lors de l'installation (en mode texte), par défaut, si tu veux une interface graphique, il faut l'installer à la main (mais si tu veux un système minimaliste au petit oignons, c'est normal de passer par là).
bépo powered
[^] # Re: Si tu peux rooter une tablette, tu peux installer debian
Posté par robin . En réponse au message Tablette sous GNU/Linux. Évalué à 1.
C'est possible que ça puisse lui aller. Par contre au niveau budget, il me semble que c'est plus cher qu'une tablette.
bépo powered
[^] # Re: Bientôt prêt pour les tablettes :-)
Posté par robin . En réponse au message Tablette sous GNU/Linux. Évalué à 1.
Merci pour les infos.
@zurvan: C'était tout à fait ce genre de retour dont j'avais besoin.
bépo powered
[^] # Re: Si tu peux rooter une tablette, tu peux installer debian
Posté par robin . En réponse au message Tablette sous GNU/Linux. Évalué à 1.
Je vais regarder. Il semble que garder android n'est pas quelque chose qui l'intéresse, ce qu'il veux au final, c'est un pc vraiment pas lourd et vraiment pas grand avec une bonne autonomie, pas exemple pour partir en rando (il est accompagnateur en montagne, donc ça peut lui permettre de montrer des trucs à ses clients.
bépo powered
[^] # Re: Si tu peux rooter une tablette, tu peux installer debian
Posté par robin . En réponse au message Tablette sous GNU/Linux. Évalué à 1.
Ça à l'air plutôt sympas. Est ce que tu l'as déjà fait ? Comment ça se passe au boot (cette partie n'est pas super clair), tu te retrouve sur l'interface Debian (gnome3, kde, …) ou celle d'Android ?
edit: j'avais oublié de poster mon commentaire :)
bépo powered
[^] # Re: Pour toi?
Posté par robin . En réponse au journal Vivent les journaux binaires !. Évalué à 1.
Merci pour ta critique intéressante. C'est tout à fait ce genre de commentaire que j'attendais en exposant mes réflexions.
bépo powered
[^] # Re: Pour toi?
Posté par robin . En réponse au journal Vivent les journaux binaires !. Évalué à 3.
J'ai aussi du mal à voir pourquoi les gens ne se fabriquent pas des interfaces dédiées qui forgent facilement les requêtes grep/sed/awk de barbus pour eux (typiquement les dates).Quitte à finir avec grep/sed/awk à la main, une fois que le résultat est pré-maché.
bépo powered
[^] # Re: que répondre devant tant de mauvaise fois
Posté par robin . En réponse au journal Vivent les journaux binaires !. Évalué à 3.
Je suis tout à fait d'accord. D'ailleurs ça serait le même problème en binaire, avec une montée de version ayant des changements incompatible. :) La normalisation du format de donnée, c'est surtout pour que les ordis arrivent à les lire sans s'arracher les transistors ;)
Certes le mode texte est lisible par un humain, mais au final c'est la machine qui lit les logs, donc il faut faire en sorte que les logs soit lisibles par la machine, sous peine d'avoir un truc bancal.
bépo powered
[^] # Re: Définition
Posté par robin . En réponse au journal Vivent les journaux binaires !. Évalué à 2.
Je suis vraiment trop con, j'ai confondu avec le SNG, qui est lui par contre une représentation texte du png. C'est dommage, j'ai loupé mon effet :(
bépo powered
[^] # Re: Définition
Posté par robin . En réponse au journal Vivent les journaux binaires !. Évalué à 1.
Par exemple celui-ci. Site officiel.
Enjoy :)
bépo powered
# Définition
Posté par robin . En réponse au journal Vivent les journaux binaires !. Évalué à 0. Dernière modification le 09 mai 2015 à 12:12.
Tout le monde s'arrache les cheveux dans ce thread sur la distinction binaire/texte. Je propose une définition, ditessmoi ce que vous en pensez.
Le fait que ce soit binaire ou texte est une question d'encodage, la façon dont on va enregistrer les données. La structure des données n'a rien à voir (on peut avoir une structure très flat en texte comme en binaire, des arbres en texte comme en binaire, …). De même la normalisation est orthogonale (on peut normaliser du texte et du binaire, ou faire n'importe quoi).
Un format texte est un format d'encodage générique, partagé par de nombreux types de donnés différents, dans de nombreux contextes, et de multiples applications, et ne sont pas liés à des contraintes matérielles. Il existe de nombreux types de format texte, mais ils partagent tous la caractéristique d'être agnostiques de la structure de données qu'ils encodent.
Un format binaire est un format d'encodage spécialisé dédié à un type de donnée, dédié à un contexte, ou un type d'application. Les formats binaires peuvent être liés à des contraintes matérielle (tels que l'endianess). Il existe de nombreux types de format binaire, chacun dédiés à un format de donnés.
edit: Je ne tiens à faire l'apologie ni de l'un ni de l'autre, ces deux formats d'encodage sont tous les deux valables dans un contexte donné.
bépo powered
[^] # Re: Pour toi?
Posté par robin . En réponse au journal Vivent les journaux binaires !. Évalué à 8.
Et qu'on soit clair. Quand on parle de log en texte, on parle uniquement de la partie stockage (le modèle). Il est bien évidemment pertinent de fabriquer un outil dédié (pour la vue) spécifique aux informations que l'on stocke dans nos logs (avec pourquoi pas un langage de requête).
Je n'ai pas bien compris dans les différentes discussions pourquoi est ce que les gens qui parlent du stockage binaire opposent forcément stockage texte à interface dédié. Ça me semble totalement orthogonal.
bépo powered
[^] # Re: Pour toi?
Posté par robin . En réponse au journal Vivent les journaux binaires !. Évalué à 9.
Tant que j'y suis dans les avantages longue durée du texte, il y a aussi celui-ci.
Supposons que l'on a beaucoup de log, et que l'on veut les conserver très longtemps. Il faut donc les compresser, la question ne se pose pas.
Choix 1 : log binaire, avec une structure de donnée efficace. On a un bon taux de compression.
Choix 2 : du texte. C'est verbeux, donc ça prend de la place. Mais, par ce qu'il y a un « mais », il y a une astuce. On manipule toujours les logs décompressé, comme ça on a besoin d'un seul outil (ou suite d'outils) pour les manipuler. En revanche pour le stockage, on les compresse. L'avantage, c'est que l'on peut avoir plusieurs types de compression. Je m'explique. Pour les logs récents ou récemment consultés, on utilise une compression très rapide (tel que lz4). On a donc un léger gain de place, et une faible perte de vitesse. Pour les logs anciens, et non récemment consultés, on peut utiliser un autre algo, avec des paramètres qui favorise le taux de compression. On a donc un très bon taux de compression en moyenne (la majorité des logs sont fortement voir très fortement compressé), tout en ayant en moyenne une très bonne vitesse de lecture (les logs récents sont en texte brut ou en lz4). De plus, les outils de compressions possèdent plusieurs implémentations documentées, et on possède des outils génériques en cas de corruption des archives.
Le double effet kiss cool, c'est que le jour ou on invente un nouvel algo de compression, avec les logs binaires, il faut tout mettre à jour : le format, et les outils pour les utiliser, ainsi qu'un convertisseur. Avec les logs textes, pas besoin de réinventer la roue. On utilise toujours les mêmes outils (ils ne savent lire que du texte décompressé de toute façon), et pour la migration, il suffit d'utiliser le décompresseur (qui existait déjà, vu que c'est celui que l'on utilisait avec l'ancien format de compression), puis de recompresser avec le nouvel algo (dans son implémentation standard). On n'a donc presque rien rajouté de spécifique dans notre code (seul les appels de fonctions compresse() et decompresse()), malgré une mise à jour significative de l'outil de stockage. Donc sur le très long terme (plus de 10 ans), ça peux être un avantage.
bépo powered
[^] # Re: Pour toi?
Posté par robin . En réponse au journal Vivent les journaux binaires !. Évalué à 5.
D'ailleurs un autre avantage du texte c'est de prendre en compte de manière transparente et native des changements considéré comme majeur en binaire.
Par exemple, si pour la date, on stocke un timestamp. Actuellement, il est « 1431114318 ». En binaire, on utilise 32bits pour stocker cette information. Le jour où on va passer en 64 bits, on va tout casser. En texte, on va stocke une chaîne : "1431114318", suivit d'un délimiteur (espace, deux points, …). Le jour ou on aura besoin d'un timestamp plus long, et b'en on va écrire un timestamp plus long. C'est tout.
Le gros avantage du texte, c'est la stabilité très longue durée (Unix à plus de 40 ans). Un format binaire est incapable de vivre aussi longtemps. Par exemple du C de 1990 est toujours compilable à l'heure actuelle, même s'il peut être difficile de l'exécuter (problème de librairie). Un binaire, c'est quasiment impossible d'en tirer encore quoi que ce soit.
bépo powered
# Un peu de lecture
Posté par robin . En réponse au journal Vivent les journaux binaires !. Évalué à 6.
Salut à tous,
Je manque encore clairement de recul pour pouvoir troller allégrement dans la bataille binaire vs texte, mais j'ai presque finis de lire ce livre disponible librement sur Internet qui explique les principes fondamentaux d'UNIX. Il date de 2003, mais malgré ça il reste encore d'actualité. C'est en le lisant que j'ai notamment compris pourquoi le it's all text est quelque-chose d'intéressant. Je vous le recommande chaudement.
Sur ce, bonne lecture.
bépo powered
# Portail captif.
Posté par robin . En réponse au journal HTTP poussé vers la sortie ?. Évalué à 3.
Merci pour le journal, c'est très intéressant, et j'espère qu'il va apporter son lot de question.
En parlant de question, comment ça se passe pour les portails captifs ? Il me semble que je n'arrive pas à m'y connecter quand les sites que j'essaie de voir sont en https. (donc le premier onglet que je charge est toujours en http, pour me connecter et ensuite je surf normalement).
Est-ce que c'est une limitation inhérente aux portails captifs, et donc le passage au tout https pourrait poser problème, où est ce qu'il « suffirait » que les admins mettent à jour leur portails ?
bépo powered
[^] # Re: Utiliser Unity en dehors d'Ubuntu
Posté par robin . En réponse à la dépêche Sortie d’Ubuntu 15.04. Évalué à 1.
J'avais regardé avant de poster, mais dans le lien, c'est un repo non officiel. D'où ma question « Est-ce que quelqu'un a testé ».
bépo powered
# Utiliser Unity en dehors d'Ubuntu
Posté par robin . En réponse à la dépêche Sortie d’Ubuntu 15.04. Évalué à 2.
Bonsoir,
Est-ce qu'il y en a parmi vous qui ont installé et testé unity ailleurs que sur Ubuntu. Ça m'arrive de temps en temps d'installer d'autres gestionnaires de fenêtres/de bureau pour voir comment ils évoluent, mais la dernière fois que j'ai essayé de le faire pour unity (sous arch), j'ai eu de gros avertissement qui disait qu'en gros je risquais de casser tout mon système.
bépo powered
[^] # Re: Bureau ?
Posté par robin . En réponse à la dépêche Debian 8 : Jessie l’écuyère est en selle !. Évalué à 3.
Aux dernières JDLL à Lyon, j'avais discuté avec un dev gnome, et on avais remarqué qu'il y avait une clé dans gconf qui permet de lancer les extensions sans vérifier la version de gnome-shell requise. Je ne sais pas si un bouton à été ajouté depuis dans gnome-tweak-tool, c'est à vérifier.
bépo powered
[^] # Re: moi je suis vieux (et con)
Posté par robin . En réponse au journal Les temps changent. Évalué à 1. Dernière modification le 27 avril 2015 à 12:51.
Mais chuut, ils n'étaient pas sensé le savoir.
bépo powered
[^] # Re: Something.js
Posté par robin . En réponse à la dépêche GNU Hurd 0.6. Évalué à 3.
Et tu as mis emacs en PID 1 ?
bépo powered
[^] # Re: Ils auraient pufaire pire...
Posté par robin . En réponse au journal Ayé, j'ai fermé mon compte PayPal. Évalué à 3.
À mais non, pas des diffs de diffs. Après on a l'impression de lire un texte de loi avec ses différents amendements.
bépo powered
[^] # Re: moi je suis vieux (et con)
Posté par robin . En réponse au journal Les temps changent. Évalué à 1.
Excellant, merci pour le lien.
bépo powered
[^] # Re: Consulter les annonces de RC
Posté par robin . En réponse à la dépêche Sortie du noyau Linux 4.0. Évalué à 2.
C'est fait. Merci.
bépo powered