Installation de Festival TTS sur Debian

Last update : April 9, 2015

Suite à l’installation du système Festival TTS sur mon MacBook Air il y a trois mois, je viens de l’installer sur mon laptop avec système d’exploitation Debian 7 Linux. Les différentes archives du système Festival ont été téléchargées et décomprimées avec ARC.

Décompression d'un archive Festival

Décompression d’une archive Festival

J’ai suivi ensuite la même procédure que sur Mac OSX, à savoir

  • création d’un répertoire Festival-TTS sur le desktop avec les sous-répertoires festival, speech_tools et festvox
  • compilation des programmes dans l’ordre speech_tools, festival, festvox
  • installation des voix et dictionnaires dans les sous-répertoires lib/voices et lib/dicts du répertoire festival
Configuration du

Configuration du programme speech_tools

La compilation du programme speech_tools s’est arrêtée avec les messages d’erreur

/usr/bin/ld: cannot find -lcurses
/usr/bin/ld: cannot find -lncurses

L’installation de la bibliothèque libncurses5-dev a réglé ce problème. La suite de la compilation s’est passée sans autres erreurs, abstraction faite de plusieurs avertissements concernant des variables spécifiées, mais non utilisées .

Il a été possible de démarrer le programme Festival avec la commande

/Desktop/Festival-TTS/festival/bin/festival

mais la synthèse d’une phrase de test

festival> (SayText "Hello, how are you")

a produit l’erreur

Linux: can't open /dev/dsp

Parmi les remèdes trouvés sur le net, j’ai opté pour la solution

apt-get install oss-compat
modprobe snd-pcm-oss

qui a été couronnée de succès.

Il ne restait plus que la configuration des différents chemins d’accès pour mettre le système Festival tout à fait opérationnel. Les commandes suivantes ont été ajoutées au script ~/.bashrc :

FESTIVALDIR="/home/mbarnig/Desktop/Festival-TTS/festival"
FESTVOXDIR="/home/mbarnig/Desktop/Festival-TTS/festvox"
ESTDIR="/home/mbarnig/Desktop/Festival-TTS/speech_tools"
PATH="$FESTIVALDIR/bin:$PATH"
PATH="$ESTDIR/bin:$PATH"
export PATH
export FESTIVALDIR
export FESTVOXDIR
export ESTDIR
Pat

Variables d’environnement et PATH du système Festival

Ca marche!

Lancement

Lancement du programme Festival TTS sur Debian Linux Wheezy

Le chargement respectivement la compilation d’une nouvelle voix, comme le luxembourgeois, ne réussit que si la voix anglaise kal_diphon est présente, si non une erreur “unbound variable rfs_info” se produit.

Raspberry Pi

Dernière mise à jour : 23 janvier 2016

Le Raspberry Pi est un nano-ordinateur monocarte à processeur ARM développé par la fondation Raspberry Pi. Cet ordinateur, qui a la taille d’une carte de crédit, est destiné à encourager l’apprentissage de la programmation informatique; il permet l’exécution de plusieurs variantes du système d’exploitation libre GNU/Linux et des logiciels compatibles. Seule la carte mère nue est fournie, sans boîtier, alimentation, mémoire, clavier, souris ni écran, afin de diminuer les coûts et de permettre l’utilisation de matériel de récupération.

Ordinateur Raspberry Pi modèle B

Ordinateur Raspberry Pi modèle B

Raspberry Pi

Les ordinateurs Raspberry Pi et les accessoires afférents sont disponibles auprès de différents distributeurs et revendeurs, parmi eux Amazon. Fin 2015, il y  a quatre modèles disponibles : PI 1 A+, PI 1 B+, PI 2 B et PI Zero. Dans le passé il y avait encore les modèles PI 1 A et PI 1 B.

La documentation officielle est disponible sur le site web de la fondation. Je dispose d’un ensemble d’ordinateurs Raspberry Pi modèle B rev. 2 (2011.12), avec des modules de caméra Raspicam et des kits Bright Pi 1.0. Les caractéristiques principales sont présentées ci-après :
Ordinateur :

  • System on a chip (SoC) processeur : Broadcom BCM2835, 700 MHz (ARM, distribution armhf)
  • RAM : 512 MByte
  • Carte mémoire : Full SD
  • Ethernet : 10/100 Mbits
  • HDMI port : 1
  • USB 2.0 ports : 2
  • Composite video output : Cinch
  • Audio output : 3,5 mm audiojack
  • Camera interface CSI-2 : 1
  • LCD display interface DSI : 1
  • Extensions : 26
  • Nombre de GPIO (general purpose input/output) : 17
  • Alimentation : microUSB, 5 Volt, 700 mA

Caméra :

  • Sensor : OmniVision OV5647
  • Résolution : 2.592 x 1.944 pixels
  • Focus : fixe >= 1m
  • Vidéo : 1080p30, 720p60 and 640x480p90

Bright Pi v1.0 :

  •  interface I2C
  • 4 LED’s bright white
  • 8 LED’s Infrarouge

Raspbian

Comme j’utilise déjà Debian sur un autre ordinateur, je me suis décidé d’installer la version Debian adaptée au Raspberry Pi, appelée Raspbian, sur mes nano-ordinateurs.

Carte mémoire 8GB reformatée

Carte mémoire 8GB reformatée

Le système d’exploitation Raspbian, les autres logiciels et les données sont enregistrés sur une carte mémoire SD 8GB classe 10. Comme ma carte SD n’était pas vierge, mais formatée sur un autre système, la procédure de reformatage classique ne fonctionnait pas.

J’ai procédé comme suit dans le terminal de commande Windows :

diskpart
list disk
select disk 1
clean
format fs=FAT32 quick
assign

Pour installer le système d’exploitation sur la carte mémoire, j’ai utilisé l’outil Win32DiskImager. La version la plus récente est 0.9.5. Les instructions comment procéder” sont disponibles sur le site web de l’organisation Raspberry Pi.

Outil Win32DiskImager

Outil Win32DiskImager

Raspicam

J’ai connecté le module camera (Raspicam) à la platine Raspberry PI sur base des instructions de set-up données sur le site web de Raspberry. Les caractéristiques sont indiquées dans les détails techniques. La caméra a été fixée sur un support spécifique.

Raspicam avec support

Raspicam avec support

Des bibliothèques (logiciels) pour piloter la caméra sont disponibles pour bash et pour Python. Les trois commandes de base en ligne pour gérer la caméra sont :

Les détails des commandes sont décrits dans l’API du module Raspicam.

Bright Pi

Bright-Pi module

Bright-Pi module

Bright Pi est un kit d’éclairage pour ajouter à la caméra Raspicam, développé par Pi Supply. Le module comprend 4 LED’s Cree blanches puissantes et 8 LED’s Liteon infrarouge.

J’étais un supporteur du projet Bright Pi sur Kickstarter.

Les éléments du module sont fournis séparément, il faut soi-même les assembler et souder. Les instructions d’assemblage et de programmation sont disponibles sur le site web de Pi-Supply.

Bright Pi utilise le bus I2C pour échanger des données avec le Raspberry Pi moyennant le chip Semtech SC620 (voir datasheet). Pour activer le bus I2C dans Raspian, il faut ajouter les deux lignes

i2c-bcm2708
i2c-dev

