24 réflexions au sujet de « Raspberry Pi et Windows IoT Core, disponible aux Editions ENI »

1. Bud 'Robert' Spencer 21 août 2017 à 22 h 38 min

   Juste une petite précision pour ceux qui souhaiteront se lancer dans le dev pour W10IoT Core : Utilisez directement la dernière version Visual Studio 2017 Community (et non pas la 2015). Les exemples de codes fournis dans ce livre devraient fonctionner tout pareil et cela vous permettra d’utiliser les dernières builds de l’os et de profiter des dernières évolutions du langage C#. Ceci dit, sachez aussi que C# n’est pas le seul langage supporté par W10IoT core. Vous pouvez aussi développer en Vb.net, C++, Python, Javascript, NodeJs …

   Répondre ↓
2. Erwann 26 août 2017 à 15 h 06 min

   Malgré tout le respect que j’ai pour la somme de travail que représente l’écriture d’un tel ouvrage, je continue de penser que IoT n’est pas la meilleure idée qui soit et que marier IoT avec Windows est la pire idée qui soit.
   Nous vivons dans un monde où les cyber-menaces se font de plus en plus précises et tangibles. Au lieu de participer à l’anesthésie collective en continuant de propager des plateformes et des approches fragiles, peu robustes et peu sûres, je préférerais que les auteurs éclairés et avisés aident au processus de réveil de la société.
   En outre, après la disparition de plusieurs environnements « exotiques » (CE, RT, …) promus par Microsoft, je ne serai pas particulièrement surpris lorsque nous apprendrons que – soudainement – Windows IoT Core ne sera plus soutenu à l’avenir.
   En particulier pour les jeunes générations qui ont envie d’apprendre et d’acquérir des compétences en informatique industrielle et en système embarqué, surtout ne perdez pas de temps à passer par la case Windows (quelqu’en soit la version).
   L’actualité montre que nous manquons de compétences en Open Source:
   http://www.silicon.fr/entreprises-recherchent-desesperement-talents-open-source-182593.html?inf_by=59a1718b671db8cc7f8b45e1
   Et mon expérience industrielle montre que nous manquons de bons et compétents automaticiens et ingénieurs pour les systèmes embarqués (les vrais, par les objets connectés avec les mots de passe administrateur codés en dur).

   Répondre ↓
