Panasonic utilise ou va utiliser une plateforme Ericsson. Ericsson est pro-brevets logiciels. Je le sais, j'y bosse, j'ai vu les brevets deposes. La politique pourrait se resumer a "votre idee peut vous parraitre evidente, mais essayez toujours, on ne sait jamais, sur un malentendu ca pourrait marcher".
Sagem va utiliser une plateforme Ericsson pour ses futurs mobiles 3G.
Quand a Motorola, voila ce qu'on trouve dans certaines de leurs docs :
Motorola grants to You a non-exclusive license to use the SOFTWARE in the manner described in the documentation associated with the product. Motorola retains ownership of the SOFTWARE including all patent, copyrights, and other intellectual property rights. You may transfer this license to use the SOFTWARE as long as the transferee agrees to be bound by the terms of this Agreement.
Pour repondre sur la question des telephones mobiles, c'est simple, tu prends le classement de ventes mondiales
1. Nokia, pro-brevet
2. Samsung. Plateforme Qualcomm, pro-brevet (CDMA entre autre)
3. Motorolla, pro-brevet
Les 7 suivants, peu importe la marque, c'est plateforme Ericsson, pro-brevet.
Tu peux toujours essayer de jeter un oeil du cote des GSM Sagem (pas UMTS) ou Sendo pour essayer de savoir ce qu'ils utilisent, mais il y a peu d'espoir.
Bref, si tu ne veux pas d'entreprise pro-brevet dans ton telephone, tu peux te mettre aux signaux de fumee, avec un peu de chance les vieux films de western peuvent faire office de preuve d'anteriorite...
Non, ça ne servirait à rien. Le but, c'est de savoir en quoi un Athlon64 est *mieux* qu'un Athlon XP, pas de savoir quelles sont les différences de performances de l'Athlon64 en mode 32 et 64 bits.
Au contraire ce serait tres utile. Ca permettrait de savoir dans quelle mesure l'amelioration de performances est due aux changements d'acrhitecture interne tels que l'integration du controlleur memoire, et dans quelle mesure ca vient du passage a 64 bits.
Ça tombe bien, pour les manipulations vidéos, l'Athlon64 intègre désormais les instructions SSE2,
Le P4 32 bits integre les instructions SSE2 depuis des annees. Est-il necessaire de passer a 64 bits pour les integrer ?
et le contrôleur mémoire est désormais intégré au processeur. :-)
Et pour faire ca, le passage a 64 bits etait necessaire ? Si tu utilises ton athlon64 en 32 bits, ca te force a utiliser un controlleur externe ?
il y a un état de fait génant dans la mesure où la RFC n'impose pas un domaine dans l'enveloppe (MAIL FROM: ...) correspondant par son MX à l'adresse IP émettrice.
Comme je l'ai ecrit juste au-dessus, ce n'est pas ce critere-la qui est teste. C'est "est-ce que cette machine est correctement declaree sur le reseau". Ca n'a rien a voir avec le MTA, c'est un pur probleme de DNS.
J'appuie cette remarque. La verification qui est faite sur ces serveurs SMTP, si c'est bien la meme que celle que je fais (et je suppose ca a l'air d'etre standard), c'est :
1/ Est-ce que l'adresse IP de laquelle j'ai recu ce message a un reverse declare ? Si ce n'est pas le cas, je jete.
2/ Je prends le resultat du test N°1, et je fais une recherche DNS dessus. Si aucune des IP retournees n'est celle qui m'a envoye le message, je jete.
Et ca n'a rien a voir avec le champ From: du mail.
Donc, je confirme les dires de Colin Leroy, le service qui t'heberge a des DNS mal configures. Tu peux (devrais) te plaindre aupres d'eux.
oualalal. Maman j'ai peur... je veux pas monter dans les voitures du monsieur.
Ne t'en fais pas, a priori c'est pas pour demain. Et si ca devait t'arriver, on n'a jamais vu l'electronique poser probleme. Par contre, les pneus, les freins, l'embrayage, la boite, le moteur, les supensions ca s'est vu. Et quand ton saut perilleux arriere se termine, la telemetrie affiche que tu as pris 28g.
Y'a rien de plus chiant que de vérifier les temps de setup et de hold d'io de 2 puces mais crois moi, si un des composants à un arbre d'horloge rapide et l'autre à un arbre lent, tu va au devant de très gros emmerde. Genre un cpu avec un fpga type actel... au hasard :)
Comme l'a dit le monsieur au-dessus, on n'a pas les memes contraintes. On travaillait sur des plages de temperatures qui sont relativement limitees, les problemes que tu as ne s'appliquaient pas dans notre cas.
Les systèmes spatiaux européens ne mettent pas encore la vie humaine en jeu.
Ceux qui equipent les Formule 1 oui, en direct a la tele.
C'est bizarre, je m'attendais plutot a voir des gens reagir sur la methode de developpement logicielle plutot anachronique, pas sur l'eletronique en elle-meme...
Non, il ne te semblait pas mal. Mais tu parles d'un stable. J'explique pourquoi il y a une periode de test (dans "testing" ca tombe bien) assez longue avant que ce soit considere "stable", et donc pourquoi il n'y a pas les toutes dernieres versions des softs.
Interessant comme idee. Mais si on suit ton raisonnement, les logiciels sortent en principe sans bug, ce qui est assez irrealiste vu la complexite de certains projets.
Meme sans compter ces problemes de jeunesse, il faut aussi voir l'integration des differents composants entre eux, la cohabitation le fait que les developpeurs upstream n'ont pas forcement de quoi valider sur plusieurs architectures, ni focement la meme version de chaine de compilation, plus les potentiels problemes de packaging, etc...
Maintenant si tu consideres qu'il faut gerer ca pour quelques 8000 paquets source upstream, ca prend un peu de temps...
C'est un peu ce qu'essaie de faire Progeny (et donc Murdock) avec le Componentized Linux, mais avec plus de grnularite.
En gros, chaque composant a son propre "repository", ce qui permet d'en faire evoluer un independament des autres, le tout etant de conserver la compatibilites. L'idee me plait bien, je me pose juste des questions sur les details techniques. Et ma derniere tentative d'installation s'est soldee par un plantage d'annaconda :(
A ouais... je comprends mieux le coup des régulateurs de vitesses...
Je le refais au cas ou ce n'etait pas deja evident. Ce n'etait pas pour des vehicules de serie mais des chassis de Formule 1. Et je peux t'assurer que ce ne sont pas les memes electroniques vu le prix.
Vous faites des testes sur 3 cartes de teste et vous "prouvé" que cela marche sur tous les composants :(
Pas du tout. On produit 36 boitiers, on passe les 36 cartes et boitiers aux tests de contraintes et validation avant de les mettre sur la piste. Et on le repasse tous les x km. Et au bout d'un certain kilometrage, il n'est plus utilise qu'a l'usine pour les tests ou il ne subira pas les contraintes de vibration et de chaleur (banc d'essais, simulateurs, etc...).
Quand au niveau des timings des composants, il en est evidement tenu compte dans la programmation au niveau soft.
Je l'ai deja ecrit, je n'ai aucune connaissance interne de l'electronique d'une voiture de serie ; donc ne tire aucune conclusion sur les problemes de regulateur de vitesse a partir de ce que j'ecris.
Parti dans mon trip, je me rends compte que je n'ai pas vraiment repondu a ta question.
Pour tout ce qui est critique (commandes volant, infos de capteurs de pedale d'accelerateur surtout), tout est double par securite. Deux capteurs, chacun sur deux bus de communication vers le boitier de controle, pour lequel des decisions sont prises en cas de valeurs differentes suivant les effets que ca va avoir.
La pedale de freins n'en a pas besoin, vu que c'est un "bete" systeme hydraulique. La seule intervention que peut avoir l'eletronique, c'est modifier la repartition avant/arriere, donc a part pour telemetrie/controle, ce n'est pas bien grave de ne pas avoir la valeur.
Sinon en interne, ben si un controlleur CAN claque, on espere que le 2eme va tenir, si un CPU crame, on ne peut pas y faire grand chose (quoi que...).
Pour le cote hardware, on utilisait des boites speciales (shake & bake).
-Une tres violente sur les cartes avant meme le premier boot, pour de tres fortes variations de temperatures, de -30 a +90 (degres C) et tres rapides, 10 degres/minutes il me semble. Vive l'azole liquide.
-Une differente avec boitier en fonctionnement qui logge toutes les donnees sur tous les capteurs, avec des vibrations et accelerations. Ca prend 10g, 4g a des grosses frequences genre 100, 1000Hz, et ca tourne toujours sans broncher. On commence a avoir des problemes avec une temperature interne de 90 degres (les alims coupent un 10eme de seconde pour refroidir). Par contre on m'avait fait modifier la valeur de temperature mini avant erreur, ca tenait bien a -10. (l'erreur etant la pour signifier que le capteur de temperature est mort). A noter que les boitiers fonctionnent toujours avec un choc de 28g (dans la voiture)...
Bien sur, tous les composants etaient aux spec militaires.
J'ai vu la deuxieme servir a tester la resistance des volants et cages d'embrayage aux vibrations.
Niveau soft, c'est a l'ancienne, en C + asm pour les parties critiques, pas d'outil de verification formelle. Par contre le code est entierement valide avec lint histoire d'eliminer un certain nombre de risques de betises, et teste pendant tres longtemps avec un certain nombre d'outils specifiques, dont simulateurs. De memoire, il y a eu 6 mois entre les premiers essais sur banc et la premiere apparition sur piste. Ca parrait un peu surrealiste aujourd'hui, mais si les gens travaillent proprement et savent ce qu'ils font, ca se passe tres bien. Garder un design simple aide beaucoup a gerer.
A noter quand meme :
-Malgres les changements d'architecture, le code n'a jamais ete repris from scratch depuis des annees mais a evolue, ce qui explique que ce soit gere par interruptions.
-Il y a une nette separation bas et haut niveau. Le haut niveau (gestion boite, traction control, supension active) tend a etre arch-independant
-2 personnes seulement pour gerer toute la partie bas-niveau. On s'entendait bien et on se comprenait techniquement, ca aide beaucoup.
-La partie haut niveau, je n'y avais pas acces (j'etais en CDD), mais j'ai cru comprendre que c'etait en partie genere par Matlab.
-Quand un plantage veut dire "potentiellement je risque d'envoyer un mec a 360 km/h dans un mur en direct a la tele", tu vais attention :)
Pour situer, ca se passait il y a un an et demi, et vu que les personnes n'ont pas change depuis, je pense que les methodes sont les memes.
Bon, maintenant arretez de me faire en parler, ca remue le couteau dans la plaie, j'ai envie d'y retourner :P
Pour les curieux, en F1, il n'y a que 3 fournisseurs d'equipement electronique embarque :
-Magnetti Marelli, propriete du groupe Fiat
-McLaren Electronics (ex TAG Eletronics), faisant partie du groupe McLaren
-PI research, recement vendu par Ford avec Cosworth
Avec ca, on couvre 90% du plateau.
Pour le reste, c'est Williams et BMW les deux seuls a faire l'eletronique hard/soft eux-meme. (homis pour les trucs generiques du type capteurs divers et varies)
De relire mieux mon commentaire. Le fait d'avoir le droit de modifier le code soi-meme n'est qu'un aspect de la chose. Il y a aussi qu'il peut le faire faire par une tierce personne competente s'il en resent le besoin (sans que ce soit necessairement celle qui lui a fourni ledit logiciel), qu'il est tout a fait en droit de le redistribuer legalement selon les memes termes que ceux dans lesquels il l'a obtenu, et que s'il est curieux il a le droit d'essayer de comprendre comment ca fonctionne .
Quand on parle de 4 libertes, le fait de pouvoir modifier le code n'est est qu'une.
Felicitations, rien a redire 19/20 (juste, par principe, on ne met pas 20/20) ;o)
Le fait est que l'industrie auto, je n'ai pas vu l'aspect grand public. Pour avoir travaille chez l'un des 4 que j'ai cites, je peux dire qu'on n'hesite pas a avoir un boitier unique pour toute la gestion du chassis (plus un a part pour le moteur), aussi bien la repartition de freinage que la boite de vitesses , l'embrayage, l'accelerateur, le controle de motricite, la suspension active, le volant, plus la batterie de capteurs et les transmissions (pile IP incluse). Le tout avec un systeme fonctionnant entierement par interruptions.
Il faut avoir confiance, mais aussi etonnant que ca puisse parraitre, ca marche, et je n'ai jamais eu echo d'un probleme logiciel en piste (a part a cause d'une patte d'un composant cassee a force de vibrations).
Bon, a l'arrivee, ce sont de toute facon deux domaines qui n'ont pas grand chose en commun
Note : Maintenant je fais dans la telephonie mobile, c'est moins rigolo...
Je pertinentoisifie ton post, j'aimerais juste reprendre la fin.
Que le grand public s'en foute d'avoir les sources c'est une chose ; mais il reste important qu'il sache qu'il y a acces, qu'il peut le modifier (ou le faire modifier) pour l'adapter a ses besoins, redistribuer le logiciel, etc... Bref, les 4 libertes tralala-machin.
En fait il suffirait que les utilisateurs lisent les licences...
Je trouve que tu as tout a fait raison !
Je propose donc de mettre fin a toutes les distributions existantes et que tout le monde utilise une LFS. La compilation, c'est ca qui est important.
Je propose egalement de bannir les projets d'interface graphiques, de bruler toutes les cartes au-dela du CGA et le retour a une console serie impose a tous, pour bien prendre conscience de l'importance de la ligne de commande et donc du libre.
N'empeche que 32 bits, c'est bien pratique pour l'alignement des donnees (par rapport aux 24 bits, hein, pas aux 16). Les 8 bits en rab, on peut les utiliser en genral soir pour ajouter un canal alpha, soit faire un bete padding.
Sinon, soit le dév. a prévu le coup et tout se passe bien (on peut imaginer que le soft exprime sont mécontentement et continue avec une solution de secours ou alors se ferme). Soit le dév. a fait ça de manière un peu sale et il va manipuler un pointeur NULL, ce qui devrait aboutir tôt ou tard à un seg fault mérité :)
J'ajoute que ce comportement a justement ca d'utile, on ne va pas se prendre un mechant coup de "unresolved symbol" parce que la lib machinchose n'est pas present. Au premier abord ca peut parraitre bizarre, mais ca permet de faire de la gestion conditionelle.
Par exemple, on peut vouloir proposer d'utiliser au choix MySQL, PostgreSQL, SQLite, Oracle, ...
Plutot que de linker dynamiquement (methode 2), on essaie de trouver la lib depuis le code, et si elle n'est pas la, tant pis, on passe, on n'essaie pas d'appeler. Ca permet de ne pas avoir besoin que toutes les libs, y compris celles inutiles, soient presentes a l'execution. Tres agreable avec un systeme de packages avec gestion des dependances pour eviter de se retrouver avec une demi-douzaine de libs installees dont on se fout completement.
Par contre derriere il faut bien gerer sont truc proprement, sinon ca explose de partout.
# J'ai honte...
Posté par imalip . En réponse au journal Moiteur au sous-sol. Évalué à 10.
Bon, ok, ----->[]
[^] # Re: Des noms !
Posté par imalip . En réponse au journal Qu'elles sont les entreprises pour les brevets logiciels ?. Évalué à 2.
Samsung utilise une plateforme Qualcomm pour ses telephones. Hors Qualcomm est pro-brevets logiciels : http://gauss.ffii.org/Search/All/Applicant/Qualcomm%20inc(...)
Panasonic utilise ou va utiliser une plateforme Ericsson. Ericsson est pro-brevets logiciels. Je le sais, j'y bosse, j'ai vu les brevets deposes. La politique pourrait se resumer a "votre idee peut vous parraitre evidente, mais essayez toujours, on ne sait jamais, sur un malentendu ca pourrait marcher".
Sagem va utiliser une plateforme Ericsson pour ses futurs mobiles 3G.
Quand a Motorola, voila ce qu'on trouve dans certaines de leurs docs :
Source : http://www.motorola.com/cgiss/docs/TS3000InstallationManual.pdf(...)
# Telephonie mobile
Posté par imalip . En réponse au journal Qu'elles sont les entreprises pour les brevets logiciels ?. Évalué à 10.
1. Nokia, pro-brevet
2. Samsung. Plateforme Qualcomm, pro-brevet (CDMA entre autre)
3. Motorolla, pro-brevet
Les 7 suivants, peu importe la marque, c'est plateforme Ericsson, pro-brevet.
Tu peux toujours essayer de jeter un oeil du cote des GSM Sagem (pas UMTS) ou Sendo pour essayer de savoir ce qu'ils utilisent, mais il y a peu d'espoir.
Bref, si tu ne veux pas d'entreprise pro-brevet dans ton telephone, tu peux te mettre aux signaux de fumee, avec un peu de chance les vieux films de western peuvent faire office de preuve d'anteriorite...
[^] # Re: Apports du 64 bits ?
Posté par imalip . En réponse au journal x86_64 es-ce vraiment utile. Évalué à 4.
Au contraire ce serait tres utile. Ca permettrait de savoir dans quelle mesure l'amelioration de performances est due aux changements d'acrhitecture interne tels que l'integration du controlleur memoire, et dans quelle mesure ca vient du passage a 64 bits.
Le P4 32 bits integre les instructions SSE2 depuis des annees. Est-il necessaire de passer a 64 bits pour les integrer ?
Et pour faire ca, le passage a 64 bits etait necessaire ? Si tu utilises ton athlon64 en 32 bits, ca te force a utiliser un controlleur externe ?
# Routerboard
Posté par imalip . En réponse au journal Besoin d'aide pour achat de routeur. Évalué à 3.
http://www.routerboard.com(...)
En particulier, la 500 est assez impressionante
[^] # Re: Hey mais c'est génial ca!!
Posté par imalip . En réponse à la dépêche Sender ID, passage en force de Microsoft. Évalué à 2.
Comme je l'ai ecrit juste au-dessus, ce n'est pas ce critere-la qui est teste. C'est "est-ce que cette machine est correctement declaree sur le reseau". Ca n'a rien a voir avec le MTA, c'est un pur probleme de DNS.
[^] # Re: Hey mais c'est génial ca!!
Posté par imalip . En réponse à la dépêche Sender ID, passage en force de Microsoft. Évalué à 4.
1/ Est-ce que l'adresse IP de laquelle j'ai recu ce message a un reverse declare ? Si ce n'est pas le cas, je jete.
2/ Je prends le resultat du test N°1, et je fais une recherche DNS dessus. Si aucune des IP retournees n'est celle qui m'a envoye le message, je jete.
Et ca n'a rien a voir avec le champ From: du mail.
Donc, je confirme les dires de Colin Leroy, le service qui t'heberge a des DNS mal configures. Tu peux (devrais) te plaindre aupres d'eux.
[^] # Re: Dans le même esprit....
Posté par imalip . En réponse au journal Vive GNU/linux & Airbus A380. Évalué à 2.
Ne t'en fais pas, a priori c'est pas pour demain. Et si ca devait t'arriver, on n'a jamais vu l'electronique poser probleme. Par contre, les pneus, les freins, l'embrayage, la boite, le moteur, les supensions ca s'est vu. Et quand ton saut perilleux arriere se termine, la telemetrie affiche que tu as pris 28g.
Y'a rien de plus chiant que de vérifier les temps de setup et de hold d'io de 2 puces mais crois moi, si un des composants à un arbre d'horloge rapide et l'autre à un arbre lent, tu va au devant de très gros emmerde. Genre un cpu avec un fpga type actel... au hasard :)
Comme l'a dit le monsieur au-dessus, on n'a pas les memes contraintes. On travaillait sur des plages de temperatures qui sont relativement limitees, les problemes que tu as ne s'appliquaient pas dans notre cas.
Les systèmes spatiaux européens ne mettent pas encore la vie humaine en jeu.
Ceux qui equipent les Formule 1 oui, en direct a la tele.
C'est bizarre, je m'attendais plutot a voir des gens reagir sur la methode de developpement logicielle plutot anachronique, pas sur l'eletronique en elle-meme...
[^] # Re: Debian is still alive !
Posté par imalip . En réponse au journal Le futur de Debian. Évalué à 2.
[^] # Re: Debian is still alive !
Posté par imalip . En réponse au journal Le futur de Debian. Évalué à 3.
Meme sans compter ces problemes de jeunesse, il faut aussi voir l'integration des differents composants entre eux, la cohabitation le fait que les developpeurs upstream n'ont pas forcement de quoi valider sur plusieurs architectures, ni focement la meme version de chaine de compilation, plus les potentiels problemes de packaging, etc...
Maintenant si tu consideres qu'il faut gerer ca pour quelques 8000 paquets source upstream, ca prend un peu de temps...
[^] # Re: Debian is still alive !
Posté par imalip . En réponse au journal Le futur de Debian. Évalué à 2.
En gros, chaque composant a son propre "repository", ce qui permet d'en faire evoluer un independament des autres, le tout etant de conserver la compatibilites. L'idee me plait bien, je me pose juste des questions sur les details techniques. Et ma derniere tentative d'installation s'est soldee par un plantage d'annaconda :(
Plus d'infos :
http://componentizedlinux.org/(...)
[^] # Re: Dans le même esprit....
Posté par imalip . En réponse au journal Vive GNU/linux & Airbus A380. Évalué à 2.
Je le refais au cas ou ce n'etait pas deja evident. Ce n'etait pas pour des vehicules de serie mais des chassis de Formule 1. Et je peux t'assurer que ce ne sont pas les memes electroniques vu le prix.
Vous faites des testes sur 3 cartes de teste et vous "prouvé" que cela marche sur tous les composants :(
Pas du tout. On produit 36 boitiers, on passe les 36 cartes et boitiers aux tests de contraintes et validation avant de les mettre sur la piste. Et on le repasse tous les x km. Et au bout d'un certain kilometrage, il n'est plus utilise qu'a l'usine pour les tests ou il ne subira pas les contraintes de vibration et de chaleur (banc d'essais, simulateurs, etc...).
Quand au niveau des timings des composants, il en est evidement tenu compte dans la programmation au niveau soft.
Je l'ai deja ecrit, je n'ai aucune connaissance interne de l'electronique d'une voiture de serie ; donc ne tire aucune conclusion sur les problemes de regulateur de vitesse a partir de ce que j'ecris.
[^] # Re: Dans le même esprit....
Posté par imalip . En réponse au journal Vive GNU/linux & Airbus A380. Évalué à 2.
Parti dans mon trip, je me rends compte que je n'ai pas vraiment repondu a ta question.
Pour tout ce qui est critique (commandes volant, infos de capteurs de pedale d'accelerateur surtout), tout est double par securite. Deux capteurs, chacun sur deux bus de communication vers le boitier de controle, pour lequel des decisions sont prises en cas de valeurs differentes suivant les effets que ca va avoir.
La pedale de freins n'en a pas besoin, vu que c'est un "bete" systeme hydraulique. La seule intervention que peut avoir l'eletronique, c'est modifier la repartition avant/arriere, donc a part pour telemetrie/controle, ce n'est pas bien grave de ne pas avoir la valeur.
Sinon en interne, ben si un controlleur CAN claque, on espere que le 2eme va tenir, si un CPU crame, on ne peut pas y faire grand chose (quoi que...).
[^] # Re: Dans le même esprit....
Posté par imalip . En réponse au journal Vive GNU/linux & Airbus A380. Évalué à 5.
Pour le cote hardware, on utilisait des boites speciales (shake & bake).
-Une tres violente sur les cartes avant meme le premier boot, pour de tres fortes variations de temperatures, de -30 a +90 (degres C) et tres rapides, 10 degres/minutes il me semble. Vive l'azole liquide.
-Une differente avec boitier en fonctionnement qui logge toutes les donnees sur tous les capteurs, avec des vibrations et accelerations. Ca prend 10g, 4g a des grosses frequences genre 100, 1000Hz, et ca tourne toujours sans broncher. On commence a avoir des problemes avec une temperature interne de 90 degres (les alims coupent un 10eme de seconde pour refroidir). Par contre on m'avait fait modifier la valeur de temperature mini avant erreur, ca tenait bien a -10. (l'erreur etant la pour signifier que le capteur de temperature est mort). A noter que les boitiers fonctionnent toujours avec un choc de 28g (dans la voiture)...
Bien sur, tous les composants etaient aux spec militaires.
J'ai vu la deuxieme servir a tester la resistance des volants et cages d'embrayage aux vibrations.
Niveau soft, c'est a l'ancienne, en C + asm pour les parties critiques, pas d'outil de verification formelle. Par contre le code est entierement valide avec lint histoire d'eliminer un certain nombre de risques de betises, et teste pendant tres longtemps avec un certain nombre d'outils specifiques, dont simulateurs. De memoire, il y a eu 6 mois entre les premiers essais sur banc et la premiere apparition sur piste. Ca parrait un peu surrealiste aujourd'hui, mais si les gens travaillent proprement et savent ce qu'ils font, ca se passe tres bien. Garder un design simple aide beaucoup a gerer.
A noter quand meme :
-Malgres les changements d'architecture, le code n'a jamais ete repris from scratch depuis des annees mais a evolue, ce qui explique que ce soit gere par interruptions.
-Il y a une nette separation bas et haut niveau. Le haut niveau (gestion boite, traction control, supension active) tend a etre arch-independant
-2 personnes seulement pour gerer toute la partie bas-niveau. On s'entendait bien et on se comprenait techniquement, ca aide beaucoup.
-La partie haut niveau, je n'y avais pas acces (j'etais en CDD), mais j'ai cru comprendre que c'etait en partie genere par Matlab.
-Quand un plantage veut dire "potentiellement je risque d'envoyer un mec a 360 km/h dans un mur en direct a la tele", tu vais attention :)
Pour situer, ca se passait il y a un an et demi, et vu que les personnes n'ont pas change depuis, je pense que les methodes sont les memes.
Bon, maintenant arretez de me faire en parler, ca remue le couteau dans la plaie, j'ai envie d'y retourner :P
[^] # Re: Dans le même esprit....
Posté par imalip . En réponse au journal Vive GNU/linux & Airbus A380. Évalué à 2.
Sur les voitures de serie, par contre...
[^] # Re: Dans le même esprit....
Posté par imalip . En réponse au journal Vive GNU/linux & Airbus A380. Évalué à 3.
-Magnetti Marelli, propriete du groupe Fiat
-McLaren Electronics (ex TAG Eletronics), faisant partie du groupe McLaren
-PI research, recement vendu par Ford avec Cosworth
Avec ca, on couvre 90% du plateau.
Pour le reste, c'est Williams et BMW les deux seuls a faire l'eletronique hard/soft eux-meme. (homis pour les trucs generiques du type capteurs divers et varies)
A l'epoque, Prost utilisait du TAG.
[^] # Re: deux questions
Posté par imalip . En réponse au journal La liberté .... belle utopie. Évalué à 2.
Quand on parle de 4 libertes, le fait de pouvoir modifier le code n'est est qu'une.
[^] # Re: Dans le même esprit....
Posté par imalip . En réponse au journal Vive GNU/linux & Airbus A380. Évalué à 4.
Le fait est que l'industrie auto, je n'ai pas vu l'aspect grand public. Pour avoir travaille chez l'un des 4 que j'ai cites, je peux dire qu'on n'hesite pas a avoir un boitier unique pour toute la gestion du chassis (plus un a part pour le moteur), aussi bien la repartition de freinage que la boite de vitesses , l'embrayage, l'accelerateur, le controle de motricite, la suspension active, le volant, plus la batterie de capteurs et les transmissions (pile IP incluse). Le tout avec un systeme fonctionnant entierement par interruptions.
Il faut avoir confiance, mais aussi etonnant que ca puisse parraitre, ca marche, et je n'ai jamais eu echo d'un probleme logiciel en piste (a part a cause d'une patte d'un composant cassee a force de vibrations).
Bon, a l'arrivee, ce sont de toute facon deux domaines qui n'ont pas grand chose en commun
Note : Maintenant je fais dans la telephonie mobile, c'est moins rigolo...
[^] # Re: Dans le même esprit....
Posté par imalip . En réponse au journal Vive GNU/linux & Airbus A380. Évalué à 6.
En sport automobile par contre, ca l'air d'etre plus du fait-maison pour ce que j'en ai vu (Williams, BMW, McLaren Electronics, PI research)
[^] # Re: Je verrais bien aussi
Posté par imalip . En réponse au journal idée Marketing pour le libre. Évalué à 2.
par debouchées, tu veux dire vomissements ?
[^] # Re: clikodrome pas bien !
Posté par imalip . En réponse au journal La liberté .... belle utopie. Évalué à 4.
Mauvaise nouvelle alors :
http://www.h1.org/~ncryer/kde.png(...)
[^] # Re: deux questions
Posté par imalip . En réponse au journal La liberté .... belle utopie. Évalué à 1.
Que le grand public s'en foute d'avoir les sources c'est une chose ; mais il reste important qu'il sache qu'il y a acces, qu'il peut le modifier (ou le faire modifier) pour l'adapter a ses besoins, redistribuer le logiciel, etc... Bref, les 4 libertes tralala-machin.
En fait il suffirait que les utilisateurs lisent les licences...
# VT100
Posté par imalip . En réponse au journal La liberté .... belle utopie. Évalué à 10.
Je propose donc de mettre fin a toutes les distributions existantes et que tout le monde utilise une LFS. La compilation, c'est ca qui est important.
Je propose egalement de bannir les projets d'interface graphiques, de bruler toutes les cartes au-dela du CGA et le retour a une console serie impose a tous, pour bien prendre conscience de l'importance de la ligne de commande et donc du libre.
[^] # Re: 16 bits contre 32 bits
Posté par imalip . En réponse au journal Quelques stats. Évalué à 2.
[^] # Re: Confusion link dynamique / appel dynamique
Posté par imalip . En réponse au journal Fonctionnement du linker dynamic sous linux. Évalué à 3.
J'ajoute que ce comportement a justement ca d'utile, on ne va pas se prendre un mechant coup de "unresolved symbol" parce que la lib machinchose n'est pas present. Au premier abord ca peut parraitre bizarre, mais ca permet de faire de la gestion conditionelle.
Par exemple, on peut vouloir proposer d'utiliser au choix MySQL, PostgreSQL, SQLite, Oracle, ...
Plutot que de linker dynamiquement (methode 2), on essaie de trouver la lib depuis le code, et si elle n'est pas la, tant pis, on passe, on n'essaie pas d'appeler. Ca permet de ne pas avoir besoin que toutes les libs, y compris celles inutiles, soient presentes a l'execution. Tres agreable avec un systeme de packages avec gestion des dependances pour eviter de se retrouver avec une demi-douzaine de libs installees dont on se fout completement.
Par contre derriere il faut bien gerer sont truc proprement, sinon ca explose de partout.