Obsidian a écrit 5299 commentaires

Sans développer, je suis déçu par la dernière Ubuntu que je trouve très régressive par rapport à la précédente (relativement aboutie), mais surtout, je crois que l'on a atteint le stade où l'on consomme 256Mo de mémoire résidente au repos (principalement dus à GNOME). Donc, la moindre application swappe pendant des heures.

Mon laptop, puisque c'est de lui qu'il s'agit, est équipé de 256Mo de RAM et je ne crois pas que je puisse l'upgrader.

Donc, avec un serveur 512Mo pas trop chargé, cela devrait quand même passer. Ceci dit, Ubuntu pour un serveur LAMP, c'est peut-être exagéré. Prend plutôt une Debian authentique, c'est ce qu'elle fait de mieux, et ce ne sera pas plus long à déployer.

De mémoire, je crois que le port parallèle est compatible TTL (0->5V), donc pas suffisant, et que le port série utilise des tensions symétriques, négatives pour un 0, positives pour un 1. Ces tensions sont en principe fixées à +/-12V mais en fait elles varient énormément d'un ordinateur à un autre, donc il vaut mieux ne pas t'y fier.

En revanche, ce que tu peux faire, c'est tirer l'alimentation des Molex de ton PC. Là, pour le coup, tu auras suffisamment de puissance et une tension bien stabilisée. Idéal pour ton capteur. En outre, en utilisant l'alimentation du PC pour ton capteur, tu peux te passer d'une isolation galvanique, mais il te faudra quand même au moins un pont diviseur pour adapter les tensions.

Bon courage.

Il l'a dit à demi-mots :

ce sont un peu vos enfants et vous ressentez une pulsion protectrice à leur égard qui ferait passer une maman-ourse pour un vulgaire saumon de rivière.

Vous savez tous avec quelle délicatesse les mamans ourses traitent les saumons de rivière ! :-)

Je te conseille plutôt d'utiliser le port parallèle. Avec la déferlante USB, tu as plus de chances de le trouver aujourd'hui qu'un port série, et surtout il est très largement utilisé pour faire ce genre de bidouille.

Sur un port série, si tu veux récupérer l'état instantané d'un bit, le mieux est d'utiliser les signaux de contrôle (DCD, CTS, etc). En revanche, utiliser le port parallèle sous Linux en particulier n'est pas aussi trivial que cela en a l'air. Il faut utiliser le module partport_pc, etc.

Sinon, brun/bleu/noir, ça ressemble surtout à une alimentation secteur monophasée. C'est curieux.

Point de vue électronique, vérifie si ton capteur propose une sortie à collecteur ouvert, sinon, il te faudra au minimum un transistor pour adapter les deux parties.

Enfin, si tu veux faire un chronométrage sans utiliser un processu qui fasse une attente active, il te faudra probablement jouer avec les interruptions.

Ça me rappelle les Guignols, autour de 1996-97, qui imitaient Jacques Calvet, en train de se lamenter parce que ses voitures étaient trop futuristes :

« Je leur demande des voitures pour dans cinq ans et eux, ils me font des voitures de l'an 2000 » :-)

Si c'est pour faire du vrai travail de géomètre, à savoir jalonner la carte en plaçant des repères dessus et faire des mesures, je ne crois pas qu'il existe à ma connaissance, de logiciel dédié à proprement parler.

Tu peux cependant essayer QCad, conçu pour le dessin industriel, et qui implémente en lui-même ces fonctions, mais je ne sais pas s'il te laissera ouvrir un bitmap en fond de document.

A la limite, les sources étant disponibles, il devrait être possible d'écrire un patch pour lui permettre de le faire.

Bon courage.

Nous vous rappellons que cette pratique est interdite et répréhensible par la loi.

Mouais. Moi, je dirais plutôt "interdite par la loi et répréhensible". Ce serait déjà plus cohérent.

La société BLOGMUSIK SAS se réserve le droit d'alerter les autorités compétentes en cas d'abus ... Ben quoi, la musique arrive bien jusqu'à mes enceintes et je ne fais que télécharger le fichier qu'on veut bien me proposer à l'écoute... En dehors de la partie technique (je me demande comment ils font pour identifier les requêtes illégitimes) je dis: ça abuse un max ! Faut pas pousser mémé dans les orties non plus...

T'as surtout dû suivre un URI qui n'existe plus et arriver sur une page de principe. Etant donné que tout passe par leur player Flash, les erreurs 404 ne devraient plus se produire en principe ! Bon, y a toujours eu des chasseurs de sorcières sur le Net et il y en aura encore longtemps ...

D'autres infos intéressantes ici, sinon :

http://www.pcinpact.com/actu/news/40617-geoip-titres-grises-(...)

C'est un problème, ces histoires de cartes vidéo. Le moindre soft un tant soit peu graphique sous Linux s'appuie sur OpenGL, qui lui, nécessite obligatoirement une accélération matérielle disponible - avec ses pilotes - pour fonctionner.

