Étienne a écrit 707 commentaires

Dans le première phrase, il fallait bien sûr lire : qui a l'avantage de colorer stderr en laissant stderr sur la sortie d'erreur et stdout sur la sortie standard.

Désolé

Étienne

PS: très drôle le strip de geekscottes quand on se répond à soi-même.

Je te propose un script qui a l'avantage de colorer stderr en laissant stderr sur la sortie standard et stdout sur la sortie d'erreur.
En fait c'est une feinte car on échange 2 fois stderr et stdout, la première fois (fonction swapandcolor) on échange et on colorize, la deuxième fois on restore l'état initial.

#! /bin/sh

function swapandcolor()
{
    "$@" 3>&2 2>&1 1>&3 | while read line
    do
        echo -e "\e[91m$line\e[0m"
    done
}

swapandcolor "$@" 3>&2 2>&1 1>&3


Étienne

Je pense que le principal élément auquel il faut faire attention pour une base simple, c'est les "AUTOINCREMENT" de Mysql qu'il faut remplacer par des séquences avec une valeur initiale correcte dans Postgresql.

Après s'il y a des procédures stockées et des triggers, je pense qu'il y a plus de boulot.

Autant pour moi, le man de ps de cette satanée RedHat n'en parle pas ...

J'ai trouvé ça sur le man de cette satanée RedHat RHEL 5.1.


Étienne

$ ps -u root -o pid,comm,lstart
[...]
26559 bash Thu Feb 14 12:24:06 2008
[...]
$


Voir la section STANDARD FORMAT SPECIFIERS de ps(1)

Sauf que tu as souvent besoin du dépôt parce que certaines combinaisons de renommages/suppressions/déplacements ne peuvent être faites sans commits intermédiaires...

Combinaisons que tu fais bien sûr souvent. Tu n'as pas besoin d'accéder au repository pour :
- rajouter un élément
- supprimer un élément
- déplacer un élément

D'autant que des suppressions et déplacements d'éléments, ce n'est pas fréquent, alors des combinaisons qui nécessiteraient d'accéder au repository, je ne pense pas qu'on puisse qualifier leur fréquence de souvent

C'est vrai qu'on fait autant de cd et ls que d'opération sur le repository. Sur ce coup là c'est de la mauvaise foi intégrale et ce n'est pas avec des arguments de ce niveau que tu vas convaincre qui que ce soit.

Une faille de sécurité comme celle-ci, mieux vaut en parler beaucoup, partout, que les gens soient au courant et mettent à jour

Le problème c'est justement qu'on en a parlé beaucoup, partout, avant que les gens ne puissent mettre à jour. On n'a pas laissé le temps aux distribs de publier les mises à jour. Il aurait suffit de 3 ou 4 jours, ça aurait permis aux packagers de bien faire leur boulot, de mener leurs tests et de faire une publication sereinement, au lieu de ça tout a été fait dans la précipitation et l'exploit a été diffusé avant le correctif officiel.

Ne me fait pas croire que ne pas divulguer un exploit pendant 3 jours c'est de la sécurité par l'obscurité. Surtout qu'à la limite, ce n'est pas tant le fait d'avoir révélé le problème qui est reproché, c'est d'avoir publié un exploit accessible au premier décérébré venu en même temps que la faille.

Pour conclure je pense que vous ne savez pas ce que c'est que la sécurité par l'obscurité. Garder une faille découverte secrète pendant quelques jours en prévenant l'auteur du soft, et lui laisser ce laps de temps pour ne pas tout faire dans la précipitation, ce n'est pas de l'obscurité, et c'est d'ailleurs comme ça que ça se passe dans la majorité des cas. Jusque là je n'ai entendu personne se scandaliser qu'une faille ne soit révélée que le jour où le correctif est présent (lorsque le délai est raisonnable bien entendu).

Ce serait intéressant d'avoir une matrice des fonctionnalités présentes dans chaque moteur pour bien voir le OU et pas une liste de fonctionnalités globales qui masque la réalité en faisant un ET.

http://dev.mysql.com/doc/refman/5.1/en/storage-engine-choosi(...)

Ici ce n'est pas la compilation mais la phase de link (m68k-elf-ld) qui ne marche pas. Il dois y avoir une problème dans ta configuration du noyau.
Verifie que CONFIG_PCI est bien activé et que tu as bien tout recompilé. Au besoin fait un "make distclean" ou repart de zero pour t'assurer que bios32.c est bien recompilé.


Etienne

