Le 07/03/2017 à 22h 37

levhieu a écrit :



Tu veux dire qu’une société intégrant 10 cœurs ARM dans un SoC paye 10 licences " />

Je comprends pourquoi les gros préfèrent payer une fois beaucoup pour avoir le droit de faire leur propre CPU





La négociation des licences et leur utilisation font traditionnellement partie d’arrangements au cas par cas qui ne sont pas rendus public.

Globalement, ARM distribue deux types de licences : une qui permet d’utiliser leur design (Cortex Ax) pour faire un SoC dont le CPU en reprend l’intégralité et une autre licence qui permet de faire un design customisé (Apple Ax, Snapdragon Krait ou Kryo par citer ces deux protagonistes).

Il faut savoir qu’ARM ne fabrique ni ne vend de SoC, il vend les licences qui permettent aux constructeurs de faire des SoC.

Le 03/03/2017 à 10h 48

yvan a écrit :



Ben j’ai bien l’impression que si c’est différents procs pour différentes tâches.

Pour du vieux code pas gourmand (genre tâches de fond, noyau effectivement) tu as de “vieux” cores avec la fréquence optimisée pour l’usage de ce vieux code et pour des trucs récents avec plein de mémoire, de la virgule flottante pour la crypto et le multimédia tu as des cores plus récents eux aussi optimisés pour leur fréquence.

Et de ce que j’en comprend c’est bien l’archi RISC qui impose qu’on ne peut pas trop jouer sur les fréquences/overclock pour garder un bon rendement et c’est pour cela qu’il y a ici trois générations de cores ici.



Après il y a forcément du marketing sur le nb de cores mais je doute que toute l’industrie se fasse chier à intégrer big.little si ça n’avait aucune utilité que ques des A72 downclockés suffisaient…



Après je suis loin d’être expert et j’ai peut être dit une connerie sur la rétrocompatibilité mais j’aimerai bien une source au moins aussi crédible qu’ARM qui indique qu’on ferait aussi bien avec moins de cores plus puissants et similaires.





Effectivement, je comprends le sens de “différents procs pour différentes tâches” et c’est bien vrai " />.



On peut le résumer ainsi, mais il faut être prudent sur ce genre de simplification.

Si on reparle des serveurs, leur taf consiste justement à traiter des tâches de “vieux code pas gourmand”, mais en quantité TRES importante et là, justement, l’explication n’est plus valable car un CPU très efficace et puissant aura l’avantage sur plusieurs CPU peu puissants.

 

Par contre, attention : cette particularité n’est définitivement pas propre au RISC !!!

Tu mélanges pas mal de choses : la crypto bénéficie d’extensions propres sur x86/64 comme sur ARM depuis des lustres, et leurs perfs tout comme la conso dépendent de l’implémentation de ces extensions.

Idem pour les FPU et les autres extensions, il y en a autant des deux côtés avec des implémentations différentes selon qu’on cherche à viser perfs ou conso.

 

Les premiers Atom ont faits les frais du in order avec une faible fréquence pour atteindre la meilleure conso, mais les perfs étaient vraiment nazes ! Intel a eu un peu de mal avant d’arriver à avoir des Atoms efficaces au niveau des SoC ARM. D’ailleurs, les petits CPU ARM (les “LITTLE”) restent sans réelle concurrence d’Intel.

A la limite, c’est là où on pourrait parler de CISC/RISC car les x86/64, pour simplifier, doivent encore traduire du CISC en RISC et ça a un coût sur la longueur du pipeline et l’efficacité, qu’ARM n’a pas (c’est une hypothèse de ma part sur l’absence d’Intel dans cette catégorie, je le précise).

Mais il ne fait aucun doute qu’Intel serait parvenu à combler l’écart, mais l’investissement est certainement trop important pour un marché qui boude le constructeur (rappelons que ARM est majoritaire sur Android).



Enfin, pour la fin de ton post, si tu attends d’ARM qu’il démontre qu’on peut faire aussi bien avec peu de CPU performants qu’avec un véritable cluster dans sa poche, sache malheureusement que le constructeur ayant un intérêt certain à vendre un maximum de licences pour fabriquer ses CPU, n’aura que peu d’intérêt à faire cette démonstration ;)

Faire cet essai demande un travail certain qui n’est pas évident à mettre en oeuvre, et qui sera vivement critiqué par les industriels qui n’ont plus que ça à vendre comme innovation.

Mais cette démonstration est à mon avis nécessaire d’un point de vue critique journalistique. Je déplore ce manque dans la presse spécialisée, depuis quelques années (précisément depuis que sont apparus les octo-cores).

Le 03/03/2017 à 10h 19

piwi82 a écrit :



Merci pour l’explication très claire " />



C’est probablement aussi pour cette raison (énergétique) qu’Apple est passé sur 2x dual-cores depuis l’aïePhone 7, les modèles précédents étaient des dual-cores simples.



De rien et effectivement pour Apple qui n’a jamais suivi cette mode de multiplication des cores " />.

Apple ne vend(ait) pas de la fiche technique mais de la fonctionnalité, c’est ce qui change tout à mon avis.







OlivierJ a écrit :



Pardon mais pour moi, cette explication n’est pas satisfaisante (je l’ai déjà lue ailleurs), malgré tes efforts de pédagogie que je salue. Je ne dis pas que tu as tort cependant :-) .



Je ne suis pas sûr que l’efficacité (le nombre d’instructions exécutées par seconde et par W) soit meilleure avec un Atom (In Order) qu’un Core i3 (Out of Order). J’avais lu que justement l’intérêt d’un coeur plus efficace et cadencé plus rapidement était de consommer plus pendant le fonctionnement en mode nominal, mais de pouvoir retourner du coup plus vite en mode sommeil plus ou moins profond (les C-states), et au final avoir une consommation plus faible sur la durée.



Pour prendre un exemple qui ne touche pas le grand public, à notre époque où la consommation électrique devient un coût qu’on prend beaucoup plus en compte, les super-calculateurs (qui font beaucoup de parallélisme) sont à base de gros CPU genre i7, plutôt que de myriades d’Atom-like multi-coeur (chaque coeur Atom est N fois moins puissant mais comme ça consomme peu en W et en surface de silicium on peut les démultiplier). C’est erroné ?





Justement, si tu as bien lu mon explication, l’efficacité globale d’un Atom in order est moins bonne qu’un CPU out of order.

C’est juste qu’un ooo aura besoin de consommer un minimum pour atteindre son efficacité “de croisière”.

Le marché des serveurs commence à s’intéresser aux CPU ARM car ils montent en puissance avec les générations, et commencent à avoir d’excellents rendements. Mais ces rendements ne sont pas toujours ceux de nos SoC de smartphones.

Le marché des serveurs est très différent du marché des smartphones : un serveur n’est pas censé être en veille la plupart de son temps et la meilleure efficacité prime sur la meilleure conso, c’est tout le contraire de la mobilité.

 

Tout n’est que question de rendement énergétique et la conso la plus basse n’est pas synonyme de la meilleure efficacité, c’est là toute la subtilité du débat.



Si on doit parler uniquement de rendement énergétique on peut résumer ainsi :

Faible fréquence : avantage in order (+ petit cache et pipeline court) / désavantage out of order

Fréquence élevée : avantage out of order (+ caché élevé et pipeline long) / désavantage in order



Le big.LITTLE permet donc de basculer sur l’un ou sur l’autre en fonction de la fréquence, ou plus généralement de la charge demandée, pour obtenir du groupe de CPU toujours le meilleur rendement.



Pour reprendre l’analogie automobile de shlagevuk, c’est comme si on comparait un petit moteur 1.0l 3 cylindres pour une citadine avec un gros V8 de sportive.

Le big.LITTLE, c’est un peu la grosse sportive qui a un V8 pour le circuit et un 1.0l 3 cylindres pour la ville.

Le 02/03/2017 à 16h 50

piwi82 a écrit :



Le simple fait de modifier dynamiquement la fréquence du processeur (comme Intel le fait depuis 2005) n’est pas suffisant ?

Honnêtement j’ai aussi de gros doutes sur le réel intérêt d’une telle architecture, ou alors Android n’en finit pas de prendre de l’embonpoint.

