Calculatrice de chez Numwork: Top ou Flop? [Python inside] - Page 7

Un des intérêts d'écrire en anglais moderne est qu'il n'y a pas de distinction tu/vous, c'est pratique

Il y a des chances qu'un support des N0100 trafiquées (soudage du même chip de Flash NOR QSPI Adesto que sur les N0110, voire d'un chip Winbond de même pinout mais utilisant des commandes Flash différentes) soit ajouté à Omega, au moins de façon semi-officielle même s'il sera moins largement testé que les N0100 et N0110 dans leur config d'usine. zardam indique que son portage de Nofrendo tourne plus lentement en Flash externe qu'en Flash interne, mais le soudage d'un chip de Flash externe rapproche quand même nettement l'enveloppe fonctionnelle des N0100 de celle des N0110.
Comme beaucoup, j'ai regretté que la quantité de RAM, qui est le facteur limitant sur les N0100, n'ait pas été augmentée sur les N0110. Cependant, quand j'avais regardé la gamme STM32F7 il y a plusieurs mois, j'avais vu que les SoCs pas chers avec une faible quantité de Flash interne sont limités à 256 KB de RAM, et que tous les SoCs avec 384 ou 512 KB de RAM ont beaucoup plus de Flash interne, et de périphériques inutiles sur ce hardware, pour un coût unitaire bien plus élevé que STM32F7 bas de gamme + chip Flash NOR externe (la somme semble inférieure à celui du STM32F4 des N0100), donc je peux comprendre pourquoi ils ont fait un tel choix. [EDIT: ça reste vrai maintenant, mentionne 1+ MB de Flash sur les chips qui ont 512 KB de RAM.]
[EDIT2: si on monte encore en gamme, le STM32H750VBT6 a 1 MB de RAM, 128 KB de Flash, une fréquence encore plus que doublée et plus de caches I et D, une unité DPFP, même un MAC Ethernet et d'autres choses inutiles ou déraisonnables sur une calculatrice faite pour des examens scolaires, et reste pourtant moins cher que le STM32F4 des N0100.]

Après il faut voir si tous ces trucs inutiles ont un impact sur l'autonomie.

Si tu ne les alimentent pas, non ca ne devrait pas.

Par contre, la partie CPU elle-même consomme peut-être davantage.

Lionel > après, les prix publics sont indicatifs. Je ne sais pas combien NumWorks fabrique de calculatrices, mais il est possible qu'ils aient obtenu un tarif intéressant pour l'achat en grosse quantité de ce composant en particulier.

J'aurait tendance a penser que la conso devrait etre assez similaire, si ce n'est pour la ram interne qui consomme probablement un peu plus

Godzil (./184) :
Si tu ne les alimentent pas, non ca ne devrait pas.

Mais est ce que c'est possible ? Au moins dans le cas de la mémoire supplémentaire, j'en doute.

Pour la mémoire, généralement non. Mais dans ce cas, c'est de la SRAM, qui ne consomme quasiment rien quand on n'y accède pas. Donc avoir davantage de RAM ne devrait pas être un désavantage du point de vue de l'autonomie.

Pour ce qui est des périphériques inutilisés, on peut les mettre en veille pour économiser l'énergie :

https://www.st.com/resource/en/datasheet/stm32h750vb.pdf :
There are several ways to reduce power consumption on STM32H750xB:
• Decrease the dynamic power consumption by slowing down the system clocks even in Run mode and by individually clock gating the peripherals that are not used

Ça fait d'ailleurs une belle différence : d'après la doc, la consommation totale avec tous les périphériques activés est plus du double de la consommation totale avec tous les périphériques désactivés.

Le CPU proprement dit a également différents mode de veille. Tout ça est relativement habituel sur ce genre de composants.

J'ai essayé de comparer la consommation de la partie CPU du STM32F730V8 (celui qui est utilisé dans la Numworks N0110) et du STM32H750VBT6 (celui cité par Lionel comme exemple), mais j'obtiens des résultats surprenants, qui me laissent penser que j'ai dû me planter quelque part - la comparaison n'est pas triviale, l'architecture est complexe et n'est pas identique pour les deux composants.

En revanche, pour 10 000 pièces, celui utilisé par NumWorks est à 2,37 $, et celui de Lionel est à 3,69 $. Ça me paraît être une bonne raison pour justifier qu'il aient choisi le premier plutôt que le second

c'est tres compliqué de donner vraiment une conso pour un CPU, et meme si en theorie un CPU avec une frequence plus elevé consommerais plus, comme il finit la tache beaucoup plus tot et si la gestion d'alimentation est fait correctement, le CPU va en fait passer plus de temps a rien faire, donc au final consommer moins.

Pour avoir eu affaire a ca, sur des machines avec des cpu de génération differente, entre 600Mhz pour l'ancienne et 1Ghz pour la nouvelle, pour la meme tache, globalement celle a 1Ghz consommait moins que celle a 600Mhz, parceque passait plus de temps en idle ou les deux sont assez equivalent qu'en marche a plein regime ou la ca consomme plus.

Entre 480 MHz / 16+16 KB cache / DPFP et 216 MHz / 8+8 KB cache / SPFP, à techno égale, on s'attendrait à ce que la partie CPU du premier consomme nettement plus que celle du second. Mais peut-être que les STM32H7 utilisent justement un noeud de techno plus fin et/ou plus low power.

Il y a en effet une raison de coût pour avoir utilisé le STM32F730V8 au lieu du STM32H750VBT6 sur la N0110. Cependant, la N0100 utilisait le STM32F412VGT6 actuellement listé à 4.52$ x 10K pièces (j'avais le souvenir de 4.9$ x 10K pièces, soit c'était pour un autre STM32F4, soit ça a baissé), et l'Adesto AT25SF641 (Flash NOR 8 MB, 104 MHz) listé sur les schémas des N0100 et présent sur les N0110 coûte moins d'1$ x 10K pièces.
Si NumWorks avait passé la première commande de STM32 légèrement plus tard, ou si ST avait sorti certains nouveaux chips un peu plus tôt, la N0100 aurait probablement utilisé un autre membre de la famille STM32. J'ignore si la même chose s'est produite pour la N0110.
J'ai lu quelque part, par exemple dans une interview de Romain Goyet, que NumWorks avait soulevé auprès des investisseurs une somme dont je ne me souviens pas précisément, bien sûr suffisante pour réaliser quelques hommes-années de dev du firmware (full custom !) et produire un certain nombre de machines avant d'en vendre une seule, mais je me souviens avoir imaginé que ça faisait de quoi produire nettement moins de 100K machines, en supposant un prix de production à 25-40€ (/2 à /3 par rapport au prix consommateur final, classique pour les matériels électroniques). NumWorks n'a pas les économies d'échelle de TI EdTech mais le coût de structure doit être plus bas.

Lionel Debroux (./191) :
Entre 480 MHz / 16+16 KB cache / DPFP et 216 MHz / 8+8 KB cache / SPFP, à techno égale, on s'attendrait à ce que la partie CPU du premier consomme nettement plus que celle du second. Mais peut-être que les STM32H7 utilisent justement un noeud de techno plus fin et/ou plus low power.

J'ai comparé à fréquence égale, sinon c'est de la triche
J'obtenais une consommation quasiment 2 fois moins importante pour le STM32H750VBT6 que pour le STM32F730V8, ce qui me semble pour le moins douteux (même en supposant que le premier soit meilleur sur le plan de la consommation que le second, en plus d'avoir davantage de cache et de supporter une fréquence plus élevée).

