Matthieu Moy a écrit 3251 commentaires

> vu que t'ecris qu'un octet ca sera la meme chose sur toute les archi,

Ben justement non. Tu écrit un octet sur 4, la question, c'est si tu écris sur les bits de poids fort ou sur les bits de poids faibles, et ça, ça dépends de l'endianness de ta machine. Exemple:


$ cat endian.c
#include <stdio.h>

int main() {
int x = 0x01020304;
int * px = &x;
printf("%x\n", *px);
*(char *)px = 'a';
printf("%x\n", *px);
}

$ uname -a
SunOS asti 5.9 Generic_117171-09 sun4u sparc SUNW,Sun-Fire-V240
$ /usr/local/soft/gcc/3.0.2/bin/gcc endian.c
$ ./a.out
1020304
61020304

$ uname -a
Linux ecrins 2.4.27-2-k7-smp #1 SMP Thu Jan 20 11:33:07 JST 2005 i686 GNU/Linux
$ /usr/local/soft/gcc/3.0.2/bin/gcc endian.c
$ ./a.out
1020304
1020361


> D'ailleur si cela avait avoir avec la portabilite ca ferait longtemps que ca serait corrige
> dans certaines distributions multi-archi.

En C ANSI, tu peux très bien faire du code endian-dependant (il suffit d'avoir droit aux cast de pointeurs). Le C *peut* être portable, si on ne fait pas de conneries avec, mais c'est pas la philosophie du language de t'empêcher d'en faire.

> Bref Fedora continue d'etre une grosse experimentation a ciel ouvert.

C'est un objectif affiché de Fedora.

http://fedora.redhat.com/about/objectives.html(...)
Be on the leading edge of open source technology, by adopting and helping develop new features and version upgrades. [...] Promote rapid adoption of new releases [...] Form the basis of Red Hat's commercially supported operating system products.

Que je traduirais grosso modo par "On se jette sur toutes les nouveautés, on fait ce qu'on peut pour que ça ne nous pète pas a la gueule, mais si ça casse, c'est toujours mieux que si ça cassait dans RHEL". (ce qui est assez logique vu que c'est principalement RedHat qui paye les développeurs ...)

> Pas de quoi attirer les foules a mon sens.

Tu en bénéficie pourtant probablement indirectement, même si tu n'utilises pas Fedora. Maintenant, si tu cherches des solutions éprouvées et longuement testées, Fedora n'est pas faite pour toi (< troll > prends une Debian stable plutôt </ troll >).

Ingrédients:

* 1 feuille de papier
* 1 scanner
* Des mains pour froisser le papier

La suite de la recette est laissée en exercice au lecteur.

;-)

Dans le cas du fichier "lock", penser aux braves gens qui ont leur /home partagé entre plusieurs machines.

Y'a des bibliothèques toutes faites pour faire du lock de manière fiable (il parait que c'est fiable même sur du NFS, mais j'ai des doutes là).

Vous battez pas. Ca dépend si c'est sur un CDRW ou un CDR, c'est tout.

... et tu as un truc monstrueusement pas portable. (big endian, little endian, toussa, ...)

Je connais pas super bien perl, mais en gros, c'est très adapté quand le shell unix ne suffit plus mais que tu ne veux pas sortir l'artillerie d'un "vrai" langage.

C'est très facile de parser du texte (y'a des expressions régulières partout), c'est faiblement typé, ce qui a mon gout est un avantage pour du code simple en non critique, mais inacceptable pour une grosse applie.

Ce que je trouve assez impressionnant, c'est ce qu'on peut faire en une ligne (les fameux "one liners" a tapper sur une ligne de commande).

Bon, ceci dit, il y a aussi des gens qui utilisent perl pour des assez grosses applies et qui en sont contents.

GCC = GNU Compiler Collection, qui inclue g++.

D'ailleurs, on peut très bien compilé du C++ avec gcc, en passant les options kivontbien.

> Mais effectivement, il me semble que c'était surtout avec le C++.

Tout a fait. L'ABI C++ a changé de 2.95 à 3.0, puis de 3.1 à 3.2 (3.0 a 3.1, je sais plus), mais elle s'est stabilisée depuis la 3.2 sur architecture Intel au moins.

