Le driver charge bien le bon firmware.
C'est juste qu'il est capable de gérer les version 21 à 26. Et que je n'ai que les fichiers ucode 22, 27 et 31. Donc il prend le 22.
J'aimerai trouver un ucode entre 23 et 26 ou savoir comment utiliser les suivants, 27 ou 31 que j'ai trouvé sur le git du noyeau.
Je cherche à faire un don pour le libre car l'utilisation qu j'en fais et le plaisir que j'en retire mérite que je donne, de mon temps ou de mon argent.
Mes utilisations majeures, mozilla/firefox, linux ou même wikipedia me semblent bien dotés.
Je donne à framasoft, tant pour leur défense du libre que pour leurs services en ligne permettant de remplacer les plateformes propriétaires.
J'ai déjà donné pour zemarmot mais je ne savais pas que le projet gimp était autant en mal de deniers.
Je vais aller faire un tour sur la page don…
Je partage cette impression. Je ne savais pas le dire poliment.
Quand j'ai essayé BeOS sur disquette, il y a peut être vingt ans (pfiu le vieux), j'ai été bluffé.
Par rapport à ce qui existait, c'était dément : beau, ergonomique, fluide, multitâche. Peut être comparable à QNX mais largement plus impressionnant que windows ou linux.
Mais maintenant que le OS encore en force (windo, GNU/linux, *BSD, MacOS) ont largement dépassé ce niveau, à part la nostalgie, qu'est-ce qui motive les personnes travaillant sur un projet comme celui-ci ? Un hobbies ? La vertu éducative ? L'ambition de faire mieux que ce qui existe ?
pas besoin d'arrêter la base ou de mettre en place des mécanisme complexe de snapshot
format de dump interopérable et pérenne
Mais de par son fonctionnement, il a des limites.
monopolise une transaction en lecture tout le temps de la lecture des tables.
doit générer du SQL ce qui est lent par rapport à une copie de fichier
la restauration elle aussi est très longue comparée à une copie de fichier car le SQL doit être interprété.
crée un fichier au moins aussi gros mais en pratique plutôt 2x plus gros que la base à sauvegarder car le SQL est plus verbeux que le binaire
n'est pas incrémentale, donc toute la base à scanner et tout la volumétrie à stocker à chaque sauvegarde
Pour une base un peu conséquente et sollicitée, il devient rapidement impossible de s'en servir pour un sauvegarde horaire. la prochaine horaire sera lancée avant même que la précédente ne soit finie. et le coût en S3, bien que bon marché, est loin d'être optimisé.
Les moyens de contournement de ces limitations seraient d'utiliser les binlogs pour l'incrémental et de la déduplication pour la full, le tout sur un slave.
C'est ce que suggère la documentation mysql d'ailleurs (ils ne parlent pas de déduplication mais de binlogs et de slave).
Je voulais poster un commentaire similaire. J'ai donc plussé.
J'ai cherché le mécanisme de backup mysql encapsulée par Arkiv - avant de lire le commentaire - car c'est l'information la plus importante pour moi.
L'utilisation de mysqldump est très structurantes pour les limitations de l'outil présenté et devrait être mentionnée dans la présentation.
Autre réaction, j'aurai séparé le script de sauvegarde du script de création du fichier de configuration. Principalement pour des raisons de lisibilité et de maintenance. Mille lignes de bash, c'est pas simple…
Ceci dit, l'effort d'intégration des toutes ses fonctions est appréciable. Merci pour le partage.
Aucun filesystem POSIX n'est tailléconçu pour cet usage.
Le besoin cloud dépasse la capacité du système considéré (une machine + son OS) donc ce ne sont pas des solutions conçues pour une utilisation de ce seul système qui vont répondre.
Dans les solutions cloud, les fonctions de gestion des metadata, de gestion des permissions, de cache, de réplication, de snapshot, de backup, etc. sont sorties du système local pour intégrer des nœuds spécialisés. Et le FS local peut/doit être beaucoup simplifié.
Le SSD utilise un firmeware pour rendre une interface (S)ATA au système.
En cela, il n'a pas de particularités par rapport à un HDD et donc ne nécessite pas de FS particulier.
En vrai, il faut supporté le TRIM et essayer de grouper les écritures le plus possible.
Mais c'est marginal.
En revanche, il y a des FS spécialisés pour le flash (UBIFS, F2FS, JFFS2).
Note qu'une solution est de ne pas prendre en compte les valeurs résiduelles, c'est à dire qui sont dans la dernière plage incomplète des modulos.
Ça se calcul facilement : 32768//6 * 6 = 32766.
Ici, on enlève tout ce qui est supérieur ou égale à 32766 :
do
r = $RANDOM
while r >= 32766
On obtient ainsi forcément un nombre compris entre 0 et 32765. Et donc une distribution parfaite.
Mais dans ce cas, le temps de génération (= nombre de boucles) n'est pas prévisible et peut être très long pour des modulos "pénibles" : ex, pour 993, il faut enlever les 992 dernières valeurs (cas pire <1000). Mais même pour 1000, il faut enlever les 768 dernières valeurs (le modulo est facile à calculer de tête). Et donc 2% de chance de faire au moins deux fois la boucle.
Jusqu'à 32768//6 * 6 - 1 = 32765, la répartition entre les 6 chiffres (0 .. 5) est équivalente : 5461 chacun.
Mais 32766, dont le modulo 6 est 0, ajoute une chance pour 0.
Et 32767, dont le modulo 6 est 1, ajoute une chance pour 1.
Au final, ce générateur de mauvaise qualité a la distribution suivante:
0 : 5462 / 32768 = 0,16668
1 : 5462 / 32768 = 0,16668
2 : 5461 / 32768 = 0,16665
3 : 5461 / 32768 = 0,16665
4 : 5461 / 32768 = 0,16665
5 : 5461 / 32768 = 0,16665
C'est un pouillème, et dans notre cas pas très important.
Mais si tu utilise ça avec un modulo plus grand, la distorsion s'amplifie et peut avoir des effets non désirés.
Bref, si l'application est sérieuse, ne pas utiliser ça ; et c'est vrai dans tous les langages : RANDOM et MODULO = PAS BIEN !
$RANDOM retourne une valeur entre 0 et 32767 (2**15 valeurs).
Donc fonctionne exactement pour des puissances de 2 mais par pour les autres cas.
Pour les autres cas, la distribution n'est pas parfaite.
Bon pour 7, l'imprécision est très faible, moins de 1 pour 1000.
Mais je dirai que c'est un coup de chance.
En français : un SGBD n'est pas nécessairement un SGBDR.
Il est encore fréquent qu'un concepteur de logiciel choisisse une base de données relationnelles pour manipuler ses données alors que l'usage n'est pas adapté : quand les relations entre les données ne sont pas très importantes.
Or les bases de données relationnelles, comme toutes les formes de stockages, ont leurs inconvénients : peu performante en I/O, peu scalable et une API plutôt lourde (à base de déclaration SQL, curseur, connexion).
Une image : si ton cas d'usage est de garer ta voiture, est ce que tu vas utiliser un parking où toutes les roues sont stockées d'un côté, toutes les portes d'un autre, etc. et qu'il faut désosser la voiture pour la garer et tout reconstruire pour la récupérer ? Non, tu vas utiliser un parking où tu peux garer ta voiture en entier et la retrouver grâce au numéro de place que tu aura mémorisé.
En revanche, une base de données relationnelles peut être très adaptée à stocker les données de gestion d'une entreprise (produit, facture, stock, commande, client) qui ont besoin d'une forte intégrité et dont l'unité de l'objet est peu importante.
Le stockage clé/valeur, choisi ici, est un des plus basique. Il propose peu de fonctionnalités (en gros put/get/delete) mais est très simple à manipuler, scalable et très performant en I/O.
J'ai franchement tripé en lisant le journal.
J'avais été très frustré de ne pas pouvoir appliquer coreboot sur du matos moderne.
Si le travail abouti, on aura beaucoup progressé.
Juste deux remarques de forme qui me sont venues à la lecture :
* le titre "Le premier, un peu bébête mais super complexe : faire rentrer notre code de BIOS dans une NVRAM ridiculement petite" est trop long et on aurai dit une faute de mise en forme sur une phrase. Il faudrait le faire commencer à "faire", en supprimant le début.
* le terme téléverser est une traduction de "upload". Un wget a plutôt tendance à télécharger (= "download") dans le cas qui nous occupe.
[^] # Re: black-list
Posté par steph1978 . En réponse au message intel Wireless AC 8265. Évalué à 2.
Le driver charge bien le bon firmware.
C'est juste qu'il est capable de gérer les version 21 à 26. Et que je n'ai que les fichiers ucode 22, 27 et 31. Donc il prend le 22.
J'aimerai trouver un ucode entre 23 et 26 ou savoir comment utiliser les suivants, 27 ou 31 que j'ai trouvé sur le git du noyeau.
[^] # Re: je ne suis pas pour la censure ...
Posté par steph1978 . En réponse au journal Attention, ça va secouer !. Évalué à 2.
Les traditions ne sont pas toutes bonnes à perpétuer…
[^] # Re: Pas si choquant que ça
Posté par steph1978 . En réponse au journal Un Python qui rivalise avec du C++. Évalué à -1.
Définir "boulot".
[^] # Re: Réécrire l'histoire
Posté par steph1978 . En réponse à la dépêche Haiku a 16 ans. Évalué à 2.
Je parlais d'essais sur des machines de 256Mo de RAM à l'époque.
# ni l'un ni l'autre, c'est du C
Posté par steph1978 . En réponse au journal Un Python qui rivalise avec du C++. Évalué à 10. Dernière modification le 27 août 2017 à 23:39.
La force de python c'est de très bien s'interfacer à des bibliothèques de calculs en C.
Et du coup, c'est du bonheur à utiliser.
# don
Posté par steph1978 . En réponse à la dépêche Nouvelles de ZeMarmot, GIMP et GIMP Motion (greffon d’animation dans GIMP). Évalué à 5.
Je cherche à faire un don pour le libre car l'utilisation qu j'en fais et le plaisir que j'en retire mérite que je donne, de mon temps ou de mon argent.
Mes utilisations majeures, mozilla/firefox, linux ou même wikipedia me semblent bien dotés.
Je donne à framasoft, tant pour leur défense du libre que pour leurs services en ligne permettant de remplacer les plateformes propriétaires.
J'ai déjà donné pour zemarmot mais je ne savais pas que le projet gimp était autant en mal de deniers.
Je vais aller faire un tour sur la page don…
[^] # Re: Réécrire l'histoire
Posté par steph1978 . En réponse à la dépêche Haiku a 16 ans. Évalué à 5.
Je partage cette impression. Je ne savais pas le dire poliment.
Quand j'ai essayé BeOS sur disquette, il y a peut être vingt ans (pfiu le vieux), j'ai été bluffé.
Par rapport à ce qui existait, c'était dément : beau, ergonomique, fluide, multitâche. Peut être comparable à QNX mais largement plus impressionnant que windows ou linux.
Mais maintenant que le OS encore en force (windo, GNU/linux, *BSD, MacOS) ont largement dépassé ce niveau, à part la nostalgie, qu'est-ce qui motive les personnes travaillant sur un projet comme celui-ci ? Un hobbies ? La vertu éducative ? L'ambition de faire mieux que ce qui existe ?
[^] # Re: Information sur le volume cible
Posté par steph1978 . En réponse à la dépêche Arkiv : Sauvegarde de fichiers et bases MySQL + archivage sur Amazon S3 et Amazon Glacier. Évalué à 2.
mysqldump a des atouts :
Mais de par son fonctionnement, il a des limites.
Pour une base un peu conséquente et sollicitée, il devient rapidement impossible de s'en servir pour un sauvegarde horaire. la prochaine horaire sera lancée avant même que la précédente ne soit finie. et le coût en S3, bien que bon marché, est loin d'être optimisé.
Les moyens de contournement de ces limitations seraient d'utiliser les binlogs pour l'incrémental et de la déduplication pour la full, le tout sur un slave.
C'est ce que suggère la documentation mysql d'ailleurs (ils ne parlent pas de déduplication mais de binlogs et de slave).
[^] # Re: Information sur le volume cible
Posté par steph1978 . En réponse à la dépêche Arkiv : Sauvegarde de fichiers et bases MySQL + archivage sur Amazon S3 et Amazon Glacier. Évalué à 2.
Je voulais poster un commentaire similaire. J'ai donc plussé.
J'ai cherché le mécanisme de backup mysql encapsulée par Arkiv - avant de lire le commentaire - car c'est l'information la plus importante pour moi.
L'utilisation de mysqldump est très structurantes pour les limitations de l'outil présenté et devrait être mentionnée dans la présentation.
Autre réaction, j'aurai séparé le script de sauvegarde du script de création du fichier de configuration. Principalement pour des raisons de lisibilité et de maintenance. Mille lignes de bash, c'est pas simple…
Ceci dit, l'effort d'intégration des toutes ses fonctions est appréciable. Merci pour le partage.
[^] # Re: ssd
Posté par steph1978 . En réponse au journal Btrfs ne serait plus le futur. Évalué à 2.
Aucun filesystem POSIX n'est
tailléconçu pour cet usage.Le besoin cloud dépasse la capacité du système considéré (une machine + son OS) donc ce ne sont pas des solutions conçues pour une utilisation de ce seul système qui vont répondre.
Dans les solutions cloud, les fonctions de gestion des metadata, de gestion des permissions, de cache, de réplication, de snapshot, de backup, etc. sont sorties du système local pour intégrer des nœuds spécialisés. Et le FS local peut/doit être beaucoup simplifié.
[^] # Re: inutile
Posté par steph1978 . En réponse au journal Openmailbox. Évalué à 3.
Tout à fait, l'appellation a d'ailleurs été interdite car jugée trompeuse pour le consommateur.
[^] # Re: ssd
Posté par steph1978 . En réponse au journal Btrfs ne serait plus le futur. Évalué à 2.
Le SSD utilise un firmeware pour rendre une interface (S)ATA au système.
En cela, il n'a pas de particularités par rapport à un HDD et donc ne nécessite pas de FS particulier.
En vrai, il faut supporté le TRIM et essayer de grouper les écritures le plus possible.
Mais c'est marginal.
En revanche, il y a des FS spécialisés pour le flash (UBIFS, F2FS, JFFS2).
# inutile
Posté par steph1978 . En réponse au journal Openmailbox. Évalué à 3.
En dehors des mots "open" et ".org", quel est le rapport avec le libre ou l'open source ?
[^] # Re: Hadoop ?
Posté par steph1978 . En réponse au journal Data Warehouse. Évalué à 1.
Pardon mais je réponds à qqun qui dit "Pourquoi Hadoop et pas Spark ?"
Donc j'en suis pas à rentrer dans les détails que tu mentionnes par la suite.
[^] # Re: Hadoop ?
Posté par steph1978 . En réponse au journal Data Warehouse. Évalué à 1.
Tu confonds Hadoop et Hive.
Hive est un moteur de requêtage MapReduce en mode disque.
Spark en mode mémoire.
Donc oui, Spark est plus rapide que Hive.
[^] # Re: Hadoop ?
Posté par steph1978 . En réponse au journal Data Warehouse. Évalué à 2. Dernière modification le 10 juillet 2017 à 14:08.
Tu confonds Hadoop et HDFS.
HDFS c'est du stockage.
Hadoop, c'est plein d'outils qui collaborent.
[^] # Re: Metriques
Posté par steph1978 . En réponse au journal Data Warehouse. Évalué à 3.
En voilà une analyse de qualité.
Encore un peu trop cher…
[^] # Re: Et en Java ?
Posté par steph1978 . En réponse au journal Parce que ca vaut largement un journal .... Évalué à 10.
Note qu'une solution est de ne pas prendre en compte les valeurs résiduelles, c'est à dire qui sont dans la dernière plage incomplète des modulos.
Ça se calcul facilement : 32768//6 * 6 = 32766.
Ici, on enlève tout ce qui est supérieur ou égale à 32766 :
do
r = $RANDOM
while r >= 32766
On obtient ainsi forcément un nombre compris entre 0 et 32765. Et donc une distribution parfaite.
Mais dans ce cas, le temps de génération (= nombre de boucles) n'est pas prévisible et peut être très long pour des modulos "pénibles" : ex, pour 993, il faut enlever les 992 dernières valeurs (cas pire <1000). Mais même pour 1000, il faut enlever les 768 dernières valeurs (le modulo est facile à calculer de tête). Et donc 2% de chance de faire au moins deux fois la boucle.
[^] # Re: Et en Java ?
Posté par steph1978 . En réponse au journal Parce que ca vaut largement un journal .... Évalué à 10.
Et j'oubliais :
[^] # Re: Et en Java ?
Posté par steph1978 . En réponse au journal Parce que ca vaut largement un journal .... Évalué à 10.
Travaillons avec 6.
Jusqu'à 32768//6 * 6 - 1 = 32765, la répartition entre les 6 chiffres (0 .. 5) est équivalente : 5461 chacun.
Mais 32766, dont le modulo 6 est 0, ajoute une chance pour 0.
Et 32767, dont le modulo 6 est 1, ajoute une chance pour 1.
Au final, ce générateur de mauvaise qualité a la distribution suivante:
0 : 5462 / 32768 = 0,16668
1 : 5462 / 32768 = 0,16668
2 : 5461 / 32768 = 0,16665
3 : 5461 / 32768 = 0,16665
4 : 5461 / 32768 = 0,16665
5 : 5461 / 32768 = 0,16665
C'est un pouillème, et dans notre cas pas très important.
Mais si tu utilise ça avec un modulo plus grand, la distorsion s'amplifie et peut avoir des effets non désirés.
Bref, si l'application est sérieuse, ne pas utiliser ça ; et c'est vrai dans tous les langages : RANDOM et MODULO = PAS BIEN !
[^] # Re: Et en Java ?
Posté par steph1978 . En réponse au journal Parce que ca vaut largement un journal .... Évalué à 3.
C'est plus simple mais c'est faux.
$RANDOM retourne une valeur entre 0 et 32767 (2**15 valeurs).
Donc fonctionne exactement pour des puissances de 2 mais par pour les autres cas.
Pour les autres cas, la distribution n'est pas parfaite.
Bon pour 7, l'imprécision est très faible, moins de 1 pour 1000.
Mais je dirai que c'est un coup de chance.
[^] # Re: BDD
Posté par steph1978 . En réponse à la dépêche Première sortie d’Élixir : embarquez, naviguez !. Évalué à 2. Dernière modification le 03 juillet 2017 à 16:22.
En français : un SGBD n'est pas nécessairement un SGBDR.
Il est encore fréquent qu'un concepteur de logiciel choisisse une base de données relationnelles pour manipuler ses données alors que l'usage n'est pas adapté : quand les relations entre les données ne sont pas très importantes.
Or les bases de données relationnelles, comme toutes les formes de stockages, ont leurs inconvénients : peu performante en I/O, peu scalable et une API plutôt lourde (à base de déclaration SQL, curseur, connexion).
Une image : si ton cas d'usage est de garer ta voiture, est ce que tu vas utiliser un parking où toutes les roues sont stockées d'un côté, toutes les portes d'un autre, etc. et qu'il faut désosser la voiture pour la garer et tout reconstruire pour la récupérer ? Non, tu vas utiliser un parking où tu peux garer ta voiture en entier et la retrouver grâce au numéro de place que tu aura mémorisé.
En revanche, une base de données relationnelles peut être très adaptée à stocker les données de gestion d'une entreprise (produit, facture, stock, commande, client) qui ont besoin d'une forte intégrité et dont l'unité de l'objet est peu importante.
Le stockage clé/valeur, choisi ici, est un des plus basique. Il propose peu de fonctionnalités (en gros put/get/delete) mais est très simple à manipuler, scalable et très performant en I/O.
[^] # Re: Pourquoi X86 (Intel)
Posté par steph1978 . En réponse à la dépêche Un pas en avant pour les serveurs libres : le projet NERF. Évalué à 4.
Ça s'achète où ?
# GG
Posté par steph1978 . En réponse à la dépêche Un pas en avant pour les serveurs libres : le projet NERF. Évalué à 6.
J'ai franchement tripé en lisant le journal.
J'avais été très frustré de ne pas pouvoir appliquer coreboot sur du matos moderne.
Si le travail abouti, on aura beaucoup progressé.
Juste deux remarques de forme qui me sont venues à la lecture :
* le titre "Le premier, un peu bébête mais super complexe : faire rentrer notre code de BIOS dans une NVRAM ridiculement petite" est trop long et on aurai dit une faute de mise en forme sur une phrase. Il faudrait le faire commencer à "faire", en supprimant le début.
* le terme téléverser est une traduction de "upload". Un wget a plutôt tendance à télécharger (= "download") dans le cas qui nous occupe.
# prix
Posté par steph1978 . En réponse au journal Diskiopi démarre un kick. Évalué à 3. Dernière modification le 30 juin 2017 à 15:12.
bon je vais faire le grognon.
pour avoir qqch de fonctionnel, faut environ mettre 500€.
pour un prix inférieur, on trouve de bonnes tablettes, compatibles Ubuntu et Android.
par rapport, je trouve le c.h.i.p plus versatile et hackable.
comme le critère économique ne semble pas le différenciant de ce projet, quel est ce différenciant ?