J'adore SQL, les regexp, Caml dans son aspect filtrage de type + type somme, bref tous ces "métalangage" où je me contente de définir en déclaratif ce que je veux obtenir sans me prendre la tête à expliquer à la machine comment elle va faire.

hm est-ce que ça "mérite" vraiment le titre de "metalangage" parce que c'est plutôt déclaratif qu'impératif ? Utilisé à bon escient c'est certes très supérieur à un spaghetti impératif buggué et 30x plus long, mais je vois pas pourquoi ça serait "méta" pour autant ? Je mettrais plus volontier du "méta" sur les trucs du genre bison.

[ Répondre ]

Je suis d'accord. Ma réaction faisait suite à ton passage concernant "3 processeurs différents" : je disais simplement que l'environnement était souvent plus primordial que le processeur en soit - si je prend un soft quelconque et ciblant GNU/Linux, codé par quelqu'un qui a entendu parlé une fois dans sa vie de little et de big endian (et du nombre de bits des mots machines) et qui a fait attention depuis (ou alors tout simplement si le soft n'est pas susceptible d'être affecté par l'endianess), il n'y aura pas de problème à le porter sur un autre processeur - gcc + glibc feront tout le boulot (ou la VM Java ou Python ou whatever - auxquels cas on n'a souvent - mais pas toujours - même plus besoin de se soucier des mots machines)

Maintenant si tu changes, au delà du simple changement d'ISA du processeur, un truc quelconque de l'environnement (compilateur, bibliothèques, noyau, implémentation de la VM) là tu as beaucoup plus de risques de mettre à jour des problèmes de portabilité.

[ Répondre ]

Les pilotes de cartes réseau sont en général assez simple et peu buggués... et quand on considère le système complet choisir de faire le test en tuant le pilote de la carte réseau et biaisé car le support de l'userspace est probablement très bon dans sa globalité en ce qui concerne les coupures impromptues du réseau. De plus les pilotes et stacks réseaux interagissent peu avec le reste du système.

Un test plus intéressant consisterait à tuer le pilote du HD alors que le système est à pleine charge d'un peu tout et n'importe quoi (et en train de swapper, gniarf :P ) et de voir ce qu'il se passe.

Dans la série des problèmes ouverts il faudrait aussi voir comment intégrer les monstrueux pilotes actuels de carte graphique dans un tel environnement, avec de bonnes performances. Bref tout un programme, qui reste encore dans le domaine de la recherche.

la conception de MINIX3 est plus solide face à Linux si on compare la tolérance aux pannes.

Peut-être vis à vis de certaines défaillances soft ; mais de toute manière les systèmes fault-tolerant ont tendance à être complètement redondant au niveau matériel et il y a des cas où ça peut mitiger le risque de défaillance soft, alors est-ce que tous les inconvénients valent la peine, alors même que les systèmes Linux sont déjà très fiable (et rapide) ?

Je vois un domaine où les micro-noyaux peuvent apporter un énorme plus : les phases de développement et mise au point sont grandement facilitées.

[ Répondre ]

La très grande majorité des verrous ne pose pas de problème de contention. Lorsqu'il y a un problème de contention, il est structurel et confiné à un niveau très fin (du moins dans Linux, qui utilise une politique de verrouillage fin), et le problème ne disparaîtrait pas magiquement par l'emploi d'un micro-noyau et le déport de la gestion de la ressource dans un processus (selon les cas il pourrait même au contraire être exacerbé).

De plus les systèmes asynchrones introduisent leur propres soucis (précisément du fait de l'asynchronisme) et dans la pratique ils sont de plus souvent partiellement encapsulés dans une couche supplémentaire pour fournir des services synchrones... L'overhead par rapport à un appel de fonction classique est ... grand.

Linux utilise aussi des primitives thread-safe lock-free très avancées et très performantes (ex: RCU) qu'il serait probablement très difficile (si ce n'est impossible) d'adapter pour l'userspace.

Dans certains cas les spinlocks conviennent tout à fait et la solution serait nécessairement plus complexe en userspace, par exemple pour de la communication ISR / partie synchrone d'un driver, sous certaines hypothèses.

Pour finir l'expérience a montré que le confinement des défaillances qu'on pensait être une des killer feature des micro-noyau n'est pas si effectif que cela (le système peut tout de même s'effondrer par effet domino dans de nombreux cas), en plus de n'être plus si nécessaire aujourd'hui (les noyaux modernes plantent peu).

[ Répondre ]

