Planet

Premiers pas avec Ubuntu 13.10 - CouvertureLes traductions sont au cœur de la philosophie Ubuntu :

  • chacun doit avoir la liberté de télécharger, exécuter, copier, distribuer, étudier, partager, modifier et améliorer le logiciel ;
  • chacun doit avoir l’opportunité d’utiliser le logiciel, même en cas de handicap ;
  • chacun doit avoir le droit d’utiliser le logiciel dans la langue de son choix.

C’est pour cela qu’aujourd'hui nous sommes heureux et fiers de vous annoncer la sortie de la version française du célèbre Manuel Ubuntu pour Ubuntu 13.10. Le manuel vous fournit de manière claire et structurée tout ce dont vous avez besoin pour débuter puis progresser avec Ubuntu. Le Manuel Ubuntu est aussi la garantie d’instructions pas à pas qui marchent, testées et intégralement en français, sans barbarismes ni mots incompréhensibles.

Pour résumer les avantages du manuel :

  • facile à appréhender – notre manuel comprend des instructions pas à pas et est dénué de jargon technique ;
  • une illustration vaut bien mieux qu’une longue description – beaucoup de captures d’écran illustrent les instructions ;
  • tout au même endroit – vous n’avez pas à parcourir le Web pour trouver de l’aide car tout se trouve dans un seul fichier ;
  • apprentissage progressif – démarrez avec les bases et apprenez au travers des différents chapitres ;
  • des dizaines de langues – traduit en plus de 52 langues, y compris des copies d’écran localisés ;
  • sous licence CC-BY-SA – téléc hargez, modifiez, reproduisez et partagez autant que vous voulez ;
  • aucun coût – nos documents sont tous rédigés par des membres de la communauté Ubuntu et leur utilisation est gratuite ;
  • imprimable – cette version est optimisée pour l’impression afin de sauver les arbres ;
  • section de diagnostic des problèmes – pour vous aider à régler rapidement les problèmes courants sous Ubuntu.

 

Télécharger le Manuel

Télécharger le manuel (13.10)

Liens directs : Ecran - Impression


Commander une version papier (13.10) sur CreateSpace (4,69 $ + frais de port)

Commander une version papier sur amazon.fr (13.10) (bientôt disponible, frais de port inclus)

Contribuer à la traduction d’Ubuntu et de sa documentation

 

 

Image: 

Fork me on GitHub

 

J'ai parlé récemment d'un script qui permet de poster automatiquement un tweet quand je publie un nouvel article sur le blog.

Ce script a été un peu modifié puisqu'il fait aujourd'hui 4 choses :

  1. Il vérifie si un nouvel article a été écrit (en cherchant la présence du message [POST] au début du message de commit Git) ;
  2. Dans ce cas, il envoie les nouveaux commits sur le dépôt Git défini par défaut ;
  3. Il met à jour le blog sur le serveur via SSH (commande make ssh_upload pour les Pelican-eux) ;
  4. Il envoie un tweet.

Tout ça c'est sympa, mais c'est un peu con d'automatiser toutes ces étapes si il faut au final lancer le script à la main. La magie de Git fait qu'on peut automatiser tout ça en utilisant les hooks de Git.

Ces hooks sont des scripts que Git lance après (ou avant) certaines étapes de son processus. Ils sont listés dans le répertoire .git/hooks/ :

╭────<quack@spiderman >───< ~/Documents/writing/blog/quack1_pelican > ‹master*› ╰───[18:52:40] $ ls .git/hooks applypatch-msg.sample post-commit pre-applypatch.sample prepare-commit-msg.sample update.sample commit-msg.sample post-update.sample pre-commit.sample pre-rebase.sample

Je ne vais pas tous les faire, les noms sont assez explicites, mais par exemple pre-commit est lancé avant le commit.

Mon script a besoin que le commit soit terminé, donc j'ai fait pointer le fichier .git/hooks/post-commit sur le script. Toute la configuration nécessaire est placée dans le fichier de conf, donc le script se lance sans souci :

╭────<quack@spiderman >───< ~/Documents/writing/blog/quack1_pelican > ‹master*› ╰───[18:53:14] $ ln -s ~/work/workspace/python/pelican_auto_tweet/pelican_auto_tweet.py .git/hooks/post-commit

Désormais dès que vous ferez un commit dans ce dépôt Git, le script se lancera et si toutes les conditions sont réunies, votre blog se mettra à jour, et un tweet sera posté !

 