, https://ti-pla.net/t23505, https://ti-pla.net/p251390 et autres: à cause du foutu mode examen des Pays-Bas, dans l'arbre des sources d'Epsilon, retour d'un fichier CC-BY-NC-ND et affichage par défaut d'un message indiquant clairement le fait que NumWorks n'engage pas sa responsabilité pour des builds non officiels.
Evidemment, c'est un mauvais signal envoyé aux forks pour l'instant amicaux d'Epsilon, mais ce qui est probablement plus embêtant, c'est qu'en l'état, des surveillants incompétents et bornés comme on en a déjà vu à l'oeuvre ces dernières années seraient bien capables de sanctionner des élèves sur la base de ce message, alors que ce n'est pas parce qu'un build est fait de manière non officielle que le logiciel est forcément non conforme, et que ce n'est pas parce qu'un build n'affiche pas qu'il est non officiel qu'il ne contient pas de fonctionnalités non conformes...
Affaire à suivre, clairement; on verra s'il y a des problèmes en pratique, et quelles seront les actions de NumWorks, des développeurs et des utilisateurs.

C'est assez logique en même temps : le mode examen est censé garantir que le fonctionnement est conforme au cahier des charges officiel, or c'est impossible à garantir avec un build tiers, par définition (même avec les meilleures intentions du monde de la part de NumWorks et des développeurs). Et je ne qualifierais pas un surveillant d'"incompétent et borné" s'il réagit à ce message, car le risque de triche est réel.

