La surprise de W7 que l'on attendit pas...

> >>         Ça pose de _gros_ problèmes, comme une émulation des signaux posix
>> et RT avec des pipes et d'autres joyeusetés de ce type. Le seul BSD qui
>> est à peu près conforme, c'est FreeBSD. Suivi par NetBSD (mais d'a ssez
>> loin en raison du nombre de ports). OpenBSD est carrément hors de
>> propos. Maintenant, le vrai troll, c'est FreeBSD contre Linux (et là ,
>> c'est la gestion des paquets qui tranchera).

>>         JKB

> C'est bien ce que je dis : tu es dans un contexteparticulier : le
> temps réel. hords de ce contexte, NetBSD n'est pas un mauvais choix,
> loin de là.

        J'aimerais que tu m'explique en quoi sigaltstack() ou sig pending()
sont des appels système temps réel.

C'est toi qui le dit (RT = Temps réel non ?) mais effectivement en
te relisant il n'yy a pas _que_ le RT ... Cela dit je ne suis pas
développeur mais admin/utilisateur et ces problèmes de signaux ne me
concernent pas trop ....

>> Ça pose de _gros_ problèmes, comme une émulation des sig naux posix
>> et RT avec des pipes et d'autres joyeusetés de ce type.

Le 09-03-2009, ? propos de
Re: La surprise de W7 que l'on attendit pas...,
totof2000 ?crivait dans fr.comp.os.linux.debats :

>>         Ça pose de _gros_ problèmes, comme une émulation des signaux posix
>> et RT avec des pipes et d'autres joyeusetés de ce type. Le seul BSD qui
>> est à peu près conforme, c'est FreeBSD. Suivi par NetBSD (mais d'assez
>> loin en raison du nombre de ports). OpenBSD est carrément hors de
>> propos. Maintenant, le vrai troll, c'est FreeBSD contre Linux (et là,
>> c'est la gestion des paquets qui tranchera).

>>         JKB

> C'est bien ce que je dis : tu es dans un contexteparticulier : le
> temps réel. hords de ce contexte, NetBSD n'est pas un mauvais choix,
> loin de là.

        J'aimerais que tu m'explique en quoi sigaltstack() ou sigpending()
sont des appels système temps réel.

C'est toi qui le dit (RT = Temps réel non ?) mais effectivement en
te relisant il n'yy a pas _que_ le RT ... Cela dit je ne suis pas
développeur mais admin/utilisateur et ces problèmes de signaux ne me
concernent pas trop ....

C'est beau de botter en touche. Et bien si, ce genre de problème te
concerne parce qu'il faut patcher les sources pour compiler sous Open et
sous Net en tournant autour des bugs ou des pseudo-limitations de
sécurité en en rajoutant d'autres.

JKB

--
Le cerveau, c'est un véritable scandale écologique. Il représente 2% de notre
masse corporelle, mais disperse à lui seul 25% de l'énergie que nous
consommons tous les jours.

Le 09-03-2009, ? propos de
Re: La surprise de W7 que l'on attendit pas...,
totof2000 ?crivait dans fr.comp.os.linux.debats :

On 9 mar, 13:35, JKB <knatsc...@koenigsberg.fr> wrote:

Le 09-03-2009, ? propos de
Re: La surprise de W7 que l'on attendit pas...,
 totof2000 ?crivait dans fr.comp.os.linux.debats :







>> >>         Exemples. J'ai des routeurs avec treize cartes ethernet (trois Quad
>> >> Sun et un Happymeal) qui tournent avec des scripts _très_ clairs.
>> > Tu peux envoyer quelques exemples que l'on puisse comparer ?

>>         Juste une partie qui concerne les trois premières interfaces :

