Barnabé a écrit 701 commentaires

En même temps, les coléoptères, ça doit être tout aussi compliqué que pour les diptères.
Et même plus, un coup d'élytre ca peut être douloureux.

Effectivement, un OS proprio et une VM proprio ca ce ressemble pas mal. Ils ont tous les deux les inconvénients du proprio, qu'on ne va pas énumérer ici, mais tu peux te servir des deux pour faire du logiciel libre.

Si je n'ai pas été clair dans ma réponse précédente, je m'en excuse et je clarifie :
j'ai trouvé ta réaction puérile.

Je n'aime pas du tout Java, je l'aimerais certainement un peu plus si la JVM de Sun était libre, mais de toutes façons, c'est un langage qui ne me convient pas. (c'est peut-être moi qui suit inadapté....) Cependant, je trouve aussi ridicule d'en vouloir à ceux qui vont du Java sous JVM Sun qu'à ceux qui font un noyau qui a besoin d'un BIOS non libre.

Et tu va rire, il y a même des logiciels libres qui dépendent de BIOS propriétaires.

Il y a un mode mineur qui s'occupe de cela : outline

Mets dans ton .emacs : (add-hook 'c-mode-hook 'outline-minor-mode)

Il y a un mode mineur qui s'occupe de cela : outline

Mets dans ton .emacs : (add-hook 'c-mode-hook 'outline-minor-mode)

MFE detected !
(Mauvaise Foi Évidente)

:o)

Le DPL est passé en force, c'est un fait.

Les développeurs debian ont lancé une procédure de destitution, encore un fait.

Ensuite l'auteur de la nouvelle ne fait qu'établir un lien de cause à conséquence. Il ne dit même pas qu'il se pose la question sur la capacité du DPL à représenter le projet, il dit juste qu'il est normal que certains se la posent.
Quelle opinion exprime-t-il ?

Je suis tout seul à ne pas voir d'avis ou d'opinions dans cette dépèche ?
De quel avis parlez vous ? Je ne voit que des faits.

Il est vrai que c'est un bon réflexe que d'aller voir du coté de SNMP pour ce genre de questions, mais là tu tombes mal : hrProcessorLoad ne fonctionne pas dans net-snmp sous Linux.
Il vaut mieux taper dans la MIB UC Davis : .iso.org.dod.internet.private.enterprises.ucdavis.laTable (.1.3.6.1.4.1.2021.10) qui te donnera le load average sur 1, 5 et 10 minutes.
Sinon, tu as .1.3.6.1.4.1.2021.11.53 (ssCpuRawIdle) qui te donne le temps pendant lequel le CPU a été inactif, mais cela t'oblige à lire 2 fois la grandeur et à faire une division.

Qu'appèles tu « la charge CPU de la machine en temps réel ? »

J'ai le sentiment que la charge CPU n'a de sens que sur un intervalle de temps, non ?

D'un aute coté, c'est pas le genre de commentaire qui reste dans les anales.

Si tu utilises amuled/amulegui :
crontab -e

0 21 * * * amuled
0 8 * * * killall amuled

pour lancer amule à 21h et le quitter à 8h

C'est marrant que t'aies gardé ce coté maquisard.

Vignettes.
Non ?

(Laconique, non ?)

En plus du Bescherelle, je te conseille un bon livre d'initiation au C....

Essaie avec des accolades....

int main(int argc, char **argv)
{
static const char LogTable256[] =
{
0, 0, 1, 1, 2, 2, 2, 2, 3, 3, 3, 3, 3, 3, 3, 3,
4, 4, 4, 4, 4, 4, 4, 4, 4, 4, 4, 4, 4, 4, 4, 4,
5, 5, 5, 5, 5, 5, 5, 5, 5, 5, 5, 5, 5, 5, 5, 5,
5, 5, 5, 5, 5, 5, 5, 5, 5, 5, 5, 5, 5, 5, 5, 5,
6, 6, 6, 6, 6, 6, 6, 6, 6, 6, 6, 6, 6, 6, 6, 6,
6, 6, 6, 6, 6, 6, 6, 6, 6, 6, 6, 6, 6, 6, 6, 6,
6, 6, 6, 6, 6, 6, 6, 6, 6, 6, 6, 6, 6, 6, 6, 6,
6, 6, 6, 6, 6, 6, 6, 6, 6, 6, 6, 6, 6, 6, 6, 6,
7, 7, 7, 7, 7, 7, 7, 7, 7, 7, 7, 7, 7, 7, 7, 7,
7, 7, 7, 7, 7, 7, 7, 7, 7, 7, 7, 7, 7, 7, 7, 7,
7, 7, 7, 7, 7, 7, 7, 7, 7, 7, 7, 7, 7, 7, 7, 7,
7, 7, 7, 7, 7, 7, 7, 7, 7, 7, 7, 7, 7, 7, 7, 7,
7, 7, 7, 7, 7, 7, 7, 7, 7, 7, 7, 7, 7, 7, 7, 7,
7, 7, 7, 7, 7, 7, 7, 7, 7, 7, 7, 7, 7, 7, 7, 7,
7, 7, 7, 7, 7, 7, 7, 7, 7, 7, 7, 7, 7, 7, 7, 7,
7, 7, 7, 7, 7, 7, 7, 7, 7, 7, 7, 7, 7, 7, 7, 7
};
/* .... */
return 0;
}

Pour ton dernier reproche :
http://linuxfr.org/2004/05/18/16263.html

Sauf que pour les dates, il n'y a pas de zero.

Sauf que pour pouvoir prétendre qu'une imprimante embarque un interpréteur PostScript, il faut payer Adobe. Et ca, c'est cher...

toutafé, voir par exemple ce petit résumé :
http://www.april.org/articles/intro/gnu.html

Richard, c'est toi ?

Effectivement, mais dans ce cas on est plus en présence d'une alternative, mais de trois.

En fait, « alternative » et « choix binaire » sont des synonymes.

Tant que tu auras 255.255.255.255 comme adresse de broadcast sur eth0, tu auras des problèmes.

En statique, il ne faut pas oublier de remplir le fichier /etc/resolv.conf

Je te conseille de prendre les problèmes 1 par 1, et de commencer par la configuration de ton interface eth0, en désactivant carrément ta ralink. Quand eth0 aura un fonctionnement normal (ce qui n'est pas le cas actuellement, même si tu peux faire de l'nternet), il sera temps de s'occuper du wifi.

Ton adresse de broadcast sur eth0 pose problème.

Si tu démontes eth0, tu devrais ne plus avoir les logs à propos de la table ARP, après qu'elle se soit vidée.

pour le 169.254, ca vient de zeroconf, c'est pas forcément grave.

Tu devrais commencer par te mettre en wifi sur un réseau privé,

ensuite essaie de configurer une adresse statique pour eth0, si tu étais en DHCP, ou en DHCP si tu étais en statique.

Je crois que tu as un serieux problème de configuration réseau.
Ta machine en voit une infinité d'autres sur le même lan, ce qui ne devrait pas se produire...
Peux tu nous montrer les résultats de :

route -n

ifconfig

cat /etc/resolv.conf


Et nous donner plus de renseignements sur ta conf réseau (dhcp, routeur adsl, wifi, tout ca....)