à la fin du fichier /etc/modules. Pour ce faire, on peut utiliser l’éditeur nano sur Raspberry Pi. Pour sauver le fichier modifié, on pousse <Ctrl>+o, ensuite <Ctrl>+x pour quitter l’éditeur. La prise en compte des nouveaux modules se fait lors d’un reboot. Pour installer les outils i2c, il faut entrer les commandes

pi@raspberrypi ~ $ sudo apt-get install python-smbus
pi@raspberrypi ~ $ sudo apt-get install i2c-tools

Pour voir les modules connectés, on peut entrer la commande

pi@raspberrypi ~ $ sudo i2cdetect -y 1
Détection des modules connectés au bus I2C

Détection des modules connectés au bus I2C

On voit qu’un seul module avec l’adresse 0x70 est connecté, le Bright Pi. Pour piloter le module Bright Pi, on utilise la commande

i2cset [-y] i2cbus chip-address data-address value

Les paramètres sont :

  • -y : option pour désactiver le mode interactif (pas de confirmation nécessaire)
  • i2cbus : 1
  • chip-address : 0x70
  • data-address : 0x00 LED’s on/off; 0x01, 0x03, 0x06, 0x08 dimming IR LED’s couples; 0x02, 0x04, 0x05, 0x07 dimming white LED’s; 0x09 gain register
  • value : dimming values : 6 bit multipliers; gain values :0000 = 31,25 microampère; 1111 = 500 microampère; max = 25 millampère par LED

Quelques exemples sont montrés ci-après :

white LED1 12 mA : sudo i2cset -y 1 0x70 0x02 ...
white LED2 1 mA :
white LED3 
...

Clavier

Comme alimentation, j’utilise le chargeur d’une tablette qui fournit 2 ampères à 5 Volt. Lors de la première mise sous tension, le Raspberry se configure automatiquement. Il ne reconnaît toutefois pas le layout de mon clavier luxembourgeois QWERTZ (respectivement français-suisse) et il faut le modifier manuellement comme suit :

pi@raspberrypi ~ $ sudo raspi-config
raspi-config

raspi-config

Le menu 4 (International Options) donne accès sélections “Change Locale”, “Change Timezone” et “Change Keyboard Layout”. Mon clavier Microsoft Wired Keyboard 600 ne fait pas partie des claviers figurant dans la liste déroulante des modèles de clavier. J’ai choisi le clavier Generic 105-key (Intl) PC. Un layout luxembourgeois n’est pas relevé, le layout du clavier français-suisse figure parmi les layouts allemands. Faut le savoir !

Via le menu 4 on peut également changer le fuseau horaire (le Luxembourg figure sur la liste des pays européens) et la langue d’affichage, par exemple pour passer en français.

Remote Desktop

Avant de pouvoir entrer des commandes il faut faire un login au système. Les paramètres par défaut pour le login sont : user name = pi ; password = raspberry. L’adresse IP attribuée par DHCP est 192.178.1.60. Pour pouvoir piloter dans l’avenir ce Raspberry, et dans la suite ses confrères, à partir de mes ordinateurs connectés en réseau local, j’ai installé le service RDP (Remote Desktop Protocol) de Microsoft sur le Raspberry Pi :

pi@raspberrypi ~ $ sudo apt-get install xrdp

Après un redémarrage du Raspberry (commande sudo reboot ou sudo poweroff), le serveur xrdp sesman est configuré pour démarrer automatiquement lors de chaque mise sous tension.

Sur les ordinateurs Windows, le service RDP est disponible d’office et peut être démarré avec le menu Accessories/Remote Desktop Connection.

Microsoft Remote Desktop Connection

Microsoft Remote Desktop Connection

Après l’établissement de la connexion, le Raspberry retourne un avertissement

Avertissement

Avertissement RDP

et ensuite la fenêtre de login suivante (module sesman-Xvnc) :

XRDP Login Window

XRDP Login Window

Ici on découvre le prochain bug. Le clavier français-suisse de mon PC Windows n’est pas supporté par le service xrdp, mais il est interprété comme un clavier anglais. Il faut donc saisir le mot de passe raspberrz au lieu de raspberry pour réussir le login. Faut le savoir !

Support du clavier français-suisse par xrdp

Linux xrdp utilise par défaut le fichier keymap /etc/xrdp/km-0409.ini (us-english) si un fichier keymap non-existant est demandé. Il semble que le client Windows xrdp demande le keymap 20409 non disponible, indépendamment du clavier connecté. Le seul remède consiste à remplacer dans Raspian le fichier km-0409.ini par le contenu du fichier keymap du clavier utilisé. Dans mon cas il s’agit du fichier km-100c.ini (voir liste des keymaps).

On peut générer ce fichier avec la commande

pi@raspberrypi ~ $ sudo xrdp-genkeymap /etc/xrdp/km-100c.ini

Attention : il faut toutefois passer en mode graphique avec la commande startx et ouvrir le LXTerminal pour passer la commande, si non on obtient le message d’erreur << unable to open display ” >>.

Cliquez sur le fichier km-100c.ini pour visualiser son contenu. Il faut encore modifier le code de quelques touches qui ne sont pas reconnus correctement. Il s’agit notamment des combinaisons <alt-gr> et des touches curseur :

  • @
  • #
  • ~
  • ¢
  • ¬
  • up

Les touches mortes (dead keys) fonctionnent correctement.

Il suffit ensuite de renommer le fichier km-0409.ini en km-0409-old.ini et de copier le fichier km-100c.ini en km-0409.ini. Faut le savoir !

Applications

Après vérification de l’authenticité de l’usager, le desktop du Raspberry se présente sur l’écran et réagit aux commandes du clavier et de la souris.

Raspberry Pi's Desktop

Raspberry Pi’s Desktop

Les programmes et applications installés d’office sur le Raspberry Pi sont :

Je me propose d’ajouter les programmes suivants :

Pour activer la caméra, il faut passer dans le menu 5 (Enable Camera) de raspi-config. Pour tester la caméra et faire une première photo, on entre la commande

pi@raspberrypi ~ $ raspistill -o camtest1.jpg

Si la caméra est positionnée à l’envers, il faut tourner l’image de 180 degrés. Cela se fait aisément avec les options “vertical flip” et “horizontal flip”.

pi@raspberrypi ~ $ raspistill -vf -hf -o camtest2.jpg

Liens

Les liens suivants fournissent des informations additionelles concernant des projets Raspberry et le clavier XRDP :

Historique de Tux Droid

Last update : 24 mars 2022

Note: En date du 1er septembre 2020 j’ai enlevé tous les liens qui ne sont plus disponibles sur Internet. J’ai assemblé tous mes fichiers relatifs à Tuxdroid dans l’archive tuxdroid-archive.zip disponible ici sur mon site web.

Présentation de Tux Droid

Tux Droid est un compagnon intelligent, c.à.d. un objet communiquant programmable sous Linux. Son aspect extérieur représente Tux, la mascotte de Linux. Tux Droid peut se tourner sur lui-même, battre les ailes, bouger le bec, fermer les paupières, clignoter les yeux (LED’s), enregistrer (microphone) et restituer (haut parleur) des sons, recevoir et émettre des commandes IR (infrarouge), capter l’intensité de luminosité et capter la pression de boutons sur la tête et dans les ailes.  Il dispose d’une batterie rechargeable et d’un dongle USB, assurant une liaison sans-fil (non WiFi) avec un ordinateur. Le dongle a la forme d’un poisson et il est appelé Fux. Tux Droid est souvent comparé au Nabaztag. Il a été créé par la société belge Kysoh SA en 2006.