Perso, depuis le début je m'attendais à ce que cette question arrive sur le tapis tôt ou tard, et je pense qu'utiliser un build tiers dans des conditions d'examen est une mauvaise idée de toute façon.

Tu sais comme moi qu'avec des machines sur lesquelles les utilisateurs ont un accès physique non restreint, dans tous les cas, le risque de triche est réel, d'autant plus si on peut les reflasher, ce qui est le cas de toutes les machines modernes
Un tricheur un tant soit peu compétent serait complètement idiot d'utiliser une version sur laquelle il y a un tel message. Je sais, c'est beaucoup demander de pas mal de tricheurs... on a vu les magnifiques opsec fails des fraudeurs du bac 2019. Et on connaît des moyens techniques pour faire des choses non conformes sur plusieurs modèles de calculatrices TI et HP, y compris plusieurs modèles autorisés aux examens actuels, au moins sur un sous-ensemble de révisions matérielles desdits modèles.

On en revient toujours au même point: la vision idiote et contre-productive des réglementateurs d'examens à la con dont le niveau ne fait que baisser...

Lionel > on est bien d'accord, la sécurité du mode examen est loin d'être infaillible pour ceux qui s'en donnent les moyens. Il serait plus honnête soit de tout autoriser, soit d'imposer l'utilisation de machines fournies par l'établissement, plutôt que ce compromis bancal.

