Se connecter
Se connecter
Mot de passe oublié ?
ou
Créer un compte
ou
Se connecter avec Facebook
Notifications
< Retour vers Bidouille & Développement Informatique
Agrandir
Bidouille & Développement Informatique
Les Mains dans le Cambouis
Bidouille & Développement Informatique
Actu 1 1
Articles
Médias 33 33
Tutoriels
Forums 326 326

Sujet Le pub des programmeurs

  • 1 925 réponses
  • 117 participants
  • 120 165 vues
  • 130 followers
Sujet de la discussion Le pub des programmeurs
Salut :coucou: y a des programeurs sur AF si oui vous bossez sous quoi ?
Afficher le sujet de la discussion
921

Citation : Bof, je crois pas etre si passione que ca, et Torvald sort souvent des anneries aussi, je cherche pas a le defendre a tout prix.


Tu es parti au quart de tour quand même ! :bravo:
Ca donne l'occasion de te taquiner, mais note bien que je n'ai pas écrit "ta passion t'aveugle", d'autant qu'on est quasiment d'accord sur tout.

Citation : Peut etre, mais "Linux fits many more sizes than any other OS ever has before" (c'est la loi de Gabou).


Pour l'instant Windows fits much more ! Mais c'est vrai que côté serveurs et autre informatique professionnelle, Linux a balayé les UNIX et d'autres produits à une vitesse incroyable. On est d'accord que jamais QNX et son micro-noyau ne vont remplacer Linux sur la moitié de machines où Linux est aujourd'hui, c'est une évidence.

Citation : Ca n'a jamais ete fait avant. Ca montre bien qu'il y a quelque chose qu'il y a quelque chose qui fait que le design et plus globalement tout le process autour de linux marche extremement bien.


Certes. Ca ne veut pas dire que Linux était toujours meilleur que ce qu'il a remplacé ; des fois il était simplement beaucoup moins cher, et au global ça suffisait pour l'emporter. Par exemple le multithreading était bien pourri avant le noyau 2.6 (et les NPTL) alors qu'il était ok depuis longtemps chez les autres Unix. On en revient au même point : contrairement à ce que dit Tanenbaum, les endroits où on a vivement besoin d'un noyau beaucoup plus fiable que celui de Linux sont certainement extrêmement rares.

En plus ya moyen de gagner beaucoup en fiabilité sans passer au micro noyau : en figeant des drivers (UAA de Vista ...) ou en les mettant en user space... et plein d'autres trucs.

Citation : Mais tout ca, ce ne sont pas des systemes distribues au sens ou Torvald l'entend.

[edit] D'ailleurs, dans quasiment tous ces domaines, Linux est de plus en plus utilise. Salle de marche ? Wall Street est de plus en plus interesse par Linux (j'ai pas trop suivi non plus); controle de fusee/satellites, la, je sais pas trop, c'est pas un domaine que je suis non plus.