Hélas non. Modifier dynamiquement la fréquence ne suffit pas.    

 

Pour simplifier, une architecture orientée perfs sera Out of Order avec beaucoup de cache et un pipeline long. Tout ça est lié : l’exécution dans le désordre, pour être efficace, aura besoin de “voir” toutes les instructions à venir pour les ordonnancer correctement, il faut donc un pipeline d’instructions long et beaucoup de mémoire cache. Et pour remplir ce pipeline, il faut beaucoup de cycles d’horloge, donc une fréquence élevée.

Cette technique permet d’avoir de très bonnes perfs mais au prix d’une fréquence élevée (conso++) et d’un cache important (conso++ encore).

Si on réduit la fréquence sur une telle archi, les perfs chutent, et il faut toujours alimenter le cache gourmand en énergie, donc l’efficacité plonge.

C’est pour ça que c’est une archi orientée PERFS.

Chez ARM c’est le “big” du big.LITTLE avec, par exemple, le Cortex A9 en ARMv7 et Cortex A72 en ARMv8.



Ensuite, il y a les architectures orientées conso : in order, pipeline court, cache réduit. C’est tout le contraire de la précédente architecture. Ces choix ne permettent pas un excellent rendement énergétique, mais l’avantage est évident : à faible fréquence, les perfs ne s’écroulent pas et la conso reste vraiment faible.

L’inconvénient est plutôt à chercher dans l’autre sens : élever la fréquence augmentera mécaniquement les perfs, mais le rendement n’étant déjà pas le meilleur devient alors mauvais (tout le contraire de la précédente archi).

Chez ARM c’est le “LITTLE” du big.LITTLE avec, par exemple, le Cortex A7 en ARMv7 et le Cortex A53 en ARMv8.

 

Le 02/03/2017 à 16h 30

levhieu a écrit :



1/ On peut discuter sans fin sur les performances comparées RISC / CISC, mais les CPUs RISC sont tout-à-fait polyvalents. D’ailleurs, je rappelle qu’un x86 moderne a un cœur RISC, mais précédé d’un étage de conversion des intructions x86 → RISC interne



2/ Les 3 modèles Axx du chip ont le même jeu d’instructions, avec les 2 modes

Mais ils ont été conçus avec des compromis performance / consommation différents.

C’est-à-dire que les plus rapides sont tellements accès sur la performance qu’on peut trouver qu’ils consomment trop même à faible charge.



Et c’est là que la question de Juju251 rejoint celle de piwi82: Pourquoi cette architecture asymétrique là où Intel joue sur les fréquences ? Je soupçonne que ça pourrait être lié à la façon dont ARM conçoit ses cœurs de telle sorte qu’ils soient implémentable sur plein de techno de fonderie, mais en disant cela je sors de mon domaine professionnel.

 

Edit: Entre temps, la réponse de quicky_2000 rappelle que la basse consommation n’est pas liée qu’à la fréquence





Intel a toujours été largué dans le marché de la mobilité, même si leurs derniers Atoms ne sont pas mal, ces CPU ne sont pas les plus réputés sous l’OS majoritaire dans le domaine (Android). Je pense que le ticket d’entrée d’Intel doit être plus élevé que chez ARM aussi, ça ne doit pas aider.

S’il n’y a pas ce genre d’architectures asymétriques chez Intel, c’est plus un problème d’offre tout simplement, qu’un problème technique (on en revient au marketing).

 



yvan a écrit :



Je ne parlais pas de performances, si intel a un core risc c’est parce que ça torche plus justement (et que ça simplifie l’archi), je parlais de polyvalence.

Et c’est bien là la raison à la multiplication des coeurs, c’est qu’avec du risc tu dois tout faire en code (beaucoup plus qu’en CISC disons) donc à chaque nouvelle génération de puces le boulot de portage est bien plus important qu’avec x86 donc en concret il est plus simple et performant de faire cohabiter des puces de fonctionnalités différentes avec des fréquences de fonctionnement différentes et optimisées pour le lien à la mémoire.



Du coup là ils ont différents processeurs pour différentes tâches, et si j’ai bien compris c’est bien lié au fait qu’ARM soit sur des principes RISC. (j’ai du mal m’exprimer dans mon premier message) donc bien moins agile qu’intel (mais bien mieux en rapport watt/perfs).





Il n’y a absolument plus aucun intérêt à évoquer la différenciation RISC/CISC à l’heure actuelle !

On ne refait pas plus du portage lors d’un passage d’une génération d’ARM à une autre que d’un x86 à un autre.

 

Du code ARMv5 (ARM9) peut très bien fonctionner sur du ARMv6 (ARM11), ARMv7 (Cortex A7, A8, A9, A12,…) ou ARMv8 (Cortex A53, A72,…).



 Par exemple, les packages précompilés de la distribution Linux Raspbian le sont pour ARMv6 pour être compatibles avec le SoC BCM2835 (ARM11 / ARMv6) du Pi 1 et 0, et sont parfaitement compatibles avec le SoC BCM2836 (Cortex A7 / ARMv7) du Pi 2 et sont toujours parfaitement compatibles avec le SoC BCM2837 (Cortex A53 / ARMv8) du Pi 3 (ou Pi2 v1.2).



Donc non, ce n’est pas “différents processeurs pour différentes tâches”, c’est différents processeurs pour différentes consos, simplement.

C’est justement là où se trouve l’aberration : leur multiplication devient logiquement contre-productive !

Le 02/03/2017 à 11h 33

Juju251 a écrit :



Ce bazar les différents types de cores Arm …

Il y a un intérêt (en pratique je veux dire) a avoir une telle asymétrie ?

Ce doit être loin d’être simple pour gérer les commutations de tâches entre les différents cores aux capacités différentes …





Oui, il y a un intérêt évident : marketing.



Ca fait quelques années que le nombre de coeurs est devenu un argument commercial, alors on s’engouffre généreusement dans cette voie.

Et ça marche à tel point que toute notion de rendement énergétique est occultée et qu’on oublie facilement qu’il est parfaitement possible de faire tourner plusieurs tâches sur un coeur performant, bien plus efficacement que plusieurs tâches sur plusieurs coeurs pas performants.

 

Les cores et la fréquence ça vend. L’autonomie et l’efficacité énergétique, ça ne figure jamais sur une fiche technique en premier argument.

Le 17/01/2017 à 09h 28

@Belial57 : je parlais des cartes d’éval à coût dérisoire pour prototyper/maquetter ;)

Le 17/01/2017 à 09h 27

@Belial57 : je parlais des cartes d’éval à coût dérisoire pour prototyper/maquetter ;)

Le 16/01/2017 à 23h 15

Le compute module se destine avant tout aux industriels (attention, pas nécessairement à l’industrie) et pas au grand public, contrairement au Raspberry Pi. En effet, le Raspberry Pi, en tant que produit grand public, n’offre aucune garantie sur la durée de vie, le form factor (important pour l’intégration), propose un stockage sur µSD, expose ses E/S sans les protéger, etc…Le compute module, en tant que produit pro, nécessite une carte hôte propriétaire (la carte mère est juste pour aider à développer), propose de l’eMMC (ou laisse le choix pour la version Lite), offre une garantie de pérennité, permet d’exploiter plus d’E/S et de ports (2 ports DSI et 2 ports CSI par exemple). Son utilisation n’est pas à la portée de tout le monde et n’a que peu d’intérêt pour tout le monde, contrairement aux industriels (comme NEC qui en a fait le choix).En fait, cette carte est un SOM (https://en.wikipedia.org/wiki/System_on_module ) et c’est relativement répandu dans l’industrie. Il n’y a malheureusement pas de standard, et l’évolutivité est au bon vouloir du fabricant.Un énorme avantage offert par la fondation aux industriels, est qu’il est possible de faire du maquettage sur une carte répandue, au prix dérisoire et ultra supportée (le Raspberry Pi), avant ou en parallèle de la conception de la carte hôte propriétaire (qui représente un coût non négligeable). C’était impensable avant le Raspberry Pi ;)EDIT : désolé, la mise en forme m*rde complètement, j’essaie d’éditer le commentaire mais ça marche pas ! J’ai d’ailleurs eu beaucoup de mal à le poster :/

Le 22/12/2016 à 11h 59

skankhunt42 a écrit :



Tu peut faire de l’électronique avec les deux, sauf qu’en pratique il te faudra ajouter un complément au pi pour en faire. Si tu branche un simple servomoteur avec un pi en iddle il aura la tremblotte car la gestion du pwm est désastreuse. Donc obligé d’acheter une carte i2c et de faire un système de communication entre les deux. Tu devra aussi avoir une autre alim pour avoir un courant correct. A chaque fois tu veut utiliser un composant c’est le même principe, c’est pas terrible. Tout ça pour des économies de bout de chandelles… 20ct la puce tout au plus.



Le zéro à l’avantage d’avoir le wifi et le bt ce qui permet d’éviter d’avoir à rajouter des dongle, surtout qu’en utilisation réelle le port usb sature assez vite et en général c’est le wifi qui lâche en premier.



J’ai bien compris que chacun à des usages différent mais il y à aussi des usages commun ! Perso mon pi il prend la poussière parce que c’est un peu la galère, et puis la update l’os j’ai la flemme… Je m’en serais bien servis comme nas mais devoir faire une partoche spéciale, monter les disques à la mano puis avoir un débit de 3mo seconde, c’est useless.



Personellement je préférais payer 10 / 15€ de plus pour avoir du i2c en natif, un contrôleur sata / usb 3, du wifi, du bt et une deuxième prise d’alim. Car l’avantage avec un pi utilisé dans différent projet si il ne sont pas simultané c’est de passer d’un appareil à un autre :)





