Le lundi 1 octobre 2007 à 22:57
Vous ajoutez un répertoire au PATH, ou bien un exécutable à l'un des chemins du PATH. Cependant, cela ne fonctionne pas et, habitué de Bash, vous vous arrachez les cheveux !
Solution : csh possède un hash des exécutables accessibles. Il faut donc bien penser à lancer la commande rehash après avoir ajouté une commande au PATH...
Le lundi 4 décembre 2006 à 20:11
Les mystères de l'informatique : lorsque mon Mac essaie de se connecter en SSH sur mon serveur domestique (une UltraSPARC sous Ubuntu Linux), il se fait jeter comme un malpropre : « connection closed », sans message de debug explicite, que ce soit sur le client ou le serveur. Ceci alors qu'un autre client (Cygwin) n'a aucun souci pour se connecter...
Après quelques recherches sur des forums, j'ai fini par découvrir que d'autres utilisateurs de Mac avaient le même problème, et qu'il suffisait de rajouter les IP des clients à problèmes dans le fichier /etc/hosts du serveur. Ça marche, mais vous conviendrez que c'est pour le moins troublant.
D'autant plus que tout fonctionnait jusqu'à ce que j'installe Netatalk (serveur AFP) et Avahi (protocole Bonjour) sur l'UltraSPARC... Je suppose que cela m'a conduit à installer un module d'authentification qui trouble les connexions... Cette hypothèse est d'autant plus plausible que j'observe le même genre de comportements sur mon serveur IMAP.
Des explications ?
Le lundi 18 septembre 2006 à 19:36
J'utilisais depuis des lustres un Cygwin/X en tant client XDMCP avec une ligne de commande du type :
XWin -xkblayout fr-latin9 -xkbmodel pc104 -query ...
Après une mise à jour de Cygwin, le clavier a brusquement refusé de passer en layout français. Pour ceux qui auraient la même mésaventure, les « bonnes » options semblent être :
XWin -xkblayout fr -xkbmodel pc105
Pour information, la ligne de commande complète est :
XWin -xkblayout fr -xkbmodel pc105 -query mon_serveur -fullscreen -depth 16
Ça me permet d'avoir un affichage plein écran, et des couleurs sur 16 bits, ce qui me semble être un bon compromis entre qualité de rendu et débit réseau.
D'un point de vue plus personnel, les posts ont été rares ce mois-ci, et j'ai du retard dans mes e-mails : c'est que j'ai été bien occupé, avec notamment la fourniture de mon mémoire de thèse à mes rapporteurs. Hé oui ça progresse !
Le samedi 5 août 2006 à 22:53
Soit le problème « ferroviaire » suivant :
Ce billet explique comment y arriver simplement, à l'aide d'un petit script en Ruby et de Gnuplot.
Le lundi 1 mai 2006 à 17:41
J'ai eu un peu de temps pour faire fonctionner ma carte de test PIC18F/USB sous Linux. Cela fonctionne très bien, à condition d'utiliser le bon pilote. Il s'agit de cdc_acm (CONFIG_USB_ACM), disponible sous le nom « USB Modem (CDC ACM) Support ». Une fois le driver chargé, la carte est reconnue automatiquement lors de la connexion. Cela crée un périphérique (/dev/ttyACM0[1]) avec lequel Minicom[2] (par exemple) permet de dialoguer.
Dans le log système, on retrouve des messages du type :
usb 2-1: new full speed USB device using uhci_hcd and address 5 drivers/usb/class/cdc-acm.c: This device cannot do calls on its own. It is no modem. cdc_acm 2-1:1.0: ttyACM0: USB ACM device
Il est à noter qu'Ubuntu (Dapper Drake) possède par défaut le driver, donc ça fonctionne out-of-the-box (on branche et zou ! Minicom !). Je ne comprends pas comment ça se fait qu'il faille un fichier .inf à Windows, parce que visiblement, ce périphérique se déclare comme étant de la bonne classe...
Le mardi 11 avril 2006 à 22:52
J'ai changé de serveur à la maison : je suis passé d'un vieux x86 (Celeron à 533 MHz) à une vieille sparc64 (UltraSparc II à 440 MHz). J'ai donc dû transplanter mon serveur IMAP Cyrus. Ce billet donne des détails sur l'opération. Il s'agit avant tout d'une référence personnelle (l'installation de Cyrus est toujours un peu délicate), mais cela doit pouvoir profiter à d'autres, à condition d'adapter les chemins. La distribution utilisée est une Ubuntu Dapper.
Le mercredi 29 mars 2006 à 23:21
Je déplorais récemment la lenteur (au moins, la lenteur ressentie) de Linux. On m'a donné, et j'ai découvert, quelques pistes d'amélioration :
init sont en développement : pinit (mais les commits sur le CVS semblent vieux de 3 ans) et InitNG (qui semble beaucoup plus actif). Elles devraient permettre le lancement en parallèle de plusieurs services, d'où, on peut l'espérer, un démarrage bien plus rapide ;Le vendredi 24 mars 2006 à 22:32
J'ai fait quelques essais avec une station Sun Ultra 10 que j'ai récupérée. Comme ce n'est pas forcément évident lorsqu'on arrive du monde PC, voici quelques petites notes qui permettent de commencer...
Sur une Sun, le programme de démarrage s'appelle OpenBoot. Il énumère et teste le matériel, et passe la main au chargeur de l'OS. Au démarrage, OpenBoot ne se manifeste généralement pas. Il faut faire Stop-A pour rentrer dans OpenBoot, et pouvoir, en particulier, choisir le boot device et régler des paramètres de configuration de base. Attention, ça peut se transformer en Stop-Q, dans des conditions bizarres, sur clavier AZERTY.
Si la Sun met un temps fou à démarrer, avec les LED du clavier qui clignotent lentement, il est possible qu'elle soit configurée pour faire un long test matériel (appelé POST). Sous OpenBoot, vérifier alors la valeur de test-switch? (printenv test-switch?), et la modifier éventuellement avec setenv.
Par défaut, la Sun utilise une résolution d'écran élevée pour sa console (adaptée aux beaux moniteurs de chez Sun !). Pour une utilisation sur un petit écran LCD : setenv output-device screen:r1024x768x60. Sous Linux, on peut de même ajouter un paramètre video=atyfb:1024x768@60 lors du chargement du noyau.
Quelques liens :
Le mardi 7 mars 2006 à 19:00
Depuis quelques jours, j'essayais d'installer Subversion sur ma Gentoo : à chaque fois, après compilation, même erreur, un peu obscure, disant que l'installation ne peut se poursuivre à cause d'insecure RUNPATH's. Le bug #81745 suit le problème, et après un peu de recherches, il semble qu'une partie des packages Gentoo soit actuellement cassés (ininstallables), sans que les mainteneurs aient le temps de résoudre le problème...
Le bug #124962 essaie d'apporter une réponse au problème, sous la forme d'un patch de /usr/lib/portage/bin/ebuild.sh, mais malheureusement, je n'ai pas réussi à l'appliquer, même après avoir réémergé Portage ! J'ai donc dû patcher à la main ce fichier, vers la ligne 1057 :
- #die "Insecure binaries detected"
+ echo "Auto fixing rpaths for ${f}"
+ TMPDIR={PORTAGE_BUILDDIR} scanelf -BXr ${f} -o /dev/null
C'est un peu sauvage, mais ça a le mérite de marcher...
Le dimanche 5 mars 2006 à 22:13
J'ai récemment prétendu que le boot était considérablement plus lent sous Linux (Ubuntu) que sous Windows, du moins sur l'ordinateur où j'ai fait ces tests. Voici les mesures précises. Bien entendu, ces résultats sont à prendre avec des pincettes, car il faudrait effectuer les tests sur plusieurs ordinateurs, mais ça fait quand-même un peu peur...
Le dimanche 26 février 2006 à 12:31
Après avoir mis à jour son fichier sieve-default, il ne faut pas oublier de l'envoyer sur le serveur car Sieve ne parcourt pas les répertoires utilisateurs... La commande : sieveshell -u username server, puis put, list, help, etc.
page 2 de 2 - billets plus récents »