Résultat, des trucs comme Chromium pourtant pleinement 2D ne fonctionnent qu'à 1 FPS sur une config' sans carte 3D, pourtant très honorable par ailleurs.

Dans le même esprit, impossible de profiter pleinement de Google Earth, par exemple, alors qu'il fonctionne bien sous Windows. Problème local : la machine en question est un portable d'un âge raisonnable, mais quand même capable de faire tourner une Hoary de manière exploitable. Impossible, donc, d'y coller une carte 3D. C'est quand même un facteur très limitant.

Même chose qu'au-dessus. Si la même distrib' ne reconnaît plus sa connexion après un changement de modem-routeur, c'est que c'est de ce côté qu'il faut chercher, et plus précisément du type de connexion lui-même.

Il y a fort à parier que ton modem utilisait par défaut le codage WEP, le procédé de codage normal du Wifi jusqu'à une époque récente - celle où l'on a démontré que l'on pouvait le casser en quelques minutes - et que ta Livebox toute neuve soit désormais configurée par défaut pour utiliser le WPA.

Je n'utilise pas Mandriva 2007 mais je suppose qu'elle est capable de gérer ce protocole toute seule. Si ce n'est pas le cas, il te faudra te palucher à la main l'installation et la configuration de wpa_supplicant. C'est fastidieux, mais ça marche. Testé avec succès sur une ancienne Ubuntu.

Bon courage.

s/supportent/gèrent/

L'ennui, c'est que la plupart des pilotes tiennent le même discours et - surtout - s'arrêtent là.

D'une part, les deux logiciels ne sont pas mutuellement exclusifs. Utiliser un excellent Flight Simulator n'empêche pas de prendre du plaisir avec FGFS non plus, ne serait-ce que pour changer un peu d'univers, surtout si ce dernier simulateur est proposé gratuitement.

D'autre part, plus encore que dans n'importe quel autre logiciel libre, la grande force de cette œuvre réside dans l'ouverture et la souplesse du code : d'un coté, la plupart des pilotes sont très attentifs à la qualité du détail (pas seulement graphique, mais aussi dans l'exactitude des informations et dans le comportement des instruments de vol) et de l'autre, il y a une armée de développeurs bénévoles qui n'attendent que ce genre de retour.

Le simulateur est donc fait pour pouvoir très rapidement être étendu. Quand on sait le nombre de petits aérodromes qu'il y a en France, et qu'ils ne seront pratiquement jamais représentés dans les produits commerciaux américains, il est intéressant d'avoir une solution libre, universelle, qui permette à chaque site de le configurer à sa guise et de partager ses cartes avec le reste du monde de l'aviation ...

Non, c'était juste son nom de famille ... /o\

(Je suis déjà dehors ->[]).

D'abord, il manque peut-être les balises <VirtualHost>, mais surtout, je vois dans chaque bloc :

ServerName ez1.mondomaine.fr:80
ServerAlias ez1.mondomaine.fr:80

et

ServerName ez2.mondomaine.fr:8080
ServerAlias ez2.mondomaine.fr:8080

À quoi te sert de définir un alias identique au servername ? Peut-être cherchais-tu à définir ex1 et 2 sur les deux ports ?

D'autre part, comme dit ci-dessus par Toto, ton documentroot est identique pour chaque hôte.

Y en a qui arrivent à faire pire : :-)

http://www.bashfr.org/?2226

Alors, pour les dépendances, lsmod lui-même te donne en vis-à-vis de chaque module la liste de ceux dont il dépend. Pour le reste tu peux aussi voir la man page de depmod et son fichier /etc/modules/2.6.xx.xx/modules.dep.

Pour les modules qui ne servent pas, le système est généralement configuré pour charger à la volée les modules dont il a besoin, donc il faut surtout désactiver les services inutiles sur ta machine et les modules ne se chargeront pas. Toutefois, il existe le fichier /etc/modprobe.d/blacklist, très utile en cas d'ambigüité, notamment.

Essayons de ne pas recourir à cat s'il est possible de s'en passer :

uniq -d test
sort test | uniq -d

En fait, il faut bien se rendre compte que ton propre code C++, celui même que tu vas compiler, ne sera pas protégé non plus. Le fait qu'il soit sous forme de langage machine ne le rend pas en lui-même indéchiffrable. Ceci est vrai, d'ailleurs, pour tous les exécutables, sous Windows comme sous Linux, ou ailleurs.

Il faut donc bien savoir quel genre de protection tu comptes apporter. S'il s'agit juste de complexifier la lecture de manière à ce que l'on ne puisse pas voir le code en clair avec un bête éditeur de texte, alors un codage type DES avec la clé de ton choix fera parfaitement l'affaire. Cela obligera les gens à la chercher au sein de ton code compilé et à aller décrypter tes chaînes directement, ce qui réserve cette tâche aux programmeurs.