[http://www.inf.ethz.ch/personal/biere/projects/ccmalloc/]

To use ccmalloc you just have to link it to your executable and run your program.


Je suppose donc que, une fois linké avec ccmalloc, il suffit de lancer le programme. Ceci dit ta ligne de link ne semble pas lier ton executable avec la bibliothèque ccmalloc. Toujours d'après la page du projet, tu peux linker en faisant :


ccmalloc g++ -o"App" ./Source/Lib.o ./Source/test.o -lacml_mp -lgfortran -lGLEW -lglut


Tu n'as ensuite plus qu'à lancer ton programme App.

C'est exact, c'est ton m68k-elf-gcc qu'il faut changer.

Etienne

Si tu n'a pas de version dispo oui, il faut les télécharger et les compiler. Ceci-dit, dans le cas qui te concerne, c'est clairement une erreur du compilateur, donc avant de changer de binutils ou de linker, il faut résoudre le problème du compilateur. Dans ton cas je pense que c'est les lignes :

        if(skb->tail>skb->end)

        {

                __label__ here;

                panic("skput:over: %p:%d", &&here, len);

here:;

        }

Qui posent problème. Essaye de voir avec quel compilateur tu peux compiler une fonction de ce genre (en particulier le

here:;

).

Je pense que tu pourrais essayer avec une version différente de gcc. Il est possible que les compilos plus récents soient plus stricts et que les headers du kernel 2.0 ne soient pas compilables. Regarde dans les sources du noyau quelle version de gcc ils préconisent.

Dans le fichier Documentation/Changes du noyau 2.0.40, voici ce qu'ils préconisent :


- Dynamic linker (ld.so) 1.7.14
- GNU CC 2.7.2.1
- Binutils 2.8.1.0.23
[...]
Note that it is _very_ unlikely that you will be able to compile the
2.0 kernel with gcc-3.x or binutils 2.9.x, and even if it compiles, it
might not work properly.

le -print ne s'applique qu'au dernier -o, donc tu as 2 solution :
- sois tu supprime le -print (action par défaut du gnu find), mais c'est moins portable
- soit tu rajoute des parenthèses :
$ find . \( -iname '*.mp3' -o -iname '*.ogg' -o -iname '*.mpg' -o -iname '*.mpg' \) -print

attention à bien mettre les \ sinon c'est le shell qui va les interpréter.

Il faut choisir ton camp :
- soit tu utilise svnserve et tu te connecte avec l'url svn://monserveur/...
- soit tu utilise svn+ssh et il faut te connecter en temps que user svn svn+ssh://svn@monserveur/...

En effet, en utilisant svn+ssh://seb@, c'est l'utilisateur seb qui est utilisé sur le système et qui lui n'a pas le droit d'accéder en écriture au repository. En revanche svnserve est lancé en temps qu'utilisateur svn et peut donc modifier le repository. Les droits d'accès sont alors configurés à travers le fichier conf/svnserve.conf qui donne un fichier de mots de passe que tu peux utiliser.

Je te conseil la lecture du svnbook [http://svnbook.red-bean.com/]

ce parametre est-il pris en compte lors de la ré-indentation auto ? J'ai pas l'impression.. ?
textwidth n'est pas pris en compte au moment de la réindentation de tout un fichier, tous simplement parceque l'indentation n'est pas un formatage, cette fonction va juste définir le nombre d'espaces ou de tabulations rajouter en début de ligne, ni plus ni moins.

Si tu veux vraiment couper les lignes à 80, il vaut mieux utiliser un indenteur tel que indent (ou bcpp plus adapté au C++) qui offrent un paramétrage beaucoup plus fin. Il est facile de filtrer le code avec
:%!indent

Tu peux même automatiser l'indentation à l'ouverture d'un fichier .c ou .h avec, dans le vimrc

au BufRead *.c,*.h :silent %!indent -kr -ts4 -l80 -lc80

Il faut que tu vois quelle option tu veux passer à indent ou créer ton fichier indent.pro


Etienne

Un media center, tu vas l'utiliser vautré dans ton canapé, pas collé à l'ecran.

En ce qui concerne la gestion de la musique, ça peut être interressant d'avoir un ecran tactile pour choisir sa musique directement sur l'ecran sans avoir à utiliser un clavier ou une télécommande. Pour une utilisation canapé, la télécommande est de rigueur.

pas de doctype -> quirks mode
doctype html <= 4/xhtml <= 1.1 -> rendu classique
doctype supérieur -> rendu "standard"

Rien besoin de forcer, mais qd même inciter à faire mieux... et y'a du taff...


Apparament, si on a un doctype qui n'hexistait pas à l'époque de IE7, IE8 aura un rendu standard. Voir [http://ejohn.org/blog/html5-doctype/] (via glazblog)

Donc pour tous les doctype actuels, on aura un rendu compatible IE7, sauf à mettre la balise meta, mais pour toutes les nouveaux doctypes on aura bien un rendu standard sans besoin de balise meta. C'est plutôt une bonne nouvelle.

Ca marche en relanceant seulement un processus
Il fallait bien sûr lire : Ca ne marche pas en relanceant seulement un processus.

Désolé

Etienne

Ca marche en relanceant seulement un processus. En effet, les droits sont donnés par le noyau au moment du login, il faut donc se relogguer pour que soient associés les groupes corrects. On peu utiliser su(1) éventuellement.

Sinon il faut passer au Hurd ;)

La première approche semble donc préférable pour des raisons de rapidité d'exécution, mais n'ayant pas l'expérience de la chose y a-t-il des cas, en C++, dans lesquels l'approche interface est plus appropriée ?

A partir du moment où tu n'as pas toutes les informations disponibles au moment de la compilation, tu ne peux pas utiliser les templates. Les interfaces se justifient pleinement lorsque le comportement doit s'adapter au cours de l'execution. Par exemple si tes objets sont créés par une Factory, tu ne sais pas précisément quel type tu manipule et tu dois donc utiliser des interfaces.

Au hasard, des programmes qu'on ne peut pas écrire autrement qu'en faisant du template meta-programming en C++ s'écrivent très simplement en python.

Juste sur ce point, je rappel juste que python est un langage au typage dynamique, ce qui fait que si tu passe un objet du mauvais type à ta fonction, tu as une erreur à l'execution. En C++ tu as une erreur à la compilation.

pour le getline j'ai toujours vu utiliser std::getline(), je ne savais même pas qu'il y avait un getline sur les istream. C'est vrai que ça manque gravement de cohérence.

Pour xsgetn, on parle là d'une fonction sur les streambuf, qui a en charge de lire et d'ecrire les fichiers textes. Le char* du xsgetn n'est pas une chaine de charactères au sens C du terme, c'est juste un buffer (non terminé par un 0 par exemple).

Je plussoie, c'est sans doute la partie la plus compliquée et la moins cohérente de la STL.