ninis666 a écrit 95 commentaires

Et pourquoi pas 'ed' sans environnement X et sans souris ?

Et j'ai toujours dans ma todolist la tâche de trouver un calculateur similaire pour le PC - hors émulateur.
Parce que rien que le RPN ça booste la productivité en calcul.

Tu en as dejà quelques-un au moins sur debian :

bash$ apt-cache search rpn
grpn - GTK+ reverse polish notation calculator
hp48cc - C-like compiler which produces HP48 RPN
orpie - RPN calculator for the terminal
texlive-pstricks - TeX Live: PSTricks packages
rpncalc - Calculatrice RPN qui tente d'émuler une HP28S

C'est sans doute à contre-courant, mais je voulais parler d'un machin avec des vraies touches. Ceux qui ont déjà pianoté sur une HP me comprendront sans doute :-)

Haaaa, les HP48 ! C'est sans parler de son buzzer ainsi que de son fabuleux écran ! Moi j'ai une 48G et une 49G+. J'ai rachetée cette dernière à un pote pour une poignée de dollars, même si j'en avais plus vraiment besoin, et là, c'est le drame !
* Les touches sont moisis
* La coque en plastique ultra cheap
* Pas de housse !
* Pas moyen de ré-utiliser le câble rs232 de l'ancienne (mais avec du bricolage de non-électronicien un peu crade, j'ai quand même réussi à le faire marcher)
* Pas de port pour mettre des 'banks' externes, (même si elle avait pas mal de mémoire utilisateur)

Mais elle était quand même livré avec le kernel 'non standard HP' qui était à la mode des grandes années des 48xx.

Mais honnêtement, je ne pense pas que tu puisses retrouver une aussi bonne machine ajourd'hui: j'ai connu un peu de tout, casio / ti / HP et jusqu'à maintenant HP48GX restera toujours LA référence (un peu comme un bon vieux Led Zep' tel que le II :) ) que tu ne retrouveras plus. Je serais toi, je chercherais du côté de l'occasion.

On est obligé de modifier le driver en commentant certaines entrés référencées par la struct "pci_driver" : il y a une table listant tous les devices PCI que le driver doit gérer. Les bidouilles avec modprobe / depmod ne peuvent pas marcher dans ce cas précis ....

Comme dirait l'autre, "get things done !" : ne donnez votre avis que sur les sujets que vous maîtrisez / avez déjà fait !

À mon humble avis (les avis, c'est comme les trouducu, tout le monde en a un ;) ), je ne crois pas que ça soit possible sans modifier / configurer le driver de ton NIC : dans un driver qui fait du "probe PCI", tel que celui de ton NIC, il va détecter tous les devices PCI qu'il peut traiter (par l'intermédiaire des vendorID / deviceID) : si tes 2 cartes apparaissent dans un même driver, elles vont être gérées par celui-ci. Je pense donc les contournements avec les modprobe / modules.conf ne marcheront pas ... Faudrait voir si c'est faisable de modifier les 2 drivers pour ne gérer que les interfaces dont tu passerais la mac address par exemple.

en utilisant '?' :) ?

Oï,

J'utilise CMake, j'arrive à lui faire copier des fichiers, dossiers et binaires lors du make install, mais je crois pas qu'on puisse lui dire de recompiler avec une option différente lors du make install. En tous cas si ça existe je veux bien la syntaxe ^^

Tu peux fixer tes variables lors de ton appel à make :

bash$ make FOO=bar

Et dans ton makefile, de t'assurer que tu n'utilises plus tes valeurs par :

# definir FOO s'il n'exsite pas
ifeq ($(FOO),))
    FOO = foobar
endif

# Utiliser FOO lors des regles de compilation
%.o: %.c
    $(CC) $(CFLAGS) -DUSER_FLAG=$(FOO) -c $^ -o $@

mon_truc: barba.o truc.o
    $(CC) $(LDFLAGS) $^ -o $@

Dans mon exemple c'est pour la compilation, mais tu dois pouvoir te débrouiller pour faire la même chose pour les copies de fichiers ...

Ça fait des bailles que FreeBSD utilise les 'ports' : toute une arborescence de makefile pour rapatrier / compiler / installer des binaires. Ça fait aussi longtemps que je m'en sers plus, mais il me semble aussi qu'il rapatrie les dernières versions des dépendances avant de compiler ...

Essaye de commenter ta ligne "auto eth0" de ton /etc/network/interfaces. "man interfaces" te donneras plus d'info quant à ces paramètres.

Sinon, pour info, l'administration système n'a rien a voire avec le dev : j'ai eu l'occasion de dépanner un serveur de dev une fois
(histoire de filer un coup de main), ben c'était bien le boxon : des fichiers de conf dans les dossiers utilisateurs, des binaires dans /etc, et je ne parle même pas des trou de sécurité (aller, un petit peu quand même : plusieurs comptes UID 0 (root), accès ssh avec les comptes root susmentionnés...). On comprend le pourquoi du métier d’intégrateur!

Ça ne veux pas non plus dire que c'est les developpeurs qui ont foutu en vrac ta machine, c'est plutôt l'admin qui a mal fait son boulot.