Le dépôt GitHub du projet est à jour, et possède déjà quelques issues que j'avais trouvé sur les scripts et que je dois corriger. Si vous utilisez les scripts, et que vous trouvez des bugs, n'hésitez pas à me les remonter, je corrigerais ça rapidement !

 

J'ai parlé récemment d'un script qui permet de poster automatiquement un tweet quand je publie un nouvel article sur le blog.

Ce script a été un peu modifié puisqu'il fait aujourd'hui 4 choses :

  1. Il vérifie si un nouvel article a été écrit (en cherchant la présence du message [POST] au début du message de commit Git) ;
  2. Dans ce cas, il envoie les nouveaux commits sur le dépôt Git défini par défaut ;
  3. Il met à jour le blog sur le serveur via SSH (command make ssh_upload pour les Pelican-eux) ;
  4. Il envoie un tweet.

Tout ça c'est sympa, mais c'est un peu con d'automatiser toutes ces étapes si il faut au final lancer le script à la main. La magie de Git fait qu'on peut automatiser tout ça en utilisant les hooks de Git.

Ces hooks sont des scripts que Git lance après (ou avant) certaines étapes de son processus. Ils sont listés dans le répertoire .git/hooks/ :

╭────<quack@spiderman >───< ~/Documents/writing/blog/quack1_pelican > ‹master*› ╰───[18:52:40] $ ls .git/hooks applypatch-msg.sample post-commit pre-applypatch.sample prepare-commit-msg.sample update.sample commit-msg.sample post-update.sample pre-commit.sample pre-rebase.sample

Je ne vais pas tous les faire, les noms sont assez explicites, mais par exemple pre-commit est lancé avant le commit.

Mon script a besoin que le commit soit terminé, donc j'ai fait pointer le fichier .git/hooks/post-commit sur le script. Toute la configuration nécéssaire est placée dans le fichier de conf, donc le script se lance sans souci :

╭────<quack@spiderman >───< ~/Documents/writing/blog/quack1_pelican > ‹master*› ╰───[18:53:14] $ ln -s ~/work/workspace/python/pelican_auto_tweet/pelican_auto_tweet.py .git/hooks/post-commit

Désormais dès que vous ferez un commit dans ce dépôt Git, le script se lancera et si toutes les conditions sont réunies, votre blog se mettra à jour, et un tweet sera posté !

 

Le dépôt GitHub du projet est à jour, et possède déjà quelques issues que j'avais trouvé sur les scripts et que je dois corriger. Si vous utilisez les scripts, et que vous trouvez des bugs, n'hésitez pas à me les remonter, je corrigerais ça rapidement !

Depuis un bon moment déjà j'écris tout en Markdown. Ce blog — et l'autre —, mes notes (avec RedNotebook entre autres), et encore plein d'autres choses de cette façon. Seul le boulot et sa suite Office me résistent encore 😋 !

Pour écrire tout ça j'utilise Sublime Text, qui est un excellent éditeur de texte. Véritable IDE, il est à la base dédié à l'édition de code source.

Du coup, quand on veut écrire du texte dedans, c'est pas super agréable...

L'avantage de Sublime-Text, c'est que chaque utilisateur peut redéfinir des préférences, qui surchargent celles par défaut. Et cerise sur le gâteau, on peut redéfinir des préférences pour chaque extension de fichiers! Et c'est justement cette fonctionnalité qui m'intéresse.

Maintenant, quand j'écris du Markdown, ça ressemble à ça :