Tout à fait, la place du compromis bancal et inégalitaire qu'est le mode examen est dans le réceptacle à déchets de votre choix...
Ca fait des années que j'écris qu'à partir du moment où on ne veut pas faire des examens intelligents et autoriser toutes les fonctionnalités des calculatrices graphiques (ça ne risque pas d'arriver, comme on le voit dans l'autre topic sur l'EN...), ce qui serait la chose à faire pour plusieurs raisons (examens plus représentatifs du monde réel, réduction des inégalités, etc.), une solution plus efficace contre la fraude que le mode examen caca est de passer au reflashage de toutes les machines en salle d'examen, avec un OS théoriquement conforme.
Des problèmes pratiques ? Je fais semblant de ne pas vouloir le savoir
Des attaques sur la supply chain ? Inévitablement, à commencer par la cause reproductible de la fuite des sujets du bac 2019: complicité interne dans un centre d'examen.

D'autres personnes qui s'intéresseraient aux opsec fails des fraudeurs du bac 2019 peuvent me contacter en privé.

Moins d'un an et demi après ./193, on sait quelles ont été les actions de NumWorks: fermer le code source, verrouiller les machines contre les OS tiers (système de restauration qui n'accepte pas des OS arbitraires), interdire le downgrade une fois que la machine est équipée de ce système de restauration, et fournir une gestion très limitée des programmes tiers: effacement quasi-systématique (même au reboot !), etc.
Il y a plus de 20 ans, les TI-68k proposaient une solution technique à la fois beaucoup plus utilisable (dualité programmes ASM persistants si archivés - hors bug de la restauration de l'archive au reboot - et FlashApps persistantes) et plus sécurisée, les FlashApps étant signées et validées. Ce n'est pas faute d'avoir décrit à NumWorks la solution technique intelligente utilisée par TI il y a plus de 20 ans, et mise au goût du jour plus récemment à cause du foutu mode examen: sur certains modèles plus récents, certaines applis sont interdites dans certains modes examen.

Malgré les consignes stupides passées pendant quelques mois au Portugal en 2021 (interdiction explicite des calculatrices open source !), par exemple, il est très difficile d'imaginer que
1) quelqu'un force NumWorks à implémenter une solution beaucoup plus limitée restrictive que celles utilisées par les constructeurs historiques bien établis de calculatrices graphiques;
2) ça leur ait pris des hommes-années de pondre une merde pareille: avant que la fermeture soit annoncée, ça faisait environ un an qu'il ne se passait plus grand chose sur le code public de l'OS.
On ignore ce que ça veut dire... peut-être que NumWorks prépare un nouveau modèle, peut-être avec un CAS, et qu'ils cherchent par tous les moyens à massacrer les anciens modèles, en attendant l'arrivée du nouveau modèle qui sera au moins aussi verrouillé. Mais à la mi-août, c'est déjà trop tard pour une disponibilité cette année, la période des achats de calculatrices étant bien entamée.

https://ti-pla.net/t25121

C'est pas joyeux tout ça...

Oui, c'est triste

Il serait intéressant d'avoir les commentaires de quelqu'un travaillant chez Numworks, mais je suppose qu'il risquerait sa place...

Après avoir lu l'article de TI-Planet, qui mentionne les éléments suivants :
- Numworks est en position de challenger face à des poids lourds comme TI ou Casio
- ils envisagent d'attaquer le marché américain
- ils ont été financés par des investisseurs externes à la boîte
- leur politique open-source leur a causé un revers magistral au Portugal (interdiction de leur calculatrice aux examens) et commence à les mettre en difficulté dans d'autres pays européens

Pour moi, il est quasi-certain que leurs investisseurs ont dû leur dire quelque chose comme "vous êtes bien gentils avec votre open-source, mais ça nous a fait perdre plein de fric. Soit vous réglez ce problème une fois pour toutes, soit on reprend nos fonds (autrement dit, la boîte coule).". Du coup, panique et serrage de vis tous azimuts.

Par ailleurs, je trouve déplacé le ton limite infantilisant de critor, sur le mode "bouh, vilains Numworks"... Je pourrais l'excuser de la part d'un adolescent. Mais il s'agit d'un professeur adulte, qui a le recul nécessaire pour savoir que la vraie vie est beaucoup plus complexe que "les gentils d'un côté et les méchants de l'autre". Évidemment, la situation actuelle est fort regrettable, mais on pouvait deviner depuis le départ que ce numéro d'équilibriste avec "open-source" d'un côté et "mode examen" de l'autre était très risqué (voir les posts précédents). Numworks a le mérite d'avoir pris le risque pendant plusieurs années, ce n'est pas rien... ce ne sont pas forcément les plus à blâmer dans cette histoire.

Pour moi, il est quasi-certain que leurs investisseurs ont dû leur dire quelque chose comme "vous êtes bien gentils avec votre open-source, mais ça nous a fait perdre plein de fric. Soit vous réglez ce problème une fois pour toutes, soit on reprend nos fonds (autrement dit, la boîte coule).". Du coup, panique et serrage de vis tous azimuts.