> Un petit 'gcc -v' affiche le numéro de version et prouve qu'il est bien là, puis 'which gcc' te dira où il se trouve.

Seulement si il est dans ton PATH justement. Sinon, "locate gcc" ou "find / -type f -name gcc".

> Pour vois la valeur de PATH, il suffit de faire 'env | grep PATH'.

Un "echo $PATH" me parait un tantinet moins bourrin ;-)

> ca c'est seulement pour Debian

Tu réalises que tu postes ça en réponse à quelqu'un qui dit "J'ai installé suse avec succès, tout se passe bien..." dans le groupe Linux.suse ;-) ;-) ?

La façon "traditionnelle" d'installer quelque chose sur la plupart des distributions, c'est plutôt d'utiliser ton gestionnaire de paquets. Sous SuSE, ça doit être yast ou quelque chose comme ça.

le ./configure && make && make install c'est plutôt la méthode "de secours", quand ce que tu cherches n'est pas disponible en package.

Juste pour préciser que SFLphone est GPL.

Ahem, et c'est ça que tu donnes comme exemple pour dire que Mandrake^W^W^Wiva est prête pour les serveurs ;-)

D'ailleurs, tu devrais faire gaffe, il y a un mec qui poste avec ton compte et qui prétends quelques commentaires plus haut qu'il y a aussi du Samba, et un serveur de mail sur ta machine.

Bon, sérieux, a part a jouer à « celui qui a le plus gros », ça sert a quoi un uptime de 375 jours ? Comptes ce que tu perds a programmer un reboot a 3h du mat, et regardes ce que tu gagnes en sécurité. Y'a pas photo.

Ben excuses-moi, mais ça, c'est le raisonnement d'un débutant en sécurité informatique.

Une attaque, de l'extérieur ou pas, ça se fait dans 99% des cas en 2 phases. D'abord, tu attaques un compte utilisateur, et après, tu cherches a passer root. Il me semble d'ailleurs que c'est comme ça que sont tombés les serveurs Debian. Le principe de base de sécurité, sur un système moderne, c'est que ces deux étapes doivent chacune être difficiles (par opposition a un vieux système comme Windows 95 ou MSDOS).

Quand un petit malin a exploité une faille include en PHP sur le serveur web de mon labo (pourtant firewallé a mort, tout ça tout ça), j'étais plutôt content que notre admin ai patché comme il faut. Notre script kiddy n'a rien pu faire. Sur ta machine, il passait root en 5 minutes.

Par ailleurs, tu pourrais jetter un coup d'oeil a ça si tu es curieux :

http://www.google.com/search?q=80%25+des+attaques+viennent+de+l%27i(...)

(Pour ceux qui ont la flemme de cliquer : Des gens compétents considèrent qu'en entreprise, 80% des attaques viennent de l'intérieur)

Bref, en ce qui te concerne, je te donne la réponse au petit questionnaire de tout a l'heure:

[X] Demain, je patche et je reboot

;-)

Non, tu n'as pas a rebooter pour changer de navigateur. Pour le kernel, par contre, c'est expliqué là :

http://www.mandrakesoft.com/security/kernelupdate(...)