Je comprends bien ce qui te manque sur le Pi actuel, et c’est d’ailleurs pour ça qu’il n’est pas dans la même catégorie que l’Arduino. Le Pi est un nano ordinateur qui sert à expérimenter et apprendre. Si tu veux faire du temps réel et du traitement précis, un micro-contrôleur 8 bits (tel que l’ATMega de l’Arduino) sera bien plus approprié, car sans OS (ou du moins sans OS lourd).

Le but d’un OS est justement de fournir des services de haut niveau, comme la pile TCP/IP, la pile Bluetooth, la gestion de systèmes de fichier, de divers langages de programmation, etc…

Encore une fois, la carte ultime qui te fera du temps réel à l’instruction près (comme le fait très bien un micro 8 bits) tout en gérant plusieurs threads et services lourds n’existe pas. C’est d’ailleurs aussi pour ça qu’il existe des systèmes hybrides (des SoC incluant un micro ou un FPGA).



D’ailleurs en parlant d’OS, si tu veux en faire un NAS, pourquoi n’installes-tu pas une distrib type openmediavault ? Ce sera bien plus efficace que de monter tes partoches à la main comme tu fais !

 

A chaque sortie d’un modèle de Raspberry Pi, la fondation est harcelée de demandes sur telle et telle fonctionnalité qui n’y est pas, pour les inclure dans la prochaine version. Leur réponse assez juste est qu’inclure une fonctionnalité qui ne servira pas au plus grand nombre c’est la faire payer aux autres.



 Quelques exemples :

• Ta puce à 20 cents : tu vas faire payer à tout le monde une fonctionnalité qui est loin d’être utilisée par une majorité ! Et qu’en est-il du suivi, des pilotes, de la compatibilité à assurer ? Ajouter une fonctionnalité ne représente pas que le prix du composant ! Et 20 cents par ci, par là, ce n’est plus des économies de bout de chandelle, crois-moi.
  
  - Mettre un port SATA : même pour une carte qui se présente comme étant un nano ordinateur, un bon USB suffirait et serait bien plus universel (ceux qui ne voudraient pas mettre de disque dur auraient un port polyvalent à utiliser pour autre chose).
  
  Donc il y a des lacunes, certes, comme le bus USB (avoir 4 vrais ports USB 2 ou 3 serait une véritable avancée), mais à chaque article sur le Pi, chacun fustige la fondation car sa petite fonctionnalité n’y est pas.
  
  
  
  Sinon pour info : le Pi 3 a bien du bluetooth/Wifi intégré mais pas le Zero. Et tous les modèles de Pi ont bien de l’I2C natif ;)

Le 21/12/2016 à 21h 21

skankhunt42 a écrit :



Le pi est sympa mais un peu trop cher pour ce qu’il est car de base ont peut pas faire grand chose avec, c’est super limité… Tout ça pour faire 2 économies de bout de chandelles… La version zéro tend à gommer tout ça mais c’est encore loin d’être le top. Sur le pi deux choses manques vraiment, la première c’est une vrai gestion des disque dur externe pour pouvoir s’en servir de nas par exemple. Un débit de 5mo seconde vous m’excusez mais pour sauvegarder des centaines de go c’est bien trop lent. La deuxième chose qui manque c’est un vrai controleur pour tout ce qui est électronique car à part faire clignoter une led un truc plus poussé demande des carte additionnelles… Ont doit adapter le code mais en plus gérer correctement l’énergie, bref pas pratique. Pour geekouiller je préfère encore tater du arduino, tu branche tu balance le code tu reboot et hop ça marche





Limité ? On peut pas faire grand chose avec ?

Tu plaisantes ?

A la limite TU ne peux pas faire grand chose avec, et c’est bien dommage pour toi.

Ce qui m’étonne le plus dans ton message c’est ensuite de dire que le Zero est mieux alors qu’il n’est pas le plus puissant, ni le mieux équipé de la gamme (c’est même volontairement tout le contraire). Et tu ajoutes que tu préfères l’Arduino qui ne joue pas du tout dans la même catégorie ! Pas très cohérent ton message.



Par contre, je suis d’accord que le Pi souffre de défauts que la fondation traîne depuis la toute première version, car elle est historiquement liée à Broadcom et au VideoCore IV (qui, pour rappel, est LE composant principal qui gère tout sur le Pi, le CPU est un périphérique comme un autre). Ils ont dû se lancer avec ce qu’ils avaient et sont maintenant piégés pour conserver une rétro-compatibilité, sans quoi la fondation perdrait sa plus grande force : la communauté.

Parmi les lacunes historiques : l’unique bus USB partagé par les 4 ports et le convertisseur USB/Ethernet.



Mais bon, la carte ultime n’existe pas et n’existera jamais car on a chacun des besoins différents. En attendant, la fondation a réussi là où beaucoup ont échoué, avec un principe admirable qui fait largement défaut à l’industrie de la hi tech : l’optimisation. Ce n’est pas le meilleur hard, mais c’est de loin le plus capable. Et ça, on ne le trouve plus nulle part ;)



Pour en revenir à la news : pour moi Pixel sur desktop x86 c’est avant tout pour uniformiser l’environnement d’apprentissage (= destination première de la fondation) en élargissant à un parc plus vaste.

 On ne vise clairement pas le geek qui aura déjà sa distrib favorite. En effet secondaire désirable : pourquoi pas une participation supplémentaire pour améliorer l’environnement Pixel (plus d’adoption = plus de participation).

Le 26/10/2016 à 18h 24

 Il ne faut pas oublier qu’une migration d’outils MS vers des outils MS (mise à niveau du matériel et des licences) a aussi un coût non négligeable. Et qu’on vienne pas me parler d’utilisation intuitive lors du passage de vieux postes sous XP vers du Windows 8, ou d’Office 2k3 à Office je_sais_plus_lequel avec des interfaces utilisateur qui marquent une rupture relativement marquée.

De toutes façons dans ce genre de contrats, quand bien même le changement est minime, il s’accompagne toujours de formation.

Donc migrer vers du libre a un coût certain, mais s’il se produit lors d’un renouvellement de licence ou parc de machines, il est à comparer avec le prix que ce renouvellement aurait coûté, avec MS ou pas.



Enfin, effectivement, en général ce débat n’a lieu qu’entre geeks, libristes ou non, car ce genre d’appel d’offres est souvent judicieusement orienté pour privilégier une solution et pas une autre (ça a toujours été comme ça, et pas que dans l’informatique).

Le 13/10/2016 à 15h 48

tomy100 a écrit :



Tout d’abord merci à tous pour vos réponses.



Pour résumer mes supérieurs considèrent Qt comme une framework destiné au PC (et donc avec les ressources qui vont derrières).