Pour modifier la configuration de Sublime Text, ouvrez un fichier Markdown (chez moi avec l'extension .md), et allez dans PréférencesSettings - MoreSyntax Specific - User.

Mon fichier de configuration ressemble à ça :

{ "extensions": [ "md" ], "auto_complete": true, "spell_check": true, "dictionary": "Packages/Language - French - Français/fr_FR (all variants).dic", "draw_centered": true, "word_wrap": "True", "wrap_width": 80, "font_size": 9, "gutter": false, "line_numbers": false, "line_padding_bottom": 2, "line_padding_top": 2, "scroll_past_end": true, "tab_size": 6 }

Ligne par ligne, qu'est ce que ça fait :

  • "extensions" désigne les extensions pour lesquelles ce fichier s'applique ;
  • "auto_complete" active la complétion automatique avec <TAB> ;
  • "spell_check" active la vérification orthographique ;
  • "dictionary" pointe sur le dictionnaire à utiliser pour la vérification orthographique (les dictionnaires proviennent de Libre Office) ;
  • "draw_centered" centre le texte dans la fenêtre ;
  • "word_wrap" coupe les lignes lors de l'affichage après X caractères ;
  • "wrap_width" désigne le nombre de caractères avant de couper la ligne ;
  • "font_size" défini la taille de la police de caractères ;
  • "gutter" je ne sais pas ce que ça fait, mais c'est défini à false dans le mode Distraction Free, donc je pense que ce n'est pas mauvais... ;
  • "line_numbers" désactive l'affichage du nombre de lignes, mais je songe à le réactiver... ;
  • "line_padding_bottom"et "line_padding_top" ajoutent de l'espacement au-dessous et au-dessus des lignes de texte, pour l'aérer ;
  • "scroll_past_end" permet de faire défiler le texte même quand on arrive à la fin du fichier ;
  • "tab_size" augmente le nombre d'espaces à utiliser pour les tabulations (en réalité Sublime Text utilise bien le caractère <TAB>, mais cette tabulation est affichée pour quelle corresponde à 6 espaces).

Plus d'options sont disponibles dans la doc de Sublime Text. Je ne pense pas avoir pensé à tout, si vous trouvez comment améliorer encore cette configuration, n'hésitez pas!

Depuis un bon moment déjà j'écris tout en Markdown. Ce blog — et l'autre —, mes notes (avec RedNotebook entre autres), et encore plein d'autres choses de cette façon. Seul le boulot et sa suite Office me résistent encore 😋 !

Pour écrire tout ça j'utilise Sublime Text, qui est un excellent éditeur de texte. Véritable IDE, il est à la base dédié à l'édition de code source.

Du coup, quand on veut écrire du texte dedans, c'est pas super agréable...

L'avantage de Sublime-Text, c'est que chaque utilisateur peut redéfinir des préférences, qui surchargent celles par défaut. Et cerise sur le gâteau, on peut redéfinir des préférences pour chaque extension de fichiers! Et c'est justement cette fonctionnalité qui m'intéresse.

Maintenant, quand j'écris du Markdown, ça ressemble à ça :

Pour modifier la configuration de Sublime Text, ouvrez un fichier Markdown (chez moi avec l'extension .md), et allez dans PréférencesSettings - MoreSyntax Specific - User.

Mon fichier de configuration ressemble à ça :

{ "extensions": [ "md" ], "auto_complete": true, "spell_check": true, "dictionary": "Packages/Language - French - Français/fr_FR (all variants).dic", "draw_centered": true, "word_wrap": "True", "wrap_width": 80, "font_size": 9, "gutter": false, "line_numbers": false, "line_padding_bottom": 2, "line_padding_top": 2, "scroll_past_end": true, "tab_size": 6 }

Ligne par ligne, qu'est ce que ça fait :

  • "extensions" désigne les extensions pour lesquelles ce fichier s'applique ;
  • "auto_complete" active la complétion automatique avec <TAB> ;
  • "spell_check" active la vérification orthographique ;
  • "dictionary" pointe sur le dictionnaire à utiliser pour la vérification orthographique (les dictionnaires proviennent de Libre Office) ;
  • "draw_centered" centre le texte dans la fenêtre ;
  • "word_wrap" coupe les lignes lors de l'affichage après X caractères ;
  • "wrap_width" désigne le nombre de caractères avant de couper la ligne ;
  • "font_size" défini la taille de la police de caractères ;
  • "gutter" je ne sais pas ce que ça fait, mais c'est défini à false dans le mode Distraction Free, donc je pense que ce n'est pas mauvais... ;
  • "line_numbers" désactive l'affichage du nombre de lignes, mais je songe à le réactiver... ;
  • "line_padding_bottom"et "line_padding_top" ajoutent de l'espacement au-dessous et au-dessus des lignes de texte, pour l'aérer ;
  • "scroll_past_end" permet de faire défiler le texte même quand on arrive à la fin du fichier ;
  • "tab_size" augmente le nombre d'espaces à utiliser pour les tabulations (en réalité Sublime Text utilise bien le caractère <TAB>, mais cette tabulation est affichée pour quelle corresponde à 6 espaces).

Plus d'options sont disponibles dans la doc de Sublime Text. Je ne pense pas avoir pensé à tout, si vous trouvez comment améliorer encore cette configuration, n'hésitez pas!

Je ne suis pas du genre à taper sur Ubuntu. Pour tout vous dire, même si j'aime beaucoup Ubuntu, je ne suis pas encore arrivé au stade « Fanboy ». Du coup, quand je vois des trucs bien chiants sur Evince, le lecteur de PDF par défaut d'Ubuntu, je n'hésite pas à en faire un billet.

La cause ? Plein de régressions sur cet outil, qui est pourtant super pratique.

L'avantage d'Ubuntu, et des distributions Linux en général, c'est d'arriver avec plein d'outils pré-installés. En particulier, Evince, le lecteur de PDF, est (ou plutôt était) parfait : léger, complet, et avec pas mal de fonctionnalités.

Sur Ubuntu 13.10, il est installé en version 3.10.

Dans cette version, très épurée, les menus ont disparus, et tout est regroupé dans la barre d'outils située en haut du logiciel.

Tout ça, c'est bien beau, ça rend le logiciel plus beau, plus rapide, plus léger, ce que vous voulez, mais ça a un très gros défaut.

Au moment de la génération d'un PDF, on peut spécifier des options à rajouter au fichier, pour par exemple demander au logiciel qui ouvrira ce fichier de ne pas afficher les barres d'outils, et de mettre un zoom à X%.

Et du coup, dans ce cas là, j'y accède comment moi à la barre de menus ?

Voilà le résultat avec l'excellent GKND :

On l'a bien profond, parce qu'il n'y a même pas de raccourci clavier pour afficher cette barre d'outils. Et pour couronner le tout, la doc n'est même pas à jour, donc aucune possibilité de trouver une solution à ça. C'est un peu con, parce que j'ai pas vraiment envie de devoir installer un nouvel outil pour faire ça.

Comme on dit : EPIC FAIL

Je ne suis pas du genre à taper sur Ubuntu. Pour tout vous dire, même si j'aime beaucoup Ubuntu, je ne suis pas encore arrivé au stade « Fanboy ». Du coup, quand je vois des trucs bien chiants sur Evince, le lecteur de PDF par défaut d'Ubuntu, je n'hésite pas à en faire un billet.

La cause ? Plein de régressions sur cet outil, qui est pourtant super pratique.

L'avantage d'Ubuntu, et des distributions Linux en général, c'est d'arriver avec plein d'outils pré-installés. En particulier, Evince, le lecteur de PDF, est (ou plutôt était) parfait : léger, complet, et avec pas mal de fonctionnalités.

Sur Ubuntu 13.10, il est installé en version 3.10.

Dans cette version, très épurée, les menus ont disparus, et tout est regroupé dans la barre d'outils située en haut du logiciel.

Tout ça, c'est bien beau, ça rend le logiciel plus beau, plus rapide, plus léger, ce que vous voulez, mais ça a un très gros défaut.

Au moment de la génération d'un PDF, on peut spécifier des options à rajouter au fichier, pour par exemple demander au logiciel qui ouvrira ce fichier de ne pas afficher les barres d'outils, et de mettre un zoom à X%.

Et du coup, dans ce cas là, j'y accède comment moi à la barre de menus ?

Voilà le résultat avec l'excellent GKND :

On l'a bien profond, parce qu'il n'y a même pas de raccourci clavier pour afficher cette barre d'outils. Et pour couronner le tout, la doc n'est même pas à jour, donc aucune possibilité de trouver une solution à ça. C'est un peu con, parce que j'ai pas vraiment envie de devoir installer un nouvel outil pour faire ça.

Comme on dit : EPIC FAIL

24 Octobre 2013 à 09:00

The Trusty Tahr débarque ! via Ubuntuser

À peine Ubuntu 13.10 est-elle sortie que débute un nouveau cycle de développement. The Trusty Tahr occupera la presse linuxienne durant les six mois à venir et inaugure la route vers ce qui sera la prochaine version à durée de vie étendue (LTS). Vendredi dernier, Mark Shuttleworth, le "sabdfl" d'Ubuntu, a dévoilé dans l'un de ses habituels billets où il s'amuse avec les allitérations le nom de code utilisé pour le cycle de développement qui s'amorce : "The Trusty Tahr", que l'on peut traduire en français par "le tahr sûr". Shuttleworth fait explicitement référence au tahr de l'Himalaya, un cousin du bouc et du chamois originaire d'Asie. En 1936, deux tahrs se sont évadés d'un zoo d' Afrique du Sud -- le pays d'origine de Shuttleworth -- et ont fondé une petite population dans la montagne de la Table. Tahr de l'Himalaya... dans l'Himalaya Comme de coutume, le choix d'un animal emblématique annonce les couleurs qui teinteront les objectifs de la prochaine version d'Ubuntu. Perché sur les hauts terrains escarpés, le tahr est symbole d'assurance, mais aussi de hardiesse et d'intrépidité ; il évoque donc les deux faces que prendra ce cycle de développement. Du côté des postes de travail et des serveurs, Ubuntu 14.04 LTS se concentrera sur le raffinement, maintenabilité et la performance -- avec peut-être comme seul grand changement l’arrivée de XMir (mais ce n'est pas encore confirmé). Du côté des terminaux mobiles, le développement est trop jeune pour se limiter à ces objectifs, et continuera sa progression vers l'atteinte de la convergence des plate-formes (téléphone, tablette, téléviseurs et ordinateurs), avec une version mobile stabilisée et plus complète et peut-être une première version pour tablette. D'autres surprises pourraient faire également parler d'elles : un possible premier téléphone ayant déjà Ubuntu Touch préinstallé et un premier aperçu de la future version d'Unity 8 sur postes de travail.  

Dépôts ouverts, images ISO prêtes : en route vers le vUDS

À peine le nouveau nom dévoilé, les dépôts sont maintenant ouverts, initialisant réellement le cycle de développement, a annoncé Matthias Klose, ingénieur logiciel chez Canonical. Les premières images ISO du média d'installation portant la patte du tahr sont aussi apparues dans le serveur cdimage.ubuntu.com. Pour le moment, les différences avec Ubuntu 13.10 sont extrêmement minimes. Une synchronisation des paquets en provenance de Debian Unstable est actuellement en cours. Ceci pave donc la voie vers le prochain (virtual) Ubuntu Developer Summit, la rencontre en ligne où les différents acteurs du développement d'Ubuntu discutent des grands axes du prochain cycle. Le prochain vUDS aura lieu du 19 au 21 novembre 2013, de 14h à 20h UTC. À l'heure d'écrire ces lignes, la grille des activités est pratiquement vide -- seule la plénière est annoncée. Surveillez l'horaire fréquemment : il devrait rapidement s'étoffer !

J'ai quelques billets en cours qui sont juste des petites astuces, relativement faciles à trouver sur Internet, mais que je préfère garder au chaud ici!

Premier truc, concernant apt — le système de gestion de paquets sur Debian, pas les attaques ciblées ;-).

Quand on fait ses mises à jour et installations de paquets depuis des miroirs des dépôts officiels, on peut obtenir l'erreur « E: Release file expired, ignoring http://debian.mirror.localhost/repo_bin/dists/sid/Release (invalid since 14h 31min 45s) », qui est levée si le fichier Release, présent à la racine du dépôt, n'est pas à jour. Ce fichier Release permet de vérifier l'intégrité des paquets téléchargés sur le dépôt.

Si vous n'avez pas la main sur le miroir, mais que vous lui faites quand même confiance et que souhaitez tout de même installer vos paquets depuis cette source, vous pouvez demander à apt de ne pas vérifier la validité du fichier Release :

$ apt-get -o Acquire::Check-Valid-Until=false update

Si vous avez accès à un shell sur la machine qui gère les miroirs, à priori c'est plutôt simple de regénérer le fichier Release, il suffit de recréer le miroir avec un debmirror, mais je n'ai jamais tenté.

 

Via StackExchange Unix

J'ai quelques billets en cours qui sont juste des petites astuces, relativement faciles à trouver sur Internet, mais que je préfère garder au chaud ici!

Premier truc, concernant apt — le système de gestion de paquets sur Debian, pas les attaques ciblées ;-).

Quand on fait ses mises à jour et installations de paquets depuis des miroirs des dépôts officiels, on peut obtenir l'erreur « E: Release file expired, ignoring http://debian.mirror.localhost/repo_bin/dists/sid/Release (invalid since 14h 31min 45s) », qui est levée si le fichier Release, présent à la racine du dépôt, n'est pas à jour. Ce fichier Release permet de vérifier l'intégrité des paquets téléchargés sur le dépôt.

Si vous n'avez pas la main sur le miroir, mais que vous lui faites quand même confiance et que souhaitez tout de même installer vos paquets depuis cette source, vous pouvez demander à apt de ne pas vérifier la validité du fichier Release :

$ apt-get -o Acquire::Check-Valid-Until=false update

Si vous avez accès à un shell sur la machine qui gère les miroirs, à priori c'est plutôt simple de regénérer le fichier Release, il suffit de recréer le miroir avec un debmirror, mais je n'ai jamais tenté.

 

Via StackExchange Unix

Pages