Tux Droid et Fux

Tux Droid et Fux

La version beta de Tux Droid a été présentée la première fois par Kysoh à la conférence OSCON 2006 (Open Source Convention) à Portland, Oregon, en juillet 2006. Le premier guide d’usager est archivé ici. La commercialisation de Tux Droid en Europe a débuté en mars 2007. Les sources de l’architecture, du matériel et du logiciel ont été ouvertes dès le début et mises en ligne sur le site web communautaire www.tuxisalive.com. Des outils de développement ont été fournis pour permettre à des développeurs de créer leurs propres applications.

La société Kysoh (Keep your sense of humor) avait été fondée pendant l’été 2005, en collaboration avec l‘Ecole Polytechnique de Mons, avec pour objectif de développer et de commercialiser des produits électroniques connectés à un PC et dédiés au divertissement. Les fondateurs de Kysoh étaient Thierry Nancy et Sébastien Domingues. L’équipe marketing était constituée de Frank Aernout, Mélanie Chamaah et Awa M’Baye. Les ingénieurs, programmeurs et infographistes étaient, par ordre alphabétique, Jean-Luc Bernard, David Bourgeois, Jérôme Conan, Julien Depasse, Pascal Hanon, Rémi Jocaille, Raphael Lamy, Paul Rathgeb (alias ks156), Olivier Vandorpe et Sebastiaan Vanpoucke.

Tux Droid en magasin

Tux Droid en magasin

Au début, la vente de Tux Droid se faisait exclusivement par Internet via le magasin en ligne de Kysoh. Dans la suite, Tux Droid était également vendus sur d’autres sites de commerce électronique comme Amazon, Thinkgeek etc, dans des magasins électroniques et même dans des grandes surfaces comme la FNAC en France et le Kaufhof en Allemagne.

La société Kysoh était très active au niveau marketing. Le 14 février 2008, Tux Droid était présenté au Brussels Girl Geek Dinner. Le 9 décembre 2008 Tux Droid a rejoint Facebook. L’année suivante et au début 2010, Tux Droid faisait la une de nombreux magazines informatiques et il était présent dans de nombreux salons et émissions TV.

Malgré ces efforts, le 28 juillet 2010,  la société Kysoh SA, située à Mons (Henegouwen), a été déclarée en liquidation judiciaire par le tribunal de Bergen en Belgique et les sites web kysoh.com et tuxisalive.com ont été fermés. Le curateur s’est retrouvé avec un stock de 3.700 Tux Droid’s à écouler.

Matériel de Tux Droid

L’électronique de Tux Droid contient une carte mère en charge des fonctions audio, capteurs, moteur et chargement batterie ainsi qu’une carte secondaire en charge de la communication sans fil avec le dongle USB. Le matériel est construit autour de trois modules : core, audio et radio. Ces modules sont interconnectés par un bus bi-directionnel SPI entre les modules radio et audio et par un bus bi-directionnel I2C entre les modules audio et core.

Modules de Tux Droid

Modules de Tux Droid

Les modules core et audio sur la carte mère sont gérés chacun par un processeur ATmega88 de Atmel. Le module radio contient un microcontrôleur RF ATR2406 de Atmel et un processeur ATmega48 de Atmel. Le dongle USB dispose d’un microcontrôleur RF AT89C5130 de Atmel. Côté radio, les puces RF exploitent la bande de fréquences 2.4Ghz, ce qui dans certains cas peut provoquer des interférences avec le WiFi et perturber la connexion du PC avec un routeur, le cas échéant. La firmware des trois processeurs et des deux microcontrôleurs peut être modifiée.

Une télécommande est jointe au Tux Droid et permet de le commander, respectivement d’agir sur les applications du PC par son intermédiaire.

La version V1 de Tux Droid a été vendue jusqu’en mi 2008, ensuite c’était la version 2 qui avait une meilleure qualité du plastique et un nouveau firmware.

Firmware de Tux Droid

La firmware du Tuxdroid peut être mise à jour pour les deux versions, mais elle n’est pas sans risques. La première étape consiste à mettre à jour le dongle USB (poisson Fux). Ensuite on connecte le câble de programmation blanc entre le dongle et Tux Droid. Le connecteur est situé à l’arrière de Tux Droid, il faut enlever le couvercle de batterie pour y accéder. Pour démarrer Tux Droid en mode bootloader, il faut appuyer le bouton de tête pendant la mise sur “on” de l’interrupteur. Uniquement l’œil gauche sera allumé pour confirmer l’état souhaité. La mise à jour du firmware des cinq processeurs de Tux Droid se fait ensuite avec des outils particuliers (TuxUp). La version la plus récente du firmware est 0.9.4, elle date du 3 décembre 2013.

Logiciels originaux de Tux Droid

L’ensemble des logiciels de Tux Droid a été appelé TDSS (Tux Droid Software Suite); il est considéré aujourd’hui comme une usine à gaz.

En mars 2007, une première version de l’architecture logicielle (V1), dédiée à Linux, a été développée et évaluée par les utilisateurs finaux. Elle a été programmée en python et GTK (api et software) et en C (daemon).

En avril 2008, le développement de la seconde version (V2) de l’ensemble des logiciels a commencé. Il s’agissait d’une réécriture en profondeur se reposant sur l’expérience accumulée par l’équipe des ingénieurs et programmeurs. Cette version était construite autour d’un serveur donnant accès aux fonctionnalités du compagnon par des requêtes HTTP. Cette suite logicielle, bâtie autour d’un Centre de Contrôle, fonctionnait sur Linux et Windows. Elle était programmée essentiellement en Java, avec quelques parties en Python (webradio et serveur HTTP) et C (Tuxdriver).

Au début de l’année 2009, un refactoring complet de la suite logicielle v2 a été entamé. Le 1er septembre 2009, la troisième version (V3) a été mise en ligne, incluant une toute nouvelle interface graphique appelée TuxBox 2.0, ainsi qu’un système de gadgets plus puissant. Cette version était basée sur un serveur web. Les langages utilisés étaient Python, Java, C et C++.

Suite à la liquidation judiciaire de Kysoh fin juillet 2010, les développements des logiciels originaux ont été arrêtés.

Le répertoire Ohloh de la société Black Duck Software révèle qu’entre mars 2006 et juillet 2010, 27 programmeurs ont contribué au développement des suites logiciel pour Tux Droid. Le code total généré dans le dépôt http://svn.tuxisalive.com/ comprend 1.432.377 lignes plus 493.816 lignes de commentaires. 6.107 révisions (commits) ont été enregistrées dans le dépôt. Les langages de programmation utilisés sont le Python (38%), le Java (23%), le C (21%)  et d’autres (18%). Sur base du Constructive Cost Model (COCOMO), l’effort de programmation total du projet est évalué à 404 personnes * années, ce qui équivaut à un coût estimé de 22 millions $.

Communauté Tux Droid