Pour eux Qt n’est pas destiné à l’embarqué, et je souhaite leur montrer qu’une IHM assez simple (consulter des mesures, évènements systèmes, etc sur un simple écran 320*240 16 bits est réalisable en Qt Embarqué).

 

Pour cela  je recherche des exemples de projet (automobile, ferroviaire, médical, aéro, etc) sur lequel tournerait une IHM développée en Qt et avec des ressources limitées (ARM à 1 ou 2 coeurs, ²⁵⁶⁄₅₁₂ Mo de RAM, etc).



Je précise que notre carte ne dispose pas de GPU, donc pas d’accélération matérielle, mais dans le même temps on ne souhaite appliquer aucun effet 3D. En gros c’est une IHM “à plat”.





Alors je veux pas te décourager, mais des exemples d’applications industrielles, t’as très très (très très) peu de chances d’en voir un publié sur le net. Et autant de chances que l’un de nous ayant bossé dessus te transfère son job qui est bien souvent du code fermé, dont la propriété revient à l’industriel/client/employeur.



Mais pour répondre à ton interrogation, QT fonctionne parfaitement bien sur de l’embarqué même léger (ARM9 sans GPU : https://youtu.be/dxFgib5qrvA)



Et comme c’est multi-plateforme, tu peux avancer comme avantage de le porter plus facilement sur une autre archi (renouvellement/changement produit dans le temps), voire de développer l’IHM sous Windows pour la déployer sur cible (nombre de cartes limité / nombre de développeurs).

Le 28/09/2016 à 21h 10

Trollalalala a écrit :



C’est sur, c’est le chipset !

J’ai lancé la commande avec un pipe grep “wi” / “Wi” et “wlan” -> rien sauf mon clavier !

Je relance avec un more et me tape toutes les lignes, pas de signe de wireless, j’en déduis donc que le chipset est décédé, c’est étonnant au bout de seulement quelques mois, mais pas très grave, je ne m’en sert jamais et au pire je dois avoir une clé wi-fi qui traîne quelque part !

Voila j’arrête de pourrir les commentaires avec mon SAV ! Merci de ton aide 



De rien, d’autres ont déjà répondu pour t’aider davantage, c’est ça la communauté " />

N’as-tu pas essayé de jouer avec des device tree overlays dans ton config.txt ? Beaucoup de tutoriaux proposent des lignes avec “dtoverlay=…” et sans savoir ce qu’on fait, on peut vite modifier le comportement matériel des GPIO (y compris ceux qui ne sont pas accessibles). Voici la doc dessus :&nbsphttps://github.com/raspberrypi/firmware/blob/master/boot/overlays/README



Un dernier test que tu pourrais facilement faire : reflasher une carte SD avec le dernier Raspbian et voir si le WiFi est toujours HS ;)

Le 28/09/2016 à 13h 59

Trollalalala a écrit :



Si un propriétaire de rpi3 peut me renseigner, j’ai récemment “perdu” mon interface réseau wlan0, “no device found” (autant en graphique qu’en terminal). Est-ce-que Raspian aurait un bug récent ou le chipset Wifi de mon pi aurait rendu l’âme ?! " />



La commande “dmesg” dans un terminal de ton Pi te renseignera sur la détection ou non de ton chipset WiFi ;)

S’il est détecté au démarrage mais pas présent, il est possible que ton fichier de conf soit daubé. Tiens nous au jus.

 



monpci a écrit :



chez moi (rp1) la mise a jour fait déconner la barre de menuhttp://sendvid.com/n7lx0073



Dans le commentaires du billet sur blog officiel, Simon Long en personne t’a répondu (2:29pm - veinard va ! ).

Le 10/09/2016 à 14h 48

vinceff a écrit :



tu peux en rajouter 3 chez moi :)



On serait donc à 65.





Heu… bon je vais essayer de compter :

1 Pi B original : encore tout câblé avec divers modules RF et météo (c’était le proto 01 de ma station météo qui ne verra jamais le jour :p )

2 Pi B+ : un en serveur d’impression qui tourne H24 depuis bientôt un an (et un en spare).

3 Pi A : un qui m’a servi de media center avec ses licences, deux qui m’ont servi à diverses manips et qui ont plusieurs GPIO de crâmés :s (et qui me servent de pièces de rechange quand d’autres ramassent)

2 Pi A+ : un qui est raccordé à un module caméra qui fait caméra IP lorsque je pars en vacances et un autre qui reprend le flambeau de la station météo abandonné par le Pi B original plus haut (proto 02).

2 Pi Zero : un qui va me servir à faire une caméra IP et un autre qui est déjà soudé de partout (du coup, ce serait le proto 03, il reprendrait peut-être la station météo du A+ qui lui-même doit reprendre celle du B)

1 Pi 2 : media center avec licences (ça change du A qu’il remplace :p )

1 Pi 3 : pas encore trouvé d’utilité à celui-là :) Je sens bien un serveur Web local pour alléger mon vieux Synology tout lent !



Bon, je commande beaucoup par voie pro, donc je paie rarement au prix fort ! Seuls les Pi Zero et les Pi 2 et 3 m’ont été facturés au prix fort. Dans le lot, il y en a même que j’ai pas payé.



Donc on en est à 77 en tout ici " />

Le 09/09/2016 à 16h 09

C’est pas faux, mais d’un autre côté, si tu regardes les PC ou smartphones autour de toi, combien les exploitent véritablement à fond ? ;)

Le 09/09/2016 à 14h 46

Joto a écrit :



Le Raspberry Pi… trop sur-dimensionné pour faire comme Arduino, et trop faible pour faire des trucs plus “ordinateur”…





Donc parfait pour être complémentaire avec l’un et l’autre et faire tout ce qu’on peut faire entre ces deux mondes " />

Le 09/09/2016 à 14h 23

bombo a écrit :



Je suis assez partagé sur les RaspBerry Pi personnellement. D’une, sur les 10 millions, combien prennent la poussière, inutilisés ?

De deux j'ai eu pas mal de retour mitigé sur la stabilité de ces derniers, il semble que sur une utilisation ponctuelle ils s'en sortent, mais que sur le long terme ils partent vite en couille.      

Du coup, est-ce qu'il mérite vraiment son succès ? Peut être, mais il y a aussi certainement un effet de mode qui a poussé à des achats pas forcément judicieux, IMHO.      

Est-ce que des gens ont tester les alternatives x86/x64 comme UP Board ?

Il ne faut pas oublier que les particuliers ne sont pas les seuls acheteurs de Pi. Je ne compte plus les utilisations pros autour de moi, et même si à mon taf on ne vend aucune solution avec le Pi, il est sur pas mal de bureaux car il permet de prototyper des solutions en un temps record.

Pour ce qui est de la stabilité, les seuls mauvais retours (en utilisation intensive H24) concernent la carte SD. Raspbian n’est pas vraiment fait pour épargner cette dernière et il existe des solutions pour la ménager. Mais là on commence à mettre les mains dans le cambouis, ça coûte, ça demande du savoir faire, et on se rapproche du coût des systèmes pros.



L’autre énorme avantage du Pi, après sont prix, est bien sûr sa communauté. Toujours pour mettre en oeuvre une maquette ou solution rapidement, cette communauté est inégalable en terme de contenu et de réactivité.

Le 01/09/2016 à 13h 56

linuxludo a écrit :



Pourquoi toujours à l’encontre de MS ?

Je ne vois pas pourquoi on ne pourrait pas en dire autant d'Apple avec ses MacBook ou iMac.      


Et pour nos chers smartphones, il y a également un OS préinstallé avec diverses apps...      


Jusqu'où ira la décision du CJUE...?

Sur les macs ou smartphones, il est impossible d’acheter l’OS d’origine en magasin comme un produit à part entière.

Après je suis d’accord que même sur ces machines on devrait pouvoir choisir son OS, mais à partir du moment où l’OS d’origine n’est pas un produit commercialisé à part entière, le débat ne s’applique pas (comment prouver la valeur d’un composant sans prix ou gratuit ?)

Le 16/07/2016 à 15h 20

127.0.0.1 a écrit :



