Le 28-05-2010, ? propos de
Re: Apprendre le langage C et quelques questions,
Marc Boyer ?crivait dans fr.comp.lang.c :
Et ton bug, il date de quand ?
De Solaris 2.8. Sous 2.7, ça se comporte normalement. La différence,
c'est que le 2.7 est issu du 2.5 qui se devait de tourner sur des
machines avec très peu de mémoire (16 ou 32 Mo) alors que le 2.8
demandait déjà beaucoup plus de mémoire pour s'installer. C'était
l'époque des U420R qui étaient vendues d'office avec 512 Mo de
mémoire (si la mienne est bonne).
Donc, vers le décolage de Java, non ?
Hélas oui (mais je ne vois pas trop ce que Java viendrait faire dans
les différents malloc() de Solaris 2.8...).
Le 28-05-2010, ? propos de
Re: Apprendre le langage C et quelques questions,
Marc Boyer ?crivait dans fr.comp.lang.c :
Et ton bug, il date de quand ?
De Solaris 2.8. Sous 2.7, ça se comporte normalement. La différence,
c'est que le 2.7 est issu du 2.5 qui se devait de tourner sur des
machines avec très peu de mémoire (16 ou 32 Mo) alors que le 2.8
demandait déjà beaucoup plus de mémoire pour s'installer. C'était
l'époque des U420R qui étaient vendues d'office avec 512 Mo de
mémoire (si la mienne est bonne).
Donc, vers le décolage de Java, non ?
Hélas oui (mais je ne vois pas trop ce que Java viendrait faire dans
les différents malloc() de Solaris 2.8...).
Le 28-05-2010, ? propos de
Re: Apprendre le langage C et quelques questions,
Marc Boyer ?crivait dans fr.comp.lang.c :
Et ton bug, il date de quand ?
De Solaris 2.8. Sous 2.7, ça se comporte normalement. La différence,
c'est que le 2.7 est issu du 2.5 qui se devait de tourner sur des
machines avec très peu de mémoire (16 ou 32 Mo) alors que le 2.8
demandait déjà beaucoup plus de mémoire pour s'installer. C'était
l'époque des U420R qui étaient vendues d'office avec 512 Mo de
mémoire (si la mienne est bonne).
Donc, vers le décolage de Java, non ?
Hélas oui (mais je ne vois pas trop ce que Java viendrait faire dans
les différents malloc() de Solaris 2.8...).
Le 28-05-2010, JKB a écrit :Le 28-05-2010, ? propos de
Re: Apprendre le langage C et quelques questions,
Marc Boyer ?crivait dans fr.comp.lang.c :
Et ton bug, il date de quand ?
De Solaris 2.8. Sous 2.7, ça se comporte normalement. La différence,
c'est que le 2.7 est issu du 2.5 qui se devait de tourner sur des
machines avec très peu de mémoire (16 ou 32 Mo) alors que le 2.8
demandait déjà beaucoup plus de mémoire pour s'installer. C'était
l'époque des U420R qui étaient vendues d'office avec 512 Mo de
mémoire (si la mienne est bonne).
Donc, vers le décolage de Java, non ?
Hélas oui (mais je ne vois pas trop ce que Java viendrait faire dans
les différents malloc() de Solaris 2.8...).
Une question de gestion des priorités chez Sun ? C'est toi qui as écrit
je crois que Solaris était un bon OS jusqu'à l'arrivée de Java.
Il me semble que le fait important n'est pas tellement qu'il y ait eut
un bug dans les malloc() de Solaris, mais plutôt qu'une fois le bug
identifié, personne ne prenne le temps de le corriger, non ?
Est-ce qu'à un moment, Sun n'a pas surtout misé sur Java, en laissant
un peu de côté Solaris ?
Le 28-05-2010, JKB <knatschke@koenigsberg.fr> a écrit :
Le 28-05-2010, ? propos de
Re: Apprendre le langage C et quelques questions,
Marc Boyer ?crivait dans fr.comp.lang.c :
Et ton bug, il date de quand ?
De Solaris 2.8. Sous 2.7, ça se comporte normalement. La différence,
c'est que le 2.7 est issu du 2.5 qui se devait de tourner sur des
machines avec très peu de mémoire (16 ou 32 Mo) alors que le 2.8
demandait déjà beaucoup plus de mémoire pour s'installer. C'était
l'époque des U420R qui étaient vendues d'office avec 512 Mo de
mémoire (si la mienne est bonne).
Donc, vers le décolage de Java, non ?
Hélas oui (mais je ne vois pas trop ce que Java viendrait faire dans
les différents malloc() de Solaris 2.8...).
Une question de gestion des priorités chez Sun ? C'est toi qui as écrit
je crois que Solaris était un bon OS jusqu'à l'arrivée de Java.
Il me semble que le fait important n'est pas tellement qu'il y ait eut
un bug dans les malloc() de Solaris, mais plutôt qu'une fois le bug
identifié, personne ne prenne le temps de le corriger, non ?
Est-ce qu'à un moment, Sun n'a pas surtout misé sur Java, en laissant
un peu de côté Solaris ?
Le 28-05-2010, JKB a écrit :Le 28-05-2010, ? propos de
Re: Apprendre le langage C et quelques questions,
Marc Boyer ?crivait dans fr.comp.lang.c :
Et ton bug, il date de quand ?
De Solaris 2.8. Sous 2.7, ça se comporte normalement. La différence,
c'est que le 2.7 est issu du 2.5 qui se devait de tourner sur des
machines avec très peu de mémoire (16 ou 32 Mo) alors que le 2.8
demandait déjà beaucoup plus de mémoire pour s'installer. C'était
l'époque des U420R qui étaient vendues d'office avec 512 Mo de
mémoire (si la mienne est bonne).
Donc, vers le décolage de Java, non ?
Hélas oui (mais je ne vois pas trop ce que Java viendrait faire dans
les différents malloc() de Solaris 2.8...).
Une question de gestion des priorités chez Sun ? C'est toi qui as écrit
je crois que Solaris était un bon OS jusqu'à l'arrivée de Java.
Il me semble que le fait important n'est pas tellement qu'il y ait eut
un bug dans les malloc() de Solaris, mais plutôt qu'une fois le bug
identifié, personne ne prenne le temps de le corriger, non ?
Est-ce qu'à un moment, Sun n'a pas surtout misé sur Java, en laissant
un peu de côté Solaris ?
Pour donner une réponse globale aux posts qui me concernent, c'est
évident que la marche est haute avec le langage c. Je me souviens de
ce samedi soir ou exténué d'installer pour la enième fois ubuntu su r
un netbook sans que soit le son, soit le micro soit compiz, soit autre
chose ne fonctionne...je me dis, je vais relever mes manches et
participer à la programmation des drivers pour porter linux sur les
machines que j'utilise.
apprendre à programmer un driver pour linux" sur google et parmi les
résultats je tombe sur un site qui donne la voie à suivre et conseil
de bonnes bases en langage c. Langage que je ne connaissais pas, tout
comme la programmation à part vba.
Je ne suis pas sûr pour quelles raisons (programmer en vba
certainement), quelques années avant, j'avais décidé d'apprendre
quelques bases sur les algorithmes toujours en autodidacte à partir
des ressources accessibles sur internet.
Ca fera un an que je me suis investi dans l'apprentissage du langage
c. J'ai bien regardé d'autres langages entre temps mais au bout de
quelques semaines avec le langage c, j'ai apprécié. J'ai essayé de
m'intéresser à la POO avec VB pour m'orienter indirectement vers V BA.
Seulement l'apprentissage des objets m'a freiné.
Et puis le langage c semble assez structuré pour apprendre comme
autodidacte.
comme 1 semaine pour apprendre l'assembleur et quelque chose comme 3
mois ou plus pour apprendre le langage c.
De mon côté, j'ai essayé de
faire un peu d'assembleur mais il existe tellement de systèmes(asm,
iasm, windows, linux... ) que j'ai été découragé. Juste pour
connaître les bases du langage c et quelques bases de l'assembleur, je
me suis dit alors que ça faisait trop. Mais si quelqu'un dit que c'est
plus simple d'apprendre l'assembleur que le langage c, je serais
curieux de connaître sa méthode. Mais je reconnais qu'il y a certains
domaines ou être autodidacte n'est pas simple. Pour reprendre un autre
post ou il est dit qu'il vaut mieux choisir le langage informatique
qu'une personne autour de soi connaît...
Je me suis rendu compte que programmer un driver avec une formation de
comptable demanderait de tels efforts que ça serait peine perdue.
Alors je continue avec le langage c car j'ai commencé et je souhaite
atteindre un certain niveau avant de changer et actuellement je
m'intéresse au C++. Certaines notions fondamentales semblent se
retrouver dans les 2 langages ;
structures qui me paraissent être les bases du langage objet que je
crois voir dans la notation pointée. Je ne sais pas si c'est le cas,
mais je me dis que savoir manipuler les structures de données en lang
c peut aider en c++.
Je ne suis pas sûr où ce que j'apprends peut me mener.
qu'on se dirige vers une spécialisation à travers des équipes
d'informaticiens ou chacun à un rôle, je suppose que c'est le cas ave c
ajax, c++, un ou plusieurs spécialistes en javascript, css, xml,
php...en c++ le langage permet de diviser assez facilement les tâches
je crois comprendre...
En c, des personnes d'expérience 10, 20...30 ans
qui ne font que ça apportent leur expertise pour créer un driver pour
tel ou tel système...
Je sais que je ne peux pas concurrencer des professionnels mais après
avoir vécu avec des amstrad cpc 64 et 6128, commodore 64, atari st
520, 1040, pc 1512 ...
je me sens attiré par l'informatique. Pour
reprendre un autre post, les jeux et applications vendus en boîte pour
un certain prix et aujourd'hui ces jeux sont disponibles en
téléchargement et sont plus abordables financièrement et de bonnes
qualités (peut-être parce que le nombre de clients et l'offre
d'application ont augmenté).
Peut-être après avoir fourni certains efforts pour apprendre un ou
plusieurs langage, je ne vais rien créer d'exceptionnel et simplement
apporter un plus à mon métier de comptable mais je ne crois pas qu'un e
personne qui connaît un ou plusieurs langages informatique peut ne pas
se sentir concernée par les possibilités de vendre une part de sa
création même en dehors de son métier de salarié? Ou bien, je ne fais
que rêver et la réalité est que tout est offshore en Inde, Chine... un
peu comme avec l'industrie du textile et les pays tigres il y 20 ou 30
ans.
Pour donner une réponse globale aux posts qui me concernent, c'est
évident que la marche est haute avec le langage c. Je me souviens de
ce samedi soir ou exténué d'installer pour la enième fois ubuntu su r
un netbook sans que soit le son, soit le micro soit compiz, soit autre
chose ne fonctionne...je me dis, je vais relever mes manches et
participer à la programmation des drivers pour porter linux sur les
machines que j'utilise.
apprendre à programmer un driver pour linux" sur google et parmi les
résultats je tombe sur un site qui donne la voie à suivre et conseil
de bonnes bases en langage c. Langage que je ne connaissais pas, tout
comme la programmation à part vba.
Je ne suis pas sûr pour quelles raisons (programmer en vba
certainement), quelques années avant, j'avais décidé d'apprendre
quelques bases sur les algorithmes toujours en autodidacte à partir
des ressources accessibles sur internet.
Ca fera un an que je me suis investi dans l'apprentissage du langage
c. J'ai bien regardé d'autres langages entre temps mais au bout de
quelques semaines avec le langage c, j'ai apprécié. J'ai essayé de
m'intéresser à la POO avec VB pour m'orienter indirectement vers V BA.
Seulement l'apprentissage des objets m'a freiné.
Et puis le langage c semble assez structuré pour apprendre comme
autodidacte.
comme 1 semaine pour apprendre l'assembleur et quelque chose comme 3
mois ou plus pour apprendre le langage c.
De mon côté, j'ai essayé de
faire un peu d'assembleur mais il existe tellement de systèmes(asm,
iasm, windows, linux... ) que j'ai été découragé. Juste pour
connaître les bases du langage c et quelques bases de l'assembleur, je
me suis dit alors que ça faisait trop. Mais si quelqu'un dit que c'est
plus simple d'apprendre l'assembleur que le langage c, je serais
curieux de connaître sa méthode. Mais je reconnais qu'il y a certains
domaines ou être autodidacte n'est pas simple. Pour reprendre un autre
post ou il est dit qu'il vaut mieux choisir le langage informatique
qu'une personne autour de soi connaît...
Je me suis rendu compte que programmer un driver avec une formation de
comptable demanderait de tels efforts que ça serait peine perdue.
Alors je continue avec le langage c car j'ai commencé et je souhaite
atteindre un certain niveau avant de changer et actuellement je
m'intéresse au C++. Certaines notions fondamentales semblent se
retrouver dans les 2 langages ;
structures qui me paraissent être les bases du langage objet que je
crois voir dans la notation pointée. Je ne sais pas si c'est le cas,
mais je me dis que savoir manipuler les structures de données en lang
c peut aider en c++.
Je ne suis pas sûr où ce que j'apprends peut me mener.
qu'on se dirige vers une spécialisation à travers des équipes
d'informaticiens ou chacun à un rôle, je suppose que c'est le cas ave c
ajax, c++, un ou plusieurs spécialistes en javascript, css, xml,
php...en c++ le langage permet de diviser assez facilement les tâches
je crois comprendre...
En c, des personnes d'expérience 10, 20...30 ans
qui ne font que ça apportent leur expertise pour créer un driver pour
tel ou tel système...
Je sais que je ne peux pas concurrencer des professionnels mais après
avoir vécu avec des amstrad cpc 64 et 6128, commodore 64, atari st
520, 1040, pc 1512 ...
je me sens attiré par l'informatique. Pour
reprendre un autre post, les jeux et applications vendus en boîte pour
un certain prix et aujourd'hui ces jeux sont disponibles en
téléchargement et sont plus abordables financièrement et de bonnes
qualités (peut-être parce que le nombre de clients et l'offre
d'application ont augmenté).
Peut-être après avoir fourni certains efforts pour apprendre un ou
plusieurs langage, je ne vais rien créer d'exceptionnel et simplement
apporter un plus à mon métier de comptable mais je ne crois pas qu'un e
personne qui connaît un ou plusieurs langages informatique peut ne pas
se sentir concernée par les possibilités de vendre une part de sa
création même en dehors de son métier de salarié? Ou bien, je ne fais
que rêver et la réalité est que tout est offshore en Inde, Chine... un
peu comme avec l'industrie du textile et les pays tigres il y 20 ou 30
ans.
Pour donner une réponse globale aux posts qui me concernent, c'est
évident que la marche est haute avec le langage c. Je me souviens de
ce samedi soir ou exténué d'installer pour la enième fois ubuntu su r
un netbook sans que soit le son, soit le micro soit compiz, soit autre
chose ne fonctionne...je me dis, je vais relever mes manches et
participer à la programmation des drivers pour porter linux sur les
machines que j'utilise.
apprendre à programmer un driver pour linux" sur google et parmi les
résultats je tombe sur un site qui donne la voie à suivre et conseil
de bonnes bases en langage c. Langage que je ne connaissais pas, tout
comme la programmation à part vba.
Je ne suis pas sûr pour quelles raisons (programmer en vba
certainement), quelques années avant, j'avais décidé d'apprendre
quelques bases sur les algorithmes toujours en autodidacte à partir
des ressources accessibles sur internet.
Ca fera un an que je me suis investi dans l'apprentissage du langage
c. J'ai bien regardé d'autres langages entre temps mais au bout de
quelques semaines avec le langage c, j'ai apprécié. J'ai essayé de
m'intéresser à la POO avec VB pour m'orienter indirectement vers V BA.
Seulement l'apprentissage des objets m'a freiné.
Et puis le langage c semble assez structuré pour apprendre comme
autodidacte.
comme 1 semaine pour apprendre l'assembleur et quelque chose comme 3
mois ou plus pour apprendre le langage c.
De mon côté, j'ai essayé de
faire un peu d'assembleur mais il existe tellement de systèmes(asm,
iasm, windows, linux... ) que j'ai été découragé. Juste pour
connaître les bases du langage c et quelques bases de l'assembleur, je
me suis dit alors que ça faisait trop. Mais si quelqu'un dit que c'est
plus simple d'apprendre l'assembleur que le langage c, je serais
curieux de connaître sa méthode. Mais je reconnais qu'il y a certains
domaines ou être autodidacte n'est pas simple. Pour reprendre un autre
post ou il est dit qu'il vaut mieux choisir le langage informatique
qu'une personne autour de soi connaît...
Je me suis rendu compte que programmer un driver avec une formation de
comptable demanderait de tels efforts que ça serait peine perdue.
Alors je continue avec le langage c car j'ai commencé et je souhaite
atteindre un certain niveau avant de changer et actuellement je
m'intéresse au C++. Certaines notions fondamentales semblent se
retrouver dans les 2 langages ;
structures qui me paraissent être les bases du langage objet que je
crois voir dans la notation pointée. Je ne sais pas si c'est le cas,
mais je me dis que savoir manipuler les structures de données en lang
c peut aider en c++.
Je ne suis pas sûr où ce que j'apprends peut me mener.
qu'on se dirige vers une spécialisation à travers des équipes
d'informaticiens ou chacun à un rôle, je suppose que c'est le cas ave c
ajax, c++, un ou plusieurs spécialistes en javascript, css, xml,
php...en c++ le langage permet de diviser assez facilement les tâches
je crois comprendre...
En c, des personnes d'expérience 10, 20...30 ans
qui ne font que ça apportent leur expertise pour créer un driver pour
tel ou tel système...
Je sais que je ne peux pas concurrencer des professionnels mais après
avoir vécu avec des amstrad cpc 64 et 6128, commodore 64, atari st
520, 1040, pc 1512 ...
je me sens attiré par l'informatique. Pour
reprendre un autre post, les jeux et applications vendus en boîte pour
un certain prix et aujourd'hui ces jeux sont disponibles en
téléchargement et sont plus abordables financièrement et de bonnes
qualités (peut-être parce que le nombre de clients et l'offre
d'application ont augmenté).
Peut-être après avoir fourni certains efforts pour apprendre un ou
plusieurs langage, je ne vais rien créer d'exceptionnel et simplement
apporter un plus à mon métier de comptable mais je ne crois pas qu'un e
personne qui connaît un ou plusieurs langages informatique peut ne pas
se sentir concernée par les possibilités de vendre une part de sa
création même en dehors de son métier de salarié? Ou bien, je ne fais
que rêver et la réalité est que tout est offshore en Inde, Chine... un
peu comme avec l'industrie du textile et les pays tigres il y 20 ou 30
ans.
On 6 juin, 04:00, heron maladroit wrote:
Pour donner une réponse globale aux posts qui me concernent, c'est
évident que la marche est haute avec le langage c. Je me souviens de
ce samedi soir ou exténué d'installer pour la enième fois ubuntu sur
un netbook sans que soit le son, soit le micro soit compiz, soit autre
chose ne fonctionne...je me dis, je vais relever mes manches et
participer à la programmation des drivers pour porter linux sur les
machines que j'utilise.
Bah, si tu n'es pas un expert dans le domaine, tu n'as pas de grande
chance de pouvoir intervenir toi même. Le langage C n'est que l'outil
qui permet d'écrire ou de modifier des drivers.
On 6 juin, 04:00, heron maladroit <cream10...@yahoo.com> wrote:
Pour donner une réponse globale aux posts qui me concernent, c'est
évident que la marche est haute avec le langage c. Je me souviens de
ce samedi soir ou exténué d'installer pour la enième fois ubuntu sur
un netbook sans que soit le son, soit le micro soit compiz, soit autre
chose ne fonctionne...je me dis, je vais relever mes manches et
participer à la programmation des drivers pour porter linux sur les
machines que j'utilise.
Bah, si tu n'es pas un expert dans le domaine, tu n'as pas de grande
chance de pouvoir intervenir toi même. Le langage C n'est que l'outil
qui permet d'écrire ou de modifier des drivers.
On 6 juin, 04:00, heron maladroit wrote:
Pour donner une réponse globale aux posts qui me concernent, c'est
évident que la marche est haute avec le langage c. Je me souviens de
ce samedi soir ou exténué d'installer pour la enième fois ubuntu sur
un netbook sans que soit le son, soit le micro soit compiz, soit autre
chose ne fonctionne...je me dis, je vais relever mes manches et
participer à la programmation des drivers pour porter linux sur les
machines que j'utilise.
Bah, si tu n'es pas un expert dans le domaine, tu n'as pas de grande
chance de pouvoir intervenir toi même. Le langage C n'est que l'outil
qui permet d'écrire ou de modifier des drivers.
In article ,
-ed- wrote:On 6 juin, 04:00, heron maladroit wrote:
Pour donner une réponse globale aux posts qui me concernent, c'est
évident que la marche est haute avec le langage c. Je me souviens de
ce samedi soir ou exténué d'installer pour la enième fois ubuntu sur
un netbook sans que soit le son, soit le micro soit compiz, soit autre
chose ne fonctionne...je me dis, je vais relever mes manches et
participer à la programmation des drivers pour porter linux sur les
machines que j'utilise.
Bah, si tu n'es pas un expert dans le domaine, tu n'as pas de grande
chance de pouvoir intervenir toi même. Le langage C n'est que l'outil
qui permet d'écrire ou de modifier des drivers.
Meme en etant un expert, il y a parfois besoin d'etre "interne" au processus
pour pouvoir developper certains pilotes.
Je ne sais pas si la situation s'est assainie recemment, mais il y avait
pas mal de pilotes linux qui, en pratique, n'etaient pas vraiment ouverts.
Quand tu vois un pilote qui a ete ecrit par un mec sous NDA (et employe de
la boite qui fabrique le matos), bourree de magic constants, et sans un
commentaire, tu as un peu l'impression que c'est juste une facon de
te donner du binaire sans le dire.
Petit avantage: si c'est bien foutu,
ca compile ailleurs que sur i386. Gros inconvenient: c'est importable sur
d'autres OS.
Si la communaute linux etait un peu plus vigilante par rapport a ce genre
de choses, et n'etait pas la premiere a accepter tout et n'importe quoi
(entre ndiswrapper pour les cartes reseaux, ou les pilotes proprietaires
nvidia, et leur ridicule excuse de pilote libre), on ne serait sans doute
pas dans la merde noire ou on est actuellement, avec une grosse partie
des boites qui ne joue pas du tout, du tout, le jeu...
In article <3356502d-e023-4f2d-b0f0-6fcd5011498e@z10g2000yqb.googlegroups.com>,
-ed- <emmanuel.delahaye@gmail.com> wrote:
On 6 juin, 04:00, heron maladroit <cream10...@yahoo.com> wrote:
Pour donner une réponse globale aux posts qui me concernent, c'est
évident que la marche est haute avec le langage c. Je me souviens de
ce samedi soir ou exténué d'installer pour la enième fois ubuntu sur
un netbook sans que soit le son, soit le micro soit compiz, soit autre
chose ne fonctionne...je me dis, je vais relever mes manches et
participer à la programmation des drivers pour porter linux sur les
machines que j'utilise.
Bah, si tu n'es pas un expert dans le domaine, tu n'as pas de grande
chance de pouvoir intervenir toi même. Le langage C n'est que l'outil
qui permet d'écrire ou de modifier des drivers.
Meme en etant un expert, il y a parfois besoin d'etre "interne" au processus
pour pouvoir developper certains pilotes.
Je ne sais pas si la situation s'est assainie recemment, mais il y avait
pas mal de pilotes linux qui, en pratique, n'etaient pas vraiment ouverts.
Quand tu vois un pilote qui a ete ecrit par un mec sous NDA (et employe de
la boite qui fabrique le matos), bourree de magic constants, et sans un
commentaire, tu as un peu l'impression que c'est juste une facon de
te donner du binaire sans le dire.
Petit avantage: si c'est bien foutu,
ca compile ailleurs que sur i386. Gros inconvenient: c'est importable sur
d'autres OS.
Si la communaute linux etait un peu plus vigilante par rapport a ce genre
de choses, et n'etait pas la premiere a accepter tout et n'importe quoi
(entre ndiswrapper pour les cartes reseaux, ou les pilotes proprietaires
nvidia, et leur ridicule excuse de pilote libre), on ne serait sans doute
pas dans la merde noire ou on est actuellement, avec une grosse partie
des boites qui ne joue pas du tout, du tout, le jeu...
In article ,
-ed- wrote:On 6 juin, 04:00, heron maladroit wrote:
Pour donner une réponse globale aux posts qui me concernent, c'est
évident que la marche est haute avec le langage c. Je me souviens de
ce samedi soir ou exténué d'installer pour la enième fois ubuntu sur
un netbook sans que soit le son, soit le micro soit compiz, soit autre
chose ne fonctionne...je me dis, je vais relever mes manches et
participer à la programmation des drivers pour porter linux sur les
machines que j'utilise.
Bah, si tu n'es pas un expert dans le domaine, tu n'as pas de grande
chance de pouvoir intervenir toi même. Le langage C n'est que l'outil
qui permet d'écrire ou de modifier des drivers.
Meme en etant un expert, il y a parfois besoin d'etre "interne" au processus
pour pouvoir developper certains pilotes.
Je ne sais pas si la situation s'est assainie recemment, mais il y avait
pas mal de pilotes linux qui, en pratique, n'etaient pas vraiment ouverts.
Quand tu vois un pilote qui a ete ecrit par un mec sous NDA (et employe de
la boite qui fabrique le matos), bourree de magic constants, et sans un
commentaire, tu as un peu l'impression que c'est juste une facon de
te donner du binaire sans le dire.
Petit avantage: si c'est bien foutu,
ca compile ailleurs que sur i386. Gros inconvenient: c'est importable sur
d'autres OS.
Si la communaute linux etait un peu plus vigilante par rapport a ce genre
de choses, et n'etait pas la premiere a accepter tout et n'importe quoi
(entre ndiswrapper pour les cartes reseaux, ou les pilotes proprietaires
nvidia, et leur ridicule excuse de pilote libre), on ne serait sans doute
pas dans la merde noire ou on est actuellement, avec une grosse partie
des boites qui ne joue pas du tout, du tout, le jeu...
Marc Espie ?crivait dans fr.comp.lang.c :Petit avantage: si c'est bien foutu, ca compile ailleurs que sur i386.
Gros inconvenient: c'est importable sur d'autres OS.
Non.
Marc Espie ?crivait dans fr.comp.lang.c :
Petit avantage: si c'est bien foutu, ca compile ailleurs que sur i386.
Gros inconvenient: c'est importable sur d'autres OS.
Non.
Marc Espie ?crivait dans fr.comp.lang.c :Petit avantage: si c'est bien foutu, ca compile ailleurs que sur i386.
Gros inconvenient: c'est importable sur d'autres OS.
Non.
JKB écrivit :Marc Espie ?crivait dans fr.comp.lang.c :Petit avantage: si c'est bien foutu, ca compile ailleurs que sur i386.
Gros inconvenient: c'est importable sur d'autres OS.
Non.
Non quoi ? Non il n'y a même pas le petit avantage quand le driver est
bien foutu (ce qui est effectivement rare, ÀMHA) ?
Ou non l'inconvénient n'est pas gros, ou ce n'est pas d'être importable,
ou le fait d'être importable n'est pas un inconvénient ?
JKB écrivit :
Marc Espie ?crivait dans fr.comp.lang.c :
Petit avantage: si c'est bien foutu, ca compile ailleurs que sur i386.
Gros inconvenient: c'est importable sur d'autres OS.
Non.
Non quoi ? Non il n'y a même pas le petit avantage quand le driver est
bien foutu (ce qui est effectivement rare, ÀMHA) ?
Ou non l'inconvénient n'est pas gros, ou ce n'est pas d'être importable,
ou le fait d'être importable n'est pas un inconvénient ?
JKB écrivit :Marc Espie ?crivait dans fr.comp.lang.c :Petit avantage: si c'est bien foutu, ca compile ailleurs que sur i386.
Gros inconvenient: c'est importable sur d'autres OS.
Non.
Non quoi ? Non il n'y a même pas le petit avantage quand le driver est
bien foutu (ce qui est effectivement rare, ÀMHA) ?
Ou non l'inconvénient n'est pas gros, ou ce n'est pas d'être importable,
ou le fait d'être importable n'est pas un inconvénient ?
Et bien, c'est non parce que les pilotes bourrés de 'magic
constants' s'adressent soit à des fonctionnalités des puces pas
forcément correctement documentées, soit à des processeurs
spécifiques (adressages spéciaux, ruses de programmation pour
contourner des problèmes des composants et attaquer des opérations
atomiques...).
Lorsque le truc compile et fonctionne sur un i386, cela ne veux pas
dire qu'il va fonctionner sur un sparc parce que le code assemblé Ã
la main et collé dans des tableaux d'entiers ne fonctionnera pas.
Idem pour les firmwares binaires (j'ai une carte Wifi Ralink dans un
adaptateur Sbus/pcmcia qui n'a _jamais_ fonctionné à cause de ça).
Et bien, c'est non parce que les pilotes bourrés de 'magic
constants' s'adressent soit à des fonctionnalités des puces pas
forcément correctement documentées, soit à des processeurs
spécifiques (adressages spéciaux, ruses de programmation pour
contourner des problèmes des composants et attaquer des opérations
atomiques...).
Lorsque le truc compile et fonctionne sur un i386, cela ne veux pas
dire qu'il va fonctionner sur un sparc parce que le code assemblé Ã
la main et collé dans des tableaux d'entiers ne fonctionnera pas.
Idem pour les firmwares binaires (j'ai une carte Wifi Ralink dans un
adaptateur Sbus/pcmcia qui n'a _jamais_ fonctionné à cause de ça).
Et bien, c'est non parce que les pilotes bourrés de 'magic
constants' s'adressent soit à des fonctionnalités des puces pas
forcément correctement documentées, soit à des processeurs
spécifiques (adressages spéciaux, ruses de programmation pour
contourner des problèmes des composants et attaquer des opérations
atomiques...).
Lorsque le truc compile et fonctionne sur un i386, cela ne veux pas
dire qu'il va fonctionner sur un sparc parce que le code assemblé Ã
la main et collé dans des tableaux d'entiers ne fonctionnera pas.
Idem pour les firmwares binaires (j'ai une carte Wifi Ralink dans un
adaptateur Sbus/pcmcia qui n'a _jamais_ fonctionné à cause de ça).