Tux Droid a toujours eu une communauté très active se reposant solidement sur Kysoh. Après la fermeture des sites web kysoh.com et tuxisalive.com, la communauté s’est organisée pour sauver les meubles. Des miroirs ont été créés pour sauvegarder les précieux paquets open source et la documentation y associée de Tux Droid. Avec la complicité d’anciens programmeurs de Kysoh, les sources et paquets des logiciels originaux ont été migrés fin août 2010 vers SourceForge.

Site web tuxdroid-community.org

www.tuxdroid-community.org

Au début c’était Anti-Bug-Computers qui était très engagée dans la récupération des données de Kysoh. Ensuite floOr a créé en octobre 2010 le forum tuxdroid-community.org; shadow89 a lancé le 16 décembre 2010 le site web tuxdroid-community.net. Le 19 mars 2011 les deux sites ont fusionné et un  nouveau projet SVN a été ouvert sur Sourceforge.

Le site web www. tuxdroid-community.org est devenu dans la suite le site unique de la communauté Tux Droid. Le site a été refait sous Drupal en septembre 2011 et comporte aujourd’hui un forum, un wiki en français et anglais avec une partie de l’ancien wiki de Kysoh, une archive avec les sources et sites web récupérés de Kysoh et une rubrique pour présenter le nouveau projet TuxDroidServer. Le site est administré par Edouard Postel (alias floOr); le forum est modéré par Joël Matteotti (alias Joe). En juin 2013 des soirées IRC (chat) ont été organisées pour répondre à des questions sur Tux Droid, mais elles n’ont pas rencontré le succès escompté.

Synthèse vocale (TTS)

L’ensemble TDSS incluait des librairies de Acapela pour la synthèse vocale et Kysoh payait les licences pour la distribution de ces librairies avec Tux Droid. L’utilisation des fichiers sons produits par la synthèse vocale d’Acapela est autorisée à des fins privés, mais la distribution des bibliothèques ou des sons n’est pas libre et réglée par des conditions spécifiques. Ce problème légal n’a pas facilité la reprise des logiciels de Kysoh par la communauté Tux Droid. Comme les clés d’exploitation des bibliothèques Acapela étaient partiellement intégrées au code, la situation était encore plus problématique. Les sources avec les interfaces (libtuxosl) Acapela ont été enlevées.

Une des priorités de la Communauté Tux Droid en 2010 était donc le remplacement de la synthèse vocale Acapela par une autre solution.

TuxBox 2.0

A la fin de l’été 2009, Kysoh avait sorti la nouvelle interface de pilotage plus pratique pour le Tux Droid, la Tuxbox 2.0, basée sur une interface web, qui remplacait l’ancien centre de contrôle. Cette interface fonctionne encore ajourd’hui. Les binaires de la TuxBox 2.0 (version 3.1.4)  pour Linux et Windows, les sources ainsi que le guide d’usager afférent sont disponibles sur le site de la communauté Tux Droid.

L’nstallateur Windows distribué est crédité à Akasanvas95, avec l’aide de Anti-Bug-Computers, Steph138 et Anthrax132.

Sur Windows, TuxBox 2.0 s’installe dans le répertoire C:/Program Files/Kysoh/. Après le démarrage, l’icône d’une patte rouge (pied d’un manchot) est affichée dans la barre des tâches en bas à droite. Cette patte passe en jaune si Fux est connecté et si la communication sans fil avec Tux Droid est établie. Si on clique sur l’icône, la fenêtre de la TuxBox est affichée. L’état de la TuxBox est indiqué avec des petits symboles dans la patte jaune, par exemple son coupé (voir figure suivante à droite) ou Tux Droid actif.

TuxBox 2.0

Icônes d’état de la TuxBox 2.0 dans la barre inférieure du desktop Windows