Le Rapsberry Pi tourne sous Raspbian. Mais ce ne sont pas nos développements qui sont sous Rapsberry Pi: ce sont des produits développés par un partenaire et que nous vendons dans notre offre produit global. Donc j’ai pas plus d’info sur leur problèmes d’appro.



Nous on fait plutot dans les cartes custom (cortex M3 sous RTOS) et, si besoin, on ajoute une SBC x86 en front-end (Celeron sous windows embedded ou sous debian, suivant les cas).





D’acc, merci pour ta réponse " />

Le 16/07/2016 à 00h 40

zhebulonn a écrit :



Merci !

 

Ça manquait dans l’article, je trouve. Au moins un petit rappel.





De rien " />

J’ai oublié aussi de préciser que cette carte apporte le support d’un élément essentiel aux industriels : la mémoire eMMC. La carte SD du Raspberry Pi normal n’est pas un support suffisamment fiable pour de nombreuses applications industrielles. Sans parler de l’approvisionnement et de la pérennité des références (comment tester qu’une mise à jour sur des équipements déjà déployés avec des cartes SD de 5 ans fonctionnera bien si on ne peut plus en approvisionner au bureau d’études ?).

 



127.0.0.1 a écrit :



Le format Compute Module est très intéressant pour les industriels. Ca leur permet de dessiner et fabriquer leur propre PCB (= la “carte-mère” qui accueille le module) en y incluant tous les extensions/contrôleurs nécessaires. Ne leur reste qu’a plugguer le Compute Module acheté sur étagère (COTS).



Ca ouvre aussi le marché des Board/PCB préfabriquées (avec LVDS, PWM, …).



Je travaille déjà avec plusieurs produits a base RPI: Le RPI s’occupe de la partie IHM/Appli/réseau, mais il faut ajouter une carte complémentaire pour piloter du hardware (connecté au RPI via USB). Donc 2 cartes (2 alims, 2 points de fixations, une nappe usb) et un protocole USB pour que les deux cartes se parlent: pas glop.





Par curiosité, tu restes sur du Raspbian pour tes produits ou tu es sur du Buildroot ou Yocto ?

Niveau de l’appro/gestion des supports µSD c’est pas trop galère ?

A mon taf, on utilise les Rapsberry Pi qu’en tant que cartes d’évaluation pour du maquettage ou des essais rapides. Vu le prix, les DA passent sans sourciller et c’est que du bonheur niveau rapidité de mise en oeuvre.

Si le CM3 sort, on risque de ré-évaluer la possibilité de le déployer sur des applications industrielles, si le coût est compatible avec le volume de vente. Non parce que le CM actuel avec un ARM11 (BCM2835) heu.. pour des futurs produits on va éviter hein :p

Le 15/07/2016 à 15h 10

Cette carte est à intégrer dans des équipements industriels pour des applications plus sérieuses.

C’est une excellente proposition de la fondation, car les développements et le maquettage peuvent se faire sur le Raspberry Pi original, à un coût dérisoire, en parallèle de la conception de la carte définitive qui accueillera le compute module.



 Si on veut comparer à ce qui se fait chez la concurrence, on a la Sabre board chez Freescale qui coûte 20 à 30x plus, pour travailler sur du SoC i.MX.

Suivant les entreprises où on conçoit ces solutions, le circuit de la demande d’achat n’est pas le même suivant le coût, donc ça peut avoir son importance sur la rapidité de mise en oeuvre. Sans compter qu’un Raspberry Pi est très polyvalent et peut aussi être utilisé pour d’autres études de faisabilité ou maquettes, la communauté aidant beaucoup au maquettage/évaluation rapide de solutions.

 

Beaucoup d’acteurs du secteur proposent leurs solutions sur module, car le format a de solides avantages (modularité, évolutivité), mais cette solution n’est malheureusement pas convenable pour toutes les applications : contraintes mécaniques du socket et coût plus élevé qu’une carte unique suivant le volume.

Le 16/06/2016 à 13h 28

ForceRouge a écrit :



Je sais pas si ta phrase est ironique ou pas.



Si tu ne l’es pas, trouve moi un site ou il est dispo à moins de 5 fois le prix public conseillé…



A part les N centaines / milliers de pi zero distribué avec ce fameu magasine, le reste c’est du bluf. Le seul moyen de l’avoir, c’est ebay avec un prix complètement démentiel.





J’en suis à mon 5ème Pi Zero acheté à son prix normal chez Pi Hut et Pimoroni (seuls 2 sont pour moi hein, je vous rassure).

 

Alors oui, il y a un déficit de l’offre par rapport à la demande, mais c’est pas impossible.

Il suffi de s’inscrire pour être notifié sur ces deux sites et tu seras prévenu à temps pour faire chauffer la CB.



A noter que depuis le lancement de la dernière version du Pi Zero, ils ont augmenté la cadence de production pour atteindre 50.000 unités par mois. L’usine de Sony a implémenté un test automatisé qui améliore la cadence (et réduit la main d’oeuvre). Ces détails sont d’Eben Upton en personne sur le forum :

https://www.raspberrypi.org/forums/viewtopic.php?f=63&t=144165



Maintenant, toutes les semaines Pimoroni et Pi Hut ont régulièrement du stock qui prend de plus en plus de temps à s’épuiser (bon, faut pas rêver, ça passe encore pas la journée hein).



Lorsque la demande aura atteint un niveau normal, la limitation à un Pi Zero par commande sera retirée de ces sites.

Le 16/06/2016 à 13h 12

Ricard a écrit :



Farnell ne produit PAS le RPi… " />









Ricard a écrit :



Oui merci je l’ai lu aussi. Ca ne change en rien le fait que Farnell n’a pas d’usine, ne fabrique pas et sous-traite seulempent  la fabrication. Farnell n’est qu’un intermédiaire (parasite) sur lequel la fondation RPi s’est appuyé au début (chacun son taf).



 





Tu as tout à fait raison de souligner ce point, à savoir que Farnell ne fabrique pas puisque l’usine appartient à Sony. Par contre, si on doit être pointilleux, je ne serais pas aussi catégorique sur l’emploi du verbe “produire” (ton premier post) qui a un sens plus large et qui pourrait, lui, convenir.



Après, selon moi, c’est un abus de langage qui est d’autant plus facilement excusable que beaucoup de fabricants d’équipements ne le sont pas car ils font sous-traiter tout ou partie de leur fabrication, mais c’est un autre débat.

Le 16/06/2016 à 12h 12

CryoGen a écrit :



Merci pour le complément " /> et surtout la précision coté “fabricant” qui manque dans la news…









bogomips a écrit :



" />

 Merci pour le complément d’information.





Mais de rien " />

Je ne sais par contre absolument rien du circuit de distribution de la version “Made in RPC” des différents Raspberry Pi. Je ne sais pas du tout si c’est Farnell ou RS. La fondation elle-même communique peu sur ce circuit de distribution via leur blog.

Le 16/06/2016 à 09h 51

bogomips a écrit :



Je ne savais pas non plus que c’était Farnell qui produisait le Pi même si ça fait au moins 15 ans que j’ai rien commandé chez eux…

Au passage je préfère Radiospares pour les particuliers les frais de port sont gratos le week end…

La fondation Raspberry Pi sous-traite la fabrication de son SBC à Farnell et RS, qui eux-mêmes, font fabriquer par l'usine de Sony aux Wales (Pencoed).     

 

Farnell et RS sont les deux fabricants et distributeurs officiels de la fondation, en ce qui concerne le Rapsberry Pi 1, 2 et 3, toutes versions confondues.

 

Le Raspberry Pi Zero a un statut particulier : la fondation fait fabriquer elle-même la carte par l’usine de Sony. J’imagine que la trop faible marge de cette carte nécessite de se passer d’intermédiaire, mais complexifie l’approvisionnement des composants et la distribution/logistique (métiers historiques de Farnell et RS), d’où les couacs qu’on connaît concernant la dispo du Pi zero.