>> [0:0] -A FORWARD -i eth0 -o eth1 -p tcp -m tcp --dport ftp -j ACCEPT
>> [0:0] -A FORWARD -i eth0 -o eth1 -p tcp -m tcp --dport ssh -j ACCEPT
>> [0:0] -A FORWARD -i eth0 -o eth1 -p tcp -m tcp --dport gopher -j ACCEPT
>> [0:0] -A FORWARD -i eth0 -o eth1 -p tcp -m tcp --dport http -j ACCEPT
>> [0:0] -A FORWARD -i eth0 -o eth1 -p tcp -m tcp --dport pop3 -j ACCEPT
>> [0:0] -A FORWARD -i eth0 -o eth1 -p tcp -m tcp --dport imap -j ACCEPT
>> [0:0] -A FORWARD -i eth0 -o eth1 -p tcp -m tcp --dport pop3s -j ACCEPT
>> [0:0] -A FORWARD -i eth0 -o eth1 -p tcp -m tcp --dport imaps -j ACCEPT
>> ...
>> [0:0] -A FORWARD -p icmp -j ACCEPT
>> [0:0] -A FORWARD -i eth0 -o eth2 -p tcp -m tcp --dport http -j ACCEPT
>> [0:0] -A FORWARD -m state --state RELATED,ESTABLISHED -j ACCEPT
>> [0:0] -A FORWARD -m state --state INVALID -j DROP
>> ...
>> [0:0] -A PREROUTING -d 192.168.0.81 -p tcp -m tcp --dport http -jDNAT
>> --to-destination 192.168.0.81:8000
>> [0:0] -A PREROUTING -s 192.168.0.83 -p tcp -m tcp --dport smtp -jMARK
>> --set-mark 1
>> [0:0] -A POSTROUTING -s 192.168.0.0/255.255.255.0 -j MASQUERADE
>> ...

> Mouais ... Je préfère largement les règles à a PF ou IPF .... Déjà là
> il faut savoir ce que signifient les "-A", "-m", "-o", "-j", avec
> parfois iun seul "-"  ou deux "-"  ...

        C'est au contraire _très_ clair.

> La au premier abord je ne sais pas ce que font tes règles .....
> En creusant un peu je suppose que :
>  -i eth0 : interface d'entrée
>  -o eth2 : interface de sortie
>   -j ACCEPT : tu laisse passer
>    -d port : tu définis le port sur lequel s'applique la règle

> Pour le reste faut que je creuse, pas le temps pour le moment (j'ai du
> taf à faire cet AM, peut être ce soir ...)

> Je n'ai pas le temps de chercher à traduire pour le moment mais faire
> la même chose avec IPF ou PF est à mon avis bien plus clair ...

        Non. J'attends pour voir la simplicité des règles IPF.

Déjà le fait que d'un premier coup d'oeil je ne puisse pas avoir une
idée de ce que ont tes règles est très révélateur ....

Une règle IPF ou PF peut être comprise facilement par quelqu'un qui ne
connait pas la syntaxe au premier abord .... Note que je met IPF et
PF dans le même sac : je m'intéresse à PF que depuis peu de temps,
cependant syntaxiquement il est très proche d'IPF.

J'ai demandé un _exemple_.

--
Le cerveau, c'est un véritable scandale écologique. Il représente 2% de notre
masse corporelle, mais disperse à lui seul 25% de l'énergie que nous
consommons tous les jours.

On 9 mar, 13:35, JKB <knatsc...@koenigsberg.fr> wrote:

Le 09-03-2009, ? propos de
Re: La surprise de W7 que l'on attendit pas...,
 totof2000 ?crivait dans fr.comp.os.linux.debats :

        C'est au contraire _très_ clair.

Non. Lorsque j'ai du choisir entre IPF et IPTABLE, j'ai choisi IPF car
j'arrivais à comprendre ce qu'une règle faisait sans avoir à passer
trois mois à retenir une syntaxe qui tient plus de l'incantation
vaudoue que d'une phrase simple. Ca revient à comparer la syntaxe de
Perl et de Python ou ruby pour faire de la POO.

> La au premier abord je ne sais pas ce que font tes règles .....
> En creusant un peu je suppose que :
>  -i eth0 : interface d'entrée
>  -o eth2 : interface de sortie
>   -j ACCEPT : tu laisse passer
>    -d port : tu définis le port sur lequel s'applique la règle

> Pour le reste faut que je creuse, pas le temps pour le moment (j'ai du
> taf à faire cet AM, peut être ce soir ...)

> Je n'ai pas le temps de chercher à traduire pour le moment mais faire
> la même chose avec IPF ou PF est à mon avis bien plus clair ...

        Non. J'attends pour voir la simplicité des règles IPF .