S'il s'agit de masquer le code même aux utilisateurs les plus avertis et motivés, là par contre, il n'y a pas de solution miracle. Il faut mettre ton code dans un fichier spécial qui va être lu par ton application principale (soit directement, soit par l'intermédiaire du mécanisme des bibliothèques partagées *.so) et là, tu mets des droits d'accès dessus. Tu te débrouilles ensuite (via des bits setgid par exemple, mais pas root) se lance sous une identité qui te permette d'y accéder.

Ca veut donc dire que l'utilisateur moyen d'un système d'entreprise ne pourra jamais y accéder. Par contre, l'administrateur et toute personne sudoer pourra toujours le faire s'il en a la motivation.

Soit :

iptables -N WHITELIST
iptables -A WHITELIST -d time.windows.com -j ACCEPT
iptables -A WHITELIST -d update.avast.com -j ACCEPT
iptables -A FORWARD { mais seulement en FORWARD -i machin -o machin } -j WHITELIST

Ce qui aura pour effet d'autoriser systématiquement ce qui se trouve dans la whitelist à passer directement, soit :

iptables -N WHITELIST
iptables -A WHITELIST -d time.windows.com -j RETURN
iptables -A WHITELIST -d update.avast.com -j RETURN
iptables -A WHITELIST -j REJECT
iptables -A FORWARD { mais seulement en FORWARD -i machin -o machin } -j WHITELIST

Pour bloquer tout ce qui n'est pas dedans, et poursuivre l'examen des autres chaînes, sinon. En fonction de la politique (-P) de chaque chaîne intégrée.

Je ne suis pas sûr d'avoir tout saisi mais il me semble que c'est surtout du masquerading qu'il faut faire.

Une connexion TCP est à double send. Si les machines de ton réseau utilisent des adresses internes, il faut bien que ta passerelle sache vers quelle machine renvoyer les paquets en retour ...

J'ai déjà eu ce genre de problème avec un log qui se remplissait à cause d'une boucle sans fin.

Si c'est bien /home qui se remplit, vérifie toutefois s'il n'y a pas de liens symboliques qui s'y réfèrent depuis autre part (/var/log, /tmp), etc.

D'autre part, il est possible que ton espace soit complètement alloué si un programme crée une multitude de fichiers qui allouent chacun 4 kilo-octets. En principe, du n'est pas dupe, mais ça dépend des options qui lui sont passées par défaut.

Un core dump à répétition est aussi envisageable.

Sais-tu quel répertoire de /home est le plus volumineux ? As-tu exploré le contenu de lost+found ?

Enfin, un top au moment où le phénomène se produit ainsi qu'un lsof | grep home devrait t'aider à localiser le processus fautif.

Bon courage.

Quelle sera la solution la plus rapide? La moins onéreuse? La plus écologique? La plus simple? Etc? J'attends for vos suggestions.

Le meilleur moyen d'avoir la paix, c'est de n'avoir rien à protéger. Sinon, en ce qui concerne la destruction de données, un expert sécurité nous avait affirmé un jour que couper un disque en quatre avec une cisaille suffisait à décourager la plupart des efforts de récupération. Je demande à voir, mais apparement, avoir un disque en plusieurs morceaux pose plus de problèmes que l'altération de sa surface.

Si vraiment tu es paranoïaque au point de plus en dormir, tu peux essayer de réduire ton disque en poudre avec un lapidaire et d'aller disperser les cendres dans la mer. Si quelqu'un me prouve que l'on peut reconstituer les données à partir de cet état, je me fais bonze.

comment puis-je éviter cela ? ps : ces tableau de caractères sont des sous programmes qui sont compilé à la volée , et ces codes ne sont pas ouvert... d'où ma question

Il s'agit là encore, comme bien souvent, d'un problème initial de conception et pas d'une limitation du compilateur. Si l'accès à ces codes doit être restreint, alors il doivent être explicitement protégés. L'une des manières de faire est d'utiliser une clé de cryptage, mais cela signifie également que le programme doit contenir la clé pour les lire.

Ca veut donc dire que si l'ordinateur peut (et doit) le faire, alors une personne quelquonque peut le faire aussi.

Reste à savoir quel niveau de protection tu comptes atteindre. S'il s'agit juste de masquer le code à la vision du premier utilisateur venu, un bête XOR pourrait presque suffir (à écarter quand même pour le principe). Si l'accès à ces codes ne doit EN AUCUN CAS être révélé, alors il faut les déporter dans un *.so distinct, et utiliser les droits d'accès du système (comme pour les mots de passe). Sachant qu'en tous les cas, un administrateur motivé pourra toujours les retrouver en quelques minutes.

Dieu m'en garde. :-)

Moi je les gère comme çà :

$ programme 2> /dev/null

Et bien, crois-le ou pas, mais depuis que j'ai adopté cette technique, je n'ai plus aucune erreur ! :-)

Non, y a toujours moyen de faire pire :

16:39 on m'a demander de debugger un prog C qui marche pas, pour faire simple j'ai remplacé tous les malloc( x) par des mallox( x * 100 ) ... et bien maintenant ça marche ... aller Zou ! au suivant !

http://quadaemon.free.fr/tribune.fortune