Ensuite, je parle de la fondation Raspberry Pi ( = assoc’ à but non lucratif), mais l’entité qui s’occupe de ça est plutôt la Raspberry Pi Trading limited (= entreprise :https://companycheck.co.uk/company/08207441/RASPBERRY-PI-TRADING-LIMITED/summary…

Le 23/05/2016 à 12h 53

Je comprends ce que tu veux dire, mais j’ai absolument pas l’impression qu’un quelconque fabricant prenne en compte ses entrées de gamme ou vieux smartphones dans ses choix d’évolutions logicielles.

 

Dans le cas d’Android, ça devient paradoxalement un inconvénient d’être mis à jour, car à un moment, beaucoup de vieux smartphones continuent de recevoir des mises à jour de composants/applications à en devenir lents et inutilisables ! Les utilisateurs se retrouvent poussés à changer leur terminal au final (pourtant chaque mise à jour logicielle promet perfs et autonomie en hausse ^^).

Et c’est à ce moment - stratégique - que suivant l’expérience utilisateur du mobile, l’acquéreur repartira sur la même marque ou non.



De mon expérience perso (entourage), pour ce qu’elle vaut : absolument, rigoureusement, TOUS les utilisateurs de smartphones entrée de gamme, qui se retrouvent déçus à plus ou moins court terme, changent de fabricant ou au moins de gamme ! Le nombre de fois où j’ai entendu “Android c’est de la m#&de, IOS c’est bien mieux” alors qu’ils sont passés d’un Wiko à 80€ à un iPhone 10x plus cher… Idem pour du Windows Phone, alors que les flagships sur cet OS ont toutes les qualités requises pour en faire un terminal de choix.



Toujours suivant mon expérience perso (entourage), si l’utilisateur vient d’un smartphone haut de gamme, quel que soit le fabricant/l’éditeur de l’OS, alors le piège se referme : les habitudes sont prises, vu que les perfs et le support permettent une expérience digne de ce nom sur le moyen/long terme, et lorsque le smartphone n’est plus supporté, le remplacement se fait dans la même crèmerie (en dépit de la dégradation de cette dernière par moments).

Le 23/05/2016 à 10h 36

warenbe a écrit :



Et moi qui me disais que j’allais surement arrêter d’acheter des smartphone Microsoft vu les problèmes sur les 950 et 950 XL (si si, il y a ENCORE des reboots journaliers, contrairement à ce que certains voudraient mefaire croire…)…



Si Apple fait de la merde, que Microsoft fait de la merde, et qu’Android souffre d’une fragmentation délirante avec enormement de téléphones bas de gamme, que reste t il ?



Qui fait encore du haut de gamme QUI MARCHE finalement ?





Je ne dis pas qu’Android ne souffre pas de défauts, mais ton argumentation le concernant n’est pas logique. Tu demandes un haut de gamme qui marche et tu évoques que l’OS de Google tourne sur énormément de bas de gamme  ?!?

En quoi ça empêche d’avoir des haut de gamme de qualité ?

Ca gêne tant que ça les utilisateurs de la marque à la pomme que les OS concurrents fonctionnent avec du matos modeste et qu’il y en ait pour toutes les bourses ?



A part ça l’argument de la fragmentation sous Android est encore et encore une fois incomparable avec IOS. J’ai mon Nexus 4 depuis sa sortie (fin 2012) et le fait qu’il soit sous Lollipop ne m’empêche en rien d’avoir le dernier Play Store, Gmail, Maps, Chrome et certains composants/applications de l’OS qui continuent à recevoir des mises à jour.

Donc il y a fragmentation, oui, mais quel INpact pour l’utilisateur final lambda, à part ne pas voir la dernière version dans le menu paramètres ?

Le 17/05/2016 à 17h 45

KP2 a écrit :



La derniere version de la cam officielle monte a 60fps en 720p. Et il y a d’autres cam non officielles (mais tout aussi fonctionnelles) qui font bien mieux, avec un mode nuit, etc





La V2 est “rabaissée” à la V1 niveau support, mais la V2 est techniquement capable de faire du 1080p à 120fps, du 720 à 180fps et du QHD à 240fps ! http://www.sony.net/Products/SC-HP/new_pro/april_2014/imx219_e.html))

 

Si j’ai toute confiance au lien direct Camera <-> GPU, je pense qu’il pourrait y avoir comme un souci de bande passante qui limitera le support soft.

Le 17/05/2016 à 17h 39

kj a écrit :



L’autre défaut (pour moi) c’est la limite du framerate à 30fps, me faudrait mini 60fps pour que ça vaille la peine pour un drone. 





Tout dépend de la définition que tu souhaites garder. 30fps, c’est le maximum pour du 1080p. En 720p tu as 60fps max et ça va jusqu’à 90fps en 480p !  (données valables même pour le module V1, le V2 pourrait faire mieux mais ça viendra je suppose).

Après, reste le souci du transport de cette vidéo, car pour faire du vol en immersion avec un drone, il faut du débit et peu/pas de latence, c’est un tout autre problème ;)

Le 17/05/2016 à 16h 06

Attention la qualité n’est pas exceptionnelle non plus. Très bien pour de la surveillance ou de la robotique ludique, mais n’importe quel smartphone moyen de gamme actuel fait mieux.

Il y a une amélioration notable niveau qualité sur le nouveau module caméra, mais il y a surtout ce qu’on peut considérer comme un défaut au niveau du réglage de la focale (fixe) qui rendrait flou sur ce qui est éloigné.

Le 17/05/2016 à 16h 01

C’est plus que probable en effet ! Surtout que les premiers témoignages arrivent et effectivement, il n’y a pas de câble.

Il n’y a plus qu’à attendre l’offre qui va bien sur ebay, car 4£ + 4£ de livraison ça pique un peu pour un bout de nappe. C’est pas par gaieté de coeur que je vais me fournir sur eBay ce genre d’accessoires, mais vu le prix pratiqué, il y a clairement abus.

Déjà, le premier Rpi Zero commandé chez Pi Hut avait 2.5£ de frais de port, mais là 4£ alors qu’il s’agit d’une enveloppe standard :/ (un avantage du Rpi Zero d’ailleurs)

Le 17/05/2016 à 14h 56

Si on en croit la citation du blog :

"To connect the camera to the Zero, we offer a custom six-inch adapter cable. This converts from the fine-pitch connector format to the coarser pitch used by the camera board"      


Il pourrait y avoir un câble adaptateur fourni, mais c'est ambigu. Les sites des revendeurs ne mentionnent rien de concret de ce côté, donc le suspens demeure en attendant de recevoir les premiers modèles.      

Sinon, avec mes Rpis, j'expérimente en grande partie (d'ailleurs certains sont un peu abîmés). Parmi les plus "stables", j'ai un classique 2B sous OpenElec en lecteur multimédia, un B+ en serveur d'impression et un A+ avec son module caméra en camera IP de surveillance.

Le 06/04/2016 à 14h 25

Ca étonne tout le monde ? Le “problème” avec les formats ouverts, c’est que rien n’empêche la concurrence (quelle qu’elle soit) de proposer une alternative. C’est totalement contraire au principe des éditeurs de logiciels fermés qui cherchent justement à verrouiller le marché en leur faveur.

Le 11/07/2015 à 16h 29

Patch a écrit :



Comment on fait pour passer une vitesse sur une boîte à variation continue, en dehors de l’augmentation du frein moteur et de la marche arrière? " />





Théoriquement, une boîte CVT a une infinité de rapports, car passer d’un rapport a un autre consiste simplement à déplacer la courroie qui lie les deux cylindres. Seulement voilà : les contrôleurs de ces boîtes ont plusieurs positions prédéfinies de courroie, ce qui fait qu’il y a bien plusieurs rapports dans la pratique.



D’ailleurs avec Mazda, ils ajoutent un embrayage. On peut se dire que ça enlève un des principaux avantages de la boîte CVT qui est le passage progressif sans rupture d’un rapport à l’autre (d’une position de la courroie à une autre), mais rajouter un embrayage permet de déplacer cette courroie bien plus rapidement que sous contrainte. L’avantage, c’est donc pour baisser plusieurs rapports rapidement en une fois (un kick-down) pour gagner en couple et reprise, et seul un embrayage permet de désolidariser la boîte.

Le 09/07/2015 à 19h 12

Fuinril a écrit :



 Mouais, sans chercher loin, je suis rentré du Maroc il y a peu. Des taxis BM/Mercedes hors d’âge avec bien plus de 250k km ça court les rues (j’ai vu 850 sur un compteur…).

 