Soit, Je te le fais dès que j'ai 5 mn ... euh ... non c'est de Linux
dont on parle et vu la syntaxe i me faudra bien 15 mn par ligne pour
comprendre ce que tu fais avec tes règles .... donc je feraiça dans le
train en rentrant du taf .... En 1 heure de trajet je devrais pouvoir
torcher 3 ou 4 règles .... Mais la premiere étape c'est de trouver une
doc de référence ...

On 9 mar, 14:09, JKB <knatsc...@koenigsberg.fr> wrote:

Le 09-03-2009, ? propos de
Re: La surprise de W7 que l'on attendit pas...,
 totof2000 ?crivait dans fr.comp.os.linux.debats :
> C'est toi qui le dit (RT = Temps réel non ?)   mais effectivement en
> te relisant il n'yy a pas _que_ le RT ... Cela dit je ne suis pas
> développeur mais admin/utilisateur et ces problèmes de signaux ne m e
> concernent pas trop ....

        C'est beau de botter en touche. Et bien si, ce genre de p roblème te
concerne parce qu'il faut patcher les sources pour compiler sous Open et
sous Net en tournant autour des bugs ou des pseudo-limitations de
sécurité en en rajoutant d'autres.

Je ne botte pas en touche : le développeur corrige le bug et fournit
le patch. La façon dont il a contourné un autre bug ou un défaut de
compatibilité posix ne me concerne que de très loin. Mon problème
c'est effectivement de pouvoir patcher dans des conditions
acceptables, mais c'est un autre problème qui n'est pas propre à BSD
ou à Linux.

Le 09-03-2009, ? propos de
Re: La surprise de W7 que l'on attendit pas...,
totof2000 ?crivait dans fr.comp.os.linux.debats :

On 9 mar, 14:09, JKB <knatsc...@koenigsberg.fr> wrote:

Le 09-03-2009, ? propos de
Re: La surprise de W7 que l'on attendit pas...,
 totof2000 ?crivait dans fr.comp.os.linux.debats :
> C'est toi qui le dit (RT = Temps réel non ?)   mais effectivement en
> te relisant il n'yy a pas _que_ le RT ... Cela dit je ne suis pas
> développeur mais admin/utilisateur et ces problèmes de signaux ne me
> concernent pas trop ....

        C'est beau de botter en touche. Et bien si, ce genre de problème te
concerne parce qu'il faut patcher les sources pour compiler sous Open et
sous Net en tournant autour des bugs ou des pseudo-limitations de
sécurité en en rajoutant d'autres.

Je ne botte pas en touche : le développeur corrige le bug et fournit
le patch. La façon dont il a contourné un autre bug ou un défaut de
compatibilité posix ne me concerne que de très loin. Mon problème
c'est effectivement de pouvoir patcher dans des conditions
acceptables, mais c'est un autre problème qui n'est pas propre à BSD
ou à Linux.

Un développeur développe soit un truc moisi dans un coin qui compile
au petit bonheur la chance, soit un programme qui suit telle ou telle
spécification qu'on appelera POSIX, POSIX-2001, SysVx, BSDx ou autre.
Lorsqu'un appel système est marqué disponible sur un OS, il _doit_
suivre les spécifications car le développeur initial n'a aucun moyen de
tester _tous_ les cas de figure. Rajouter un patch pour un OS dans un
coin, un autre pour un autre OS ailleurs dans le programme, c'est au
mieux avoir la certitude de ne plus rien comprendre dans un futur assez proche,
au pire, avoir des programmes qui se comporent bizarrement dans certains
cas. Le problème n'est effectivement pas limité à Linux ou aux BSD et
est général, mais force est de constater que ce problème se pose pour
au moins Net et OpenBSD.

Je vais arrêter là, tu me fatigues.

JKB

--
Le cerveau, c'est un véritable scandale écologique. Il représente 2% de notre
masse corporelle, mais disperse à lui seul 25% de l'énergie que nous
consommons tous les jours.

>         Tu réponds à côté de la plaque. Lorsque pour une raison de sécurité,
tu es contraint à recompiler toutes les dépendances de ton systèmes , tu
aimerais bien une gestions de paquets _binaires_ passant par autre chose
qu'un pkgsrc.

