Heh... Donc si je résume bien, une entreprise qui fait de l'argent ne devrait pas donner les specs pour *ahem* forcer les utilisateurs à passer à la version supérieure..
Derrière ce commentaire, il me semble poindre un jugement implicite sur les modalités nécessaires à "faire de l'argent" mais passons.
Les vrai problème pour la libération des specs sont:
* Utilisation du matériel en dehors des limites légales. C'est à ce sujet particulièrement vrai pour les puces wifi qui sont limités légalement en puissance selon les pays.
Or, les limites changent d'un pays à l'autre. Du coup, le puces wifi modernes sont concues avec des limites hardware en générale bien plus importante que ce que la loi autorise, et la limitation est alors logicielle, lors du chargement du microcode de la puce à l'initialisation du driver.
Libérer les specs, ici, c'est rendre possible l'utilisation en dehors des limites légales, à la responsabilité du constructeur. C'est aussi un argument important pour ne pas donner les sources des microcodes. Même si, on est d'accord, un hackeur expérimenté peux rétro-analyser les valeurs d'initialisation et arriver à contourner les limites légales.
* Concurrence: réveler les specs c'est aussi donner des informations sur le fonctionnement interne de la puce. Or ici, une entreprise investit beaucoup d'argent dans la conception de nouvelles technologies et n'a pas forcément envie de donner à ses concurrents le mode d'emploi pour reproduire leur puces..
Vala, c'est quand même autre chose que "faire de l'argent = manipuler le consomateur" et companie...
Mouais... D'expérience, les faille qui permettent de passer root n'ont souvent rien à voir là dedans. De base le technicien ou le développeur a accès à la base de données client en clair, et on parle plus d'un employé mal intentionné que d'une faille de sécurité..
Enfin, si il y a une faille de sécurité, mais je crois pas qu'elle se situe dans le noyau linux dans ce cas-là :-)
Ceci dit, sans nier que cela ait pu t'embêter, les failles dites de sécurité sont prétendument critiques à cause des risques majeurs, entendre financiers, qu'elle peuvent faire courir.
On lit souvent, dans la réponse au mail de Linus que j'ai cité, que les faille de sécurité sont la porte ouverte au *vol de centaines de cartes bleues* et autres conséquences exagérées.
Ici, je ne vois pas vraiment en quoi la faille est si problématique. D'ailleurs, en rêgle générale, les failles d'escalade de droits à partir d'un compte local me semblent toujours des failles secondaires, les principales étant celles qui permettent d'avoir un shell à partir d'une application distante...
Tout ça pour dire que le rush style « ouah encore une faille dans linux » et les « héros » de la sécurité style Brad Spengler, perso j'adhère pas, et je me sens plus proche de ce que dit Linus sur le sujet...
J'ai un peu du mal à capter la dangerosité de la faille. En particulier du fait que le bug permette une escalade de droits à partir d'un compte utilisateur normal.
Ainsi, par exemple, je ne me soucie pas trop de cette faille sur ma machine personelle. Je suis le seul à avoir un accès. D'autre part, si on parle d'accès distant sur un serveur, alors il y a de grandes chances que WINE et consors soient complètement hors-jeu, donc l'administrateur a juste à positionner le flag qui va bien, et je suis sur que c'est deja probablement le cas..
one reason I refuse to bother with the whole security circus is that I think it glorifies - and thus encourages - the wrong behavior.
It makes "heroes" out of security people, as if the people who don't just fix normal bugs aren't as important.
In fact, all the boring normal bugs are _way_ more important, just because there's a lot more of them. I don't think some spectacular security hole should be glorified or cared about as being any more "special" than a random spectacular crash due to bad locking.
C'est vrai. Enfin, la portabilité d'une application POSIX est de toute façon problématique sous windows, et cygwin a une API OSS, donc au final, OSS est aussi un bon choix dans ce cas.
ALSA est un echec tout simplement parce que les APIs de son sont un bordel sans nom sous linux alors même qu'ALSA était censé uniformiser cela.
L'API ALSA n'est satisfaisante pour personne. Ni assez documentée pour satisfaire les usages vraiment spécialistes, ni suffisament simple pour le reste.
Il suffit de regarder l'historique des sur-couche inventées pour parer à cela: arts, esound, jack, pulseaudio, etc etc... Elles ont toutes été inventées dans le même but: avoir une API plus "simple" et uniforme à utiliser que ALSA.
Si tu ajoute encore que chacune de ces couches émulent ALSA, OSS, et même plus ça devient vraiment toufu.
Implémenter le simple support d'un output audio sous linux est absolument cauchemardesque du point de vue du développeur, et je ne parle même pas des utilisateurs qui ne s'y retrouvent pas quand ils ont un pb de config.
Bah moi je comprend en tout cas.. et je crois que les autres lecteurs qui ont mis des bonnes notes aussi. Essaie de coder une simple application qui lise un fichier WAV avec OSS et ALSA et tu aura surement un début de réponse :-)
Ouais enfin ya aussi une lib userland livrée avec alsa, et elle ne le fait pas non plus, d'où la nécessité d'une nouvelle couche en plus...
Enfin l'argument de séparation kernel/userland n'est pas aussi simple que cela. Prend par exemple les périphériques video, c'est tout un bordel dans ce cas et on n'est pas encore sorti de l'auberge...
Héhé, j'avais oublié l'absence de documentation....
Juste pour donner un exemple simple, si on veux fixer le rate (la fréquence) des données communiquées à la carte son sous ALSA, on utilise la fonction:
snd_pcm_hw_params_set_rate_near
Qui retourne la valeur la plus proche possible du hardware... Et donc, tout le monde doit ensuite de demerder pour faire la conversion dans son coin..
OSS dans le noyau est mort depuis longtemps et aurait du effectivement être erradiqué depuis un moment.
En revanche, le développement d'OSS n'a jamais cessé, bien qu'il soit devenu un moment propriétaire, ce qui a surement attisé les esprits.
Maintenant, il faut aussi constater l'échec d'ALSA. C'est une API impossible, qui se voudrait à la fois bas niveau et haut niveau, et dont l'adoption par les applications simples type bureautique a été un echec flagrant.
Tous les programmeurs qui ont un jour voulu ajouter une simple sortie audio à leur programme linux doivent très bien connaitre le problème. Comparé à cela, l'API OSS était parfaite pour un usage grand public.
Résultat, on se retrouve avec des sur-couche supplémentaires, pulseaudio, jack et compagnie..
Ce n'est pas forcément une mauvaise chose, pourvu que, enfin, l'API d'un de ceux là, pulseaudio apparement, devienne standard ET relativement aisé à utiliser.
Maintenant vouloir eradiquer toutes les applications utilisant OSS est stupide. Cela fait deja un paquet d'années qu'ALSA est en place et si un nombre relativement important d'applications continuent d'utiliser OSS c'est bien que l'API ALSA est inutilisable pour eux.
Enfin il n'est pas exclu que les modules récents OSS fassent leur apparition en tant que module externes dans Debian, laissant le choix à l'utilisateur d'avoir ALSA ou OSS, puisque le logiciel libre est *aussi* une question de libre choix.
Et, comme les sur-couche pulseaudio et companie supportent OSS comme API de sortie, tout le monde devrait s'y retrouver...
Si, en plus, pulseaudio supporte l'émulation OSS plus correctement qu'ALSA il n'y a pas de raison de vouloir supprimer les applications utilisant OSS.
En fait, si j'ai bien compris, la directive SELinux de red hat autorise explicitement le mapping à l'adresse 0. C'est un premier problème.
Ce qui est maladroit c'est qu'il y a conflit entre deux directives. D'un coté un directive hors SELinux interdit de mapper à l'adresse zero, de l'autre une directive SELinux l'autorise.
Au final, en matière de sécurité, on voudrait toujours avoir comme combinaisons de plusieurs restrictions la restriction maximale. Ce n'est pas la cas ici, puisque SELinux permet alors d'affaiblir la sécurité du système en donnant la possibilité de contourner une autre directive de sécurité plus stricte.
Justement, Brad Spengler étant un personnage qui aime bien la polémique (voir son interview, le deuxième lien), et développant un concurrent direct de SELinux, je pense qu'il serait quand plus honnête de développer les problèmes et d'utiliser une terminologie moins partisane
Il y a d'un coté une faille du noyau linux portant sur l'execution de code mappé à l'adresse mémoire zero, c'est la faille.
De l'autre, il y a un mécanisme de protection générique, mmap_min_addr qui permet en théorie d'empecher l'exploitation de la faille.
Enfin il y a SELinux qui, du fait d'un mauvais design, permet de contourner le mécanisme de protection générique mmap_min_addr.
Du point de vue de SELinux, c'est plus un problème de « defect by design » qu'à proprement parler une « faille ». Le fonctionnement utilisé est celui prévu (maladroitement) par les developpeurs.
La simple façon de s'en rendre compte, c'est que sans la faille noyau, il n'y aurait rien à exploiter, SELinux ou pas...
A propos de la faille de sécurité SELinux et compagnie. Ce que le lis là: http://lwn.net/Articles/347006/
C'est qu'en fait la vraie faille concernait l'utilisation de certaines opérations sur les socket pour lesquelles les pointeurs définissant les opérations applicables sur la socket étaient non initialisés.
Ainsi, pour pouvoir exploiter la faille, il fallait alors faire remplir l'adressage mémoire initial, zero, avec la fonction à executer, et on se retrouve avec la possibilité d'exécuter n'importe quoi avec les droit root.
Ainsi, le paramètre qui permet de choisir un adressage mémoire minimal plus grand que zero est une façon d'empecher l'exploitation de la faille et non la faille elle-même.
Ce n'est pas ingénierie inverse mais ingénierie à rebours qui est écrit.
De plus, ce n'est pas parce qu'un mot vient du français qu'il recouvre le même sens en anglais. Par exemple tous les faux amis, comme eventually, ou encore actually.
Dans le cas d'ingénierie, le sens est différent puisque la notion d'engine, moteur, n'est pas présente dans le sens français.
Pour revenir au terme initial, je ne sais pas trop comment le traduire. En utilisant ingénierie, je dirai rétro-ingénierie, mais, encore une fois, appliquer le terme d'ingénierie à ce domaine est abusif. Pour ce qui est du code binaire, on peux dire décompilation, qui a à peu près le même sens, mais ne s'applique pas à un protocole par exemple.
En fait je « traduirai » en français soit par une périphrase, comme « analyse à postériori du fonctionnement du programme », ou alors carrément le terme d'origine, reverse engineering.
Je ne sais pas mais ingénierie à rebours me parait un très bon exemple d'une traduction abusive. Les mots sont bien traduits en français, mais le sens est resté le sens anglo-saxon..
Il se trouve que le terme "engineering" n'as pas exactement le même sens que "ingénierie". En particulier en anglais engine désigne aussi le moteur, ce qui fait marcher une machine. Du coup, "reverse engineering" peux se comprendre bien plus facilement: il s'agit de comprendre à l'envers comment fonctionne le "moteur".
En français au contraire, rien de tel. L'ingénierie désigne l'ensemble des processus liés à l'étude et la réalisation d'un projet. Du coup ingénierie à rebours on a l'impression que ça veux dire qu'on a fait un projet industriel à l'envers, ce qui n'a pas trop de sens...
Du coup au lieu de trouver un équivalent en français d'un terme anglo-saxon, on contribue à importer le sens anglo-saxon en français.
C'est aussi le cas lorsque l'on voit des traductions mot à mot de certaines expressions, comme "en terme de" etc..
Je trouve ça assez savoureux qu'au final traduire les expressions sans connaître assez bien la langue amène à importer, calquer le sens anglais sur les mots français.. !
Voila tout à fait le genre de réaction qui me pousse à lancer des trolls comme celui-ci..
Au fond, je comprend a 100% l'explication sur les différents mode de lecture donnée plus haut, et je ne suis pas franchement pour une réforme de l'orthographe qui, il est vrai, appauvrirait la langue.
Cependant, ce qui chagrine ce sont les différentes attitudes et jugements portés par les gens vis-à-vis de ces problèmes.
Non, cher Nonor, il n'est pas uniquement question de paresse. Cela devient même pire quant on en vient à prétendre que le type en face est un imbécile parce qu'il ne serait pas capable de faire la gymnastique logique nécessaire à une écriture correcte. D'ailleurs, le sujet favori de discussion en France à ce titre, ce sont les gens qui ont un poste ou une position considérée comme prestigieuse et qui font des fautes... Cela ne colle pas avec notre culture de l'apparence..
Qu'on ait une écriture riche et compliquée, ok, mais que cela devienne un prétexte à discrimination, jugement à l'emporte pièce, non.. Et encore plus quand le fond est complètement sacrifié sous prétexte qu'il y a trop de fautes..
Ou alors, pour comparer, on pourrait aussi prétendre que tous ceux qui n'installent pas linux from scratch sont des crétins finis...
Sauf qu'aucune langue véritablement parlée¹ n'a jamais été crée ex-nihilo... La langue est une oeuvre collective, et en ce sens sera toujours incohérente, évoutive et différente d'une région/personne à une autre.. That's how it is ! :)
¹: Ha si, l'espéranto a été parlé.. Pour donner des ordres aux esclaves en Afrique du Sud... Comme ça ils comprennaient pas la langue de leur maitres et apprenaient uniquement un fragment de l'espéranto nécessaire pour leur donner des ordres..
Quand une faute change le sens ou parasite le contexte, je suis d'accord.
Le problème étant que la majorité des fautes qui sont relevées relèvent en fait de l'ambiguïté de l'écrit par rapport à l'oral, et sont en fait des erreurs dues au fait que le français ajoute tout un tas de choses à l'écrit qui soit ne se prononcent pas, soit se prononcent exactement de la même façon.
Par exemple les sons o, au, eau; ou encore les conjugaisons non prononcées, comme il s'est tromper ou encore ils s'étai trompés etc...
Ces spécificités françaises sont absolument horribles pour les étrangers, qui peuvent très bien parler français, mais ont de gros problèmes à écrire correctement, voire même à lire (on dit Merine ou Mesrine.. ou les deux ?)
Prétendre que faire des fautes d'orthographe en français est un problème pour le sens, en ce sens, est je trouve, faux.
En général, les français répondent que ces spécificités écrites sont une trace du passé de la langue, comme les accents circonflexes mentionnent par exemple un s dans le vieux français (île par exemple).
Cependant, on peux pousser le troll un peu plus loin: si, au fond, un langage écrit est un outil de communication, pourquoi ne pas en faire un outil le plus simple possible d'utilisation.. C'est après tout la démarche rationnelle en général, comme pour linux et ubuntu par exemple.
Ainsi, pourquoi pas un langage écrit ou chaque son, chaque mot, s'écrit comme il se prononce ? Cela aura comme effet de permettre à un plus grand nombre de s'exprimer correctement, voire même d'éviter tout discrimination, puisque c'est aussi souvent le pb des gens qui écrivent avec des fautes..
D'ailleurs d'autres langues l'ont fait, l'espagnol par exemple...
Ha, oui, mais cela nous enlèverait la possibilité d'être pédant en reprenant les fautes des autres.. Culturellement inacceptable :-P
Idem, c'est un très bon créneau ce soft, et j'ai toujours été surpris que cela ne soit pas deja fait dans les distrib majeures. Pour les medias type mémoire flash, cela parrait meme etre un minimun de bon sens..
Plus généralement, je dis sans avoir trop lu, mais si tu vx vraiment avoir la classe, peut-être pourrais-tu voir pour rendre cela standard via freedesktop.org. D'ailleurs, encore une fois on se demande pourquoi ils l'ont pas deja fait...
Perso j'écris très souvent sans relire à fond, et je fais plein de fautes en général non volontaires.
En revanche, je remarque toujours qu'il n'y a que sur les forums français que systématiquement on trouve dans les 5 premiers commentaires un mec pour reprendre les fautes.
J'ai même contribué, tout du moins au début, avec un fort mauvais niveau d'anglais dans des forums/mailing list/etc.. et je n'ai *jamais* vu quelqu'un reprendre mes fautes.
Du coup j'ai tendance à penser que cette obession pour la correction des fautes semble culturellement bien franchouillarde..
PS: post sans correction, sinon ça serait tricher :)
Se pourrait-il que certains investisseurs précèdement tête brûlé prêt à investir dans une start-up prometteuse -- quitte, même, à verser dans l'utopisme en faisant confiance au logiciel libre -- se soient ravisés ?
[^] # Re: Et la doc du matériel alors?
Posté par Romain Be. . En réponse à la dépêche Broadcom prend le large. Évalué à 1.
Derrière ce commentaire, il me semble poindre un jugement implicite sur les modalités nécessaires à "faire de l'argent" mais passons.
Les vrai problème pour la libération des specs sont:
* Utilisation du matériel en dehors des limites légales. C'est à ce sujet particulièrement vrai pour les puces wifi qui sont limités légalement en puissance selon les pays.
Or, les limites changent d'un pays à l'autre. Du coup, le puces wifi modernes sont concues avec des limites hardware en générale bien plus importante que ce que la loi autorise, et la limitation est alors logicielle, lors du chargement du microcode de la puce à l'initialisation du driver.
Libérer les specs, ici, c'est rendre possible l'utilisation en dehors des limites légales, à la responsabilité du constructeur. C'est aussi un argument important pour ne pas donner les sources des microcodes. Même si, on est d'accord, un hackeur expérimenté peux rétro-analyser les valeurs d'initialisation et arriver à contourner les limites légales.
* Concurrence: réveler les specs c'est aussi donner des informations sur le fonctionnement interne de la puce. Or ici, une entreprise investit beaucoup d'argent dans la conception de nouvelles technologies et n'a pas forcément envie de donner à ses concurrents le mode d'emploi pour reproduire leur puces..
Vala, c'est quand même autre chose que "faire de l'argent = manipuler le consomateur" et companie...
# Numéros de version ?
Posté par Romain Be. . En réponse à la dépêche OpenSSH v5.4 : Certificat et Révocation. Évalué à 3.
Juste par curiosité, y-a-t-il une raison particulière pour que les versions majeurs soient en .4 ?
[^] # Re: Exploitabilité *réelle*
Posté par Romain Be. . En réponse à la dépêche Faille locale dans les fonctions pipe_*_open() du noyau Linux. Évalué à -1.
Enfin, si il y a une faille de sécurité, mais je crois pas qu'elle se situe dans le noyau linux dans ce cas-là :-)
[^] # Re: Exploitabilité *réelle*
Posté par Romain Be. . En réponse à la dépêche Faille locale dans les fonctions pipe_*_open() du noyau Linux. Évalué à -2.
Ceci dit, sans nier que cela ait pu t'embêter, les failles dites de sécurité sont prétendument critiques à cause des risques majeurs, entendre financiers, qu'elle peuvent faire courir.
On lit souvent, dans la réponse au mail de Linus que j'ai cité, que les faille de sécurité sont la porte ouverte au *vol de centaines de cartes bleues* et autres conséquences exagérées.
Ici, je ne vois pas vraiment en quoi la faille est si problématique. D'ailleurs, en rêgle générale, les failles d'escalade de droits à partir d'un compte local me semblent toujours des failles secondaires, les principales étant celles qui permettent d'avoir un shell à partir d'une application distante...
Tout ça pour dire que le rush style « ouah encore une faille dans linux » et les « héros » de la sécurité style Brad Spengler, perso j'adhère pas, et je me sens plus proche de ce que dit Linus sur le sujet...
# Exploitabilité *réelle*
Posté par Romain Be. . En réponse à la dépêche Faille locale dans les fonctions pipe_*_open() du noyau Linux. Évalué à 1.
Ainsi, par exemple, je ne me soucie pas trop de cette faille sur ma machine personelle. Je suis le seul à avoir un accès. D'autre part, si on parle d'accès distant sur un serveur, alors il y a de grandes chances que WINE et consors soient complètement hors-jeu, donc l'administrateur a juste à positionner le flag qui va bien, et je suis sur que c'est deja probablement le cas..
Pour finir, je rejoins totalement la position de Linus dans ce message:
http://article.gmane.org/gmane.linux.kernel/706950
one reason I refuse to bother with the whole security circus is that I think it glorifies - and thus encourages - the wrong behavior.
It makes "heroes" out of security people, as if the people who don't just fix normal bugs aren't as important.
In fact, all the boring normal bugs are _way_ more important, just because there's a lot more of them. I don't think some spectacular security hole should be glorified or cared about as being any more "special" than a random spectacular crash due to bad locking.
[^] # Re: Suppression d'OSS et état de l'audio sous Linux
Posté par Romain Be. . En réponse à la dépêche Des nouvelles du noyau Debian. Évalué à 2.
Non, la plateforme qui manque vraiment est OSX..
[^] # Re: Suppression d'OSS et état de l'audio sous Linux
Posté par Romain Be. . En réponse à la dépêche Des nouvelles du noyau Debian. Évalué à 3.
ALSA est un echec tout simplement parce que les APIs de son sont un bordel sans nom sous linux alors même qu'ALSA était censé uniformiser cela.
L'API ALSA n'est satisfaisante pour personne. Ni assez documentée pour satisfaire les usages vraiment spécialistes, ni suffisament simple pour le reste.
Il suffit de regarder l'historique des sur-couche inventées pour parer à cela: arts, esound, jack, pulseaudio, etc etc... Elles ont toutes été inventées dans le même but: avoir une API plus "simple" et uniforme à utiliser que ALSA.
Si tu ajoute encore que chacune de ces couches émulent ALSA, OSS, et même plus ça devient vraiment toufu.
Implémenter le simple support d'un output audio sous linux est absolument cauchemardesque du point de vue du développeur, et je ne parle même pas des utilisateurs qui ne s'y retrouvent pas quand ils ont un pb de config.
[^] # Re: Suppression d'OSS et état de l'audio sous Linux
Posté par Romain Be. . En réponse à la dépêche Des nouvelles du noyau Debian. Évalué à 3.
[^] # Re: Suppression d'OSS et état de l'audio sous Linux
Posté par Romain Be. . En réponse à la dépêche Des nouvelles du noyau Debian. Évalué à 4.
Enfin l'argument de séparation kernel/userland n'est pas aussi simple que cela. Prend par exemple les périphériques video, c'est tout un bordel dans ce cas et on n'est pas encore sorti de l'auberge...
[^] # Re: Suppression d'OSS et état de l'audio sous Linux
Posté par Romain Be. . En réponse à la dépêche Des nouvelles du noyau Debian. Évalué à 5.
Juste pour donner un exemple simple, si on veux fixer le rate (la fréquence) des données communiquées à la carte son sous ALSA, on utilise la fonction:
snd_pcm_hw_params_set_rate_near
Qui retourne la valeur la plus proche possible du hardware... Et donc, tout le monde doit ensuite de demerder pour faire la conversion dans son coin..
Et ce n'est qu'un exemple :-)
[^] # Re: Suppression d'OSS et état de l'audio sous Linux
Posté par Romain Be. . En réponse à la dépêche Des nouvelles du noyau Debian. Évalué à 9.
En revanche, le développement d'OSS n'a jamais cessé, bien qu'il soit devenu un moment propriétaire, ce qui a surement attisé les esprits.
Maintenant, il faut aussi constater l'échec d'ALSA. C'est une API impossible, qui se voudrait à la fois bas niveau et haut niveau, et dont l'adoption par les applications simples type bureautique a été un echec flagrant.
Tous les programmeurs qui ont un jour voulu ajouter une simple sortie audio à leur programme linux doivent très bien connaitre le problème. Comparé à cela, l'API OSS était parfaite pour un usage grand public.
Résultat, on se retrouve avec des sur-couche supplémentaires, pulseaudio, jack et compagnie..
Ce n'est pas forcément une mauvaise chose, pourvu que, enfin, l'API d'un de ceux là, pulseaudio apparement, devienne standard ET relativement aisé à utiliser.
Maintenant vouloir eradiquer toutes les applications utilisant OSS est stupide. Cela fait deja un paquet d'années qu'ALSA est en place et si un nombre relativement important d'applications continuent d'utiliser OSS c'est bien que l'API ALSA est inutilisable pour eux.
Enfin il n'est pas exclu que les modules récents OSS fassent leur apparition en tant que module externes dans Debian, laissant le choix à l'utilisateur d'avoir ALSA ou OSS, puisque le logiciel libre est *aussi* une question de libre choix.
Et, comme les sur-couche pulseaudio et companie supportent OSS comme API de sortie, tout le monde devrait s'y retrouver...
Si, en plus, pulseaudio supporte l'émulation OSS plus correctement qu'ALSA il n'y a pas de raison de vouloir supprimer les applications utilisant OSS.
[^] # Re: A propos de la faille de sécurité..
Posté par Romain Be. . En réponse à la dépêche Nouvelle version 2.6.31 du noyau Linux. Évalué à 1.
Ce qui est maladroit c'est qu'il y a conflit entre deux directives. D'un coté un directive hors SELinux interdit de mapper à l'adresse zero, de l'autre une directive SELinux l'autorise.
Au final, en matière de sécurité, on voudrait toujours avoir comme combinaisons de plusieurs restrictions la restriction maximale. Ce n'est pas la cas ici, puisque SELinux permet alors d'affaiblir la sécurité du système en donnant la possibilité de contourner une autre directive de sécurité plus stricte.
[^] # Re: A propos de la faille de sécurité..
Posté par Romain Be. . En réponse à la dépêche Nouvelle version 2.6.31 du noyau Linux. Évalué à 1.
Il y a d'un coté une faille du noyau linux portant sur l'execution de code mappé à l'adresse mémoire zero, c'est la faille.
De l'autre, il y a un mécanisme de protection générique, mmap_min_addr qui permet en théorie d'empecher l'exploitation de la faille.
Enfin il y a SELinux qui, du fait d'un mauvais design, permet de contourner le mécanisme de protection générique mmap_min_addr.
Du point de vue de SELinux, c'est plus un problème de « defect by design » qu'à proprement parler une « faille ». Le fonctionnement utilisé est celui prévu (maladroitement) par les developpeurs.
La simple façon de s'en rendre compte, c'est que sans la faille noyau, il n'y aurait rien à exploiter, SELinux ou pas...
Romain
# A propos de la faille de sécurité..
Posté par Romain Be. . En réponse à la dépêche Nouvelle version 2.6.31 du noyau Linux. Évalué à 1.
A propos de la faille de sécurité SELinux et compagnie. Ce que le lis là:
http://lwn.net/Articles/347006/
C'est qu'en fait la vraie faille concernait l'utilisation de certaines opérations sur les socket pour lesquelles les pointeurs définissant les opérations applicables sur la socket étaient non initialisés.
Ainsi, pour pouvoir exploiter la faille, il fallait alors faire remplir l'adressage mémoire initial, zero, avec la fonction à executer, et on se retrouve avec la possibilité d'exécuter n'importe quoi avec les droit root.
Ainsi, le paramètre qui permet de choisir un adressage mémoire minimal plus grand que zero est une façon d'empecher l'exploitation de la faille et non la faille elle-même.
[^] # Re: Ingénierie à rebours difficile à défendre ???
Posté par Romain Be. . En réponse à la dépêche ScummVM dans des jeux Atari, au mépris de la GPL. Évalué à 1.
De plus, ce n'est pas parce qu'un mot vient du français qu'il recouvre le même sens en anglais. Par exemple tous les faux amis, comme eventually, ou encore actually.
Dans le cas d'ingénierie, le sens est différent puisque la notion d'engine, moteur, n'est pas présente dans le sens français.
Pour revenir au terme initial, je ne sais pas trop comment le traduire. En utilisant ingénierie, je dirai rétro-ingénierie, mais, encore une fois, appliquer le terme d'ingénierie à ce domaine est abusif. Pour ce qui est du code binaire, on peux dire décompilation, qui a à peu près le même sens, mais ne s'applique pas à un protocole par exemple.
En fait je « traduirai » en français soit par une périphrase, comme « analyse à postériori du fonctionnement du programme », ou alors carrément le terme d'origine, reverse engineering.
[^] # Re: Ingénierie à rebours difficile à défendre ???
Posté par Romain Be. . En réponse à la dépêche ScummVM dans des jeux Atari, au mépris de la GPL. Évalué à 1.
Il se trouve que le terme "engineering" n'as pas exactement le même sens que "ingénierie". En particulier en anglais engine désigne aussi le moteur, ce qui fait marcher une machine. Du coup, "reverse engineering" peux se comprendre bien plus facilement: il s'agit de comprendre à l'envers comment fonctionne le "moteur".
En français au contraire, rien de tel. L'ingénierie désigne l'ensemble des processus liés à l'étude et la réalisation d'un projet. Du coup ingénierie à rebours on a l'impression que ça veux dire qu'on a fait un projet industriel à l'envers, ce qui n'a pas trop de sens...
Du coup au lieu de trouver un équivalent en français d'un terme anglo-saxon, on contribue à importer le sens anglo-saxon en français.
C'est aussi le cas lorsque l'on voit des traductions mot à mot de certaines expressions, comme "en terme de" etc..
Je trouve ça assez savoureux qu'au final traduire les expressions sans connaître assez bien la langue amène à importer, calquer le sens anglais sur les mots français.. !
[^] # Re: Aïe les yeux
Posté par Romain Be. . En réponse à la dépêche Ultracopier, la copie enfin facile. Évalué à -1.
Au fond, je comprend a 100% l'explication sur les différents mode de lecture donnée plus haut, et je ne suis pas franchement pour une réforme de l'orthographe qui, il est vrai, appauvrirait la langue.
Cependant, ce qui chagrine ce sont les différentes attitudes et jugements portés par les gens vis-à-vis de ces problèmes.
Non, cher Nonor, il n'est pas uniquement question de paresse. Cela devient même pire quant on en vient à prétendre que le type en face est un imbécile parce qu'il ne serait pas capable de faire la gymnastique logique nécessaire à une écriture correcte. D'ailleurs, le sujet favori de discussion en France à ce titre, ce sont les gens qui ont un poste ou une position considérée comme prestigieuse et qui font des fautes... Cela ne colle pas avec notre culture de l'apparence..
Qu'on ait une écriture riche et compliquée, ok, mais que cela devienne un prétexte à discrimination, jugement à l'emporte pièce, non.. Et encore plus quand le fond est complètement sacrifié sous prétexte qu'il y a trop de fautes..
Ou alors, pour comparer, on pourrait aussi prétendre que tous ceux qui n'installent pas linux from scratch sont des crétins finis...
[^] # Re: Aïe les yeux
Posté par Romain Be. . En réponse à la dépêche Ultracopier, la copie enfin facile. Évalué à 2.
¹: Ha si, l'espéranto a été parlé.. Pour donner des ordres aux esclaves en Afrique du Sud... Comme ça ils comprennaient pas la langue de leur maitres et apprenaient uniquement un fragment de l'espéranto nécessaire pour leur donner des ordres..
[^] # Re: Aïe les yeux
Posté par Romain Be. . En réponse à la dépêche Ultracopier, la copie enfin facile. Évalué à 1.
Le problème étant que la majorité des fautes qui sont relevées relèvent en fait de l'ambiguïté de l'écrit par rapport à l'oral, et sont en fait des erreurs dues au fait que le français ajoute tout un tas de choses à l'écrit qui soit ne se prononcent pas, soit se prononcent exactement de la même façon.
Par exemple les sons o, au, eau; ou encore les conjugaisons non prononcées, comme il s'est tromper ou encore ils s'étai trompés etc...
Ces spécificités françaises sont absolument horribles pour les étrangers, qui peuvent très bien parler français, mais ont de gros problèmes à écrire correctement, voire même à lire (on dit Merine ou Mesrine.. ou les deux ?)
Prétendre que faire des fautes d'orthographe en français est un problème pour le sens, en ce sens, est je trouve, faux.
En général, les français répondent que ces spécificités écrites sont une trace du passé de la langue, comme les accents circonflexes mentionnent par exemple un s dans le vieux français (île par exemple).
Cependant, on peux pousser le troll un peu plus loin: si, au fond, un langage écrit est un outil de communication, pourquoi ne pas en faire un outil le plus simple possible d'utilisation.. C'est après tout la démarche rationnelle en général, comme pour linux et ubuntu par exemple.
Ainsi, pourquoi pas un langage écrit ou chaque son, chaque mot, s'écrit comme il se prononce ? Cela aura comme effet de permettre à un plus grand nombre de s'exprimer correctement, voire même d'éviter tout discrimination, puisque c'est aussi souvent le pb des gens qui écrivent avec des fautes..
D'ailleurs d'autres langues l'ont fait, l'espagnol par exemple...
Ha, oui, mais cela nous enlèverait la possibilité d'être pédant en reprenant les fautes des autres.. Culturellement inacceptable :-P
[^] # Re: Petit rajout
Posté par Romain Be. . En réponse à la dépêche Ultracopier, la copie enfin facile. Évalué à 5.
Plus généralement, je dis sans avoir trop lu, mais si tu vx vraiment avoir la classe, peut-être pourrais-tu voir pour rendre cela standard via freedesktop.org. D'ailleurs, encore une fois on se demande pourquoi ils l'ont pas deja fait...
[^] # Re: Aïe les yeux
Posté par Romain Be. . En réponse à la dépêche Ultracopier, la copie enfin facile. Évalué à 6.
En revanche, je remarque toujours qu'il n'y a que sur les forums français que systématiquement on trouve dans les 5 premiers commentaires un mec pour reprendre les fautes.
J'ai même contribué, tout du moins au début, avec un fort mauvais niveau d'anglais dans des forums/mailing list/etc.. et je n'ai *jamais* vu quelqu'un reprendre mes fautes.
Du coup j'ai tendance à penser que cette obession pour la correction des fautes semble culturellement bien franchouillarde..
PS: post sans correction, sinon ça serait tricher :)
[^] # Re: Regression
Posté par Romain Be. . En réponse à la dépêche Ubuntu Jaunty Jackalope (9.04) est sortie. Évalué à 2.
[^] # Re: L'injure au chef de l'Etat
Posté par Romain Be. . En réponse à la dépêche Rejet de l'Hadopi par l'Assemblée nationale française (et conséquences). Évalué à 1.
[^] # Re: le piratage va trop loin , et le langage avec ....
Posté par Romain Be. . En réponse à la dépêche Rejet de l'Hadopi par l'Assemblée nationale française (et conséquences). Évalué à 1.
Il faudrait généraliser à pas mal d'autres sujets politiques malheureusement..
# Crise..
Posté par Romain Be. . En réponse à la dépêche OpenMoko arrête le développement du GTA03. Évalué à 2.
Se pourrait-il que certains investisseurs précèdement tête brûlé prêt à investir dans une start-up prometteuse -- quitte, même, à verser dans l'utopisme en faisant confiance au logiciel libre -- se soient ravisés ?