« If you use lilo, once you have modified your /etc/lilo.conf file, you must execute "lilo -v". Grub users do not have to do anything extra. Now you can put the poudre verte on your PC.. » (a peine modifié pour l'occasion).

> c'est tellement minime.

Moi aussi, tu sais, au début, on m'a dit « Linux, c'est implantable, inattaquable, c'est merveilleux. ».

Seulement, si tu considères comme minime le fait qu'un simple utilisateur puisse passer root sur ta machine, je préfère que ça ne soit pas toi qui administre les serveurs de mon boulot. Voyons voyons ... A quoi le serveur a tout faire de l'entreprise du mosieur est-elle vulnérable ?

http://www.mandrakesoft.com/security/advisories?name=MDKSA-2004:029(...)
A local root vulnerability was discovered

http://www.mandrakesoft.com/security/advisories?name=MDKSA-2004:037(...)
There is an exploitable integer overflow (celui là, ils disent que c'est pas trop grave)

http://www.cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-0228(...)
allows local users to gain privileges.

http://www.mandrakesoft.com/security/advisories?name=MDKSA-2004:066(...)
allow local users to elevate privileges

http://www.mandrakesoft.com/security/advisories?name=MDKSA-2004:087(...)
a local attacker can abuse this vulnerability to gain access to uninitialized kernel memory, [...] This kernel memory can possibly contain information like the root password,

http://www.mandrakesoft.com/security/advisories?name=MDKSA-2005:022(...)
=> La liste est trop longue, j'ai la flème de copier-coller !

Pour ceux qui trouvent qu'un exploit local n'est pas grave, dites-vous que certains admins de debian.org croyaient peut-être ça aussi, avant.

« Nan nan, chef, le serveur, il est hyper secure. Vous avez pas vu la pub a la télé ? »

> uptime 375 jours.

Cocher la bonne case :

[ ] J'utilise un noyau qui n'a pas eu de faille de sécurité depuis 375 jours
[ ] J'utilise la technologie X qui patche mon noyau sans rebooter
[ ] J'avais téléchargé mon noyau via IPOT, il était déjà patché pour les failles inconnues (variante: J'utilise viguard, je suis a l'abris de tout)
[ ] Demain, je patche et je reboot
[ ] Autre: préciser .........

> c'est quoi un message de syslog?

une portion pertinente de /var/log/syslog

Sinon, la commande dmesg peut donner des info intéressantes. Essaye

grep '/dev/hd' /var/log/syslog

et

dmesg | grep '/dev/hd'

Il y a peut-être des messages intéressants.

C'est sur que si tu as un vrai secret a cacher, c'est pas suffisant. Par contre, pour dissuader un concurrent de te repomper ton code, c'est déjà très suffisant : Ca lui coûtera moins cher de redévelopper from scratch que de comprendre ton code.

Ni plus ni moins qu'avec la version gratuite, non ?

Ben cite un autre outil qui était selon toi à un niveau comparable à BK au moment ou Linus a migré.

> Ouai, mais Linus a vraiment été très arrogant sur ce coup.

Linus arrogant ? C'est un pléonasme ;-)

> Rien ne permet de prouver que l'accélération de l'inclusion des nouveautés dans le noyau est due à BK.

Je pense que Linus est bien mieux placé que nous deux pour en juger, et il est plus que clair là dessus.

> l'absence de noyau 2.7, etc.

L'abscence de noyau 2.7, elle est due a la possibilité de tester les patchs dans des branches différentes avant inclusion dans la mainline. Tu te vois sérieusement faire ça avec CVS ?

> Et s'il avait demandé à la communauté de développer un outil proposant les
> mêmes fonctionalités que bitkeeper au moment où il a décidé de l'adopter, tu
> ne penses pas qu'il y aurait des solutions beaucoup plus évoluées à l'heure actuelle?

C'est un peu ce qu'il s'est passé, non ? Arch est né avec comme objectif affiché de remplacer BK pour le kernel par exemple. Linus dit dans son mail: « I sure had hoped that it would have happened only once there was a reasonable open-source alternative. », ce qui veut bien dire qu'il aurait migré vers une solution open-source si elle avait été a la hauteur.

La licence de BitKeeper fait ch**r, tout le monde préfère que Linux utilise autre chose. En attendant, je suis bien content d'avoir un noyau Linux qui marche bien avec un développement actif et rapide. C'est en partie grace a BK, on ne peut pas le nier.

> IBM ou les autre paieraient sans doute, non ?

Ben justement, pas tous les autres.

Un des rôles de Torvalds, c'est d'animer une communauté autour du noyau. BitKeeper était déjà source de conflits avec la version gratuite, là, c'est la goute d'eau qui fait déborder le vase. La bourde, ça serait de continuer avec BK. Cf. son mail sur la lkml ou il explique ça très bien.

http://lkml.org/lkml/2005/4/6/121(...)

> maintenant il l'a dans le cul...

A mon avis non. Si Torvalds n'avait pas migré vers BitKeeper, il y a pas mal de gens qui seraient restés a CVS sans se poser de questions. Le coup de pied dans la fourmilière a permis de montrer qu'on pouvait faire mieux, et du coup, des alternatives intéressantes se développent.

Résultat, d'ici quelques mois, il aura quelque chose de comparable a BitKeeper en open-source. Ça n'aurait probablement pas été le cas autrement.