mouais ... Enfin quand je met à jour :
- je recompile le package et ses dépendances dans un environnement
vierge. Je me retrouve ainsi avec un ensemble cohérent de packages
binaires précompilés
- j'installe ensuite via pkg_add avec les options de mise à jour (-
u) le (ou les) packages que je veux mettre à jour
- en cas de problème (conflit avec d'autres packages) c'est du cas
par cas ... Mais jusqu'à aujourd'hui je n'ai rien rencontré
d'insurmontable. En tout cas Debian n'est pas exempt non plus de ces
problèmes ... La gestion des dépendances est peut être un peu mieux
foutue que sous NetBSD, mais bon ... pour ma part j'ai appris Linux
avec une Slackware donc côté gestion des dépendances, NetBSD c'est
toujours mieux ....

>         Un développeur développe soit un truc moisi dans un c oin qui compile
au petit bonheur la chance,

C'est malhereusement souvent le cas (et pas que dans le LL)

soit un programme qui suit telle ou telle
spécification qu'on appelera POSIX, POSIX-2001, SysVx, BSDx ou autre.

D'accord avec toi ... Mais en général, ceci ne concerne que les
couches basses d'une appli non ? N'y a-t-il pas moyen (sauf cas
particulier), d'encapsuler ces spécifications pour que ce soit
portable sur des archi n'implémentant pas ces normes ? (c'est une
question : je ne suis pas développeur, j'ai just fait un peu de
developpement dans ma jeunesse et je suis loin de maitriser tous les
aspects que tu évoques).

Lorsqu'un appel système est marqué disponible sur un OS, il _doit_
suivre les spécifications car le développeur initial n'a aucun moyen de
tester _tous_ les cas de figure.

Je n'ai jamais dit le contraire ... mais ça reste une utopie car
aucun OS n'est dépourvu de bugs

Rajouter un patch pour un OS dans un
coin, un autre pour un autre OS ailleurs dans le programme, c'est au
mieux avoir la certitude de ne plus rien comprendre dans un futur assez p roche,
au pire, avoir des programmes qui se comporent bizarrement dans certains
cas.

Ce n'est pas forcément au développeur initial de s'occuper du portage
pour telle ou telle archi, mais s'il organise bien son code, n'y a-t-
il pas moyen d'isoler les parties concernées dans des bibliotèques
adaptées et laisser les gens qui portent les applis gérer ces
particularités ?

Le problème n'est effectivement pas limité à Linux ou aux BSD et
est général, mais force est de constater que ce problème se pose po ur
au moins Net et OpenBSD.

Pour OpenBSD : je ne connais pas suffisamment pour juger donc je n'en
parlerai pas. Pour NetBSD, si on le compare à Linux, il est normal que
les bugs soient plus vite corrigés, car le nombre de développeurs est
moins important sous NetBSD, pour un nombre d'archi supporté quasi
identique ( peut-être un peu plus pour NetBSD).

        Je vais arrêter là, tu me fatigues.

Tu me déçois, je te pensais plus endurant ..... Ca change de la
Troidé et de Windows non ?

Le 09-03-2009, ? propos de
Re: La surprise de W7 que l'on attendit pas...,
totof2000 ?crivait dans fr.comp.os.linux.debats :

        Un développeur développe soit un truc moisi dans un coin qui compile
au petit bonheur la chance,

C'est malhereusement souvent le cas (et pas que dans le LL)

soit un programme qui suit telle ou telle
spécification qu'on appelera POSIX, POSIX-2001, SysVx, BSDx ou autre.

D'accord avec toi ... Mais en général, ceci ne concerne que les
couches basses d'une appli non ? N'y a-t-il pas moyen (sauf cas
particulier), d'encapsuler ces spécifications pour que ce soit
portable sur des archi n'implémentant pas ces normes ? (c'est une
question : je ne suis pas développeur, j'ai just fait un peu de
developpement dans ma jeunesse et je suis loin de maitriser tous les
aspects que tu évoques).