La fenêtre principale (Vivre avec Tux) de la TuxBox, qui est une page web locale (http://127.0.0.1:270), accédée via le port 270,  présente quatre autres volets :

  • Gadgets : ce sont des mini-applications (plugins comprimés avec extension .scp) hébergées sur l’ordinateur qui fournissent des informations personalisées telles que e-mails, prévisions météorologiques, nouvelles, etc.
  • Attitunes : ce sont des animations robotiques combinant des mouvements, des sons et de la synthèse vocale. Elles apportent une touche sympathique aux fonctions des gadgets.
  • Outils : ce sont des programmes pour configurer Tux Droid (par exemple créer des attitudes)
  • Magasin en ligne : c’est le dépôt de téléchargement central des gadgets
TuxBox 2.0 pour Tux Droid

TuxBox 2.0 pour Tux Droid

La barre des icônes affiche les gadgets installés.Tux Droid prononce le nom de chaque gadget sélectionné. On peut faire défiler les gadgets avec la souris, la télécommande ou en appuyant sur les ailes de Tux Droid. La majorité des gadgets nécessite d’être configuré, ce qui peut se faire dans la rubrique “Gadgets” du menu supérieur. Les attitunes installées sont gérées dans la rubrique “Attitunes”. La rubrique “Outils” donne accès à Attitune Studio pour créer et modifier des attitudes, au Controller pour commander en direct les mouvements de Tux Droid ainsi qu’à des pages de configuration et d’aide.

Tux Droid Attitude Studio and Tux Droid Controller

Tux Droid Attitune Studio and Tux Droid Controller

La rubrique “Magasin en ligne” permettait dans le passé de  télécharger des nouveaux gadgets. Cette fonction n’est plus opérationnelle. Le wiki “How To List” de la communauté Tux Droid contient des informations comment programmer un nouveau gadget (plugin) : Hello World, Python, Java, Google Gadget, … et comment l’installer ensuite dans la TuxBox 2.0. Les anciens gadgets sont encore disponibles dans les archives sur le site de la communauté.

Le fonctionnement et l’affichage de la TuxBox 2.0 sous Linux sont similaires à ceux de Windows. Sur Linux, ce sont les distributions originales de Kysoh qui sont disponibles. Le port 54321 est utilisé par défaut pour l’accès au serveur HTTP.

Un problème de la TuxBox 2.0 est le fait qu’il n’y a plus d’adaptations et on constate de plus en plus souvent des incompatibilités avec les évolutions de Windows et Linux. Sous Windows, on arrive dans certains cas à faire fonctionner TuxBox 2.0 sur une version récente en mode “administrateur” ou en mode “compatibilité XP / Vista”. Sur Linux, il faut être un utilisateur chevronné pour trouver des solutions en cas de problème.

La communauté a donc cherché des solutions pour assurer la pérennité de Tux Droid.

TuxDroidServer et TuxDroidClient

Joël (Joe) Matteotti a démarré en juin 2012 le développement d’un nouveau projet baptisé TuxDroidServer. Il s’agit d’un serveur TCP multiclients/multithreads, programmé en ANSI-C99 et intégrant son ancien projet TuxDroidInterface. Il utilise par défaut le port 9595 pour la communication. Ce projet a été très bien accueillie par la communauté Tux Droid.

Une année plus tard, presque jour sur jour, Joe a créé son propre blog sous le domaine tux-droid.eu pour mieux présenter l’évolution de son projet, tout en continuant à modérer le forum communautaire Tux Droid.

Le grand avantage de TuxDroidServer est sa portabilité, car il se compile aussi bien sous Windows que sous GNU/linux, sans modification du code, et il est aussi portable au sens où il ne nécessite aucune installation. La synthèse vocale est basée sur le projet open source espeak. La version la plus récente (révision 153) du code a été déposée début décembre 201.

Les grandes étapes du développement de TuxDroidServer sont :

  • 7.6.2012 : première version basée sur l’ancien projet TuxDroidInterface rev34
  • 10.6.2012 (rev 9 à 12) : entre autres, ajout des commandes Tux_Micro() pour la gestion du micro et Tux_Audio() pour la lecture de musique
  • 12.6.2012 (rev 17) : ajout de la commande Tux_PlayAtt() permettant la lecture d’attitunes
  • 13.6.2012 (rev 21) : entre autres, ajout d’un fichier de configuration
  • 19.6.2012 (rev 24) : ajout d’un système d’authentification
  • 21.6.2012 (rev34) : ajout d’un petit shell pour démarrer et arrêter le serveur
  • 23.6.2012 (rev 39) : entre autres, ajout des commandes Tux_Sleep() et Tux_Wakeup()
  • 23.7.2012 (rev 49) : ajout d’un logger
  • 28.7.2012 (rev 55) : entre autres, ajout des commandes Tux_Remote() et Tux_User()
  • 28.8.2012 (rev 61) : entre autres, ajout de la commande Tux_Timestamp()
  • 17.9.2012 (rev 67) : ajout des commandes Tux_getMicro() et Tux-getSoundCard()
  • 15.1.2013 (rev 71) : création d’une nouvelle branche du projet qui utilise PortAudio
  • 7.2.2013 (rev 79) : ajout d’un système d’identification et de gestion des priorités
  • 30.5.2013 (rev 96) : ajout du framework unittests
  • 8.8.2013 (rev 122) : entre autres, ajout d’un système de traduction pour rendre TuxDroidServer multilingue
  • 20.9.2013 (rev 141) : entre autres, ajout de la reconnaissance vocale basée sur Google Speech API
  • 27.11.2013 (rev 151) : introduction de l’obligation d’entrer l’identifiant
TuxDroidClient alpha version

TuxDroidClient alpha version

Pour faire fonctionner TuxDroidServer, on a besoin du driver Tux Droid. La version la plus récente est 0.0.6 rev30.

Joe a également réalisé en QT/C++ une application graphique (GUI), nommée TuxDroidClient, permettant de contrôler un Tux Droid géré par TuxDroidServer.

Des binaires pour la version 7 de TuxDroidClient et de la version 150 de TuxDroidServer sont disponibles pour Windows 32bits. Un tarball Linux de la version 150 est également disponible pour processeurs Intel 32 bits.

Applications Android pour Tux Droid

Une première application Android pour commander Tux Droid a été développée en octobre 2009 par r3gis. Joe a également développé une application Android en juin 2012. Il vient de la mettre à jour à la version 1.3.0.

Situation en 2022

Sur le forum ubuntu.fr une communauté intéressée au TuxDroid est toujours active. Il y a également un nouveau site web tuxdroid.tounepi.com mis à jour.

Liens

Quelques liens avec des informations additionnelles au sujet de Tux Droid sont relevés dans la liste qui suit :

Debian Linux

Last update: December 25, 2021

En 2012 j’ai installé avec succès la distribution Debian Linux sur un ancien notebook Sony Vaio, avec clavier AZERTY, 1 MB RAM et processeur Centrino Duo. Dans le cadre d’un projet j’étais amené à compiler une librairie Java complexe sur base d’un fichier Rakefile. Comme la compilation échouait sous Windows XP, Vista et 7, je cherchais d’autres solutions pour progresser. Comme le créateur du fichier Rakefile effectuait ses développement sous Linux, je privilégiais la piste d’installation d’un nouveau système de développement Linux sur un ordinateur séparé comme première solution.

Linux

Linux est le nom couramment donné à tout système d’exploitation libre fonctionnant avec le noyau Linux. Le noyau Linux a été créé en 1991 par Linus Torvalds pour les compatibles PC construits sur l’architecture processeur x86. Depuis, il a été porté sur de nombreuses architectures et il est utilisé dans une très large gamme d’ordinateurs, de serveurs et de systèmes embarqués. Ses caractéristiques principales sont d’être multitâche et multi-utilisateur. Linux bénéficie d’une communauté de milliers de programmeurs qualifiés qui font évoluer le noyau et les paquets.

Commandes Linux

Linux dispose de centaines, voire de milliers de commandes. Une vue d’ensemble des commandes Linux les plus importantes a été publiée en 2021 par PC & Network Downloads (PCWDLD).

Linux Commands Cheat Sheet (PCWLDL)

PCWLDL publie des tutoriels et revues et fournit des conseils dans le domaine des technologies d’information, en particulier en relation avec des applications Linux/Ubuntu/Centos/Unix/Cisco etc.

Distributions Linux

Il existe plusieurs distributions Linux différentes, par exemple :

Debian Linux

Comme la distribution Debian est à l’origine de différentes autres distributions et considérée comme très stable, j’ai choisi cette variante de Linux pour la création du système de développement. Il y avait trois versions Debian à l’époque : stable = Squeeze, testing = Wheezy, development = Sid disponibles pour 12 architectures. La version Wheezy disponible il y a un an était 7.2, publiée le 12 octobre 2013. En 2015, la  version stable est Jessie.

J’avais téléchargé les images ISO officielles pour DVD pour l’architecture i386. Il s’agit des fichiers suivants :

  • debian-7.2.0-i386-DVD-1.iso
  • debian-7.2.0-i386-DVD-2.iso
  • debian-7.2.0-i386-DVD-3.iso
  • debian-update-7.2.0-i386-DVD-1.iso

Les fichiers ont été gravés sur DVD avec le programme Free ISO Burner. J’ai démarré le notebook Sony Vaio avec la première DVD installé dans le lecteur et suivi les instructions sur l’écran. Les fichiers iwlwifi-3945-1.ucode et iwlwifi-3945-2.ucode ont été demandés lors de l’installation. J’ai cherché ces deux fichiers sur Internet et chargé sur un stick USB. Les autres DVD ont été scannés par le système et l’insertion de l’une ou l’autre DVD dans le lecteur a été demandé en fonction de l’installation des différents paquets. J’ai du répéter l’installation plusieurs fois à cause d’erreurs de manipulation (try and error). Finalement le système était opérationnel et le desktop se présentait comme suit :

Debian Linux Desktop

Debian Linux Desktop

Je viens de faire début novembre 2014 la mise à jour de Wheezy sur la version 7.7 édité le 18 octobre 2014. Une mise à jour de maintenance a été effectuée le 4 avril 2015.

Signalisation de la disponibiltié d'un update

Signalisation de la disponibilité d’un update

Software Update

Software Update

Display Manager

Debian Linux supporte trois gestionnaires d’affichage principaux :

Lors du login, je peux choisir les gestionnaires suivants :

  • GNOME (= default)
  • GNOME Classic
  • KDE Plasma Workspace

Je préfère le gestionnaire GNOME pour l’affichage.

Permissions et Sécurité

Dans Linux tout fichier se voit attribuer des droits pour 3 identités :

  • le propriétaire – l’utilisateur qui a créé le fichier ou l’utilisateur que root a désigné comme propriétaire
  • le groupe (qui n’est pas forcément le groupe du propriétaire)
  • les autres (ceux qui ne font pas partie du groupe)

Pour chaque identité il existe 3 droits d’accès :

  • r – read (le droit de lecture)
  • w – write (le droit d’écriture)
  • x – execute (le droit d’exécution)

La commande ls -l nous permet d’afficher les droits d’un fichier. La commande chmod (CHangeMODe) permet de définir et de changer les droits d’accès d’un fichier ou d’un ensemble de fichiers. L’option -R permet de traiter les répertoires de façon récursive.

Lors de l’installation de Linux, on met en place au moins deux comptes :

  • Le compte root dont le nom est «root» et à qui on attribue un mot de passe. C’est le Superutilisateur ou l’administrateur du système.
  • Un compte utilisateur auquel on peut attribuer n’importe quel nom («mbarnig» par exemple).

La commande whoami affiche le nom du compte. En mode utilisateur, le terminal affiche l’invité de commande

mbarnig@debian:~$

A condition de connaître le mot de passe de «root», un utilisateur peut devenir super-utilisateur et tout faire sur le système, en entrant la commande su, validée par “Enter”. Le mot de passe est demandé, et après la saisie correcte, le terminal affiche l’invité de commande

root@debian:/home/mbarnig#

La commande sudo (Substitute User Do) est similaire, mais les droits sont plus limités. On n’a pas besoin d’entrer le mot de passe «root». En outre, la validité du rôle «root» est limité dans le temps, il y a une expiration automatique après 15 minutes.

gksu

commande gksu

Pour utiliser des applications graphiques en mode «root», on a recours aux commandes gksu et gksudo. Une autre manière de devenir superutilisateur est d’ouvrir le terminal «root». Pour quitter le mode «root», on entre la commande exit. Pour suspendre le système, on utilise le menu Suspend. Pour arrêter le système, on presse simultanément Ctrl-Alt-Del, afin d’afficher la fenêtre Power-Off.

Structure des fichiers

Linux voit ses disques comme une unique arborescence. Une partition contient la racine du système de fichier, qu’on note /. D’autres partitions (CD-ROM, memory stick, …) peuvent être montées dans des répertoires. La structure standard des répertoires est décrite par le FHS (Filesystem Hierarchy Standard).

Les répertoires racine sur mon système Debian sont :

  • bin – contient les commandes de base nécessaires au démarrage et à l’utilisation d’un système minimaliste
  • boot – contient les informations nécessaires au démarrage de la machine
  • dev – contient les fichiers spéciaux correspondant aux périphériques
  • etc – contient la plupart des fichiers de configuration
  • home – contient les répertoires personnels des utilisateurs. L’utilisateur mbarnig a pour répertoire /home/mbarnig (alias Home)
  • lib – contient les principales bibliothèques partagées
  • lost+found – contient les fragments de fichiers perdus après la réparation d’un disque endommagé
  • media – point de montage pour les médias amovibles
  • mnt – point de montage pour les systèmes de fichiers temporaires
  • opt – contient les logiciels commerciaux
  • proc – contient des fichiers avec des infos sur l’état du système et des processus en cours d’exécution
  • root – contient le répertoire de l’administrateur système
  • run – répertoire non standard pour centraliser les fichiers résidant en mémoire
  • sbin – contient les commandes de base nécessaires à l’administration système
  • selinux – Linux security module (LSM) qui permet de définir une politique de contrôle d’accès
  • srv – contient des données pour les services hébergés sur le système
  • sys – contient des données relatives au nouveau système de fichiers virtuels
  • tmp – contient les fichiers temporaires
  • usr – (UNIX System Resources) : contient des répertoires semblables à ceux présents à la racine mais qui ne sont pas nécessaires au fonctionnement minimal du système
  • var – contient des données fréquemment réécrites

Pour naviguer à la racine on utilise la commande

cd /

Pour chercher un fichier, on utilise les commandes

root path    : find / -name "filename"
current path : find . -name "filename"

On peut utiliser le joker (l’étoile *) avec des noms de fichier incomplets.

L’occupation du disque est indiquée avec le Disk Usage Analyzer.

Linux Disk Usage Analyzer

Path

Les commandes qu’on écrit au clavier dans le shell sont cherchées dans l’ordre des répertoires contenus dans la variable PATH. Son contenu est une chaîne qui contient les chemins des répertoires séparés par deux-points (:). Pour afficher le contenu de la variable PATH, on utilise la commande

echo $PATH

Sur mon système le contenu se présente comme suit, avec les options de formatage


mbarnig@debian:~$ echo $PATH | tr : \\n
/usr/local/sbin
/usr/local/bin
/usr/sbin
/usr/bin
/sbin
/bin

Il a plusieurs scripts d’initialisation qui définissent les variables d’environnement, comme le PATH. Les plus usuels sont :

  • /etc/bash.bashrc  : script valable pour tous les utilisateurs, exécuté par une shell interactive lancée dans une session existante
  • /etc/profile  : script valable pour tous les utilisateurs, exécuté par une shell login qui demande UserID/Password, par exemple pour accéder au Desktop Debian lors du démarrage du système
  • ~/.bashrc  : script valable pour l’utilisateur identifié, exécuté par une shell interactive
  • ~/.profile  :script valable pour l’utilisateur identifié, exécuté par une shell login

Le caractère tilde ( ~ ) est utilisé pour spécifier le répertoire home d’un usager, comme par exemple /home/mbarnig. L’interprète de commande effectue la substitution

~/hello.txt  >> /home/mbarnig/hello.txt
~/hi.txt >> /home/hi.txt

Les scripts /etc/bash.bashrc, ~/.bashrc, etc/profile et ~/.profile sont des fichiers cachés qui ne sont visibles qu’avec l’option “show hidden files” dans le menu de l’explorateur de fichiers. La modification d’un fichier dans le répertoire /etc/ n’est possible qu’en “root”, par exemple avec la commande

gksu nautilus /etc/profile

Une shell login recherche les scripts ~/.bash_profile, ~/.bash_login et ~/.profile dans cet ordre. Par défaut, les deux premiers fichiers (~/.bash_profile et ~/.bash_login) ne sont pas présents sur Debian.

Une shell non-interactive est activée par un programme et n’exécute aucun des scripts énumérés ci-avant. Les usagers qui souhaitent utiliser la même configuration pour les shells logon et non-login peuvent charger (source) le script ~/.bashrc dans le script ~/.profile, respectivement le script /etc/bash.bashrc dans le script /etc/profile.

J’ai opté pour inclure tous les variables d’environnement (PATH, …) dans le script ~/bashrc. Ce script est lu le premier si on ouvre le terminal standard en tant que usager, c.à.d. si on n’est pas “root”.

Environnement de développement

J’ai installé les paquets ruby, rake, java, gcc et g++ avec les commandes suivantes dans le terminal de commande root :

root@debian:/home/mbarnig# apt-get install ruby1.9.1
root@debian:/home/mbarnig# apt-get install rake
root@debian:/home/mbarnig# apt-get install default-jdk
root@debian:/home/mbarnig# apt-get install gcc
root@debian:/home/mbarnig# apt-get install g++
root@debian:/home/mbarnig# apt-get install subversion
root@debian:/home/mbarnig# apt-get install scons
root@debian:/home/mbarnig# apt-get install libfltk1.3

En outre les paquets suivants ont été installés de la même manière : autoconf, automake, xorg-dev, freeglut3-dev. Pour tester l’environnement de développement, des programmes Hello World ont été compilés dans différentes langues de programmation.

Java

Le code suivant a été écrit avec l’éditeur gedit et enregistré comme fichier HelloWorld.java dans le répertoire Home/Java.

public class HelloWorld {
public static void main(String[] args) {
System.out.println("Hello, World");
}
}

Avec la commande

mbarnig@debian:~$ javac HelloWorld.java

dans l’application Terminal, le programme a été compilé en HelloWorld.class. Le programme est exécuté ensuite avec

mbarnig@debian:~$ java HelloWorld

La compilation de la librairie Java avec le fichier Rakefile a été également exécutée correctement, en invoquant la commande rake dans le répertoire en question.

C++


Le code suivant a été écrit avec l’éditeur gedit et enregistré comme fichier helloworld.cpp dans le répertoire Home/C++.

#include <iostream>
using namespace std;
int main()
{
cout << "hello world\n";
return 0;
}

Avec la commande

mbarnig@debian:~$ g++ helloworld.cpp -o helloworld

dans l’application Terminal, le programme a été compilé en exécutable helloworld. Le programme est exécuté ensuite avec

mbarnig@debian:~$ ./helloworld

Gestion des paquets

Un paquet est un logiciel ou une partie d’un logiciel, qui a été préparé dans un format spécial, afin de faciliter sa recherche, la consultation d’informations à son sujet, ainsi que son installation et sa désinstallation. Ce paquet prend la forme d’un fichier avec un nom particulier : nom-du-logiciel_numéro-de-version_nom-de-l’architecture.deb. Un fichier paquet contient les binaires du programme ainsi qu’un certain nombre d’en-têtes. Le système de gestion des paquets de Debian est très performant et très facile à utiliser. Grâce à lui, les logiciels s’installent, se retirent et peuvent être mis à jour très facilement.

La commande de base pour manipuler des paquets Debian est dpkg. Elle ne peut toutefois pas télécharger des fichiers ou gérer des dépendances. Pour installer un paquet .deb disponible on utilise la commande

dpkg --install nom_paquet.deb

Lors de l’installation les différentes étapes et les erreurs éventuelles sont affichées. L’installation peur s’effectuer en deux temps comme suit

dpkg --unpack nom_paquet.deb
dpkg --configure nom_paquet.deb

On peut obtenir des informations sur les paquets avec les options suivantes :

  • dpkg –listfiles nom_paquet  (sans .deb) : liste des fichiers installés par un paquet
  • dpgk –search file : paquet d’où provient ce fichier
  • dpkg –status nom_paquet.deb : entêtes d’un paquet installé
  • dpkg –list : liste des paquets connus du système
  • dpkg –contents nom_paquet.deb : liste des fichiers contenus dans un paquet non-installé
  • dpkg –info nom_paquet.deb : entêtes d’un paquet non-installé
  • dpkg –remove nom_paquet.deb : suppression d’un paquet installé, sans les dépendances et fichiers de configuration
  • dpkg –purge nom_paquet.deb : suppression d’un paquet installé, avec les dépendances et fichiers de configuration

La commande dpkg tient un journal verbeux de toutes ses actions dans /var/log/dpkg.log.

À un niveau plus élevé, on trouve les commandes apt et apt-get (advanced package tool) tout comme un outil plus récent aptitude qui peut être utilisé en mode console où en mode graphique. aptitude est la commande recommandée pour gérer les paquets. On peut toutefois mélanger les commandes aptitude det apt-get. Une autre interface graphique est Synaptic.

Synaptic

Synaptic Package Manager

Une ancienne interface qui n’est plus recommandée est DSelect.

apt a besoin qu’on lui fournisse une liste de sources de paquets : c’est le fichier /etc/apt/sources.list qui décrira les différents emplacements (ou sources) publiant des paquets Debian. La liste des sites web miroirs qui distribuent les paquets Debian est disponible sur le site web de l’organisation Debian. Les archives Debian au Luxembourg sont hébergées sur les sites web debian.mirror.root.lu/ (root S.A.) et debian.mirror.lhisp.com/ (lhisp Luxembourg Hosting)

Un générateur en-ligne d’une liste source Debian est disponible sur le site web debgen.simplylinux.ch. Mon fichier /etc/apt/sources.list se présente comme suit :

deb http://ftp.de.debian.org/debian stable main 
contrib non-free
deb http://ftp.debian.org/debian/ wheezy-updates main 
contrib non-free
deb http://security.debian.org/ wheezy/updates main 
contrib non-free

Création d’un paquet .deb

Un paquet Debian n’est pas seulement une archive de fichiers destinés à l’installation, mais il contient également des méta-informations pour gérer les dépendances, les conflits, les suggestions, l’installation et la suppression des fichiers. Le fichier-méta le plus important est control. Un exemple simple pour intégrer le programme helloworld dans un paquet .deb est présenté ci-après :

Package: helloworld
Version: 1.0
Installed-Size: 1024
Maintainer: Marco Barnig - mbarnig@pt.lu
Architecture: i386
Section: custom
Priority: optional
Essential: no
Filename: helloworld.deb
Depends: bash
Description: affiche le texte "hello world" sur l'écran

Les paquets plus complexes utilisent en outre les paramètres suivants :

Recommends: dépendances facultatives (liste des paquets 
dont l'installation est recommandée pour que le système 
fonctionne correctement)
Suggests: autres dépendances facultatives 
Conflicts: liste des paquets qui peuvent entrer en conflit 
avec le paquet 
à installer 
Tag: clés de recherche 
Size: taille du paquet 
MD5sum: empreinte digitale du paquet (sécurité)

En plus du fichier control, le paquet Debian peut contenir un certain nombre de fichiers et de scripts appelés par dpkg à différentes étapes du traitement du paquet. Il s’agit des fichiers suivants :

preinst - ce script est exécuté préalablement l'installation 
du paquet
postinst - ce script est exécuté après l'installation 
du paquet
md5sums - liste des empreintes numériques de tous les 
fichiers du paquet
conffiles - liste des fichiers de configuration

Pour assembler le paquet, un répertoire mon_paquet est créé avec le contenu suivant :

/DEBIAN/control
/usr/bin/helloworld

Ensuite on peut générer le paquet avec la commande dpkg-deb :

dpkg-deb --build mon_paquet

On peut répertorier le nouveau paquet dans le répertoire Home avec la commande

find -name mon_paquet.deb

et l’installer avec la commande

dpkg -i mon_paquet.deb

Mise à jour

Le système de paquets utilise sa propre base de données pour garder une trace des paquets qui sont installés, de ceux qui ne sont pas installés et de ceux qui peuvent être installés. Le programme apt-get utilise cette base de données pour retrouver comment installer les paquets demandés par l’utilisateur ainsi que pour retrouver les paquets supplémentaires nécessaires afin qu’un paquet sélectionné fonctionne correctement. Pour mettre à jour cette liste, on utilise la commande

apt-get update

Cette commande vérifie la liste des paquets trouvés dans les archives dans /etc/apt/sources.list. La mise à niveau de paquets est effectuée avec la commande

apt-get upgrade

L’option -u oblige apt à afficher la liste complète des paquets qui seront mis à niveau.
Pour faire la mise à jour vers une nouvelle distribution, on utilise la commande

apt-get dist-upgrade

(distribution-upgrade). Cette commande est aussi utilisée pour faire la mise à niveau dans les dépendances des paquets installés. Les commandes

apt-get clean
apt-get autoclean

sont utilisées pour supprimer des paquets non-utilisés. Pour afficher la version installé d’une distribution Debian, on utilise la commande

cat /etc/debian_version

ou

lsb_release -a

De Wheezy à Jessie

La version 8.0 de Debian, connue sous le nom de Jessie, a été initialement publiée le 26 avril 2015. La version 8.6 a été publiée le 17 septembre 2016. Comme mon système actuel avait un problème de démarrage, j’ai du réinstaller fin 2016 la version originale de Debian 7 (Wheezy) à partir de mes DVD’s. Pour activer le WiFi, j’ai copié le fichier iwlwifi-3945-ucode à l’emplacement /lib/firmware. Ensuite j’ai procédé à un update / upgrade de Wheezy, suivi d’un changement de version en remplaçant “Wheezy” par “Jessie” dans la liste “/etc/apt/sources.list“.

Pour aller dans le mode terminal, entrez ctrl+alt+f1. Pour retourner dans le mode graphique, entrez ctrl+alt+f7.

Liens

La liste suivante fournit des liens vers des sites web avec des informations utiles au sujet de Linux :

MEDION Combirecorder DVD & Video

Dernière mise à jour: 24 février 2020

Medion Combirecorder DVD – VHS

J’utilise l’enregistreur DVD (Digital Versatile Disc) & magnétoscope VHS (Video Home System) MD 83425 de MEDION pour copier des cassettes VHS sur un DVD et ensuite le convertir en format mpeg 4.

Le mode d’emploi est le suivant (avec télécommande) :

  1. Insertion de la cassette vidéo à copier
  2. Insertion d’un DVD-R vierge
  3. Position STOP en poussant 2 fois sur la touche Stop
  4. Ouverture du menu SETUP et sélection de l’option REGLAGES GENERAUX
  5. Sélection de l’option ENREGISTREMENT > MODE DUPLICATION > VCR -> DVD
  6. Fermeture du menu pricipal en poussant sur la touche Setup
  7. Sélection du mode VCR
  8. Position de la cassette avec Play, Forward ou Backward à l’endroit du début de la copie
  9. Position de la cassette en mode PAUSE
  10. Sélection du mode DVD
  11. Sélection de la qualité d’enregistrement avec REC SPEED (entre 1 heure et 8 heures, 2 heures est la durée standard DVD)
  12. Lancement de la copie en poussant sur la touche DUBBING
  13. Arrêt de l’enregistrement en poussant sur la touche Stop
  14. Répétition des actions 7 à 13 pour copier d’autres séquences
  15. Finalisation du DVD-R en sélectionnant l’option FINALISATION dans le menu SETUP > DVD (un DVD-RW n’a pas besoin d’être finalisé pour le lire sur un autre lecteur)

Pour parcourir une cassette VHS en vitesse, on peut activer F.FORWARD pendant le PLAY.

Les formats .package et .sims3pack de Sims 3

Sims 3 utilise deux formats pour regrouper les fichiers avec les resources et données du jeu :

  • les fichiers .package sont les fichiers du jeu eux-même
  • les fichiers .sims3pack sont de mini-executables contenant un ou plusieurs .package

Pour télécharger des contenus en format .package,  il faut installer le fichier Resource.cgf dans le répertoire:

C > Program Files > Electronic Arts > Les Sims 3.

et les fichiers téléchargés dans le répertoire :

C > Program Files > Electronic Arts > Les Sims 3 > Mods > Packages > dossier 1 > dossier 2 > dossier 3  (maximum 3 niveaux de sous-dossiers)

Le logiciel Install Helper Monkey permet d’installer d’une façon conviviale les téléchargements au format .package.
En double-cliquant sur un fichier .sims3pack, l’utilitaire associé (le lanceur du jeu Sims 3) installe les données au bon endroit. Pour enregistrer les données d’uen façon plus contrôlée, on peut recourir au programme S3PME.

La 3D débarque sur le web !

Dernière mise à jour : 1 août 2018

Atmo Logo

Le lundi 26 mars 2001, Adobe Systems Incorporated avait levé le voile sur un système 3D interactif pour le web qui avait le potentiel de révolutionner l’Internet. Le système s’appellait Atmosphere, utilisait la technologie de streaming 3D de Viewpoint (Metastream), permettait d’importer des personnages et objets animés dans Poser ProPack 4 de Curiouslabs et se basait sur l’expérience de pionniers dans le domaine des mondes virtuels 3D comme Digitalspace. Atmosphere intégrait en outre différentes technologies de pointe développées par des créateurs ingénieux et des petites start-up.

Le jour de l’annonce publique, Adobe a démarré une phase de test beta à couverture mondiale. Le lancement commercial du système était prévu pour l’automne 2001.

Comme la technologie 3D était ma passion depuis plusieurs années, j’ai eu l’opportunité de pouvoir participer dès le début aux tests beta et d’avoir accès aux forums et ressources de développement Atmosphere. J’avais arrangé mon congé de façon à pouvoir participer au test beta pendant une semaine. J’ai été le premier amateur 3D à créer son propre monde virtuel sur mon site web hébergé par P&T Luxembourg et à le présenter à la communauté des développeurs Atmosphere. C’était le mercredi 28 mars 2001 à 5h42am (pacific time), deux jours après le lancement de la phase de test beta.

Présentation du système Atmosphere

Le système Atmosphere se composait de quatre éléments:

  • un navigateur 3D qui peut-être utilisé comme stand-alone ou comme plug-in dans un navigateur classique Explorer ou Netscape
  • un serveur de communication utilisant un nouveau protocole de communication basé sur IRC et qui s’appelle yacp
  • un outil de création de mondes virtuels 3D Adobe Atmosphere
  • un ensemble d’outils fournis par des sociétés tierces pour modéliser des objets géométriques en 3D, créer des textures et des images, animer des personnages, composer de la musique, enregistrer, traiter et comprimer des sons etc.

Pour avoir une première idée des possibilités et performances du système Atmosphere, il faut s’imaginer que cette technologie permettait de se mettre dans la peau de Lara Croft et d’explorer des mondes 3D virtuels interactifs comme dans les jeux Tomb Raider. La fascination du système Atmosphere consistait dans le fait qu’on n’était pas seul dans le monde virtuel 3D, mais qu’on pouvait y rencontrer d’autres usagers représentés par des personnages animés (Avatars) et de dialoguer et d’interagir avec eux.

Place d’Armes Virtuelle

Les figures qui suivent présentent un exemple des possibilités que Atmosphere offrait au début des années 2000 pour réaliser des mondes virtuelles. La Place d’Armes avait été réalisée en 3D avec un réalisme étonnant.



Les prochaines figures montrent des outils disponibles à l’époque pour créer des terrains en 3D, pour les importer dans Adobe Atmosphere et pour les optimiser afin de garantir un affichage parfait.






Atmosphere a passé la majorité de son existence en version bêta, car ce n’est qu’en février 2004 que Adobe présentait la première version (build 216) de son nouveau produit pour le web 3D émergent.

Malgré les avances technologiques de cet outil de création de mondes virtuels en 3D, le produit Adobe Atmosphere n’a jamais connu un vrai lancement commercial et a été abandonné le 19 décembre 2004.