Je suis aussi dans dev système, toutes proportions gardées, comme Rob Pike, et avec le temps on acquière quand même beaucoup de savoir faire en administration / configuration d'un système, même si l'on ne le maîtrise pas forcement. Je pense que sa réflexion va un peu plus loin que du genre "ma carte video marche mal avec tel kernel, donc Linux c'est de la merde". Je pense qu'il voulait tout simplement passer à autre chose qui reste un systeme Unix : il faut rappeler qu'il était (est toujours ?) pro-brevet notament quant à X dont il a contribué ....

C'est un peu rude quand même de le qualifier de noob : il aura écrit plus de ligne de code que toi dans toute une vie ...

raise est plus 'thread safe' que kill, cf man raise :

Dans un programme monothreadé, elle est équivalente à :

kill(getpid(), sig);

Dans un programme multithreadé, elle est équivalente à :

pthread_kill(pthread_self(), sig);

Donc mieux autant utiliser raise sans trop se poser la question :)

La commande "tr" permet de remplacer / supprimer des caractères. La ligne suivante supprime tout les saut de lignes de fichier.txt

bash$ tr fichier.txt -d '\n'

C'est sûrement dû au CLOSE-ON-EXEC. Je ne pense pas que tu puisses le manipuler directement en utilisant des FILE *, mais avec des file descriptor ça devrait marcher, comme dans ce bout de code :

#include <stdio.h>
#include <fcntl.h>
#include <unistd.h>

int main(int ac, char **av)
{
    int input, output;
    const char * modem = "/dev/ttyMODEM";
    const char * argv[4];

    input = open(modem, O_RDONLY);
    if (input < 0) {
	fprintf(stderr, "Can't open <%s> for reading: %m\n", modem);
	return 1;
    }

    output = open(modem, O_WRONLY);
    if (output < 0) {
	fprintf(stderr, "Can't open <%s> for writing: %m\n", modem);
	return 1;
    }

    if (fcntl(input, F_SETFD, 0) < 0) {
	fprintf(stderr, "Failed to clear close-on-exec flag in input: %m\n");
	return 1;
    }

    if (fcntl(output, F_SETFD, 0) < 0) {
	fprintf(stderr, "Failed to clear close-on-exec flag in output: %m\n");
	return 1;
    }

    if (dup2(input, STDIN_FILENO) < 0) {
	fprintf(stderr, "Cant set input: %m\n");
	return 1;
    }

    if (dup2(output, STDOUT_FILENO) < 0) {
	fprintf(stderr, "Cant set output: %m\n");
	return 1;
    }

    close(input);
    close(output);

    argv[0] = "/usr/sbin/chat";
    argv[1] = "-v";
    argv[2] = "-f";
    argv[3] = NULL;
    if (execv(argv[0], argv) < 0) {
	fprintf(stderr, "Failed to execv(%s, %s, %s): %m\n", argv[0], argv[1], argv[2]);
	return 1;
    }

    return 0;
}

Où sinon, evilwm qui ne fait que gérer les fenêtres, à savoir :

• afficher les fenêtres
• les déplacer
• les redimensionner
• les mettre dans des bureaux virtuels
• Ouvrir un terminal avec un raccourci clavier (parce que quand même, faut pas déconner !) Tout ça au clavier (ou à la souris pour les moins aguerris :) ).

La seule fioriture shiny, c'est la fonction de "snap" activable lors de son lancement.

Le plus gros défaut que je lui trouve, c'est qu'il ne gère pas de fichier de conf pour la description des attributs des fenêtres (les forcer à rester sur un certain bureau ou tous, leur géométrie par défaut etc.).

Avec un xcompmgr par dessus, tu as un gestionnaire de fenêtre tout élégant et léger : pas besoin d'avoir 500Mo de libs à installer pour ne s'en servir que de 5Mo.

Ou de faire de depmod -A et rebooter ta machine ...

Ola,

Tu ne pas avoir les libs que tu as utilisé pour linker ton binaire (libc.so, ld-linux.so, etc.) sur ton arm. Tu peux faire 'ldd helloworld' pour les lister et les recopier sur la cible.

Tu peux essayer de te procurer ces ouvrages de référence :

1/ Linux in a nutshell, O'reilly
Ellen Siever, Stephen Spainhour, Jessica P. Hekman, Stephen Figgins

2/ The UNIX programming environment, Prentice-Hall
Brian Kernighan, Rob Pike

Le 2ème est un peu vieux et ne parlera pas de choses exclusives à Linux mais à tout système Unix (Linux / BSD / AIX etc ...). Sachant que les 2 gus ayant écrit ce bouquin sont les pères de pas mal des briques élémentaires que l'on se sert aujourd'hui les systèmes Unix.

Je te laisse les trouver en français, moi étant un intégriste de la VO.

Pour la différence entre la taille de la partition != l'espace disque libre + l'espace disque utilisé : Il s'agit des "reserved blocks" : sur un fs en ext2 (ou ext3) tu auras toujours des blocks reservés. Tu peux voir leur comptage actuel avec dumpe2fs et en changer le nombre avec tune2fs.

Ensuite tu peux toujours activer la compression des log si tu utilise logrotate (en ajoutant "compress" dans les fichiers de conf de celui-ci (/etc/logrotate.conf ou dans /etc/logrotate.d/*) cf man logrotate.

en faisant du arping vers toutes les machines de ton réseau

ici, sur 192.168.0.X avec 1 <= X <= 254 pour un reseau en 255.255.255.0

bash# for i in `seq 1 254` ; do arping -c 1 -w 5000 192.168.0.$i 2>/dev/null | grep index ; done