Je vais te donner un seul exemple. Je développe des outils de calcul
parallèle. Pour cela, je me limite aux spécifications strictement
POSIX-2001 (c'est un choix qui en vaut un autre). Je pars donc du
principe que sur tous les OS POSIX-2001, mon code va fonctionner de la
même façon, et ce n'est _pas_ le cas. Il faut coller des rustines un peu
partout. Résultat, j'ai des fichiers .h différents selon les OS et les
processeurs (donc un solaris.h qui redéfinit le malloc, parce que le
malloc de la libc marqué comme thread safe dans la doc ne l'est pas !).
Tu te retrouves au final avec des rustines, avec des patches qui
consistent à tourner autour d'un problème parce que tu te rends compte
au bout de cinq ans de développement que NetBSD (pour ne pas le citer)
ne se comporte pas correctement et que tu es contraint au bricolage pour
contourner un problème dans un code qui ne s'y prête plus. Et je ne
parle pas de trucs foireux comme les chaînes statiques ou allouées
renvoyées par certaines fonctions ou du caractère soi-disant thread-safe
de dlsym(). Bref, je passe plus de temps à contourner les bugs
intrinsèques des différents OS qu'à implanter des algorithmes.

Lorsqu'un appel système est marqué disponible sur un OS, il _doit_
suivre les spécifications car le développeur initial n'a aucun moyen de
tester _tous_ les cas de figure.

Je n'ai jamais dit le contraire ... mais ça reste une utopie car
aucun OS n'est dépourvu de bugs

Je viens de remonter un bug à Sun dans Solaris 10/sparc (carrément
dans la libc qui se vautre dans des free() sur un mutex dans certains
contextes). Je mets ma main à couper que le truc sera corrigé très vite.
J'ai remonté les trucs que j'ai trouvé aux équipes d'OpenBSD, je me suis
fait bouler parce que la spécification POSIX n'était pas 'secure'. Ques
Net, ils sont plus réactifs. Tout ça pour dire que les bugs existent.
Faut-il encore vouloir les corriger.

Rajouter un patch pour un OS dans un
coin, un autre pour un autre OS ailleurs dans le programme, c'est au
mieux avoir la certitude de ne plus rien comprendre dans un futur assez proche,
au pire, avoir des programmes qui se comporent bizarrement dans certains
cas.

Ce n'est pas forcément au développeur initial de s'occuper du portage
pour telle ou telle archi, mais s'il organise bien son code, n'y a-t-
il pas moyen d'isoler les parties concernées dans des bibliotèques
adaptées et laisser les gens qui portent les applis gérer ces
particularités ?

Ce n'est pas simple du tout. On peut raisonnablement penser qu'un
signal sera traité correctement partout parce que les fonctions en
question sont d'assez haut niveau.

Le problème n'est effectivement pas limité à Linux ou aux BSD et
est général, mais force est de constater que ce problème se pose pour
au moins Net et OpenBSD.

Pour OpenBSD : je ne connais pas suffisamment pour juger donc je n'en
parlerai pas. Pour NetBSD, si on le compare à Linux, il est normal que
les bugs soient plus vite corrigés, car le nombre de développeurs est
moins important sous NetBSD, pour un nombre d'archi supporté quasi
identique ( peut-être un peu plus pour NetBSD).

Pas compris. S'il y a moins de développeurs, cela devrait être plus
lent, non ?

        Je vais arrêter là, tu me fatigues.

Tu me déçois, je te pensais plus endurant ..... Ca change de la
Troidé et de Windows non ?

Ça fait huit jours que je dépiote la libdl de Solaris pour trouver
un bug enfoui. Un truc qui fait que de temps en temps, en contexte
multithreadé, dlsym() renvoit NULL sur un point d'entrée _existant_.
Ça finit par miner mon endurance.

JKB

--
Le cerveau, c'est un véritable scandale écologique. Il représente 2% de notre
masse corporelle, mais disperse à lui seul 25% de l'énergie que nous
consommons tous les jours.

> > Pour OpenBSD : je ne connais pas suffisamment pour juger donc je n'en
> parlerai pas. Pour NetBSD, si on le compare à Linux, il est normal qu e
> les bugs soient plus vite corrigés, car le nombre de développeurs e st
> moins important sous NetBSD, pour un nombre d'archi supporté quasi
> identique ( peut-être un peu plus pour NetBSD).

        Pas compris. S'il y a moins de développeurs, cela devra it être plus
lent, non ?

Oui, je me suis mal exprimé désolé ( voila ce qui se passe quand on
fait trop de choses en même temps) :
Reformulé ça donne :
Pour NetBSD, si on le compare à Linux, il est normal que les bugs
soient moins vite corrigés car le nombre de développeurs est moins
important sous NetBSD, pour un nombre d'archi supporté quasi identique.