J'espère que ce qu'ils considèrent être de la programmation fonctionnelle est autre chose que des immondices illisibles (et accessoirement indébuguable, je parle d'expérience... :/ ) à base de templates qui nécessitent l'emploi d'adaptateurs dans tous les sens pour des raisons techniques dont ne devrait surtout pas se soucier le développeur (ex: mem_fun)

histoire de fixer les idées, voici ce qu'on peut lire dans GnuGK :

return InternalFind(compose1(bind2nd(equal_to<H225_EndpointIdentifier>(), epId),
mem_fun(&EndpointRec::GetEndpointIdentifier)));


(où pour couronner le tout InternalFind est bien sûr lui même une template)

ce qui signifie à peu près, dans un langage intelligible par un être humain normal et sans à avoir à apprendre des foisons de symboles supplémentaires :

return InternalFind(lambda x: (x.GetEndpointIdentifier() == epId))


Bref si ça progresse vers quelque chose de moins sataniste que l'exemple cité ci-dessus, c'est une bonne chose. Sinon il faudrait mieux interdire aux gens de faire du mauvais fonctionnel inutile en C++, car ce n'est pas maintenable par quelqu'un qui ne passe pas sa vie à étudier ce langage et ses "subtilités" (pour rester poli).

En passant l'emploi d'une approche pseudo fonctionnelle et donc d'une syntaxe aussi biscornue ne se justifiait absolument pas ici en pratique, une boucle avec un return quand l'élément est trouvé aurait été bien plus compréhensible, maintenable et débuguable.

La syntaxe et la nécessité de compenser des faiblesse structurelles du langages (mem_fun + besoin de noter explicitement H225_EndpointIdentifier, sans même parler de l'opérateur == qui visuellement n'est plus repérable) disqualifie donc en pratique une approche qui pourtant peut être considérée comme conceptuellement supérieure.

[ Répondre ]

Si tu as développé un peu du code sur 3 processeurs différents, tu sais que faire cela permet de découvrir plein de bogue...

Bah il y a au moins deux solutions pour écrire du code userspace portable du point de vue du CPU, du premier coup :

1) utiliser un langage dont le runtime est à base de VM
2) si on ne fait pas 1, ne pas coder comme un gruik, faire attention. (marche aussi pour les drivers simples en kernel space)

L'environnement est généralement bien plus problématique que le CPU qui impacte généralement guère plus que big/little endian 32 / 64 bits - ce qui est trivial à gérer moyennant un peu de concentration. Par exemple j'ai déjà codé un soft pour cible POSIX testé sous GNU/Linux, AIX, HP-UX, Solaris et j'en passe, et faisant du GNU d'habitude je me suis laissé allé à croire que strtod() retourne tout le temps 0 quand on lui file une chaîne vide, ce qui n'est pas le cas sous AIX. On peut aussi voir des comportement différents selon les système quand on met LC_NUMERIC en français : des fois la virgule est utilisée, des fois le point.

[ Répondre ]

C'est un progrès vers quelque chose de sensé. Peut-être que dans 10 ans ils introduiront le concept de foreach ? :p (et dans trente la citoyenneté de première classe des fonctions, révons un peu !)

[ Répondre ]

Si on en croit http://www.celog.fr/cpi/lv1_tt1.htm#8 :

"L'existence d'un contrat de commande de logiciel n'entraîne pas la cession automatique au commanditaire des droits afférents au logiciel."

Faute d'accord préalable, le développeur est donc probablement dans son droit.

[ Répondre ]

c'est mal

[ Répondre ]

Ça doit être une justification postmoderne aux langages SMS et Skyblog ?

[ Répondre ]

'fin je reviens de voir "Entre les murs" et je risque de pondre un texte sur la question...

J'attends ça avec impatience :)

Pour en revenir sur la théorie et la pratique, je voudrais juste rajouter que je rejoindrai absolument tous ceux qui pensent que la manière la plus simple, efficace, etc... d'enseigner/apprendre est d'illustrer par du très concret - même si ça n'atterrit pas forcement dans un domaine d'application, souvent la métaphore suffit (enfin je parle du niveau collège / lycée, évidement y a des concepts de maths du supérieur qui sont... difficilement projetable dans la vie de tous les jours) Quand j'étais au lycée c'est comme ça que je comprenais tout ce qu'on me racontait en physique (en m'imaginant des trucs moi même dans les cas où le prof n'avait pas pris la peine), et j'ai par la suite donné quelques cours de soutiens (maths / physique) qui m'ont conforté dans cette opinion.
Mes petites représentation mentales ont même continuées à m'aider dans une certaines mesure en prépa (genre ne serait-ce qu'imaginer pleins de petits electrons dans un tuyau quand on fait de l'elec, hm je dirais que c'est merveilleux :p )

[ Répondre ]

Aujourd'hui avec mes élèves j'ai parlé de l'éclipse de Soleil de 1999. Pourquoi la Lune et le Soleil paraissent avoir la même taille alors que le Soleil est beaucoup beaucoup plus gros que la Lune ? Ai-je fait de l'hyper théorie ?