3. spourre 31 août 2017 à 19 h 29 min

   Votre avis, comme tout avis courtoisement exposé, est certes respectable mais excessif dans sa présentation manichéenne (L’empire MS contre le libre).
   Ce caractère excessif nuit à sa crédibilité.
   Tout d’abord, donner à penser que Linux est exempt de faille est une contrevérité largement infirmée par les faits. Pour la petite histoire, il est plaisant de souligner que le premier vers réseau a tourné sous ……….UNIX (et pour cause, le géniteur de Windows devaient encore mouiller ses couches à cette époque).
   Le gros avantage des *NIX est la nette séparation entre l’utilisateur lambda et l’administrateur et que, historiquement, le linuxiens était un geek qui savait, en général, ce qu’il faisait (compiler son kernel ou les driver de son scanner étaient des tâches normales).
   La « démocratisation » de Linux et un certain effet de mode ont contribué à apporter une autre catégories d’utilisateurs, anesthésiés par les clickodromes .
   En devenant une part non négligeable du marché (surtout les serveurs et l’infrastructure réseau) Linux est devenu une cible intéressante pour les hackers, y compris étatiques.
   Il est amusant de signaler, 2 articles sous celui que vous citez, un article concernant une attaque ciblée de Linux par la CIA (cf. wikileaks):
   http://www.silicon.fr/outlawcountry-la-cia-detourne-le-trafic-des-pc-et-serveurs-linux-179387.html?inf_by=59a1870e671db884038b4916
   Par ailleurs, votre lien n’est pas très pertinent pour soutenir votre point de vue. Il y aurait un manque de développeurs open source, surtout avec le cloud ? Il faudrait préciser (ce que ne fait pas l’article) ce qu’est un développeur open source; AMHA, on peut faire de l’open en C# 😉
   Il ne faut pas confondre le chemin et le but. Ce qui compte, ce n’est pâs l’outil ou l’IDE utilisé pour développer mais l’application. Bien souvent le développeur n’a pas le choix et est contraint par la culture ou les choix maison.
   J’ai été confronté aux 2 environnements dans ma vie professionnelle et même si j’ai une très nette préférence pour UNIX (donc Linux), je dois admettre que MS permet de faire des développements qui tiennent la route et d’avoir des serveurs stables; il faut par contre avoir des compétences et ne pas se contenter de next clic next, reboot, ….
   L’avantage de Windows (si, si, il y en a) est d’être homogène . Un environnement complet de développement, surtout issu de la maison mère, est cohérent et ne risque pas de ruiner une configuration.
   Essayant depuis plusieurs mois d’implémenter un ensemble complet de cross-compil, debugg, sur une tour debian, pour la Raspbian, je n’ai obtenu que de planter ma tour (depuis je ne test qu’en VM) ou d’avoir une chaîne obsolète. Merci a Debian d’avoir passé Rasbian Jessie à multiarch, c’est très utile sur une carte ARM (comme d’avoir du swapp sur une carte SD).

   Il y a un point où je vous rejoins, c’est le manque effarent de maîtrise des concepts de base, y compris chez des bac++ . Si vous suivez le forum, même dans les discussions « techniques » (très rares), vous pourrez le constater.

   Répondre ↓
   1. Bud 'Robert' Spencer 1 septembre 2017 à 0 h 42 min

      Un développeur, c’est un développeur. Il ni a pas de compétence Open Source à avoir ou pas la dedans. Professionnellement on ne développe par conviction religieuse, on le fait en fonction des besoins et des contraintes des entreprises et des clients pour qui on bosse.

      Que ce soit sur le blog ou sur le forum, dès que le sujet windows 10 IoT Core est abordé on a systématiquement droit aux lever de bouclier des linuxiens intégristes (qui généralement n’ont aucune maitrise du sujet et racontent souvent n’importe quoi). Perso je trouve ça complètement ridicule. Il faut bien admettre que les premières versions pour le Pi n’étaient pas terribles. Admettre aussi que la très grande majorité des utilisateurs de Pi ne sont pas des makers mais de simples utilisateurs de truc tout fait (media center, domotique ‘clé en main’, retro-gaming … ). Puis admettre que la prise en main d’un IDE comme Visual Studio est un peu plus complexe que de copier/coller quelques lignes d’un code python dans un éditeur de texte.

      Peut-être qu’un jour on aura sur le forum une vraie rubrique dédiée à ce système vraiment très intéressant et peut être même une pour le c# (qui fonctionne aussi très sous raspbian). Cela permettrait sans doute de démystifier tout ça et donnerait une véritable idée de ce qu’est réellement w10IoT Core sur le Pi

      @Spourre :
      Bien sûr que l’on peut faire de l’Open source en C# et pas que : https://opensource.microsoft.com/

      Répondre ↓
      1. François MOCQ Auteur de l’article1 septembre 2017 à 14 h 35 min

         Bonjour
         je ne sais pas si Alexandre lit les commentaires mais je le lui dirai en direct si ce n’est pas le cas… les pages de framboise314 lui sont grandes ouvertes s’il souhaite proposer quelques tutoriels win10 ou C# 😉
         cordialement
         François

         Répondre ↓
   2. destroyedlolo 8 septembre 2017 à 17 h 37 min

      Salut,

      C’est désolant de voir encore et toujours les mêmes discours bornés anti/pro machins : c’est simplement ridicule. Si certains s’éclatent sur du wIoT, grand bien leur face, si d’autres (et j’en fais parti) préfèrent autre chose, tant mieux pour eux. Maintenant, ca ne sert a rien de se voiler la face des pb et des risques qu’on a d’un coter comme de l’autre.

      Mais bon, on s’en fou …

      Plus constructif, comme légèrement abordé sur le forum (avant que ca ne parte dans le bruit et la confiture), il n’y a strictement aucune raison de planter quoi que ce soit en faisant une chaine de crosse compilation : ca se faisait très bien il y a des décennies, ca se fait encore plus facilement maintenant grace à des chaines et des outils matures.
      Je ne dis pas non plus que c’est facile et qu’elles se compilent à tout les coup du premier coup, je dis juste qu’il n’y a aucune raison de peter quoi que ce soit 🙂

      A+

      Répondre ↓
      1. spourre 8 septembre 2017 à 19 h 11 min

         Bonjour,

         @destroyedlolo
         « C’est désolant de voir encore et toujours les mêmes discours bornés anti/pro machins »
         +1
         Mais, AMHA, ni Bud ni moi n’avons fait preuve d’intégrisme puisque moi, je reconnais des qualités à l’environnement MS et que Bud, utilise aussi de l’open.
         Erwann a certainement une vision un peu idéalisée du monde libre mais ses propos sont mesurés.
         Si tu veux un exemple d’intégrisme « libriste », consternant de bêtise et d’inculture réunies, je t’invite à regarder nos récentes réponses à un con tributeur sur le forum. ;-((

         « Plus constructif, comme légèrement abordé sur le forum (avant que ca ne parte dans le bruit et la confiture), il n’y a strictement aucune raison de planter quoi que ce soit en faisant une chaine de crosse compilation : ca se faisait très bien il y a des décennies, ca se fait encore plus facilement maintenant grace à des chaines et des outils matures.
         Je ne dis pas non plus que c’est facile et qu’elles se compilent à tout les coup du premier coup, je dis juste qu’il n’y a aucune raison de peter quoi que ce soit 🙂 »

         J’ai pourtant déjà expliqué que cela m’est arrivé. Sur une tour avec Jessie 64 bits, j’ai tenté d’installer une chaîne de cross-compilation en suivant un tuto d’Opensilicium. Je partage en effet l’avis de Denis (le rédac chef d’alors) lorsqu’il trouve anachronique d’installer des logiciels à coups de ./configure, make & make install, comme on faisait il y a 10 ou 15 ans.
         Cela ruine les dépendances et le gestionnaires de paquets (DEB, RPM, …) n’y retrouve pas ses petits.
         J’ai donc commencé à ajouter le multi-arch, puis les bibliothèques 32 bits puis les dépôts puisque la chaîne n’était pas dans ceux de Debian (recup d’un vieux projet embedian, abandonné au profit de l’architecture multi-arch).
         De fil en aiguille, ma conf est devenu instable. J’aurais pu passer des heures à la réparer mais j’ai préféré repartir sur une base saine.
         Depuis, je fais mes essais dans une VM et je m’autorise de m’affranchir des dépôts et je pioche dans les GIT. J’ai obtenu des chaînes fonctionnelles mais terriblement datées.
         Sans être un obsédé de la dernière version, AMHA il faut au moins être dans la même branche majeure que la cible (GCC 6.3; kernel 4.9 et libc 2.24 pour Rasbian). Cela me semble nécessaire pour pour bénéficier des fonctionnalités et des patchs de sécurité.
         Pour rester dans le droit fil de cette discussion, il faut bien reconnaître que la multitude de solutions, plus ou moins compatibles entre elles, plus ou moins maintenues selon l’implication de l’équipe (parfois un homme seul) est à la foi le point fort et le point faible du libre (cela a aussi causé la mort des UNIX).
         Il est certain qu’une distribution monolithique, imposant ses critères comme le fait MS (et la pomme) est plus cohérente. De plus, en cas de problème, il est assez facile de se tourner (souvent, moyennant finances) vers un interlocuteur unique.

         Nota: Pour mon problème, j’ai posté et sur Raspbian-france et sur Debian.fr. J’ai des lectures mais 0 réponses.

         A+

         Sylvain

         Répondre ↓
         1. destroyedlolo 8 septembre 2017 à 19 h 59 min

            Salut,

            > une chaîne de cross-compilation en suivant un tuto d’Opensilicium.

            Ben je ne connais pas ce tuto mais il y a forcement un loupé quelque part, car même si tu compiles à la main,
            – les binaires ont un prefix pour éviter d’écraser les autres (genre armv7a-hardfloat-linux-gnueabi-gcc)
            – les includes, lib, … se trouvent dans des sous arbos elles-aussi préfixées (/usr/lib64/gcc/armv7a-hardfloat-linux-gnueabi).

            Quand aux chaines de cross-compile, il n’y a strictement aucune raison qu’elles changent ces protections (ou alors … il vaut mieux s’en passer 🙂 ).

            > il trouve anachronique d’installer des logiciels à coups de ./configure,
            > make & make install, comme on faisait il y a 10 ou 15 ans.

            Oui et non : j’en suis revenu des distrib binaires ou t’es obligé de suivre les choix (parfois débile) fait par les mainteneurs … Bon, ok, a l’époque je jouai avec Ubuntu, j’ai donc cherché un peu les ennuis, et quand je parle de choix débile, ca m’a gaver de devoir y recompiler systématiquement PHP car un « moron » avait décrété qu’il fallait utiliser la PNG du système, parfaitement obsolete, alors que même les mainteneur de la dite lib disait qu’il fallait utiliser celle inclue dans PHP.
            Ensuite, il m’arrive aussi d’utiliser des outils qui ne sont pas packagés, ou dont les packages sont tellement vieux (genre SDcc toujours sous Ubuntu, la goute qui a fait débordé le vase 🙂 ) qu’une compile local devient inévitable.

            > Il est certain qu’une distribution monolithique, imposant ses critères comme le
            > fait MS (et la pomme) est plus cohérente.

            Je ne sais pas pour Apple, mais j’ai déjà pété des m$ uniquement en installant un programme qui mettait à jour une DLL … qui devenait incompatible avec d’autres trucs. Je ne parle meme pas des drivers video qui foutent la grouille dans tel ou tel navigateur. Franchement, de tous les systèmes que je connais (y compris Linux avec son inénarrable libc), y’avait que le regretté Amiga ou ce genre de chose n’arrivait pas : le système imposait une compatibilité ascendante stricte des librairies.

            > Nota: Pour mon problème, j’ai posté et sur Raspbian-france et sur Debian.fr.
            > J’ai des lectures mais 0 réponses.
            Franchement, est-ce étonnant : comme tu l’as dit toi meme sur le forum, la majorité des gens viennent y chercher des solutions prémachées et ne cherchent surtout pas a comprendre.
            C’est pourquoi délaisse le forum, c’est pourquoi je ne participe plus qu’aux sujets qui m’intéresse, parce qu’au bout d’un moment, ca gave d’y voir toujours les memes questions, maintes fois répondu, pour des gens qui ne savent même pas utiliser « search » 🙁

            Répondre ↓
4. Erwann 1 septembre 2017 à 15 h 26 min

   Je crains avoir été mal compris et en conséquence de m’être mal exprimé.
   Tout d’abord, quelques précisions:
   > de formation, je suis ingénieur automaticien et « systèmes » (industriels, embarqués)
   > avec environ 30 ans d’expérience (en plus de mes études)
   > entre autres activités, j’accompagne l’industrie pharmaceutique sur les questions liées à la conformité réglementaire des systèmes informatisés et automatisés
   > depuis 2004, j’enseigne en tant qu’intervenant industriel les « bonnes pratiques de génie logiciel » à des étudiants en 2° année de Master « Automatique et Informatique Industrielle ».
   —
   Mon premier souci est d’abord la capacité à qualifier/valider un système et d’en maintenir l’état qualifié/validé tout au long de la phase opérationnelle.
   > Le manque de transparence de Windows est un souci, dès la phase de qualification, il devient un problème crucial pendant la phase opérationnelle (gestion des changements vs. gestion des patches et des mises-à-jour sur une ou deux décennies)

   Mon second souci est causé par la faiblesse architecturale des systèmes qui conduisent tout à la fois à des non-conformités graves et à une incapacité à assurer le long terme.
   > Par exemple, la plupart des instruments analytiques en chimie et en biologie ont des logiciels de contrôle qui tournent sous Windows, souvent programmés en VBa avec l’aide de .NET. La faible compétence des équipes de développement conduit à des architectures immatures : par exemple, si l’utilisateur quitte sa session, l’analyse s’arrête, alors que cette analyse peut durer plusieurs heures voire plusieurs jours. J’ai tout à fait conscience que Windows permet d’implémenter de vraies architectures client/serveur ; néanmoins, force est de reconnaître, que le développeur « standard » qui sévit dans des entreprises, dont la fonction première n’est pas de faire du logiciel, fait souvent du VBa « sans réfléchir » et sans prendre en considération quelques principes élémentaires pour délivrer des architectures robustes.

   Mon troisième souci est lié à la durée d’exploitation de systèmes industriels coûteux, voire très coûteux (de 100 kEUR à > 1’000 kEUR) qui sont rendus obsolètes en seulement quelques années suite au manque de support à long terme de l’environnement opérationnel (c’est la principale raison d’avoir encore autant de systèmes qui tournent sous Windows XP ; et j’ai plusieurs clients qui ont encore quelques (de plus en plus) rares systèmes sous NT4, voire même sous DOS). Si l’on rajoute à cela les contraintes liées à la conservation des données et à leur lisibilité pendant 10 ou 20 ans, le problème devient réellement vital.

   Mon quatrième souci est de devoir constater le manque de curiosité et de volonté d’apprentissage de mes étudiants qui se limitent seulement à ce qui leur semble facile (même si tel n’est pas le cas) : c’est-à-dire, à une zone de confort avec un horizon très limité.
   > Malgré l’intitulé du Master (auto, info indus), au cours de ces dernières années, je rencontre de plus en plus d’étudiants pour qui installer Linux dans VirtualBox est déjà un challenge et qui se limitent à faire du VBa et des macros sous Excel (les notes des collègues en C/C++, Ada, etc. ne reflètent malheureusement que trop bien cette triste réalité). De même, les notions de comportement « temps réel » (c’est-à-dire déterministe) et de robustesse des systèmes leur sont totalement étrangères; et ils y sont imperméables.

   Je ne dis pas que Microsoft est le mal absolu et que le monde Open Source est parfait.
   Je constate simplement un manque récurrent d’esprit critique de la part de ceux qui ont grandi exclusivement dans un environnement Windows, y compris pour des informaticiens et des automaticiens.
   Le défi quotidien auquel je suis confronté se résume à:
   – Qualité et fiabilité
   – Sécurité
   – Capacité à gérer le changement
   – Long terme (10 – 25+ ans).
   Force est de reconnaître, qu’il est plus aisé de répondre à ces défis dans un environnement open source (qui certes évolue mais dont la transparence facilite la prise en compte de ses évolutions) qui est moins à la merci de décisions commerciales versatiles (cf. Windows CE, Windows Mobile, Windows RT, etc.).

   Ma remarque initiale était soustendue par tous ces aspects. IoT core est sans doute bien. Néanmoins ce que je vois de l’internet des objets me confirme dans mon sentiment d’une anesthésie généralisée rendant toute réflexion critique (pas dans le sens de critiquer mais d’une capacité rationnelle à mettre les choses en perspective) quasiment impossible.

   GNU/Linux, BSD, etc. ne sont ni sûrs à 100%, ni des environnements parfaits ; ils sont simplement ouverts et permettent de répondre aux questions que l’on se pose.
   —
   PS: Au cours de ces dernières années, mes étudiants m’ont malheureusement prouvé à plusieurs reprises leur incapacité à faire bien avec peu : c’est-à-dire qu’ils ont été incapables de réaliser un projet relativement simple (en l’occurrence en Python avec SQLite) et de le faire tourner sur un Raspberry Pi. Florilège des remarques entendues (même si elles sont erronées) :
   – pas assez de mémoire
   – pas assez puissant
   – on ne peut pas utiliser de framework (y-a-t-il un équivalent à .NET sous Raspbian ?)
   – …
   —
   Désolé d’avoir été aussi long.

   Répondre ↓
   1. Bud 'Robert' Spencer 2 septembre 2017 à 2 h 18 min

      Tu vois Erwann, ton raisonnement est typiquement celui auquel on a chaque fois droit.

      Quand tu parles des avantages d’un système ouvert (que j’approuve), tu oublies de préciser qu’avant d’aller modifier tout un tas de code pour recompiler un kernel avec pour but de l’adapter à un besoin spécifique et être sûr que tout restera utilisable, il faut déjà avoir une très bonne maitrise de ce système dans sa généralité et un bon, voir très bon niveau de développeur. Quand ensuite tu parles d’un un système propriétaire, tu évoques des problèmes de mise à jour qui démontre une méconnaissance totale des moyens et des méthodes existantes pour leur déploiement et pour ce qui est du développement, tu nous parles de calcul scientifique sans doute très complexe capable d’accaparer un système plusieurs jours mais tout ça développé en vbA et sans même être capable de le faire tourner en background. Si tu veux mon avis, ce n’est l’architecture du système qui est faible mais plutôt celui qui a décidé et qui utilise la méthode. Soyons un peu sérieux. Comparer ce que peut faire un gourou Linux aux mauvaises pratiques d’un utilisateur Windows lambda est un peu light comme argument si on veut comparer les 2 systèmes de façon objective.

      Revenons à nos moutons. De quoi parle-t-on au juste ici ? D’un os spécialement fait pour les makers, d’un langage de programmation moderne et d’un vrai outil de développement professionnel. Tout ça couronné par le bouquin de Mr Svetec pour ceux qui veulent un peu d’aide pour faire leur premier pas dans le développent d’objets qui font clignoter des leds. Eh bien moi, je ne vois là que des choses intéressantes qui devrait au moins réveiller la curiosité des vrais passionnés. Après je me fous pas mal de savoir si il y a un pingouin ou une fenêtre de dessiné sur la boite. Ça fait 30 ans que je développe sur les 2 donc si il y en avait un qui n’était pas viable, je m’en serais sans doute aperçu depuis longtemps 😉

      Répondre ↓
5. Erwann 2 septembre 2017 à 10 h 29 min

   Bud,
   je ne veux pas polémiquer mais :
   1/ Utiliser un environnement de développement basé sur un système ouvert, ne signifie pas forcément devoir recompiler et « touiller » les bas-fonds du système (noyau compris).
   2/ Je te recommande d’aller écumer les catalogues des principaux fabricants d’équipements analytiques (HPLC, MS, automates d’analyse de sang et d’urine, etc., lecteurs de plaque, analyseurs bio-électronique, etc.) tu auras ainsi une meilleure idée des points que j’évoque et des ravages causés par des architectures applicatives immatures et peu fiables.
   Il en va de même pour de nombreux équipements de production « skid mount ».

   Pour info, l’excuse « à deux balles » évoqués par ces fabricants est que les exigences pharma (validation, disponibilité sur le long terme, lisibilité des données sur le (très) long terme) sont « anecdotiques » et négligeables (sic) par rapport à leurs autres clients (que l’on aimerait bien connaître hors le monde universitaire).
   Devant batailler depuis plus de 20 ans sur ce sujet, j’y suis particulièrement sensible.

   Je suis entièrement d’accord sur le fait que le système n’est pas la cause, mais bien les développeurs et autres « architectes ». En revanche, force est de constater, que l’éco-système windows a généré une majorité de « développeurs » anesthésiés qui ne savent pas faire grand chose hors de VBa et de .NET.
   Le Raspberry Pi est pour moi une sorte de lumière dans les ténèbres, me redonnant l’espoir de pouvoir de nouveau rencontrer de jeunes développeurs avec une soif d’apprendre et une envie de faire bien (quelque soit l’environnement qu’ils utilisent).

   Malheureusement, je ne noircis pas la réalité.
   —
   PS: Nous passerons sous silence la stratégie de la Pomme qui a tellement verrouillé son environnement qu’un étudiant n’est plus en mesure de pouvoir aisément faire des développements pour une tablette (en théorie c’est possible, dans les faits, c’est presque mission impossible).

   Répondre ↓
6. Bud 'Robert' Spencer 3 septembre 2017 à 19 h 34 min

   ‘Des développeurs anesthésié qui ne savent pas faire grand-chose hors de vba et .Net…’

   Là, je suis obligé d’apporter un peu d’info parce qu’i l y en a visiblement grand besoin …

   vbA n’est pas à proprement un parler un langage de programmation. Il ne sert pas à faire des programmes. vbA signifie Visual Basic pour Application et ce n’est qu’une petite partie des runtimes VB (je n’ai pas dit vb.Net …) qui ont été intégrés dans toutes les applications Office et de nombreux logiciels non MS (Autocad d’Autodesk et Solidworks de Dassault Systemes pour les plus connus). vbA n’est pas destiné à des développeurs mais à des utilisateurs ‘avancés’ de CES applications pour créer des macros POUR ces applications.

   .Net n’est pas un langage de programmation mais un ensemble de technologies qui repose notamment sur une CLI (infrastructure de langages commune) standardisée, ouverte, certifiée (iso, ecma …) et indépendante du langage de programmation. De nombreux langages non MS ont été portés (plus ou moins bien …) pour l’utiliser y compris dans le monde libre (Ada, Python, Ruby, Lua, Php … en font partie).

   Il ni a pas UN framework .NET, mais DES frameworks .Net dont la grande majorité sont open source. Pas besoin d’avoir une machine qui tourne sous windows pour utiliser la technologie .Net. C’est multi-OS, et multi-plateforme. Et Même si tu n’as pas d’OS, le .Net Micro Framework (plus communément appelé NetMf) est un projet open source qui sait s’en passer. Les exemples les plus connus qui l’utilisent sont les carte Netduino (arduino .net ) , les carte Fez de chez GHI Electronics et son implémentation sur les microcontrôleur STM32.

   Alors oui, il est beaucoup plus facile de troller une technologie que l’on ne connait pas plutôt que de l’apprendre ou au moins de s’y intéresser pour avoir un vrai avis objectif dessus. Pour la petite histoire, c’est Anders Hejlsberg qui est à l’ origine de la conception du Framework .Net et qui dirige le département c#, quand à Miguel de Icaza il est entre autre à l’origine de Mono et Xamarin (Si tous ces noms ne te disent rien, Google te dira qui ils sont). Crois-tu vraiment qu’un génie précurseur et qu’un pillier fondamental de l’open source s’intéresserait à une technologie comme .Net si elle était foireuse comme tu le penses ? Combien de troll .Net comme le tient peuvent se vanter d’avoir autant fait pour le libre ou se vanter d’avoir le niveau de compétence de ces 2 gugus ?

   Si je devais finir par une citation, je citerais Pierre Desproges :
   L’ouverture d’esprit n’est pas une fracture crane 😉

   Répondre ↓
   1. spourre 3 septembre 2017 à 23 h 10 min

      +1 pour VBA qui n’est que le langage des macros des logiciels MS (comme LibreOffice a le sien).
      En général, ce sont les « power users » qui « développent », sans aucun background informatique.
      Cela donne, trop souvent, de belles merde* non documentées, programmées avec les pieds et qui atterrissent au service informatique quand l’auteur n’est plus là (stagiaire, mutation, retraite…).
      Cela comporte aussi son lot d’incompatibilités (access par exemple) en cas de changement de version.

      Pour mono, le portage sur Linux a généré, AMHA à juste raison, son lot de critiques. Ce n’est pas le remarquable travail de Icaza qui est en cause mais le fait que ce n’est « qu’un portage » et non un développement communautaire, à la traîne des décisions de MS:
      http://linuxfr.org/users/patrick_g/journaux/pourquoi-monoc-est-une-folie

      Répondre ↓
      1. Bud 'Robert' Spencer 4 septembre 2017 à 20 h 52 min

         Tu sais Sylvain, des belles m*rd*s, j’en ai vu sous tous les os et dans tous les langages (et j’en ai fait aussi, comme tout le monde). Bon la faut bien admettre que pour ça, les scores explosent depuis que tous les débutants se mettent à coder a tout va sur les Pi, mais on ne peut quand même pas leur en vouloir de ne pas être des gourous en programmation dès les premières lignes de code. Ils essaient, ils apprennent (souvent tout seul) et c’est très bien.

         Bien sûr, la grande bataille perdue des anti-mono. J’avais suivi ça de très très près au début du projet puis j’ai fini laissé courir tellement ca virais au ridicule. Ça allait du refus de l’intégration de mono et de certain programme écrit en c# dans certaine distribution jusqu’à un refus total du projet satanik. Ça avait foutu un tel boxon à l’époque qu’en comparaison ce qui se passe en Syrie depuis 6 ans fait figure de wk à Dysneyland. Ceci dit, on avait eu droit à peu à la même fronde quelques années plus tôt avec Java donc on était rodé (ce qui ne l’a pas empêché de devenir en très peu de temps le langage de programmation le plus utilisé). Comme c’était prévisible, la très grande majorité des critiques ne provenaient ni de contributeurs open-source, ni même de développeurs, mais juste d’utilisateurs linux qui avaient peur de bruler en enfer s’il y avait la moindre trace d’idée du méchant bill$ sur leur système (à chacun ses phobies …). De temps en temps tu as intégriste de l’os du futur (son futur à lui hein, pas le nôtre …) qui tombe la dessus en cherchant depuis 6 semaines comment scripter la copie d’un fichier de sa clé usb vers son Ubuntu et c’est reparti. Ce que tous ces trolls nuisible semblaient oublier (ou plutôt ne savaient pas), c’est que beaucoup de technologies qui sont devenues des grands standards sous linux proviennent de solutions qui au départ étaient propriétaire.

         Tient, voilà la traduction d’un article bien plus intéressant qui date de 2009 (écrit par un vrai contributeur du projet Mono).
         http://tweekers.free.fr/blog/index.php?post/2009/07/01/Et-c-est-reparti-%3A-pourquoi-Mono-n-est-pas-une-menace.

         Sinon, depuis tout ça, le projet Mono se porte plutôt bien. La dernière build date d’Aout 2017, les technologies .Net continue d’évoluer y compris dans l’open source et ma connaissance aucun pc qui l’utilise sous linux, windows ou mac n’a encore pris feu à cause de ça … croisons les doigts 😉

         Pour ma part je ne l’ais testé que tardivement sur le PI. Comme pour le reste, si on se contente des dépôts Raspbian on reste aux versions préhistoriques et forcement ce n’est pas la panacée. Par contre si on se met à jour, ça le fait. J’ai même été surpris par les performances. Je n’en attendais pas tant sur un toupitipi. J’avais prévu de faire un tuto là-dessus pour le forum mais vu l’état d’esprit qui y règne quand on aborde un truc pondu par Satan …

         Répondre ↓
         1. spourre 4 septembre 2017 à 23 h 52 min

            Bonsoir Bud,

            Tu connais ma position quant à MS. Ses produits ne sont pas les merd* infâmes que certains rebelles, récemment convertis à Linux, se plaisent à dénoncer à coups de « windaube » pour faire rebelz ;-(

            Par contre, les pratiques commerciales de MS sont détestables et je pense que la communauté du libre n’a pas oublié les campagnes de FUD, les procès et l’intimidation de certains revendeurs (Motorola, Samsung, mais ils n’ont jamais attaqué directement Google, trop gros poisson ) et l’attaque directe de Linux par SCO (racheté par MS) !
            C’est pour cela que les accords entre SuSE et MS sont si mal passés et que cette distribution n’a toujours pas le succès qu’elle mériterait.
            MS n’a revu sa position que par opportunisme, Linux devenant incontournable dans certains domaines.

            Répondre ↓
            1. Bud 'Robert' Spencer 5 septembre 2017 à 20 h 45 min

               Je connais ta position Sylvain, mais tu crois vraiment que quand Thomas Pesquet a mis ses fesses sur un lanceur Soyouz pour aller se balader dans les étoiles il s’est souvenu que l’origine du projet était un missile nucléaire intercontinental de l’ère Stalinienne ?

               Ma position à moi elle est très simple. Je ne suis ni politicien ni juriste et encore moins un moraliste. Je suis un technicien, il y a des technologies qui innovent, je les utilise. C’est pas plus compliqué que ca 😉

               Répondre ↓
7. Erwann 3 septembre 2017 à 20 h 31 min

   Bonsoir Bud,
   je te remercie des explications que tu proposes et qui pour certaines m’étaient déjà connues (mais pas concernant les créateurs de .NET).
   Je suis désolé que tu prennes certaines de mes remarques au niveau personnel car, ne te connaissant pas, ce n’est évidemment pas à toi que je pensais en écrivant les messages précédents.
   Comme dans tous les domaines, il existe de bons et de « moins bons » développeurs. Pour en revenir aux soucis que je mentionnais précédemment, il y a de nombreux « moins bons » développeurs chez de nombreux fabricants d’instruments analytiques, qui faisaient (et font) l’objet de mon ire.
   Tu évoques très bien le point faible de ce que je mentionnais :
   >> vbA n’est pas destiné à des développeurs mais à des utilisateurs ‘avancés’ de CES applications pour créer des macros POUR ces applications <<
   C'est exactement le problème ! De nombreux outils sont utilisés en dépit du bon sens car les personnes qui les utilisent ne savent pas.
   Ce qui me chagrine c'est que la grande majorité des étudiants que je rencontre se comportent de manière similaire.
   Lorsque j'évoque au cours de discussions avec les fabricants d'instruments analytiques les opportunités / possibilités de portage de leurs applicatifs vers d'autres environnements (OS) plus pérennes et mieux maîtrisable sur le long terme, la réponse standard que j'obtiens est: "ce n'est pas possible, nous sommes sur VB(a) et .NET".
   Je te crois bien volontiers en ce qui concerne le support d'environnements autres que Windows, mais, là encore, la question est de savoir comment l'application a été architecturée et implémentée. Une mauvaise architecture et une implémentation de mauvaise qualité peuvent sans doute fonctionner sous Windows, mais ces faiblesses ferment la porte à tout portage "aisé" et économiquement rentable.
   —
   PS: n'ayant pas peur d'une fracture du crâne 😉 je pense que je vais acheter le livre d'Alexandre pour découvrir Win IoT Core un peu plus en détail (sans pour autant l'utiliser).
   Je te remercie de m'avoir rendu encore plus curieux à ce sujet.

   Répondre ↓
   1. Bud 'Robert' Spencer 4 septembre 2017 à 20 h 56 min

      Rassure toi Erwann, il ni a rien de personnel et Je ne suis en conflit avec rien du tout. Pratiquant entre autre VS (depuis 1997) et C# (depuis 2002), j’apportais juste un petit conseil simplement technique à ceux qui seront tenté d’acheter le bouquin de Mr Svetec pour découvrir ces solutions. Comme je l’ai déjà écrit, la plupart de ceux qui débutent dans la programmation en C# directement sous W10IoT Core pour le PI vont généralement à l’échec. Espérons que ce bouquin fasse qu’il en soit autrement

      Répondre ↓
8. Serge 10 septembre 2017 à 20 h 44 min

   Bonjour,
   Tu as raison François… Ça polémique dur !
   Moi, je voudrai juste savoir quelles sont les ressources consommées par WioT.?
   – mémoire, place disque, CPU
   Quelle(s) interface(s) est(sont) proposées ?
   – PowerShell, Bash, Windows
   Faut il acquérir une licence onéreuse ?
   Merci

   Répondre ↓
   1. François MOCQ Auteur de l’article25 septembre 2017 à 11 h 16 min

      Bonjour Serge
      Désolé pour le retard de la réponse, je rentre de vacances 🙂
      je vais laisser Alexandre répondre…
      cordialement
      François

      Répondre ↓
   2. Alexandre SVETEC 26 septembre 2017 à 7 h 52 min

      Bonjour Serge,
      J’avoue ne jamais avoir effectué de mesures en situation réelle ni même avoir eu l’occasion de saturer un Raspberry sous Windows IoT Core. Windows IoT Core ne fonctionne que sur les cartes Pi2 et Pi3, disposant d’1Go de RAM ainsi qu’avec les CPU de 900Mhz et 1,2Ghz. La préconisation officielle est une carte SD de 4Go mini. Il reste alors 2Go de libre après installation.
      Les performances de la carte SD impactent directement la rapidité d’exécution de l’ensemble, plus que la vitesse du CPU. Il ne faut surtout pas hésiter à utiliser une carte avec de hautes vitesses de lecture et d’écriture (60 à 90 MBits/s).
      Windows IoT Core est prévu pour fonctionner avec une application en premier plan. Il n’y a pas de bureau de menu démarrer etc… C’est l’interface de votre application qui reste affiché en permanence, façon objet connecté. On peut aussi le démarrer sans interface graphique, donc sans écran. On lui fait alors exécuter des taches de fond sans interface graphique.
      Pour le contrôler à distance, il existe le DevicePortal (pages web d’administration), la console SSH avec un CMD.exe classique ou bien PowerShell.
      Enfin, je terminerai sur votre dernière question que l’on me pose si souvent : Windows IoT Core est GRATUIT, ainsi que la version Community de Visual Studio qui vous permet de créer vos applications dans de multiples langages.

      Répondre ↓
   3. Bud 'Robert' Spencer 26 septembre 2017 à 14 h 28 min

      Bien résumée par Alexandre, mais je me permets quelques précisions.

      Concernant l’usage CPU et Ram, c’est comme pour tous les os, cela dépend principalement des services et des fonctions activées (Tous ceux activés par défaut ne sont pas forcement nécessaire une fois le projet IoT en place).

      Les mode d’accès :

      Windows IoT Dashbord : Programme qui permet la découverte des devices sur le réseaux. Accessoirement il dispose aussi de toutes les fonctions pour déployer l’OS sur les cartes SD.
      Remote Client : Un client de bureau à distance qui permet d’avoir la sortie GUI sans avoir besoin de connecter un écran au PI.

      Device Portal : Une webapp d’administration très complète embarquée par l’os (elle dispose d’ailleurs d’un tableau de bord paramétrable pour visualiser en temps réel l’état des ressources). C’est l’outils indispensable à étudier quand on débute avec W10IoT Core. Device Portal met aussi à disposition une API REST (JSON) qui permet beaucoup de chose et qui est extensible à souhait.

      SSH : Permet d’utiliser une interface de ligne de commande standard Windows depuis un client SSH quelconque

      PowerShell : Permet d’utiliser une interface de commande et de script PowerShell.

      Partage de Fichier : Permet d’accéder aux dossiers et fichiers du PI par l’explorateur de fichier sous Windows.

      FTP : Windows 10 IoT Core héberge nativement un serveur FTP

      D’autre possibilités moins connus sont aussi disponible nativement comme par exemple le suivi en temps réel des traces système et réseaux en utilisant ETW (Event Tracing Windows), le débogueur système winDgb et bien d’autres choses existantes sous Windows en général.

      Toujours pour confirmer ce qu’écrivait Alexandre, W10IoT Core est libre en téléchargement et n’a pas de clé de licence à saisir. J’ajoute que contrairement aux idées reçues, on peut très bien se passer d’un PC sous Windows pour utiliser ou programmer un IoT sur cet OS. Un mac ou un linux peu parfaitement faire l’affaire si on est prêt à se passer de la puissance et des fonctionnalités offertes par un outil comme Visual Studio.

      Répondre ↓
9. Yannick 12 novembre 2017 à 14 h 03 min

   Hello,

   super livre qui m’a permis de bien démarrer sous IoT.

   En revanche je rencontre un problème que j’ai pu reproduire avec le code source de l’auteur.

   Le capteur Ti CC2650 S’endort et alors la lecture des données plante avec un message d’erreur assez clair sur le fait que le capteur fait la sieste (Voir ci-dessous)

   « Value does not fall within the expected range. »

   Dommage que ce ne soit pas expliqué comment réveiller le capteur avant d’en faire la lecture…

   Du coup ça perd tout son sens !!!

   Je ne trouve pas de solution malheureusement …

   Répondre ↓
   1. Alexandre Svetec 12 novembre 2017 à 21 h 37 min

      Bonsoir,
      La première chose est d’impérativement utiliser un dongle Bluetooth, et de désactiver la carte Bluetooth du Pi3.
      Ensuite le module Sensor Tag CC2650 possède des états éteint / visible / en marche décrits à la page 437 un peu particuliers et déroutants. Ainsi, ce qu’il peut se passer, c’est une perte de liaison Bluetooth replaçant le module en mode visible. Il reste alors dans ce mode durant deux minutes, puis s’éteint faute de connexion. Une fois éteint, il n’y a aucun autre moyen pour le réveiller que d’appuyer sur son bouton pour le remettre en mode visible afin de rétablir la connexion Bluetooth.

      Essayez de changer de pile, même si elle affiche 70%, surtout si la température descend (c’est de saison !). Vérifiez si le phénomène persiste avec une distance réduite, ou avec l’application officielle.
      Tenez-nous au courant !
      Alexandre.

      Répondre ↓

Ce site utilise Akismet pour réduire les indésirables. En savoir plus sur comment les données de vos commentaires sont utilisées.