Les Renault et les Peugeot sont des voitures (presque) neuves - mais visiblement la Logan a nettement plus percé sur ce créneau - jamais des anciennes.





J’avais bien en tête l’Afrique du nord " />

Sans parler de 205, j’y ai vu des 504 et plus rarement des 505 ayant atteints le million de km, mais là on parle aussi de voitures d’un autre âge " />

Au fait, c’est pas au Maroc que les Duster sont vendus avec la marque Renault ?

Le 09/07/2015 à 19h 09

mtaapc a écrit :



C’est pas un pléonasme moisi et italien ? " />

 



Me souviens d’un dicton ! les italiens capables du pire comme du meilleur : Fiat et Ferrari





LOL le pléonasme " />

Blague à part, ils ne sont pas pires que d’autres, tout est question de catégorie/gamme et donc de prix, comme chez tous les constructeurs. Certains modèles bénéficient d’une attention particulière qui en fait de bons modèles et d’autres sont simplement négligés voire ratés.

Comme tous les autres constructeurs dits “généralistes” on peut trouver leurs véhicules moins solides, moins fiables, avec des aléas de finition, mais le prix va avec, y compris celui de l’entretien et des réparations.

Quand j’entends des comparaisons de BMW avec Renault par exemple, ça me fait souvent bondir : c’est pas la même gamme.

Le 09/07/2015 à 15h 09

Précise quel(s) “moteur moisi italien” pète tout seul ? Si tu parles des moteurs modernes à vocation sportive (ce qui m’étonnerais car Lancia ont les mêmes) ils n’ont pas vraiment mauvaise réputation. Le répandu 1.4l qu’on retrouve un peu partout dans le groupe est parfaitement solide et fiable. Je ne parle même pas de ses prédécesseurs blocs Fire qui sont increvables (conçus pour ne pas casser en cas de rupture de distrib).

Les seuls soucis connus autour de moi avec des moteurs italiens concernaient le mazout 1.9l bi-turbo, mais étrangement, l’autre bi-turbo dans mon entourage, d’une autre marque, a aussi que des soucis.

S’il y a bien une filiale du groupe italien qui n’est pas à critiquer, c’est bien FPT.

Le 09/07/2015 à 13h 13

L’électronique dans nos voitures modernes a permis de rajouter sécurité, efficacité et confort. Le tout accompagné de progrès conséquents en mécanique (qu’il faut pas oublier). Je préfère largement l’automobile actuelle à celle de nos aïeux.

De temps en temps il y a quelques bugs ou anomalies, dont certains peuvent coûter cher, certes, mais globalement je vais voir mon concessionnaire pour un entretien tous les 2 ans ou 30.000 km (préconisation constructeur) ce qui fait qu’au final le budget n’est pas énorme au regard de tout l’équipement et le confort que ma voiture m’apporte. Pour la clim, 10 minutes par semaine a peu d’INpact sur la conso globale, et je n’ai jamais eu à la recharger en 4 ans sur ma précédente voiture (recharge obligatoire avec le changement de mon compresseur suite à un accident, sinon la clim marchait parfaitement).

Le 09/07/2015 à 12h 57

brazomyna a écrit :



Un cas particulier ne fait pas une généralité. Mais un bon indicateur (empirique mais plus généraliste) est par exemple de constater (genre sur leboncoin) le nombre de bmw avec 250 000 km et le nombre de peugeot, renault, etc…





S’il y a des BMW (ou Audi, Mercedes, etc…) sur leboncoin avec autant de kilomètres, ça veut d’abord dire que c’est parce qu’il y en a qui sont prêts à les acheter à ce kilométrage.

Ce n’est pas un indicateur de fiabilité en soi, l’affirmer serait faire un lien qu’il faudrait alors justifier par une preuve.

Il faudrait savoir combien de BMW (pour reprendre ton exemple) d’une même génération arrivent jusqu’à 250 000km, comparé aux autres marques.

 

Pour info, nombre de véhicules “généralistes” (Peugeot, Renault pour reprendre tes exemples) qu’on accepterait pas sur leboncoin ont une bonne seconde vie une fois exportés, et atteignent souvent bien plus que 250 000km.

 

Le 01/07/2015 à 14h 57

Le sujet est vaste, pour parler de syntaxe pure, on pourrait évoquer l’héritage (sans jeu de mots) direct du C : le “-> / .”, l’opérateur “&” qui a 2 utilisations différentes (adresse/référence), la déclaration/définition dans 2 fichiers différents (ça a des avantages et des inconvénients), etc…

Si on prend la syntaxe du C++ elle-même, je trouve qu’elle peut devenir sacrément indigeste lors de l’utilisation de choses pourtant essentielles comme les templates, les itérateurs de la STL, les design patterns et autres joyeusetés.

La liste est longue, et au final ça fait paraître le C++ comme une surcouche objet au C (un rajout disgracieux). Ca peut passer pour un avantage car ça permet de bénéficier de la puissance du C (bas niveau, pointeurs) en faisant de l’objet, mais dans la pratique, le gros inconvénient, c’est qu’on fait souvent du C++ comme on fait du C. Pour parler syntaxe, il n’y qu’à voir, par exemple, l’utilisation de for_each en C++ pour comprendre que beaucoup utilisent encore la simple boucle for académique. Là aussi les exemples sont nombreux.

 

Il me semble que le langage D ou Vala ont pour ambition de combler ces lacunes, mais je n’ai jamais encore vu des projets mettant en oeuvre ces langages.

Le 30/06/2015 à 16h 18

Isshun a écrit :



C11 à beau être récent le C et surtout le C++ accuse quand même une lourde dette technique, je pense particulièrement à l’horreur qu’est le multi-threading que ce soit avec c++11 ou boost, ou bien l’utilisations des lambda qui est assez lourdes.

La gestion manuelle de la mémoire est également un reliquat, le GC c'est un coup fixe, donc plus les performances des machines augmentes moins ce coup est important, sur les PC actuel ce coup est négligable (il suffit de lancer VisualVM et de monitorer l'utilisation CPU du GC pour s'en convaincre), même dans le mobile ont commence à s'en fiche, il ne reste que l'embarqué où cela importe.      

Java à lui aussi un certain age mais il pars de moins loin, donc il est un peu plus raccord avec les technologies récente, ne serait-ce que syntaxiquement, le fait qu'il soit managé aussi lui à permit d'intégrer de nouveaux paradigmes bien plus facilement. mais il reste moins élégant que le C# (et c'est un dev java qui parle )

Spa faux, le C++ fait pas propre sur bien des tableaux, à commencer par la syntaxe. Pour ce langage à mi-chemin entre le bas et le haut niveau, la question de savoir s’il est obsolète peut peut-être se poser (car au final, vieux ou récent, je pense que c’est surtout l’obsolescence dont il est question), mais c’est pas le débat initié.

 

Pour revenir au C, tu as bien fait de citer l’embarqué, et je rajouterai la programmation système dans sa globalité, où il est toujours parfaitement d’actualité et irremplaçable, car simplement plus bas niveau.

Effectivement, pour une application avec de nombreuses fonctionnalités utilisateur (interface utilisateur, BDD, réseau, etc…) il faut vraiment en vouloir pour tout se taper en C (même si ça reste faisable). Là effectivement les langages de haut niveau prendront bien plus agréablement le relais.

Il n’est pas question de “modernité ou ancienneté des technologies”, juste de contexte et de cible.

Le 30/06/2015 à 13h 06

gokudomatic a écrit :



Oui, c’était ton propos. Et ma réponse était : on s’en fout. C ne rajeunit pas juste parce qu’il est encore maintenu. Il date de 1972, il est donc des années 70. Insinuerais-tu que ce qui est vieux doit être jeté? J’espère que non.





Mais où as tu eu le début de semblant d’impression de t’imaginer que j’aurais pu insinuer une telle chose ?

Je ne sais pas comment tu interprètes mes posts, mais soit tu as un sérieux souci de compréhension, soit j’ai un sérieux souci d’expression. Je veux bien admettre la seconde hypothèse, alors j’essaie de reformuler :

 

Toi : “Le C est une vieille technologie qui date des années 70”