On fait plus Thalès au collège mais au lycée ?

[ Répondre ]

oups j'avais loupé ton paragraphe sur les profs.

Mais je persiste !

C'est à eux de donner des exemples d'application au lieu de "réciter" bêtement ! (remarque la thermo, je sais pas pourquoi j'ai _toujours_ détesté, même si je savais très bien que ça sert à faire des frigo entre autre)

[ Répondre ]

J'pense que le problème principal c'est que t'as eu de mauvais profs.

[ Répondre ]

Je ne résiste pas à l'envie de résumer la thèse de l'article du dernier lien du commentaire parent :

Puisque Flemming n'a pas "protégé" la pénicilline en soit (ce qui est interdit et en plus l'article cite Flemming lui même qui résume parfaitement la situation: il n'a rien inventé ! mais bon, passons), personne ne s'est lancé dans la recherche d'un procédé de fabrication.

Bref Pierre Bresse énonce que cela a retardé (relation de causalité au moins partielle) le développement d'une application industrielle.

J'aimerais lui demander comment cela aurait-il pu se faire que les industriels eussent été au contraire ravis de la présence d'une "protection", chose qui, sauf si je n'ai absolument rien compris au concept de "protection", n'aurait que pu les freiner plus que l'absence de protection...

Grand maître de l'absurde, ce Pierre Breese ! J'espère qu'il existe des défenseurs des brevets qui emploient des raisonnement plus rationnels... (si, si, sincèrement ! :) )

Et où par la suite on apprend de toute façon par d'autres sources (commentaire) que les procédés de fabrication ont bien été brevetés, et que ce sont des causes techniques qui ont retardé le développement de la pénicilline. On a eu le droit à un combo déformation de l'histoire + absurdité du raisonnement !

Enfin, c'est sans étonnement que j'apprends grâce à Google qu'il défend les brevets logiciels : http://www.zdnet.fr/actualites/informatique/0,39040745,39125(...) (attentions multiples raisonnements du même acabit dans cette interview)
D'un autre coté ça me donne un peu d'espoir : je me dis que s'ils avancent des arguments de ce style à chaque fois et que leurs interlocuteurs analysent un peu leurs discours, ils pourront débusquer les supercheries et les arnaques.

[ Répondre ]

Sauf que dans le contexte libéral amoral actuel, tu peux te gratter pour obtenir une définition pragmatique de "assez".

Déjà qu'on autorise les salaires délirant sans limitation, vouloir mettre des limitations comme celles là au coeur du système est voué à l'échec. (pcq d'une certaine manière ça contribuerait à limiter les salaires indécents et qu'aucun responsable n'est prêt à limiter les salaires indécents)

[ Répondre ]

T'es sur de tout ce que t'avances ? Si oui ça vaut ptet le coup de prévenir le Software Freedom Law Center si ya toujours BusyBox dessus (cf. http://www.busybox.net/license.html )

[ Répondre ]

Attention à ne pas leur donner de mauvaises idées / les titiller dans le mauvais sens, car le multiposte tu l'as déjà sans boiboite (via des protocols et codecs standards sur ton ordinateur). Donc si pour eux tenir la cohérence légalement revient à couper le multiposte quand t'as pas de boiboite à 5 euros, y'en a qui vont faire la gueule.

[ Répondre ]

Le problème c'est que le C est probablement plus "ambigu" que le Java quand on fait une erreur de syntaxe, surtout en ce qui concerne les proto et si on continue de supporter la syntaxe K&R.

De plus je ne me suis pas habitué à utiliser un IDE sous Linux lors de mes débuts sous cet OS et j'ai du mal à changer cette habitude - avant 2000 y'avait pas grand chose qui arrivait ne serait-ce qu'à la hauteur d'un bon vieux Turbo C sous DOS ergonomiquement parlant, et les vim et emacs étaient trop exotique de mon point de vue => je vais probablement faire dresser les cheveux sur la tête de quelqu'uns (et rappeler des souvenirs à d'autres) mais je codais sous mcedit à l'époque (sur un 486). Aujourd'hui X-Window me permet d'avoir autant de terminaux que je veux dans lesquels je mélange des builds et d'autres choses, donc je n'accroche pas plus sur les IDE - d'autant que je bosse typiquement sur un assez grand nombre de paquets, mais plutôt de manière très ponctuelle sur chaque, et que des grands coups de rgrep dans un shell donne de meilleurs résultats dans ce cas là.

[ Répondre ]

Ces erreurs 1145 erreurs dont 1144 faux positifs sont dues à la compilation d'un seul module (et plus précisement à l'absence d'_un_ ";" à la fin d'un prototype dans un header).

[ Répondre ]