Quelle serait selon vous la meilleure distribution Linux pour gérer des outils de domotique ? Et pour quelles raisons ?
Le message suivant est spécialement dédié à Frédéric Mazué:
Tu pourrais m'aider à développer des outils de domotique en Java ? 8) 8) 8)
AMHA Il n'y en pas vraiment de "meilleure" du moins telle que la question est posée.
Si les périphériques sont connectés en Ethernet ou sur le port Série, n'importe quel vieux Linux ira très très bien.
Maintenant si les périfs sont de l'USB et du WI-FI, alors n'importe quel Linux ira très très bien :)
.... du moment qu'il y a un noyau >= 2.6 dedans
En fait la question quelle distrib peut se poser surtout si la machine qui accueille Linux n'est pas un PC classique. Si il s'agit d'embarquer un Linux dans un hardware exotique certaines distribs iront mieux que d'autres, mais là faut voir selon le hardware en question.
Par exemple une machine sans Cd-ROM ni lecteur mais capable de booter sur le réseau. Alors Debian est parfait pour ça, Puisqu'il existe un package de boot réseau.
Maintenant dans la Soekris qui embarque mon serveur, j'ai boostrapé une Gentoo qui n'est pas du tout prévue pour un boot réseau à la base. Mais avec Linux, jamais rien d'impossible :)
Java pas tête :?: :!: :twisted: :twisted: :twisted: :twisted: :twisted:
Merci pour ta réponse parfaite.
Bon pour Java évidemment je plaisantais. J'ai pas pu m'empêcher, comme je sais que c'est ton language préféré ... 8)
Si ça se trouve ma réponse n'est pas parfaite du tout.
Le monde Linux est tellement riche que peut être il existe une distribution dédiée à la domotique.
Si quelqu'un connaît ça, qu'il ne se prive surtout pas de donner l'info ici :)
Nan ?
Pourquoi ? Java me semble tout indiqué pour la domotique. C'est de l'information à basse fréquence, donc pas besoin de perfos. Par contre la richesse des bibliothèque de ce langage aiderait. Ainsi que la portabilité.
Je me trompe ?
Oui :)
Il n'y aura de portabilité que quand des bibliothèques pour piloter les périphériques auront été écrites pour toutes les plates-formes. Ce qu'on fera aussi bien en C si on veut.
Qui à écrire les bibli, je le fais simplement en C et je n'ai pas besoin d'interfacer ensuite avec le JNI, je gagne donc du temps Alors que Java m'en ferait perdre.
Et puis on parle de Linux en plus, alors la portabilité...
Tiens si je veux piloter un périphériques USB je le ferai bien plus facilement en C++ qu'en Java sous Linux.
Pas besoin de perfos tu dis :?:
Alors autre exemple. Ma soekris: 256 Mo de mémoire
Pour l'instant j'ai dedans Apache, Dovecot, Postfix, PostgreSQL
Ca tourne impec.
Supposons que je veuille aussi piloter un périf connecté sur le port série. Je sais le faire en 2mn en C ou C++
En Java faut déjà que je vérifie si leur bibliothèqe de port série fonctionne sur ma Soekris ce qui n'est pas gagné. Mais admettons. Quand j'aurais lancé la JVM, avec quoi les autres applis vont tourner ? Qu'est-ce qui va leur rester comme ressources mémoire et CPU :?:
rien
nada
nothing
(void *)NULL
Pas besoin de perfos ? En temps d'exécution admettons à la limite, mais en consommation de mémoire...
Java est bon à rien ici comme ailleurs. Bon dans une applet à la rigueur.
Bon ça va j'ai compris, tu as voulu me faire troller et tu as réussi ton coup ;)
:lol:
:D
Bon, ceci dit, pour des serveurs plus "standards" je ne suis pas ton avis sur Java - j'ai au boulot un type qui ne jure que par le C et qui se signe chaque fois que je prononce le mot "interprété" et c'est lourd à la fin - mais c'est un autre débat.
Pour revenir à ta question, la plus petite distrib que j'ai trouvé (je voulais faire tourner OpenOffice sur un PII 333 avec 96 Mo) c'est PuppyLinux (http://www.puppylinux.org) mais ça fait un peu gadget, j'ai l'impression. (pour info je n'ai pas réussi).
Quand tu l'auras utilisé un peu plus tu changeras d'opinion :)
En outre "serveurs standards" qu'est-ce que c'est ?
Il est vrai que j'ai pris un exemple très typé avec ma Soekris. :)
Mais alors disons que pour la domotique on va simplement recycler un vieux PC standard. J'en ai un justement. Je ne m'en sers que comme serveur de backups et je pourrais bien l'affecter aussi à la domotique. Ca parait raisonnable comme approche "standard". Parce que je vais quand même pas faire les frais d'un bi-xeon dernier cri pour allumer mon grille-pain ;) Seulement voilà, je n'ai que 256 mo de Ram dans ce PC aussi. Et on retombe sur le problème.
Moi je voudrais bien que tu me sortes un argument technique solide en faveur de Java. La question au départ c'est piloter des périf domotique sous Linux. Allez dis moi en quoi le choix de Java est il pertinent ?
Ah mais alors là non ce n'est pas le débat. Vraiment pas. Mais alors vraiment pas en ce qui me concerne.
Des types comme ça existent, il faut de tout pour faire un monde.
Mais je ne rentre pas dans cette catégorie. Je suis contre les dogmes et les credos en général et en informatique en particulier.
Je suis avant tout un pragmatique. Je ne choisis pas un outil par idéologie mais parce qu'il convient *bien* à un travail donné.
Et le jour où je devrai faire quelque chose pour lequel Java convient, je prendrai Java, sans état d'âme.
C'est simplement que jusqu'à aujourd'hui je n'ai jamais vu que Java soit le meilleur outil pour un travail et que chaque fois que j'ai du l'utiliser contraint et forcé à l'insu de mon plein gré, ça ne m'a apporté que des désagréments et des problèmes.
Mais je n'ai rien contre les langages interprétés moi. Si tu lis Programmez! depuis longtemps tu sauras que je suis un inconditionnel de Python depuis toujours.
J'ai même la faiblesse de croire avoir contribué à le faire connaître en France il y a quelques années.
Python c'est bien un langage interprété n'est-ce pas ?
Et Python c'est vraiment quelque chose de formidable.
C'est qu'OpenOffice tes 96 Mo il va les dévorer à lui tout seul.
Mais bon avec une partition de swap bien dimensionnée ;)
Mais pourquoi aller voir du côté de PuppyLinux pour ça ?
N'importe quelle distrib économiquement configurée, avec un noyau compilé le plus petit possible, ça doit le faire non ?
C'est vrai que je ne n'utilise Java (professionnellement) que depuis la 1.0b2 :P
Soyons sérieux, c'est un outil magnifique qui a amené la portabilité et l'interopérabilité à l'informatique.
Justement ça, ce n'est pas du tout un serveur standard. Combien de personnes font de la domotique ?
Un serveur standard c'est un pare-feu, un contrôleur réseau, un serveur web, de gestion de conf, de disque...
Clairement, il n'est pas pertinent dans ton cas - quoi que des runtimes Java tournent sur des cartes à puce...
Mais allons plus loin : en quoi Linux est-il pertinent pour on problème ?
Te rends-tu compte de la mémoire et du disque perdus par le système d'exploitation ?
Ce qu'il te faut, c'est un runtime temps-réel minimal permettant de faire tourner une seule aplication : la tienne. Peut-être justement en Java ?
Franchement là je ne te suis pas sur ce sujet. J'ai essayé Python et l'ai abandonné. C'est inexploitable de manière professionnelle. On en reparlera le jour où il y aura possibilité d'indenter de manière correcte et sûre.
Je travaille plutôt avec Perl (bon, ok c'est pas génial mais ça marche), Php (en tant que script, pas seulement sous Apache) ou TCL (sans Tk). En test en ce moment, j'essaie BeanShell (c'est un shell en Java)
Dans mon cas non, je ne crois pas, il me fallait au moins le JDK et un serveur X11 pour faire tourner Ooffice. Ce qui me mets en rage c'est que finalement ce PC tourne très bien - avec Ooffice - mais sous Windows98...
C'est donc une question d'appréciation....
En ce qui me concerne, les bugs du garbage collector de la 1.02 ne m'ont pas enchanté dès le départ.
Quand je vois que la fuite de mémoire des Jframe n'a été que corrigé récemment dans une révision de la 5.0, je ne trouve pas ça trop magnifique.
Et encore est-ce vraiment corrigé ?
Ah oui tiens, dans la JDK 5.0 ils viennent de corriger un énorme trou de sécu dans le traitement des gif.
Je me demande si ce trou était présent depusi la 1.02b ?
Bon je ne vais pas insister dans cette discussion.
Je sais comment ça commence et comment ça finit en général.
Tu trouves Java magnifique c'est ton droit. Qu'il en soit donc ainsi :)
Je le trouve détestable. C'est mon droit :)
Par contre je t'invite quand même à nuancer ton jugement. Je prends Python comme exemple. Je le prends simplement parce qu'il est déjà dans la discussion. J'aurais pu prendre autre chose.
Bref Python est antérieur à Java et avec lui il y avait déjà portabilité et interopérabilité. Et entendons nous bien, je ne dis pas que Python l'a amené. Parce qu'il y en a eu d'autres avant.
Je trouve vraiment dommage que tant de gens se fassent l'écho du marketing de Sun "Java a amené la portabilité". Ce n'est pas vrai.
J'ai souvent entendu aussi. "Java innove avec le ramasse miette". Alors qu'en fait, McCarthy avait mis le premier ramasse-miettes dans son Lisp il y a plus de 50 ans.
Ey man tu te contredis. :)
Quand j'ai pris l'exemple de ma Soekris, c'était bien un serveur standard au sens où tu l'entends. Serveur Web etc. C'est bien ce que j'ai dit. Et j'ai dit ne pas vouloir y ajouter un Java pour des raisons de consommations de ressources. Qu'il s'agisse de piloter de la domotique ou autre chose.
Tu m'as dit à ce moment "ce n'est pas standard" alors je me suis dit 'Bon il pense que ma Soekris n'est pas une machine standard," Alors je vais lui parler d'un vieux PC.
Je suis content de lire que ce n'est pas pertinent. Mais ce n'est pas "mon" cas
Ah voilà... taquin comme je suis, je ne peux pas m'empêcher de la lâcher: "est-ce pertinent ?"
:oops:
Mea culpa, je n'ai rien dit :oops: :oops:
Mais enfin en quoi est-ce mon problème :?: Je ne suis pas le posteur initial de la question moi :!:
Je n'ai aucun problème.
Meuh ?
M'enfin ?
Quid ?
Moi je te suis plus.
Un jour tu me dis que les perfs ce n'est pas important et le lendemain tu me parles de temps réel.
Là tu me parles de gâchis de mémoire et tu me dis de mettre un Java qui est quand même connu pour ne pas être économe à ce niveau. Et si j'ai une seule application dans une machine multi tâche ce n'est pas non plus un gâchis de ressources ?
Vraiment je ne te suis pas. Ou alors par "runtime temps réel minimum" tu as voulu parler d'une machine dédiée ?
Mais un runtime ce n'est pourtant pas machine. Je pige pas.
Par contre ce que je pige très bien c'est qu'un runtime réellement temps réel et réellement économe en ressouces, qui conviendrait très bien au propos ça existe en informatique. Ca s'appelle Erlang et ça mérite vraiment d'être découvert.
Lol :lol:
Lol :lol:
Pas génial question clarté du code en effet.
Mais Perl a rendu d'immenses services. Et il en rend encore.
Et il a sans aucun doute "amené" la portabilité avant Java ;)
Je connais. Tant que tu y es, essaie aussi Looking Glass :)
Ah bon ?
Ah bon ?
Bon pour X c'est d'accord :D
Mais comment se fait-il que j'ai OpenOffice qui tourne très bien sur mes bécanes sans Java ?
Curieux...
Mais je dois avouer que ça m'amuse que tu dises implicitement que Java est un rien gourmand ;)
Là je dois dire que tu me déçois.
Bon, pour les langages on ne va pas converger, je sens :wink:
(surtout que je n'ai encore rien dit sur ce que je pense de Ruby... :evil: )
On pourrait en faire un sujet à part entière.
Revenons au problème de la domotique.
Est-ce qu'un serveur dédié avec un runtime et une application personnalisée ne serait pas une solution intéressante - surtout à mettre au point ?
Mais je n'y connais pas grand-chose - sauf sur les runtimes Ada embarqués sur des machins qui volent mais on est loin du problème.
J'avais essayé dans les années 80 de piloter un train électrique avec un Commodore 64 ( en assembleur ) mais plus rien sur ce sujet depuis lors.
En effet :)
Ah ben on va peut être converger un peu, parce que Ruby je ne l'aime pas tellement. Je lui préfère Python... forcément :)
Et à l'infini :)
oui, incontestablement :)
Ah oui, Java n'existait pas à l'époque ;)
"plus rien sur ce sujet depuis lors" Dommage... piloter des trucs et des machins, c'est vraiment de l'informatique amusante.
Ma foi, peut être que l'on aura l'occasion de parler d'expériences de ce genre, qui sait ? :)
En effet, je vais jeter un oeil à Erlang et pourquoi pas, remonter un vienx Pentium de la cave...
C'est vrai qu'à force de disposer au boulot de quadri-processeurs avec 8Go de mémoire (des Sparcs), j'en oublie les contraintes de base, désolé...
Pas de quoi être désolé. :)
Un forum c'est fait pour discuter contradictoirement :)
Bonne découverte avec Erlang. Un langage génial et très injustement méconnu.
Du gros calibre... :)
Tiens ça me fait penser à une anecdote.
Un développeur C++/Linux (pas moi) que je connais s'est posé la question de savoir s'il avait intérêt à abandonner son fidèle Emacs pour Eclipse et le plugin CDT.
Il a essayé sur un bi-xeon avec 3Go de ram et sur un projet comptant quelques milliers de fichiers.
Et bien la machine s'est effondrée et Eclipse s'est avéré totalement inutilisable.
Le type a repris son Emacs et est content avec :)
Moi Emacs je m'en sers beaucoup aussi. Pour indenter mon code Python par exemple ;)
Bonne journée à toi :)
JRebillat, je pensais à toi ce matin :)
En effet ce matin j'ai enfin trouvé le temps de faire ce que j'avais l'intention de faire depuis que j'avais installé mon site dans ma Soekris. A savoir virer le gros, gourmant Apache et servir mes pages avec Erlang. Si ça t'intéresse tu peux en savoir un petit plus sur mon blog de programmez! et aussi sur mon site
Et puis allez je vous invite tous, histoire de voir si mon affaire tiens la charge ;)
Mais je ne suis pas inquiet :)
Bonsoir.
Bravo pour le site, il est indiscernable du précédent.
J'ai regardé un peu Erlang.
Mais je n'ai pas trouvé ce que je cherchais.
Je voulais un runtime - un programme qui boote tout seul, pas une machine virtuelle ( pour ça j'ai Java qui me convient très bien ;) ).
J'ai manqué quelque chose quelque part ?
Au fait, si tu cherches des serveurs web alternatifs, j'avais utilisé il y a quelques années un serveur écrit en TCL - petit et génial mais ma boite n'a pas adopté :(
Bonjour :)
Merci :)
C'est que comme je le dis sur mon site, lorsque j'ai choisi un modèle de design (je ne suis pas capable de faire de belles pages moi même), j'ai choisi avant tout quelque chose qui irait bien pour passer au dynamique. Autrement dit, j'ai autant regardé le code HTML des pages que l'aspect extérieur pour choisir. Donc c'était facile après.
Un peu...
C'en est un...
Je me demande si on a la même définition de runtime. "qui boote tout seul" c'est un OS ça non ?
Oh oui...
Java et Erlang n'ont rien en commun. Par exemple en Java tu peux coder des boucles for ou while, en Erlang tu ne peux pas :) Au delà de la boutade soyons plus sérieux: Erlang ne devrait pas être vu comme une machine virtuelle mais bien comme un OS. Quand Java est un langage orienté objet, Erlang est un langage orienté processus et concurrence. En Erlang le processus est un type natif, ce que ne sont ni Thread ni Process en Java.
Tu peux voir Erlang comme un OS. Bon c'est vrai qu'il ne "boote pas" tel qu'il est distribué actuellement , mais faut pas oublier que c'était l'OS de routeurs téléphoniques d'Ericsson. Il bootait donc dedans. Bien sûr ça demande d'écrire du code, mais il me semble qu'il est possible d'en faire un OS bootable directement. En admettant que ça soit intéressant de le faire. Car quand tu lances un runtime Erlang dans un Linux c'est déjà comme si tu avais un OS embarqué. Tu peux charger du code à chaud, faire plein de choses folles et défrisantes. Ce qui n'est pas le cas (du tout) d'une JVM. Mais bon pourquoi pas en effet faire un Erlang bootable, ça serait idéal pour de l'embarqué vu la faible gourmandise en ressources. Et je le répète, à l'origine, Erlang c'était ça dans les routeurs Ericsson. Pour piloter en temps réel des routeurs monstrueusement sollicités, bref, un OS quoi :)
Moi j'imagine bien des Erlang embarqués dans moutl appareils répartis dans la maison et supervisés par un appareil central, ou se surpervisant les un les autres. Un vrai truc de science fiction *très* facile à faire sur les bases d'Erlang.
Mais bon, faut pas nécessairement se fixer sur Erlang. Peut être qu'il y a d'autres approches ou solutions (hors Java ;) )
Par contre, si tu me le permets, pour évaluer les possibilités, d'Erlang, le regarder "un peu" c'est peut être trop peu ;)
Non, j'ai ce qu'il me faut :)
Mais j'aime bien TCL et sa philosophie :)
Ce dont je ne doute pas.
Ce dont je doute encore moins :(
Tiens tu me me tends la perche là. Alors puisqu'on est là à causer, je vais te dire quelques unes des raisons pour lesquelles je déteste tant Java.
Selon moi, Java n'invente rien, n'innove en rien et n'apporte rien techniquement. Selon moi toujours, ce n'est pas un langage de technicien (sans manquer de respect à James Gosling, grand technicien, le débat n'est pas là), c'est un langage de marketing. Selon moi encore, à l'époque Netscape et voyant que Microsoft sous estimait Internet, Sun a voulu attirer les gens chez eux, et donc inventé le slogan "Java Write Once RunEverywhere", ce qui voulait dire "Codez donc sous Windows, et ainsi vous pourrez aller facilement à Solaris." Bon ça n'a pas vraiment marché mais c'est désolant qu'on entende si souvent "Java a apporté la portabilité" alors qu'en fait la portabilité est un problème depuis toujours et que moult solution ont été apportées avant Java. Toi qui fait du TCL et du Perl, tu es bien placé pour le savoir. Même là Java n'a rien amené en fait.
Malheureusement ce n'est pas tout. Voilà qu'arrive Microsoft. Ils se sentent en retard (commercial, pas technique hein ? ;) ) face à Java. Que font ils ? Créent ils quelque chose ? Surtout pas. Selon la technique éprouvée depuis l'époque Visicalc/Multiplan, ils font ce que fait le concurrent et disent "c'est mieux parce que c'est Microsoft". Voilà donc C# qui est le même que Java. Et aussi VB.Net qui est encore le même pour faire bonne mesure. Le même fondamentalement, au delà de la syntaxe bien sûr.
Et ce n'est pas tout :(
En France on est des spécialistes de la frilosité en matière de choix technologiques. Mais alors vraiment spécialiste, plus que nulle part ailleurs à ma connaissance. Alors on choisit Java et ou C# sans même prendre le temps considérer ce qui existe d'autre, ni même se renseigner si quelque chose d'autre existe.. Et cela conduit à écrire des milliers de lignes de code quand 200 aurait suffit autrement...
Mais ça permet d'ouvrir le parapluie. "Ah pardon, j'ai choisi Java, c'est reconnu, ce n'est pas de ma faute si le développement a explosé le budget de 1000%)" "Ah pardon j'ai choisi Microsoft, vous ne pouvez pas me le reprocher."
Bref toi et ton serveur TCL vous connaissez ça n'est-ce pas ?
Seulement voilà, à l'Est, très à l'Est, il y a des informaticiens très doués, créatifs, hardis, innovants. Des gars qui utilisent actuellement des langages de pointes comme Haskel ou Erlang, ou plein d'autres, et pas trop de Java.
Et qu'est-ce qui va se passer ? Comme le plombier polonais vient piquer le boulot du plombier français, un jour l'informaticien de Pologne ou d'Inde (attention aux indiens, sans blague) viendra piquer le boulot de l'informaticien français, parce qu'il développe mieux, plus vite, moins cher, avec de meilleurs outils et savoir faire.
Java... pfff...
Bon, je sais que personne ne va me croire et que peu vont être de mon avis, mais tant pis, ça soulage de le dire :D
Dans nos fusées, le programme de vol est constitué d'un runtime Ada (SAE d'Aonix) sur lequel boote le processeur - en fait il y a donc un seul programme (single ou multi-thread, ça dépend). c'est lui qui s'occupe de tout, un peu comme un OS, c'est vrai, mais qui ne servirait pas de processus client.
C'est un truc comme cela que j'aurais aimé trouvé en logiciel libre. Voyant qu'Erlang n'offrait pas cela de manière immédiate, je ne m'y suis intéressé "qu'un peu" pour l'instant.
Voila, c'est un peu ça l'idée - avec Erlang ou autre chose.
J'aime beaucoup. Je l'avais même porté sur mon Atari STF à une époque !
Oui... et de formation. Un remplaçant du Pascal pour apprendre aux jeunes à programmer.
Toutefois il y a un aspect que je ne trouve pas dans ta réflexion, c'est la notion de maintenabilité.
Pour moi, elle contient deux aspects :
1- la clarté du code.
Là, je trouve - c'est mon avis personnel - que Java, avec ses déclarations, ses contrôles et ses structures permet une bonne lisibilité du code, l'impose même. A l'inverse, des langages comme Ruby, par exemple, sont plus elliptiques donc moins clairs. Dans un article de ce journal - il y a deux mois je crois - il est fait l'apologie que, en Ruby, ce qui est génial c'est de ne pas avoir à déclarer de "return" en fin de fonction - ce que je n'admettrais pas chez mes collaborateurs. heureusement pour Ruby, on peut quand même les déclarer, donc tout n'est pas perdu ;) (Pour Python, dont on ne sait pas quand se termine un bloc, tu comprends ma réticence à l'employer).
2- La diffusion de la connaissance.
Qui connaît Erlang ? Qui sait encore programmer en TCL ? Quelques geeks comme nous... Par contre, c'est hélas un fait, Perl et Java sont bien plus diffusés - ce n'est pas un gage de qualité, seulement une probabilité plus grande de trouver un assistant technique capable de maintenir le code. (Python arrive très fort, donc est à surveiller)
Là, pas d'accord !
Je préfère avoir 2000 lignes intelligibles, maintenables et claires que 200 lignes sorties tout droit d'un concours d'obscurification :cry:
Pourquoi tu mets ta phrase au futur ? C'est déjà le cas chez nous : je travaille avec des Italiens et des Espagnols, sans parler des contacts avec les Russes !
Les Indiens pas encore directement, seulement comme sous-traitants de nos sous-traitants...
je te comprends mieux. Mais je n'approuve pas tout. C'est vrai que Java est lourd, gourmand, etc... Donc Ok, je prends une barrette d'1 Go et un proc un peu plus puissant avant de mettre Tomcat sur mon serveur et finalement ça roule pas si mal...
Non, le language qui m'énerve le plus, c'est l'incontournable Javascript des clients Web. S'il y avait autre chose que des applets en Java comme alternative, j'en serais vraiment ravi !
Donc on se comprend bien :)
PS: tu travailles dans une branche intéressante, passionnante même dis donc :)
Certes Java est très académique et donc adapté à l'enseignement. Enfin adapté aux profs, je veux dire.
Mais est-ce un bien ? Quand on a appris java, est-ce qu'on connaît l'informatique, est-ce qu'on sait programmer ? On pourrait certainement en discuter à l'infini. Mais à mon humble avis la réponse est clairement non.
Je n'en ai pas parlé parce que ça tombe tellement sous le sens :)
Ce sont des points cruciaux, incontestablement.
Et bien je ne partage pas cet avis. Plus le code est verbeux, plus c'est (à mon avis) difficile à relire et à maintenir.
Apologie je ne sais pas. Mais je trouve normal qu'un auteur parle avec enthousiasme de la technologie qu'il apprécie. Je le fais moi même souvent :)
Cela dit perso, je ne suis jamais tombé en pamoison devant Ruby qui n'invente pas grand chose.
:?:
Heu non, mais peu importe, laissons Python.de côté :)
Faux problème ->
Pas de qualité en effet, tu l'as dit :)
Est-ce bien certain ?
-> Et puis c'est un faux problème je pense. Un langage comme Erlang (pour rester sur cet exemple) est bien plus facile à apprendre et à maîtriser que Java.
Et puis ce n'est pas si difficile de former un programmeur quand le langage ou la techno sont *bien adaptés* au développement. J'insiste sur le bien adapté.
En informatique contrairement à d'autres domaines d'expressions, plus c'est long, moins c'est bon :lol:
Et qui parle de 200 lignes obfusquées ? Non non, j'ai voulu dire dans mon message précédent que 200 lignes claires valent mieux que 20000 lignes obfusquées. Sans blague.
Excès d'optimisme, volonté de ne pas trop déranger... comme tu voudras :)
Ah les russes... très à l'Est aussi....Je l'ai dit dans mon post précédent, attention à l'Est ;)
Très dangereux.
:)
Mais surtout, tu l'as compris aussi, je présume, j'essaie de lutter contre la pensée unique en informatique, ce qui est assez difficile de nos jours ... :(
Ton "pas si mal" me fait penser au trou de la Sécurité Sociale, jamais comblé. ;)
Mon serveur d'application il tourne dans 5 mo et répond plus rapidement que Java.
Pas si mal finalement ;)
Parce que tu vois ton Tomcat il monopolise Ta bécane. Tu ne fais rien d 'autres avec ton Tomcat et plus rien d'autre avec ta machine non plus. Bref, Java est ridicule. Tandis que moi mon runtime Erlang (oui oui celui qui sert les pages, le même) il me sert à d'autres choses, d'autres applications que le site je veux dire, et il ne monopolise pas ma bécane qui me sert à encore d'autres choses en dehors du runtime Erlang. Et attention hein ? Geode 266 Mhz, 233 Mo je te rappelle.
Essaie de mettre Tomcat là dedans pour voir ;)
Qui donc m'a écrit ça il y a peu de temps:
Non vraiment, sans te taquiner, je préfère mon pas si mal.)
Là je te suis à 100%
Javascript, une autre atrocité héritée de l'époque Netscape.
Il y eu des tentatives de faire autres chose. Par exemple avec Grail le navigateur en Python. Et les applets s'écrivaient en Python ;) Il y a donc des alternatives :)
Mais toujours ce problème de la pensée unique. En outre c'est difficile à fédérer, c'est le moins que l'on puisse dire :(
Bon dans le fond nous sommes d'accord sur bien des choses :)
Sur l'essentiel même je pense :)
Ah au fait, pourquoi pas Java dans les fusées :?:
Serait-ce parce que ça coûte trop cher si ça se casse la g..... :?: ;)
Pour une autre raison ?
Oui, je sais. J'ai une chance formidable d'allier mes passions et mon travail !
C'est un combat de tous les jours... contre la désinformation.
Et j'en ai appris énormement avec cette discussion !
Oui, j'en avais conscience en l'écrivant ;)
En effet.
Tu ne vas pas aimer la réponse, je le sens... ;)
A l'heure actuelle la seule raison c'est que le runtime n'est pas certifié...
Il y a des tas d'études en cours, avec d'un Java temps-réel, gravitant autour d'UML2 et d'autres concepts aussi médiatiques !
Remarque moi aussi :)
Voilà...
Merci. J'en suis vraiment très heureux :)
Il ne peut pas l'être :)
Ou du moins il ne devrait pas.
Non non sans blague.
Si tu lis bien les spécifications de Java et de la JVM, tu constateras que le JVM peut à tout moment lever une exception InternalError.
Par exemple en exécutant int i = 1; tu n'as pas de garantie que l'InternalError ne soit pas levée.
Mais ça n'est pas tout, toujours dans les Specs, on voit qu'une InternalError est de nature asynchrone, donc ça implique qu'il n'est, fondamentalement, pas possible d'écrire un programme déterministe en Java, ce qui pour piloter une fusée est gênant il me semble.
Et ce n'est pas tout. Une erreur interne ça peut être grave, mais ça n'empêche pas la JVM de continuer ses blagues, c'est à dire faire n'importe quoi, pendant un temps indéterminé:
"The Java platform permits a small but bounded amount of execution to occur before an asynchronous exception is thrown."
Bref la seule chose que l'on peut certifier avec une JVM pilotant une fusée, c'est un crash :)
En effet ça ne me plait pas beaucoup :evil: Je ne vois pas le bien fondé du choix médiatique pour piloter une fusée. Ca rappelle un peu l'histoire du Titanic qu'il a voulu aller trop vite pour faire la une des journaux. Enfin bon c'était réussi finalement :lol:
Moi tes décideurs, je les trouve bien légers... Enfin léger ce n'est pas le terme. Je devrais plutôt dire que c'est un problème de poids.
Parce qu'une barrette de Ram ça a une masse. Masse qui se répercute directement sur la consommation de carburant et sur la trajectoire.
Je voudrais bien être là pour voir un type ajouter une barrette de Ram au dernier moment avant le lancement. :lol:
Sans plaisanter sur la barrette de Ram, et puisqu'on parlait de Java et d'Erlang. Le premier a été conçu pour faire joujou avec un grille-pain dans un labo, le second pour faire face a des contraintes industrielles extrêmement sévères.
Sans vouloir insinuer qu'Erlang devrait servir à piloter les fusées, que l'on choississe, pour cela, un outil médiatique plutôt qu'un outil industriel, ça me dépasse.
Mais au fait, rafraîchis moi la mémoire , tu dois bien le savoir toi, le robot qui s'est bêtement planté sur mars, ce n'était pas déjà pour une raison de cet ordre ?
Ho, que si ! L'espace coûte cher. Il faut des appuis, des partenaires...
Et pense à la puissance des lobbies !
(Sur le spatial comme pour l'aéronautique, Windows a tenté mais s'est vite retrouvé hors course. Microsoft lui-même a dû reconnaître que ses softs ne pouvaient pas être certifiés, car pleins de trous et de code mort).
Quelque chose dans le genre, oui.
Ce qui freine pas mal, quand même, c'est que notre matériel actuel n'est pas "spatialisable". Cela signifie qu'il n'est pas fiable hors de l'atmosphère.
Je m'explique : dans l'espace circulent pleins de particules (pour simplifier genre rayons X ou gamma) qui traversent tout, y compris les navettes. Lorsqu'ils arrivent près de la Terre, elles sont stoppées par des phénomènes particuliers, mais en orbite elles se baladent. elles sont si pleines d'énergie que lorsqu'elles traversent un transistor dans un processeur, elles créent des perturbations. Mais elles sont si petites que dans un 68020 où les transistors sont "gros", c'est négligeable. Par contre sur un Pentium IV, elles peuvent changer des 0 en 1 dans le processeur, qui peut alors planter -Java ou pas d'ailleurs.
Donc actuellement les calculateurs en orbite vivent avec du matériel considéré partour ailleurs comme "obsolète" (des 486 pour la navette, je crois). En ce qui concerne Java, dur de le faire tourner sur 4 Mo de RAM - sans disque pour swapper ;)
Pour revenir au sujet du fil - que nous avons un peu bousculé sans trop le perdre - j'ai beau chercher je ne trouve pas ce "runtime" dont je parlais, capable de booter comme un micro-kernel et de lancer une unique application temps-réel - de domotique par exemple. Tu as une idée ?
En fait si, j'en ai bien trouvé un. Il se nomme JNode mais évidemment tu devines en quoi il est écrit :D Donc il faut un gros PC pour le faire tourner - il a planté sur mon PC de test à 900 Mhz et 256 Mo - pourtant de capacité bien supérieure à ce qu'il faudrait pour de la domotique...
Où avais je là tête ?
Mais non en fait. Ceci explique cela, mais ce n'est pas un bien fondé...
Lol :lol:
Ca je savais
Mais ça je ne savais pas
C'est fou ça :twisted:
Lol :lol:
Non. Mais si je rencontres quelque chose, je te le dirai.
Lol et...
.. et re Lol :lol:
Donc non je n'ai pas d'idée de runtime tout prêt. Mais moi, comme je te l'ai dit, j'écrirai le code pour adapter Erlang. Ou en faisant quelque chose de plus spécialisé mais sur la base d'Erlang. En me renseignant avant auprès de Joe Amstrong, le créateur d'Erlang, pour savoir s'il n'existe pas déjà quelque chose dans un carton.
Pourquoi Erlang en résumé ? Parce que c'est *parfaitement* adapté à la concurrence et aux applications distribuées, ce que me semble être typiquement l'environnement domotique de science fiction dont nous avons parlé. En plus en Erlang les processus peuvent se surveiller les uns les autres et si un plante en lancer un autre pour prendre le relai, plein de choses ébourriffantes comme ça. (renseigne toi sur ce qui s'appelle les behaviour)
Fais une expérience
Si tu as un réseau chez toi, attribue par l'imagination un rôle à chaque machine. Celle-ci réfrigérateur, celle-là cafetière
Et même pour ne pas être limité, attribue virtuellement une pièce (cuisine, salon..) à chaque bécane et dans chaque bécane
fait tourner *plusieurs* runtime Erlang, (pas de limite théorique, et dans 900 Mo tu peux en mettre ;) ) chacun étant un noeud de réseau tel four@cuisine, cafetiere@cuisine, tv@salon, eclairage@salon. Tous ces noeud étant *de facto* en communication les uns avec les autres, sur chaque bécane *et* dans tout ton réseau.
Bref fait ton système de domotique virtuellement comme ça. Et code un peu pour que tout ce petit monde coopère de concert. Tu vas alors immanquablement découvrir les folles possibilités d'Erlang (et de Mnesia sa base de données lègère et distribuée) et je te promets que ca va te fasciner.
Java ? tu n'y penseras même plus, comme on oublie un mauvais rêve ;)
Je reviens sur Java embarqué avec des nouvelles toutes fraîches.
Donc, une société spécialisée dans le temps réel et qui fait surtout de l'Ada (pas de nom) se lance dans le "Java embarqué temps réel".
En creusant un peu, appeler cela du Java semble un peu exagéré car :
- le code est compilé en binaire machine, par en bytecode Java
- il n'y a plus de ramasse-miettes, la portée et la durée de vie des variables est spécifée par annotations,
- ils ont enlevé tout ce qui les gênait et risquait de perturber le déterminisme
- ils n'ont pas porté la grande majorité des bibliothèques - pour cause : elles ne sont évidemment pas compatibles...
Donc en réalité, on a un C++ mâtiné d'Ada avec une syntaxe pseudo-Java... C'est de la cométique, en fait !
Merci pour les nouvelles, c'est très intéressant de savoir :)
Un peu exagéré en effet lol :lol:
Lol :lol:
Lol :lol:
D'ailleurs, Java ou pas, un ramasse-miette "à la Java" c'est porteur de problèmes potentiels pour de l'embarqué. Alors quand il s'agit d'une application critique comme une fusée, la décision n'a rien d'étonnant
Avec ce que tu dis, j'ai comme l'impression que nous nous rapprochons d'une gestion de mémoire à la Erlang où le nettoyage est fait lorsqu'on quitte une portée lexicale. ;)
Lol :lol:
Autant dire qu'ils ont changé les spécifications et que ce n'est donc plus du Java du tout :D
Lol :lol:
Java est moins portable et interopérable qu'il n'y paraît de prime abord finalement ;)
Lol :lol:
cométique... Je suppose que tu as voulu écrire cosmétique mais qu'en toi même tu pensais comique ;)
Parce que c'est bien une farce, une mascarade.
Bon comme je l'ai toujours dit, Java ne sert à rien (les applets peut être ?) et surtout pas à des applications industrielles critiques.
Et je ne cache pas que ça me fait plaisir que tu sois venu le confirmer :)
D'ailleurs pour en revenir au ramasse miettes de Java, rien qu'à cause de lui et de son mode de fonctionnement, je ne voyais vraiment pas comme il aurait pu être certifié par des gens compétents pour piloter une fusée.
Techniquement il me semble qu'un ramasse-miettes qui fonctionne périodiquement dans un thread séparé, ça ne peut convenir dans un environnement aux contraintes aussi sévères que l'aérospatiale. Et encore... pour ce que j'en connais des contraintes, qui sont certainement bien pires, bien plus rigoureuses que ce que j'imagine depuis mon fauteuil.
Mais je trouve dommage que pour faire du remue ménage médiatique on colle un label Java comme ça. Ca serait tellement mieux de valoriser et de faire connaître des solutions technologiques viables.
Et tout cas je dois rendre hommage à ton objectivité et à ton honnêté dans la discussion, c'est vraiment un plaisir :)
En fait, le problème se pose ainsi :
- Ada est parfait (en retirant l'allocation dynamique) pour le temps-réel critique mais plus personne ne code en Ada sauf nous - au point que la société qui fait le compilateur bat de l'aile...
- C et C++ posent des questions insurmontables sur le test et la validation du code
- Les langages interprétés sont hors de question, de même que l'assembleur.
=> d'où l'idée d'utiliser Java pour en effet faire un "coup" et se remettre à flots.
De rien.
Java n'est qu'un des langages que j'utilise, donc je n'étais déjà pas un inconditionnel :D
Et je ne me contente pas de polémiquer, je préfère analyser ce que disent mes interlocuteurs. Il n'y a que les c*n qui ne changent pas d'avis quand les explications tiennent la route.
Je continue de programmer en Java (encore tout cet après-midi, tiens) mais... depuis quelques temps j'ai une autre vue sur la question, plus ouverte.
Et de ça, c'est moi qui t'en remercie.
Pour être parfait il doit l'être. Si je ne m'abuse, le langage a bien été développé par l'armée américaine pour piloter les missiles. Donc vous êtes en plein dans son domaine de prédilection.
C'est ça qui est désolant. La culture informatique se déduit de plus en plus à Java et C# (soit deux fois le même). Et je vois souvent des gens faire des acrobaties pas pensables pour coder en Java et en des milliers de lignes ce qui ce code efficacement et avec concision en prenant l'outil adapté.
Enfin dans notre pays c'est comme ça, comme on en a parlé plus haut, et ça me semble très grave.
Ben avec les moyens que vous avez, vous devriez pouvoir écrire votre compilateur.
J'imagine...
:oops:
Au plaisir d'une nouvelle discussion sur ce forum :)