Moi : “Heu non… ton Java adoré fonctionne avec :)”

(====> Note : donc c’est une technologie encore bien d’actualité !!!)

 

Ensuite, si je peux me permettre une petite précision, le C tel qu’utilisé actuellement n’est pas le C des années 70. Il y a eu l’ANSI C89/90, C95, C99 et dernièrement C11.

Donc on peut dire que le C actuel est une technologie de 2011.

(Je sais pas pour toi, mais moi, même à l’école, je n’ai jamais codé en K&R C tel qu’utilisé jusqu’à la fin des 70’s)



Si on suit le même raisonnement, ça fait aussi de Java une vieille technologie, car datant des années 90.

Si on étend le raisonnement à d’autres domaines, l’automobile et l’aéronautique sont des technologies ancestrales du siècle dernier.

Le 30/06/2015 à 11h 38

Si je t’ai posé la question, c’est parce que tu insinuais qu’un certain langage parfaitement d’actualité était une “technologie des 70’s”.

 

Donc bon. Sans C, pas de Java, ni le reste de tes technologies bien actuelles, c’était le propos.

Le 30/06/2015 à 09h 51

Parce que tu crois que ton Java est fait avec quoi ?

Le 28/06/2015 à 22h 06

Avoir une argumentation avec des sources, c’est bien, et tout le mérite t’en revient.

Mais tu m’excuseras, j’espère, de ne pas forcément suivre une argumentation parfaitement orientée comme celle que tu présentes, avec une incohérence de taille qui plus est (comparaison des temps de codage open/closed source mentionnée dans mon précédent post), en minimisant bien (trop) facilement le travail des concurrents.



La fin de mon précédent post n’était pas anodine. Si tu veux te lancer dans un comparatif des coûts de développement des différents principaux OS actuels VS Windows, tu peux, mais ça demandera un travail tout autre que celui que tu as fourni.

 

Le monde des partenariats dans l’industrie du logiciel (nécessaires pour développer de tels OS) est une nécessité vitale, dont l’opacité évidente rendrait l’investigation journalistique particulièrement ardue.

Tous ceux qui ont côtoyés de près ou de loin ces acteurs dans le monde de la presta savent de quoi je parle.

 

MS n’aurait jamais sorti NT sans IBM. les développements de Win RT ainsi que les précédentes versions de CE ou Mobile n’auraient jamais pu se faire sans travaux conjoints chez certains partenaires comme Freescale, Intel, Samsung ou d’autres fabricants. Idem pour DirectX qui n’aurait jamais pu se développer sans coopération étroite des principaux concernés. On pourrait également citer le monde des serveurs ou clusters.

La liste peut être longue, les références sur le web se trouvent facilement et les exemples ne manquent pas.



Ce qu’il faut en retenir, c’est que de ces partenariats, il en résulte des coûts de développement qui se retrouvent fatalement répartis à un échelle qui serait plutôt compliquée à définir, pour des raisons évidentes.

S’imaginer que MS (ou un autre) pourrait assumer seul de tels développements et non seulement irréaliste, mais surtout juste simplement impossible techniquement.

 

Donc pour reprendre la fin de ton post : tu nous reproches de rester sur nos certitudes, mais le seul qui semble en avoir une coriace et inébranlable ici, c’est bien toi en maintenant que MS est le seul à (je cite) “continuer de maintenir entièrement tous les rouages d’un OS de la tête aux pieds”.

Le 27/06/2015 à 17h 30

En lisant ton commentaire, tu minimises clairement la participation aux projets open-source des concurrents de MS, et donc l’investissement que cela représente.

De plus, Apple ou Google ne se contentent pas de reprendre les briques de distros en les personnalisant, comme le font Redhat ou Ubuntu avec un GNU/Linux, en créant leurs distros.

 

Pour reprendre tes composants d’un OS, même si tu as prévenu que la liste était simplifiée, il y a une très importante quantité de travail qui n’y est pas représentée : les API systèmes, propres à chaque OS.

Déjà sans parler d’API, même la libc n’est pas la GNU/libc chez les deux concurrents.

 

Parmi les éléments de ta liste, les “pilotes génériques” ne sont pas à confondre avec les pilotes intégrés à l’OS, qui sont bien l’oeuvre de constructeurs. Les seuls vrais pilotes génériques ne sont pas nombreux (comme l’USB avec tous ses modes, par exemple).

 

Toujours dans ta liste, un important élément : le serveur graphique. Je ne vois pas en quoi Google et Apple ont moins investis que MS. Google utilise sa propre solution et Apple n’a pas toujours utilisé X.org.

 

Ce ne sont que quelques exemples. Le fait est qu’effectivement, MS fait bande à part, là où certains mutualisent une partie de leur investissement. Mais la vraie question est de savoir quelle quantité de travail dans chaque OS respectifs, incombe vraiment à chaque éditeur. Et je ne pense pas que MS ait une charge disproportionnée face aux autres, d’autant que l’éditeur se repose bien plus que tu ne sembles le croire sur des partenaires pour développer les composants de son OS (seulement, ce n’est pas dans le cadre communautaire de l’open-source, mais de partenariats bien ficelés).

 

 Tu compares dans un post suivant de nombreux chiffres, qui reviennent à comparer des coûts de développement open-source vs des coûts de développement closed-source de chez MS. Il aurait fallu comparer les coûts closed-source des différents protagonistes et concurrents actuels pour que la comparaison soit pertinente (bon courage pour y arriver).

Le 26/06/2015 à 22h 41

Bon, déjà, le noyau de Windows NT a été conçu conjointement avec IBM, même si l’immense majorité du taf revien(drai)t à MS.

Mais revenons sur ton argumentation visant à tenter de justifier le prix de l’OS, car ayant été développé  de A à Z chez MS.

Tu oublies une chose très importante : OS est différent de noyau.

La conception du noyau d’OSX (ou d’IOS, ou d’Android, ou d’autres OS payants basés sur des noyaux libres), a beau avoir été répartie davantage que celui de NT, il ne représente qu’une petite partie de l’OS.

Apple ou Google ont bien (ré)écrits tout l’écosystème qui gravite autour des noyaux repris (API, librairies, services, interface utilisateur, etc…), pour en faire leur OS à part entière. Je ne pense pas que la quantité de travail fournie par MS soit suffisamment différente pour représenter un tel écart de prix.

 

Non, MS, c’est du soft à coups de licences à l’ancienne (celle-là qui brille sur le côté du PC) et ça DOIT se voir.

L’entreprise sait pertinemment que personne ou presque n’achète son OS en version boîte étant donné que si tu as un PC, tu as déjà son OS. Donc le prix qu’il affiche est juste pour donner aux utilisateurs une valeur marketting/psychologique à son produit. Et ils ne veulent pas brader (ça peut se comprendre vu leur stratégie).

 

Apple eux, savent que leurs clients ont une valeur marketting/psychologique globale par rapport à leurs produits. L’OS n’étant pas l’élément mis en valeur (il n’y a qu’à voir leurs pubs), inutile d’en afficher le prix qui n’a aucune importance.

 

Google eux, c’est totalement différent : c’est pas de la licence, c’est pas du matériel. Leur stratégie, c’est du service et de la collecte de données. Le client paye l’OS et son développement sans même s’en rendre compte, en l’utilisant.

Le 02/02/2015 à 16h 06

Heu… c’est totalement faux tout ça !



Déjà, les composants du premier Rpi sont toujours produits car le SoC BCM2835 est le même dans les A, A+ et B, B+ actuels.



Ensuite, à la sortie de chaque modèle, la fondation précise que tant qu’il y aura de la demande, les modèles seront fabriqués. La sortie du Rpi 2 ne déroge pas  à la règle :

Are you discontinuing the Raspberry Pi 1 Model B and B+?No. We have a lot of industrial customers who will want to stick with Raspberry Pi 1 for the time being. We’ll keep building Raspberry Pi 1 Model B and Model B+ as long as there’s demand for it. Both these boards will continue to sell for $35.

Source :http://www.raspberrypi.org/raspberry-pi-2-on-sale/



On est pas dans de la production one-shot de cartes chinoises grand public là, on est sur des composants industriels et tant qu’il y a de la demande, il y a de l’appro.