Les modèles NumWorks restent très majoritairement implantés en France, quand même. Et un des principaux investisseurs historiques est (semi- ?)public français (BPI, il me semble).
Comme cause racine, je mettrais davantage ça sur le compte de ceux qui commettent les réglementations d'examen que sur une pression directe d'investisseurs. Mais le résultat est le même.

Qu'il y ait eu pression des investisseurs ou pas, on peut difficilement ne pas remarquer que NumWorks implémente des règles auxquelles les autres fabricants ne sont pas soumis, ou en tout cas, ne l'étaient pas jusqu'à présent. Une interprétation excessivement charitable serait que NumWorks veut emmerder les autres fabricants, en indiquant aux faiseurs d'examen que les autres modèles ne sont pas sécurisés (*), et fossoyer la calculatrice graphique, dont l'intérêt a toujours résidé dans l'ouverture. Une autre interprétation serait qu'ils ont toujours voulu que ça se termine ainsi et qu'ils ont profité quelques temps de la réputation d'ouverture de leurs machines... réputation qui est définitivement terminée, d'autant que la réputation négative est beaucoup plus persistante que la réputation positive.
La façon de faire - mauvaise communication de la part de NumWorks, mauvais timing, et fourniture à très grands frais de développement d'une solution peu utilisable alors que des alternatives intelligentes existent - est pourtant de nature à augmenter les risques que des choses réellement néfastes pour le business model soient publiées. Que des faiseurs d'examen exigent des choses de ce genre serait regrettable, mais bon, on a l'habitude que ceux-là ne brillent pas par leur compétence. En revanche, si ce sont des investisseurs qui ont exigé ça pour tenter de regagner la confiance des faiseurs d'examen, et que NumWorks n'a pas essayé de faire passer le message ou pas réussi, alors leur incompétence leur fait prendre un gros risque de retour de flamme spectaculaire. L'expérience - involontaire ! - passée a clairement montré quand publier les choses qui embêtent les fabricants: peu avant les principaux examens de l'hémisphère nord. L'information arrivera aux oreilles des faiseurs d'examens encore plus facilement maintenant qu'il y a 10 ans.

*: les faiseurs d'examens sont trop cons pour comprendre qu'il n'y a pas de solution pour sécuriser des équipements auxquels les utilisateurs ont un accès physique non restreint. De toute façon, sur le marché, il n'y a qu'un modèle réellement verrouillable, à défaut d'être verrouillé pour l'instant: la Prime G2, seule machine à disposer d'un secure boot et d'un processeur convenables. Un modèle rare et cher, d'assez loin le plus puissant du marché, dont le fabricant a en pratique abandonné le développement, puisque les deux personnes qui travaillaient dessus ne le font plus qu'à temps très partiel. HP avait tout pour proposer une super implémentation de Python, ils ont été les derniers à le faire.

NumWorks veut emmerder les autres fabricants,

Je doute vraiment qu'une boîte fasse ça uniquement pour casser les pieds des autres…

J'en doute assez aussi, d'où mon "excessivement charitable". Mais d'un autre côté, des personnes liées à un constructeur qui s'amusent à contacter les faiseurs d'examens pour emmerder les autres constructeurs, enfin surtout NumWorks, ça s'est vu très récemment, avec Maurits van Altvorst, comme indiqué dans l'article de TI-Planet. Même si Maurits van Altvorst a cherché à faire disparaître les traces de son post et du fait qu'il était lié à un autre constructeur, respectivement sur son site et sur sur LinkedIn, il en reste des traces comme https://ti-pla.net/p261839 et https://ti-pla.net/p261914 . Le berger pourrait vouloir répondre à la bergère.

Superbe

Lionel > j'ai travaillé pour une petite entreprise française qui avait des investisseurs similaires à ceux de NumWorks (je ne me souviens plus des noms, mais de mémoire, il y avait soit la BPI soit un autre organisme à la fonction similaire)*.