Mmmh, si, je pense que Torvalds parlait des "applications distribuées" (et non d'un OS distribué), car derrière il ajoute :

Citation : In contrast, if you do distributed physics calculations, and one node goes down, you can usually just re-assign another node to do the same calculation over again from the beginning. That is not true if you have a really distributed system and you didn't even know where the data was coming from or where it was going


Je pense que ce sont des utilisations dont il n'est pas familier, c'est tout.

Et oui dans ces systèmes c'était très généralement des Unix commerciaux qui étaient utilisés, et donc désormais Linux pratiquement partout. Les défauts des threads et du support du C++ étaient encore gênant il y a quelques années, mais maintenant c'est fini. D'ailleurs l'implication d'IBM et autres intel (au niveau de son compilateur) montre bien que la direction actuelle est complètement Linux (pour ce genre de systèmes).

Citation : Oui mais Torvald n'a toujours parle que de son domaine, la ou les performances comptent enormement.


On est d'accord. Pour certaines applications (et non OS), courantes dans l'industrie (mais pas côté grand public), ces concepts sont intéressants. Pour le système d'exploitation, possible que ça ait un intérêt, mais certainement très confidentiel.

SAP tourne sur Windows NT, doit tourner sur Linux, et ne doit rien avoir à foutre d'un micro-noyau. Tibco, Oracle, Weblogic et MQ-Series non plus !

C'est bien l'homme qui cause le dérèglement climatique - AudioFanzine sans PUBlicité

922

Citation : D'ailleurs, dans quasiment tous ces domaines, Linux est de plus en plus utilise.


En gros, à partir de B, jusqu'à E on trouve du linux.
Pour du A je pense que ce n'est jamais le cas, et que ce n'est pas près de l'être : Linux compte trop de lignes pour être certifiable. Mais c'est un marché ultra-spécifique (notamment au niveau hardware). Donc ça n'apporte rien par rapport au débat Tanenbaum / Torvalds.

C'est bien l'homme qui cause le dérèglement climatique - AudioFanzine sans PUBlicité

923

Citation :
Pour l'instant Windows fits much more !



Franchement, je vois pas pourquoi tu dis ca ? Deja, windows tourne pas sur tant d'architectures que ca (x86 pour les windows classiques, ppc pour la xbox 360, et arm pour windows CE ?). Ensuite, meme si c'est souvent anectodique, chaque fois qu'un nouveau truc sort en hardware, linux tourne dessus peu de temps apres: ca va des consoles de jeu a toute sorte de NAS et cie.

Linux tourne quand meme sur pres de 50 architectures differentes. Il y a enormement de FS qui tournent sous linux (la aussi, pionnier a ce niveau la: rien de revolutionnaire, mais le vfs de linux est en avance sur tous les autres UNIX depuis longtemps autant que je sache)

Apres, la ou je te suis completement, c'est que linux marche pour les memes raisons que windows, quelque part: tu peux avoir le meme systeme au boulot et a la maison, et ca, pour le developpement, c'est important. Ballmer gueulait developers, developers, et le mouvement open source en general fournit ca a des niveaux dont meme MS ne peut pas rever.

Citation :
Par exemple le multithreading était bien pourri avant le noyau 2.6 alors qu'il était ok depuis longtemps chez les autres Unix



C'est discutable, ca. Il y a quand meme un point important a ce niveau la: linux a ete le seul OS generaliste (a ma connaissance) qui au court du temps, a vu ses performances de creation / context de process augmenter et non diminuer. Ensuite, le multi threading, c'est pas dans la philosophie Unix. Enfin, c'est une des innovations et differences importantes de linux par rapport aux autres Unix, il y a le system call clone, qui rentre en jeu la dedans, qui permet de creer des processus/threads tres rapidement (man clone Unlike fork(2), these calls allow the child process to share parts of its execution context with the calling process, such as the memory space, the table of file descriptors, and the table of signal handlers. (Note that on this manual page, "calling process" normally corresponds to "parent process". But see the description of CLONE_PARENT below.)

Il y a quelques annees, j'avais cette idee que les Unix proprietaires etaient "vachement plus mieux" que linux niveau performances, et la, avec opensolaris, qui est quand meme repute (c'est le meme code que solaris), tu vois qu'en fait, les performances sont bien moindres que linux dans pas mal de cas.

Citation :
Pour du A je pense que ce n'est jamais le cas, et que ce n'est pas près de l'être : Linux compte trop de lignes pour être certifiabl



A ce niveau la, tu peux pas utiliser le C, de toute facon, non ? C'est typiquement le sujet sur lequel je connais rien. T'as des projets comme ASTREE: ); return false;" rel="nofollow" target="_blank">http://www.astree.ens.fr/, qui font la verification du C, mais je me souvient m'etre fait explique par des gens beaucoup plus intelligents que moi que le C est une horreur quan d tu veux faire des preuves formelles, car le langage a enormement de situations non specifiees (pour ASTREE, ils precisent que tu ne peux pas utiliser d'allocation dynamique, par exemple).
924

Citation : Franchement, je vois pas pourquoi tu dis ca ? Deja, windows tourne pas sur tant d'architectures que ca (x86 pour les windows classiques, ppc pour la xbox 360, et arm pour windows CE ?)


Je parlais en nombre d'utilisateurs (donc nombre de PCs équipés avec Linux ou Windows). Je reconnais que dès que l'on va parler de "nombre de types d'utilisateurs différents", Linux l'emporte probablement déjà. Toi tu parles du hardware, et là aussi Linux supporte beaucoup plus de plateformes.

Citation : C'est discutable, ca. Il y a quand meme un point important a ce niveau la: linux a ete le seul OS generaliste (a ma connaissance) qui au court du temps, a vu ses performances de creation / context de process augmenter et non diminuer. Ensuite, le multi threading, c'est pas dans la philosophie Unix.


Un problème typique et très gênant : tu fais la maintenance d'un logiciel sur 10 ou 20 ans, au début il est sur un Unix commercial, et il est multithread. Tant que dans Linux les threads systèmes étaient plaqués sur des processus, les signaux (SIGPIPE...) atterrissaient forcément dans le thread responsable de l'action. Or avec POSIX il n'était pas censé avoir cette limitation, le signal est de niveau processus et non thread. D'où gros problème. Maintenant qu'il y a la Native Posix Thread Library, c'est ok.

Citation : A ce niveau la, tu peux pas utiliser le C, de toute facon, non ?


