ARM devrait faire comme Intel pour AES : des instructions spécialisés. Et puis, 2 ou 3 versions de jeu d'instructions mais pas une pléthore de combinaison comme Intel : cela empêche d'avoir un intérêt pour les dev logiciel d'utiliser ces instructions, car ule jeu d'instruction intéressant est trop peu commun.
Il devrait compléter les instructions crypto, l'usage des copro étaient une mode : mais il n'y a jamais tous les modes disponibles, et la programmation du coproc peut prendre plus de temps que de faire le boulot sur le cpu pour les petits paquets. A moins d'avoir un truc énorme à faire comme la décompression vidéo. De plus, cela rend nécessaire l'écriture d'un drivers spécifique pour l'OS, alors qu'une instruction ne demande qu'un assembleur pour être généré.
Le plus gros problème pour arm est de ne pas avoir définit une plateforme minimale ce qui empêche de faire un binaire universel, ce qui parait délirant. On ne peut pas avoir une distrib unique "arm" comme une version 386 pour les compatibles x86, il faut une version différente par SoC ou presque.
Finalement, est-ce qu'il ne faudrait pas commencer par définir intelligence?
C'est justement la difficulté : personne n'arrive à la même. D'où la blague de dire que intelligence est tout ce qui n'arrive pas à faire un ordinateur.
Excellente question. L'intelligence humaine inclut également la sensibilité, les sentiments. Que sont les sentiments? C'est vaste, infini, indéfinissable…
Non justement, les sentiments sont assez bien connu. Il y a moins d'une dizaine de base, qui varient en intensité. Pour avoir coder des "robots", j'ai l'impression que les sentiments servent à faire quelques choses plutôt que rien, quand il n'y a pas assez d'informations pour prendre une décision rationnelle.
Surtout que la façon de posé la question est idiote : "mur ou enfants" ?
Or la machine a une infinité de choix possible, qui va sans doute se réduire à freiner un max, tout en tentant d'éviter l'obstacle en passant entre les 2.
Pour avoir codé en ocaml avec des map() et des fold_left(), j'ai vraiment du mal à réécrire des boucles, c'est beaucoup trop facile d'écrire de la merde (boucle infinie, offbyone, etc…). C'est vraiment ce qui me manque le plus en Go (golang) avec les types sommes.
le conseil n°1 que tous ces tutos vous donnera sera: ne surtout jamais oublier de préciser une zone de diffusion et une durée limitées; un ayant droit classique veut se donner la possibilité de pouvoir revoir régulièrement ses droits au cas où la situation évolue.
D'un point de vue d'informaticien, c'est totalement insupportable comme manière de voir les choses. Jamais on est payé en fonction du succès du code. C'est un peu une prise d'otage, je pense à un logo par exemple. Le logo prend de la valeur car il devient connu, comme une marque, mais c'est très loin de sa valeur purement "graphique", c'est le travail de toute la boite. De mon point de vue, cela ressemble à du parasitisme.
Pour aller dans ton sens, le travail de "base" d'un graphiste est très mal payé, ce qui n'est pas le cas pour un codeur.
Un chiffrement informatique convenable est totalement impénétrable avec les techniques actuelles (hors technique de la clef à molette, chantage, etc).
Avec un mot de passe 128 bits réellement aléatoire oui. Mais attention si on utilise des hash de password trop rapide, hashcat fait 1 milliard de clef à la seconde(avec sha1, seulement 5000/s avec bcrypt), de quoi tester rapidement tous mots de passe généré par un humain.
Un vieux principe pour un serveur est de chiffrer le disque et de jeter la clef. Impossible de l'éteindre sans tout perdre. Il vaut mieux avoir une bonne alimentation.
Je peux te retourner l'argument. Peut être en ayant une taille, un poil plus grand, le JPEG aurait une qualité largement supérieur.
Globalement, il est sûr que je n'utiliserais jamais des JPEG aussi abimé, les mettre dans une comparaison n'a pas de sens. Même certain AV1 sont moches, celui de l'église de l'armée US dont il manque des traverses horizontales.
Je suis d'accord que la comparaison entre les 2 images pour avoir des qualités comparables est complexe. Mais bon, il existe plusieurs métriques qui pourrait être utilisé (PSNR, …).
Pas vraiment non. Personne n'utilise des photos aussi abimés. Il serait plus utile de trouver un taux de compression avec peu d'artefact visible, et voir la taille résultante.
Est-ce qu'il existe un filtre photo d'amélioration "de base" ?
En général, sur les photos qui sortent de mon APN, il manque un peu de vivacité dans les couleurs que je corrige avec une courbe de couleur qui ressemble à la correction gamma. Ensuite, il manque toujours un peu de contraste locale, c'est ce qui était fait "au tirage" à l'époque, en rajoutant plus ou moins de lumière sur le papier photo.
Parfois, il faudrait corriger la balance des blancs, il y a longtemps il existait un filtre où il fallait cliquer sur du blanc dans la photo, car les filtres où il faut estimer la température de la lumière lors de la prise de la photo et la température réglé sur l'appareil, sont trop compliqués.
L'idéal serait de pouvoir le faire à partir des photos RAW 12 bits plutôt que depuis le JPEG 8 bits. Je n'ai pas retenté depuis longtemps, mais je n'ai jamais réussi un "développement de RAW" avec du logiciel libre (DCRAW), la gestion du pattern de bayer était pourris, et les filtres anti bruit, trop ou pas assez lissant (myriade de pixel rouge vs lissage à mort), bref, impossible de faire mieux que le jpeg de qualité moyenne qui est stocké dans le RAW nikon, un comble.
Le top est aussi la correction géométrique de la lentille, il existait un outil pour ça, mais sa base de donnée ne doit plus être à jour il me semble. C'est encore mieux si la correction se fait sur les couleurs différentes, pour enlever les aberrations chromatiques comme les franges violettes, dû au fait que la lumière n'est pas déviée de la même façon par les lentilles selon la longueur d'onde.
Bien sûr que tu te trompes, un algo pourrait déduire des règles de l'observation d'un certain nombre de parti. Mais c'est rarement ce qu'on lui demande.
Pour l'apprentissage, oui, j'avais calculé 3 milliards de parties d'après leur sujet d'étude. Par contre, quand il joue, il utilise les mêmes table, et la vitesse d'évaluation est de l'ordre de 30 000 itérations par seconde.
Non pas du tout justement, puisque AlphaZero est plus fort que Alpha Go. Le programme consiste en un parcours d'arbre, un système de deep learning, et les règles du jeu, c'est tout.
Il n'est absolument pas question de traitement de masse, tu as 20 ans de retard. Le traitement de masse c'était deep blue d'IBM (minmax amélioré). Lors d'une partie, Deep blue évlue des millions de fois plus de position par seconde que Alpha Zero (parcours d'arbre montecarlo (?) avec statistique trouvé par apprentissage). Celui-ci est pourtant infiniment meilleur joueur.
L'article de l'express est assez mauvais. On dirait que l'auteur a une vision très très vague de ce qu'est le machine learning et le deep learning. Il en tire des conclusions qui sortent de nul part.
"La véritable IA n'existera jamais, car le monde est inconnaissable."
"Il n'est pas rationnel d'être à 100% rationnel, or un ordinateur est à 100% rationnel."
"Ceux qui tireront leur épingle du jeu seront ceux qui continueront d'ajouter de la valeur. … Bref, de tous les métiers relevant de la création. "
Comme si une large de part de la création n'était pas simplement un agrégat de solution existante adapté aux contraintes externe !
Et c'est le travail de l'éditeur de liens : il scanne les .o et construit un arbre de dépendance pour n'inclure dans les exécutables que le code effectivement appelé. C'est pour ça que (avec certains linkers anciens), il fallait spécifier deux fois des .a (ou .lib) en cas de dépendances tordues…
De mémoire, les linkers ne scannaient rien du tout, il ne faisait qu’agglomérer les .o que l'on lui donnait, et donnait une adresse mémoire au objet du .o.
Si un programme "Hello World" qui ne demande qu'un "printf" se retrouve lié statiquement avec une bibliothèque de plusieurs Mo, pour le coup, c'est du code mort facilement éliminable en liant uniquemnt "printf" et ses fonctions dépendantes.
Justement non. Ce n'est pas simple. Historiquement les compilateurs fonctionnaient toujours par morceau pour gérer la pénurie de mémoire des ordinateur (d'où les .o du C). Pour enlever les fonctions inutiles, il faut être capable de détecter toutes les appels de fonction en scannant le code entier. J'imagine qu'aujourd'hui on doit pouvoir décortiquer en mémoire, un programme entier, mais cela donne forcément une taille limite.
Je me rappelle d'un hello-world avec une boite de dialogue en Lisaac, celui-ci, comme le go, récupérait tout le code et en faisait de la bouillis. Au final, le binaire faisait 12ko.
[^] # Re: Pour les ordinateurs personnels, c'est pas ça…
Posté par Nicolas Boulay (site web personnel) . En réponse au journal ARM vs Intel. Évalué à 4.
ARM devrait faire comme Intel pour AES : des instructions spécialisés. Et puis, 2 ou 3 versions de jeu d'instructions mais pas une pléthore de combinaison comme Intel : cela empêche d'avoir un intérêt pour les dev logiciel d'utiliser ces instructions, car ule jeu d'instruction intéressant est trop peu commun.
Il devrait compléter les instructions crypto, l'usage des copro étaient une mode : mais il n'y a jamais tous les modes disponibles, et la programmation du coproc peut prendre plus de temps que de faire le boulot sur le cpu pour les petits paquets. A moins d'avoir un truc énorme à faire comme la décompression vidéo. De plus, cela rend nécessaire l'écriture d'un drivers spécifique pour l'OS, alors qu'une instruction ne demande qu'un assembleur pour être généré.
"La première sécurité est la liberté"
[^] # Re: Effet de mode?
Posté par Nicolas Boulay (site web personnel) . En réponse au journal ARM vs Intel. Évalué à 6.
y'a trustzone, c'est pareil. Un ring 0 que tu ne contrôles pas si tu n'as pas les clefs pour y envoyer des "applications".
"La première sécurité est la liberté"
[^] # Re: Effet de mode?
Posté par Nicolas Boulay (site web personnel) . En réponse au journal ARM vs Intel. Évalué à 5.
Le plus gros problème pour arm est de ne pas avoir définit une plateforme minimale ce qui empêche de faire un binaire universel, ce qui parait délirant. On ne peut pas avoir une distrib unique "arm" comme une version 386 pour les compatibles x86, il faut une version différente par SoC ou presque.
"La première sécurité est la liberté"
[^] # Re: "Intelligence artificielle", pourquoi pas?
Posté par Nicolas Boulay (site web personnel) . En réponse au journal "Intelligence artificielle", vraiment?. Évalué à 3.
C'est justement la difficulté : personne n'arrive à la même. D'où la blague de dire que intelligence est tout ce qui n'arrive pas à faire un ordinateur.
Non justement, les sentiments sont assez bien connu. Il y a moins d'une dizaine de base, qui varient en intensité. Pour avoir coder des "robots", j'ai l'impression que les sentiments servent à faire quelques choses plutôt que rien, quand il n'y a pas assez d'informations pour prendre une décision rationnelle.
"La première sécurité est la liberté"
[^] # Re: Commentaire bookmark
Posté par Nicolas Boulay (site web personnel) . En réponse au journal "Intelligence artificielle", vraiment?. Évalué à 3.
Surtout que la façon de posé la question est idiote : "mur ou enfants" ?
Or la machine a une infinité de choix possible, qui va sans doute se réduire à freiner un max, tout en tentant d'éviter l'obstacle en passant entre les 2.
"La première sécurité est la liberté"
[^] # Re: Fonctionnel vs Impératif
Posté par Nicolas Boulay (site web personnel) . En réponse au lien État des lieux des langages fonctionnels. Évalué à 3.
Pour avoir codé en ocaml avec des map() et des fold_left(), j'ai vraiment du mal à réécrire des boucles, c'est beaucoup trop facile d'écrire de la merde (boucle infinie, offbyone, etc…). C'est vraiment ce qui me manque le plus en Go (golang) avec les types sommes.
"La première sécurité est la liberté"
[^] # Re: Ca pose à un autre problème...
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Il ne demandait qu'à payer !. Évalué à 5.
D'un point de vue d'informaticien, c'est totalement insupportable comme manière de voir les choses. Jamais on est payé en fonction du succès du code. C'est un peu une prise d'otage, je pense à un logo par exemple. Le logo prend de la valeur car il devient connu, comme une marque, mais c'est très loin de sa valeur purement "graphique", c'est le travail de toute la boite. De mon point de vue, cela ressemble à du parasitisme.
Pour aller dans ton sens, le travail de "base" d'un graphiste est très mal payé, ce qui n'est pas le cas pour un codeur.
"La première sécurité est la liberté"
[^] # Re: Analogie du coffre-fort
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Le Conseil constitutionnel autorise les juges à vous demander vos clés de chiffrement. Évalué à 3.
Avec un mot de passe 128 bits réellement aléatoire oui. Mais attention si on utilise des hash de password trop rapide, hashcat fait 1 milliard de clef à la seconde(avec sha1, seulement 5000/s avec bcrypt), de quoi tester rapidement tous mots de passe généré par un humain.
"La première sécurité est la liberté"
[^] # Re: Pas inquiété
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Le Conseil constitutionnel autorise les juges à vous demander vos clés de chiffrement. Évalué à 3.
Un vieux principe pour un serveur est de chiffrer le disque et de jeter la clef. Impossible de l'éteindre sans tout perdre. Il vaut mieux avoir une bonne alimentation.
"La première sécurité est la liberté"
[^] # Re: comparaison JPEG/AV1
Posté par Nicolas Boulay (site web personnel) . En réponse au journal AV1 : le codec du futur ?. Évalué à 4.
Je peux te retourner l'argument. Peut être en ayant une taille, un poil plus grand, le JPEG aurait une qualité largement supérieur.
Globalement, il est sûr que je n'utiliserais jamais des JPEG aussi abimé, les mettre dans une comparaison n'a pas de sens. Même certain AV1 sont moches, celui de l'église de l'armée US dont il manque des traverses horizontales.
Je suis d'accord que la comparaison entre les 2 images pour avoir des qualités comparables est complexe. Mais bon, il existe plusieurs métriques qui pourrait être utilisé (PSNR, …).
"La première sécurité est la liberté"
[^] # Re: comparaison JPEG/AV1
Posté par Nicolas Boulay (site web personnel) . En réponse au journal AV1 : le codec du futur ?. Évalué à 2.
J'aurais fait l'inverse mais bon.
"La première sécurité est la liberté"
[^] # Re: comparaison JPEG/AV1
Posté par Nicolas Boulay (site web personnel) . En réponse au journal AV1 : le codec du futur ?. Évalué à 10.
Pas vraiment non. Personne n'utilise des photos aussi abimés. Il serait plus utile de trouver un taux de compression avec peu d'artefact visible, et voir la taille résultante.
"La première sécurité est la liberté"
[^] # Re: .
Posté par Nicolas Boulay (site web personnel) . En réponse au journal section liens : je trouve ça nul.. Évalué à 6.
bof, cela pourrait être "caché" derrière un [+] par défaut
"La première sécurité est la liberté"
# Dev photo
Posté par Nicolas Boulay (site web personnel) . En réponse au lien G'MIC : Appliquer des tas de filtres en ligne de commande ! (Galerie). Évalué à 4.
Est-ce qu'il existe un filtre photo d'amélioration "de base" ?
En général, sur les photos qui sortent de mon APN, il manque un peu de vivacité dans les couleurs que je corrige avec une courbe de couleur qui ressemble à la correction gamma. Ensuite, il manque toujours un peu de contraste locale, c'est ce qui était fait "au tirage" à l'époque, en rajoutant plus ou moins de lumière sur le papier photo.
Parfois, il faudrait corriger la balance des blancs, il y a longtemps il existait un filtre où il fallait cliquer sur du blanc dans la photo, car les filtres où il faut estimer la température de la lumière lors de la prise de la photo et la température réglé sur l'appareil, sont trop compliqués.
L'idéal serait de pouvoir le faire à partir des photos RAW 12 bits plutôt que depuis le JPEG 8 bits. Je n'ai pas retenté depuis longtemps, mais je n'ai jamais réussi un "développement de RAW" avec du logiciel libre (DCRAW), la gestion du pattern de bayer était pourris, et les filtres anti bruit, trop ou pas assez lissant (myriade de pixel rouge vs lissage à mort), bref, impossible de faire mieux que le jpeg de qualité moyenne qui est stocké dans le RAW nikon, un comble.
Le top est aussi la correction géométrique de la lentille, il existait un outil pour ça, mais sa base de donnée ne doit plus être à jour il me semble. C'est encore mieux si la correction se fait sur les couleurs différentes, pour enlever les aberrations chromatiques comme les franges violettes, dû au fait que la lumière n'est pas déviée de la même façon par les lentilles selon la longueur d'onde.
"La première sécurité est la liberté"
[^] # Re: Ça fait quoi, en fait?
Posté par Nicolas Boulay (site web personnel) . En réponse à la dépêche OPP 1.3.7 — Open Projection Program. Évalué à 7.
En fait la discussion a déjà eu lieu, il y a 3 ans :)
https://linuxfr.org/users/gabu/journaux/cinema-libre-3-ans-apres#comment-1628389
"La première sécurité est la liberté"
[^] # Re: Ça fait quoi, en fait?
Posté par Nicolas Boulay (site web personnel) . En réponse à la dépêche OPP 1.3.7 — Open Projection Program. Évalué à 6.
Il y a un spécialiste du DCP qui traine sur linuxfr (Prae ?). Je crois même qu'il existe une lib pour les lire.
"La première sécurité est la liberté"
[^] # Re: Bêtise naturelle
Posté par Nicolas Boulay (site web personnel) . En réponse au journal "Intelligence artificielle", vraiment?. Évalué à 5.
Bien sûr que tu te trompes, un algo pourrait déduire des règles de l'observation d'un certain nombre de parti. Mais c'est rarement ce qu'on lui demande.
"La première sécurité est la liberté"
[^] # Re: Bêtise naturelle
Posté par Nicolas Boulay (site web personnel) . En réponse au journal "Intelligence artificielle", vraiment?. Évalué à 5.
C'est toujours amusant de voir que les gens veulent changer la définition précédente de "l'intelligence" dés que la machine dépasse l'humain.
"La première sécurité est la liberté"
[^] # Re: Bêtise naturelle
Posté par Nicolas Boulay (site web personnel) . En réponse au journal "Intelligence artificielle", vraiment?. Évalué à 3.
Pour l'apprentissage, oui, j'avais calculé 3 milliards de parties d'après leur sujet d'étude. Par contre, quand il joue, il utilise les mêmes table, et la vitesse d'évaluation est de l'ordre de 30 000 itérations par seconde.
"La première sécurité est la liberté"
[^] # Re: L'ordinateur est rationnel, et alors ?
Posté par Nicolas Boulay (site web personnel) . En réponse au journal "Intelligence artificielle", vraiment?. Évalué à 5.
Non pas du tout justement, puisque AlphaZero est plus fort que Alpha Go. Le programme consiste en un parcours d'arbre, un système de deep learning, et les règles du jeu, c'est tout.
"La première sécurité est la liberté"
[^] # Re: Bêtise naturelle
Posté par Nicolas Boulay (site web personnel) . En réponse au journal "Intelligence artificielle", vraiment?. Évalué à 6.
Il n'est absolument pas question de traitement de masse, tu as 20 ans de retard. Le traitement de masse c'était deep blue d'IBM (minmax amélioré). Lors d'une partie, Deep blue évlue des millions de fois plus de position par seconde que Alpha Zero (parcours d'arbre montecarlo (?) avec statistique trouvé par apprentissage). Celui-ci est pourtant infiniment meilleur joueur.
"La première sécurité est la liberté"
[^] # Re: L'ordinateur est rationnel, et alors ?
Posté par Nicolas Boulay (site web personnel) . En réponse au journal "Intelligence artificielle", vraiment?. Évalué à 3.
Comment expliques-tu alors la créativité de alphazero dans le jeu d'échec et de Go ?
"La première sécurité est la liberté"
# mauvais
Posté par Nicolas Boulay (site web personnel) . En réponse au journal "Intelligence artificielle", vraiment?. Évalué à 10.
L'article de l'express est assez mauvais. On dirait que l'auteur a une vision très très vague de ce qu'est le machine learning et le deep learning. Il en tire des conclusions qui sortent de nul part.
Comme si une large de part de la création n'était pas simplement un agrégat de solution existante adapté aux contraintes externe !
"La première sécurité est la liberté"
[^] # Re: langue
Posté par Nicolas Boulay (site web personnel) . En réponse à la dépêche Des alternatives à grep, ls et find. Évalué à 3.
De mémoire, les linkers ne scannaient rien du tout, il ne faisait qu’agglomérer les .o que l'on lui donnait, et donnait une adresse mémoire au objet du .o.
"La première sécurité est la liberté"
[^] # Re: langue
Posté par Nicolas Boulay (site web personnel) . En réponse à la dépêche Des alternatives à grep, ls et find. Évalué à 3.
Justement non. Ce n'est pas simple. Historiquement les compilateurs fonctionnaient toujours par morceau pour gérer la pénurie de mémoire des ordinateur (d'où les .o du C). Pour enlever les fonctions inutiles, il faut être capable de détecter toutes les appels de fonction en scannant le code entier. J'imagine qu'aujourd'hui on doit pouvoir décortiquer en mémoire, un programme entier, mais cela donne forcément une taille limite.
Je me rappelle d'un hello-world avec une boite de dialogue en Lisaac, celui-ci, comme le go, récupérait tout le code et en faisait de la bouillis. Au final, le binaire faisait 12ko.
"La première sécurité est la liberté"