Là, tu racontes n'importe quoi, quand tu règles EXT3 (et 4) pour journaliser les données, tu ne tombes à pas à 100 io/s.
"Ou au moins aussi lentement que pour une base de données quand elle assure la même chose."
Je ne considère pas qu'un fsync() assure quoique ce soit, il demande une écriture en urgence qui tue beaucoup les performances, alors que bloquer (fdone()) jusqu'à une écriture effective, rendra exactement le même service mais avec de bien plus grande performance globales.
I2C est trop simple et demande beaucoup de CPU pour être gérer : la réception du message à mettre en mémoire, n'est pas faite par un DMA.
Si tu as une application avec plein de capteurs et un µp de gestion, tu as une floppé de bus qui converge vers ce µP. Sans gestion automatique, le cpu va passer son temps à gérer ses bus, ce qui est complètement con.
Dans une application robotique, tu lis tes capteurs 100 fois par seconde, ce n'est pas événementiel du tout. Tu as donc des trames prévisibles à gérer. Faire ça en I2C demande du soft et beaucoup de temps cpu.
De plus, il me semble que la version à 3.4Mhz a du mal avec le multipoint. Quitte à faire un bus IO avec un vrai espace d'adressage sur un seul bit, autant faire en sorte que sa distribution en étoile soit possible (genre clock + data, un dans chaque sens, (4fils) + 2*4 pour une distribution en étoile = 12 fils).
Disons que j'avais en tête, le fait que le fonctionnement de fsync() est monstrueusement stupide (90% du temps on voudrait un fdone()), et que la garantie d'écriture avec de bonne performance est assuré par les FS depuis longtemps (avec un journal ou par "soft update"). Le problème est que les FS protège surtout leurs métadonnées, car ils ne peuvent pas vraiment connaitre la taille du grain que l'on veux réellement écrire sur disque (ou à oublier complètement).
Je demande d'ailleurs si un système de fichier moderne, si il garantie qu'un write() (et non un fwrite()) est garanti d'être écrit complètement ou pas du tout, en interdisant toute écriture partielle.
Pour le cas d'écriture aléatoire sur disque, cela veut dire l'écriture de ligne très différente, on peut imaginer des structures de données, ou elles sont tout de même écrites de façon séquentiel par bloc.
On peut imaginez un format de coque comme pour le format ATX.
Ensuite, on peut définir une taille d'écran, une fois la guerre des tailles fini, il va rester 3 ou 4 tailles différentes.
Ensuite, il faut définir le facteur de forme de l'électronique (avec port µusb, SIM et SD), de l'écran, et de la batterie. Mais je ne pense pas que l'on puisse moduler le bloc électronique.
Hello, est-ce qu'il existe un base nosql qui s'embarque de la même façon que sqlite ? Un truc qui garanti l'intégrité du fichier, mais dont on se fout un peu du coté "ACID" ?
C'est histoire de dépasser les 100 transactions par seconde.
Le principe de faire des légo avec des ordinateurs posent toujours le même problème : les connecteurs coutent plus chère que les puces. Plus, c'est rapide, plus c'est chère. Thunderbolt peut changer les choses mais, il y aura toujours le problème de la consommation.
Par contre, il peut toujours définir des standards d’interconnexion comme USB ou I2C, voir un standard logiciel BIOS (comme Arduino).
Pour l'embarqué très petit, je trouve qu'il manque un bus type I2C avec du débit mais avec un grand espace d'adressage, mono master et avec DMA. L'idée est d'avoir un µP dont des zones mémoire, se mette à jour régulièrement par DMA, sans surcout CPU de communication, mais plus simple que les CAN, et autre I2C.
Chez moi, cela rame beaucoup moins en plein écran (gpu intel), et cela rame plus(+) si la vidéo embarqué n'est pas visible en entier sur la page, comme si le fait de tronquer lui faisait faire du travail en plus.
J'ai aussi un netbook (EEE) de dev, Atom avec 2 Go de RAM et SSD intel. La machine est hyper véloce, sauf pour lire les vidéos youtube qui ne sont pas en pleine écran, et le navigateur rame un peu.
Peut être que cela va mieux avec les atom bi-coeur.
C'est pas un netbook que tu veux ? Genre un truc pas chère à base d'atom qui fait 10 ou 11 pouce. Pour avoir plus rapide, et la même autonomie, il faut ensuite taper dans l'ultrabook, mais c'est 2.5x plus chère.
Non mais en touchant au drivers de base comme la RTC ou celle des gestion de la mémoire (drivers plateforme), il n'y a pas plus interne au noyau.
L'embarqué va plus loin que l'ajout de drivers, il y a pas mal de bidouille. Par exemple, Sony utilisait le suspend to disk, pour avoir un boot ultra rapide en utilisant une 1er image propre mais toujours la même sur ses cameras.
"il est par exemple expliqué que la NSA dépense chaque année 250 millions de dollars pour travailler avec les entreprises du high tech et "influencer secrètement" la conception de leurs logiciels… sans doute en les poussant à installer des portes dérobées, en espionnant leur développement ou en les piratant."
Il y a infiniment plus de monde qui joue avec le code de Linux qu'avec le code de Windows. Par exemple dans le monde de l'embarqué, énormément de code est écrit pour supporter tous les matériels bas niveau. Linux est partout dans ce monde : appareil photo, télévision, caméscope, "box", lecteur BR, Androïd, système de loisir d'avion, etc…
C'est beaucoup beaucoup plus de monde que pour Windows.
Le problème de tous ses TPM, c'est toujours de savoir qui contrôle les clefs.
Dans le trust computing, les master clefs étaient géré par une instance extérieur, un peu comme si quelqu'un d'autre d'inconnu avait les clefs de chez vous.
Si les clefs sont contrôlé à l'installation, par l'utilisateur uniquement, c'est au contraire une téchno utile.
[^] # Re: nosql embarqué ?
Posté par Nicolas Boulay (site web personnel) . En réponse à la dépêche SQLite 3.8.0 : n'ayez pas peur du zéro. Évalué à 2.
Là, tu racontes n'importe quoi, quand tu règles EXT3 (et 4) pour journaliser les données, tu ne tombes à pas à 100 io/s.
"Ou au moins aussi lentement que pour une base de données quand elle assure la même chose."
Je ne considère pas qu'un fsync() assure quoique ce soit, il demande une écriture en urgence qui tue beaucoup les performances, alors que bloquer (fdone()) jusqu'à une écriture effective, rendra exactement le même service mais avec de bien plus grande performance globales.
"La première sécurité est la liberté"
[^] # Re: quelques remarques
Posté par Nicolas Boulay (site web personnel) . En réponse à la dépêche Je crée mon jeu vidéo E01 : les systèmes à entités. Évalué à 2.
Comment tu fais un arbre d'entité ? Est-ce que des entités peuvent être référencé dans les composantes ?
"La première sécurité est la liberté"
[^] # Re: netbook ?
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Une tablette pour programmer. Évalué à 3.
L'XPS 13 a une dalle brillante, c'est pour moi inutilisable en extérieur, ce qui est un comble pour un ultraportable.
Le E… a une autonomie pas top de mémoire.
"La première sécurité est la liberté"
[^] # Re: oui mais non
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Un smartphone fait de pièces standardes pour lutter contre le gâchis écologique. Évalué à 2.
I2C est trop simple et demande beaucoup de CPU pour être gérer : la réception du message à mettre en mémoire, n'est pas faite par un DMA.
Si tu as une application avec plein de capteurs et un µp de gestion, tu as une floppé de bus qui converge vers ce µP. Sans gestion automatique, le cpu va passer son temps à gérer ses bus, ce qui est complètement con.
Dans une application robotique, tu lis tes capteurs 100 fois par seconde, ce n'est pas événementiel du tout. Tu as donc des trames prévisibles à gérer. Faire ça en I2C demande du soft et beaucoup de temps cpu.
De plus, il me semble que la version à 3.4Mhz a du mal avec le multipoint. Quitte à faire un bus IO avec un vrai espace d'adressage sur un seul bit, autant faire en sorte que sa distribution en étoile soit possible (genre clock + data, un dans chaque sens, (4fils) + 2*4 pour une distribution en étoile = 12 fils).
"La première sécurité est la liberté"
[^] # Re: pas dans le sens du vent
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Un smartphone fait de pièces standardes pour lutter contre le gâchis écologique. Évalué à 2.
Le pop se fait pour la mémoire, le reste se fait sur le même die.
Chez TI, ils ont eu beaucoup de mal à mettre la partie RF de la radio sur le die numérique. Je ne sais pas si ils ont réussi.
"La première sécurité est la liberté"
[^] # Re: nosql embarqué ?
Posté par Nicolas Boulay (site web personnel) . En réponse à la dépêche SQLite 3.8.0 : n'ayez pas peur du zéro. Évalué à 2.
Tu pourrais être plus précis ? Pour la base de donnée, je n'y connais pas grand chose, mais ce n'est pas du tout le cas des système de fichiers.
"La première sécurité est la liberté"
[^] # Re: nosql embarqué ?
Posté par Nicolas Boulay (site web personnel) . En réponse à la dépêche SQLite 3.8.0 : n'ayez pas peur du zéro. Évalué à 2.
"select" SQL, pas le select() posix.
"La première sécurité est la liberté"
[^] # Re: nosql embarqué ?
Posté par Nicolas Boulay (site web personnel) . En réponse à la dépêche SQLite 3.8.0 : n'ayez pas peur du zéro. Évalué à 1.
C'est pas faux.
Disons que j'avais en tête, le fait que le fonctionnement de fsync() est monstrueusement stupide (90% du temps on voudrait un fdone()), et que la garantie d'écriture avec de bonne performance est assuré par les FS depuis longtemps (avec un journal ou par "soft update"). Le problème est que les FS protège surtout leurs métadonnées, car ils ne peuvent pas vraiment connaitre la taille du grain que l'on veux réellement écrire sur disque (ou à oublier complètement).
Je demande d'ailleurs si un système de fichier moderne, si il garantie qu'un write() (et non un fwrite()) est garanti d'être écrit complètement ou pas du tout, en interdisant toute écriture partielle.
Pour le cas d'écriture aléatoire sur disque, cela veut dire l'écriture de ligne très différente, on peut imaginer des structures de données, ou elles sont tout de même écrites de façon séquentiel par bloc.
"La première sécurité est la liberté"
[^] # Re: nosql embarqué ?
Posté par Nicolas Boulay (site web personnel) . En réponse à la dépêche SQLite 3.8.0 : n'ayez pas peur du zéro. Évalué à 2.
Et on est autour de 100 op/s, c'est vraiment pas top. A croire que personne n'utilise les db dans ce mode là.
"La première sécurité est la liberté"
[^] # Re: L'idée est sympathique mais c'est loin d'être facile
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Un smartphone fait de pièces standardes pour lutter contre le gâchis écologique. Évalué à 3.
On peut imaginez un format de coque comme pour le format ATX.
Ensuite, on peut définir une taille d'écran, une fois la guerre des tailles fini, il va rester 3 ou 4 tailles différentes.
Ensuite, il faut définir le facteur de forme de l'électronique (avec port µusb, SIM et SD), de l'écran, et de la batterie. Mais je ne pense pas que l'on puisse moduler le bloc électronique.
"La première sécurité est la liberté"
[^] # Re: nosql embarqué ?
Posté par Nicolas Boulay (site web personnel) . En réponse à la dépêche SQLite 3.8.0 : n'ayez pas peur du zéro. Évalué à 1.
Je veux la persistance quand même.
"La première sécurité est la liberté"
[^] # Re: nosql embarqué ?
Posté par Nicolas Boulay (site web personnel) . En réponse à la dépêche SQLite 3.8.0 : n'ayez pas peur du zéro. Évalué à 3.
LevelDB a l'air pas mal : Environ 5x plus rapide que SQLite.
"La première sécurité est la liberté"
[^] # Re: nosql embarqué ?
Posté par Nicolas Boulay (site web personnel) . En réponse à la dépêche SQLite 3.8.0 : n'ayez pas peur du zéro. Évalué à 1.
Par transaction,je pensais IO/s (un write, un read, un select…)
"La première sécurité est la liberté"
[^] # Re: nosql embarqué ?
Posté par Nicolas Boulay (site web personnel) . En réponse à la dépêche SQLite 3.8.0 : n'ayez pas peur du zéro. Évalué à 2.
Oui, mais c'est surtout histoire de résister à une coupure de courant, et un kill -9.
"La première sécurité est la liberté"
# nosql embarqué ?
Posté par Nicolas Boulay (site web personnel) . En réponse à la dépêche SQLite 3.8.0 : n'ayez pas peur du zéro. Évalué à 2.
Hello, est-ce qu'il existe un base nosql qui s'embarque de la même façon que sqlite ? Un truc qui garanti l'intégrité du fichier, mais dont on se fout un peu du coté "ACID" ?
C'est histoire de dépasser les 100 transactions par seconde.
"La première sécurité est la liberté"
# oui mais non
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Un smartphone fait de pièces standardes pour lutter contre le gâchis écologique. Évalué à 3.
Le principe de faire des légo avec des ordinateurs posent toujours le même problème : les connecteurs coutent plus chère que les puces. Plus, c'est rapide, plus c'est chère. Thunderbolt peut changer les choses mais, il y aura toujours le problème de la consommation.
Par contre, il peut toujours définir des standards d’interconnexion comme USB ou I2C, voir un standard logiciel BIOS (comme Arduino).
Pour l'embarqué très petit, je trouve qu'il manque un bus type I2C avec du débit mais avec un grand espace d'adressage, mono master et avec DMA. L'idée est d'avoir un µP dont des zones mémoire, se mette à jour régulièrement par DMA, sans surcout CPU de communication, mais plus simple que les CAN, et autre I2C.
"La première sécurité est la liberté"
[^] # Re: netbook ?
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Une tablette pour programmer. Évalué à 4.
ça ? http://www.materiel.net/ordinateur-portable/sony-vaio-pro-svp1121a4e-b-93424.html
"La première sécurité est la liberté"
[^] # Re: Oui mais non
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Une tablette pour programmer. Évalué à 2.
Chez moi, cela rame beaucoup moins en plein écran (gpu intel), et cela rame plus(+) si la vidéo embarqué n'est pas visible en entier sur la page, comme si le fait de tronquer lui faisait faire du travail en plus.
Et coté Navigateur, c'est fluide ?
"La première sécurité est la liberté"
[^] # Re: Oui mais non
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Une tablette pour programmer. Évalué à 2.
J'ai aussi un netbook (EEE) de dev, Atom avec 2 Go de RAM et SSD intel. La machine est hyper véloce, sauf pour lire les vidéos youtube qui ne sont pas en pleine écran, et le navigateur rame un peu.
Peut être que cela va mieux avec les atom bi-coeur.
"La première sécurité est la liberté"
[^] # Re: netbook ?
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Une tablette pour programmer. Évalué à 1.
C'est un xps 13 ou un truc pro ? Le truc pro est lourd non ?
"La première sécurité est la liberté"
# netbook ?
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Une tablette pour programmer. Évalué à 4.
C'est pas un netbook que tu veux ? Genre un truc pas chère à base d'atom qui fait 10 ou 11 pouce. Pour avoir plus rapide, et la même autonomie, il faut ensuite taper dans l'ultrabook, mais c'est 2.5x plus chère.
"La première sécurité est la liberté"
[^] # Re: un autre lien
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Chiffrement SSL et confidentialité. Évalué à 3.
Non mais en touchant au drivers de base comme la RTC ou celle des gestion de la mémoire (drivers plateforme), il n'y a pas plus interne au noyau.
L'embarqué va plus loin que l'ajout de drivers, il y a pas mal de bidouille. Par exemple, Sony utilisait le suspend to disk, pour avoir un boot ultra rapide en utilisant une 1er image propre mais toujours la même sur ses cameras.
"La première sécurité est la liberté"
[^] # Re: un autre lien
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Chiffrement SSL et confidentialité. Évalué à 4.
PRISM n'a rien a avoir avec Windows.
En effet, le nom du programme semble être BULLRUN. Mais l'article n'est pas très clair.
http://www.numerama.com/magazine/26916-comment-la-nsa-peut-contrecarrer-le-chiffrement-des-communications.html
"il est par exemple expliqué que la NSA dépense chaque année 250 millions de dollars pour travailler avec les entreprises du high tech et "influencer secrètement" la conception de leurs logiciels… sans doute en les poussant à installer des portes dérobées, en espionnant leur développement ou en les piratant."
"La première sécurité est la liberté"
[^] # Re: un autre lien
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Chiffrement SSL et confidentialité. Évalué à 3.
Il y a infiniment plus de monde qui joue avec le code de Linux qu'avec le code de Windows. Par exemple dans le monde de l'embarqué, énormément de code est écrit pour supporter tous les matériels bas niveau. Linux est partout dans ce monde : appareil photo, télévision, caméscope, "box", lecteur BR, Androïd, système de loisir d'avion, etc…
C'est beaucoup beaucoup plus de monde que pour Windows.
"La première sécurité est la liberté"
[^] # Re: On signe quoi, en fait?
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Booting a Self-signed Linux Kernel. Évalué à 8.
Le problème de tous ses TPM, c'est toujours de savoir qui contrôle les clefs.
Dans le trust computing, les master clefs étaient géré par une instance extérieur, un peu comme si quelqu'un d'autre d'inconnu avait les clefs de chez vous.
Si les clefs sont contrôlé à l'installation, par l'utilisateur uniquement, c'est au contraire une téchno utile.
"La première sécurité est la liberté"