Si, ça peut. Par contre faut que le compilateur soit certifié également, ce qui élimine aussi gcc. Ca se complique. :mrg:
Les méthodes formelles ne sont pas systématiquement utilisées dans ces contextes. Il peut y avoir un mélange aussi : méthode formelle (SDL) pour le découpage en tâches (processus ou threads, mono ou multi machines) et inter-communications, puis codage avec tests unitaires de bouts de code purement fonctionnels.

C'est bien l'homme qui cause le dérèglement climatique - AudioFanzine sans PUBlicité

925

Citation :
Je parlais en nombre d'utilisateurs (donc nombre de PCs équipés avec Linux ou Windows).



Ah, ok. Mais a ce niveau la, ca veut plus dire grand chose techniquement. Linux qui tourne sur 50 arch differentes, ca veut dire quelque chose techniquement. Windows qui fournit 95 % des machines desktop, ca veut aussi dire quelque chose, mais c'est plus forcement technique :)

Citation :
Or avec POSIX il n'était pas censé avoir cette limitation, le signal est de niveau processus et non thread.



Surtout, pthread est ultra sous specifie vis a vis des signaux. Je crois pas que ce probleme soit specifique a Linux ? Comme le dit Brian Sullivan (a priori pas un demi mauvais a ce sujet):

Citation :
On Unix systems, using threads and signals together is a nightmare.



D'ailleurs, je suis en train de me dire, un peu de mauvaise foi: la notion de thread, c'est finalement tout ce que Tannenbaum reproche a linux: tu partages ton espace d'adressage pour gagner en performances, mais ca devient beaucoup moins fiable :)
926

Citation :

Si, ça peut. Par contre faut que le compilateur soit certifié également, ce qui élimine aussi gcc. Ca se complique.



Il ya bien des limitations, puisque ASTREE par exemple ne peut pas prendre en compte l'allocation dynamique de memoire et la recursion. Un truc par exemple bien lourd en C pour un domaine que je connais un tout petit peu, le calcul numerique, c'est l'aliasing de pointeur. Fortran n'a pas ce probleme, et ca explique en grande partie ses performances.
927

Citation : D'ailleurs, je suis en train de me dire, un peu de mauvaise foi: la notion de thread, c'est finalement tout ce que Tannenbaum reproche a linux: tu partages ton espace d'adressage pour gagner en performances, mais ca devient beaucoup moins fiable


Exact. C'est bien ce à quoi je pensais en parlant des applications (par opposition à l'OS). Si on veut du très fiable, avec un coût de maintenance raisonnable, sur une longue durée et des gros logiciels, faut éviter les appels synchrones, donc le multithread, les call-backs... et privilégier (le plus possible mais sans délirer) l'asynchrone, les messages (appelés aussi événements), le monothread. C'est un peu plus compliqué dès le début, mais à terme ça vaut largement le coup. Alors que dans l'autre cas, on s'enfonce dans l'indémerdable.

John Ousterhout avait écrit un fameux papier là-dessus. Pas très technique, mais très bien expliqué. C'est surtout avec lui (et pour les applications que j'ai évoquées) que je suis d'accord. Je vois beaucoup moins l'intérêt pour l'OS ; donc je vote nettement Torvalds contre Tanenbaum pour les prochaines évolutions de Linux. ;)

C'est bien l'homme qui cause le dérèglement climatique - AudioFanzine sans PUBlicité

928
Salut,
J'ai besoin d'un petit conseil à propos d'un bouquin, je shouaite me mettre au vhdl, et je cherche donc des bouquins qui puisse m'apprendre à utiliser ce langage. Après recherches, j'ai trouvé VHDL Introduction à la synthèse logique (Philipe Larcher) quelqu'un connait ce bouquin ? Il est bien foutu, facile à comprendre ? Et est ce que le vhdl change en fonction du FPGA utilisé ? Genre, je programme un truc pour un Xilinx avec 400K de porte, je pourrais le mettre sur un autre qui aurait plus ou moins de porte ? (evidement si j'utilise les 400K, je risque pas de pouvoir mettre mon programme sur un 200K) ?

Merci.
929
Quand tu fais ta simulation, tu sais la place qu'il prend et donc si tu peux le mettre sur un 200k ou un 400k. Normalement, le VHDL est universel, donc un programme pour Xilink fonctionnera avec une autre marque aussi, il y a juste la bibliothèque de composants à changer au cas où.

http://blog.audio-tk.com/

Audio Toolkit: http://www.audio-tk.com/

930
J'ai un petit problème :

j'ai séparé ma page en trois frames horizontales et j'ai glissé mon menu déroulant dans l'une d'elles. Le problème est que les sous-menus n'apparaissent pas quand ils se déroulent, puisqu'ils sont cachés par la frame du dessous... :(
que faut-il faire ?

j'ai entendu parler d'un "z-index" , qui permettrait de régler ce pb mais je sais pas trop ce que c'est.