Je pense que tu surestimes grandement la technicité et la rationalité des discussions entre les investisseurs et les entreprises, et que tu sous-estimes le pouvoir décisionnel des investisseurs.

Derrière la façade des discours publics à la sauce "nous soutenons l'innovation", tu trouves des financiers qui gèrent un gros portefeuille d'entreprises, et qui raisonnent sur deux critères : leurs résultats financiers et la confiance qu'ils leurs accordent. Les aspects techniques sont secondaires, ils n'y comprennent pas grand-chose, et d'ailleurs ça ne les intéresse pas vraiment. Ils n'ont pas d'états d'âme non plus pour laisser tomber une entreprise qui n'atteint pas les résultats qu'ils attendent, vu que pour eux ça n'est qu'un investissement parmi plein d'autres.

Quand ils soutiennent l'open-source, ce n'est pas par conviction, c'est simplement parce que c'est à la mode. Je peux te dire qu'après un fiasco comme celui du Portugal, l'open-source passera de la case "atout commercial" à "risque majeur" dans leur esprit. Et leur réaction ne sera pas "cherchons le meilleur compromis technique entre les intérêts des utilisateurs et les contraintes du marché", mais plutôt "votre business-plan prévoyait X€ de chiffre d'affaires au Portugal. Comment allez-vous faire pour remonter la pente et nous fournir des garanties pour que ça ne se reproduise plus ?".

La direction de Numworks a probablement dû passer un sale quart d'heure, et devoir promettre beaucoup pour sauver les meubles. Il est toujours délicat de juger le comportement des entreprises en se basant sur les infos publiques, il se passe tellement de choses en coulisses...

Ça me paraît beaucoup plus probable comme explication qu'une stratégie délibérée de la part de Numworks.

* pour l'anecdote : après qu'on ait implémenté tout ce que les investisseurs demandaient pour préparer la commercialisation à l'étranger, la réponse de l'un d'entre eux a été "merci, mais on n'y croit plus, donc on arrête de vous soutenir". Voyant ça, les autres investisseurs se sont dépêchés de faire la même chose. Du coup, plus de trésorerie et dépôt de bilan de la boîte dans la foulée. Et du coup, je n'ai pas été payé pour le boulot correspondant...

Merci d'avoir partagé ta mauvaise expérience avec ce genre d'investisseurs.
Je sais bien qu'il se passe beaucoup de choses en coulisses, que ce soit avec les investisseurs ou les faiseurs d'examens à la con. Mais si NumWorks a volontairement promis, ou dû promettre, quelque chose qui est de nature à augmenter les risques sur le business model... c'est stupide.

Lionel Debroux (./208) :
Mais si NumWorks a volontairement promis, ou dû promettre, quelque chose qui est de nature à augmenter les risques sur le business model... c'est stupide.

Disons que c'est un pari. Ça diminue le risque que les organisateurs d'examens leur cherchent des poux dans la tête, mais ça mécontente leur clientèle... Ils ont dû estimer que le premier facteur était plus important que le second. On verra bien si l'avenir leur donnera raison, ou pas.

Un truc vraiment stupide, ce serait un fabricant de calculatrices qui essaie d'empêcher les gens de faire des mathématiques avec des nombres premiers, alors même que ça fait des années que ces nombres ne servent plus à grand-chose... et qui ne prévoit pas l'effet Streisand qui s'ensuit. Mais je parle là d'un situation purement hypothétique, bien évidemment

Bien évidemment ^^
Bon, avec ce fabricant-là, on devrait être tranquilles, au moins jusqu'à ce que l'équipe dirigeante change. Il y a 10 ans (déjà !), celui qui était déjà très haut dans l'organigramme et qui est actuellement le chef était parfaitement conscient que les avocats avaient fait une grosse bêtise et qu'il ne fallait pas la recommencer.