Hum, je ne vois pas comment tu fais.
Prenons un cas simple : SSH.
Imaginons que tu doives avoir obligatoirement du SFTP sur le port 22 pour un logiciel ne supportant pas autre chose (j'ai déjà vu ça avec des banques), mais que le port 22 est déjà utilisé pour ton SSH normal et que tu ne peux pas le bouger. Comment tu veux faire la distinction sans avoir deux adresses IP ? Au niveau réseau, le nom d'hôte disparait, tu reçois des paquets TCP à destination de 1.2.3.4:22. Éventuellement, ils peuvent contenir une info sur la cible, comme le SNI de HTTPS… Mais donc il faut que ton reverse proxy gère spécifiquement chaque protocole ?
Ça me parait juste infaisable sans avoir des adresses IP en stock… et donc sans IPv6 pour la plupart des gens qui veulent faire de l'auto-hébergement, ou sur le long-terme.
Et tu fais quoi pour un service qui ne soit pas en HTTP/HTTPS ? Je sais que c'est plus à la mode, mais y'a quand même des protocoles plus adaptés pour certaines taches que HTTP :)
Malheureusement, ce que fait systemd est nécessairement invasif. À partir du moment où tu veux gérer les services comme ça, tu te retrouves à intégrer beaucoup de choses… Bon, réimplémenter un client SNTP ou DHCP, faut pas déconner, c'est pas nécessaire.
C'est parce que numerama a maintenant ce type de «contenu» que je ne mets plus dans mes catégories importantes de flux RSS…
Donc désormais l'azerty issu de l'IBM PC est l'azerty de Windows, il n'existe plus d'ordinateurs non Apple visibles par les plus jeunes, à part «les vieux Compaq de la salle de technologies du collège» (Compaq, disparu en 2002)…
Leur but semble d'être juste de faire à peu de frais du contenu qui apportera assez de clics pour la pub.
Je n'ai pas encore vu un environnement de dév de la sorte sous Linux (environnement tout intégré, avec GUI, etc.), c'est chose faite, bravo. :)
Il y a également Lazarus (Freepascal) qui est pas mal du tout en tout intégré. J'attends que Gambas 3.12 soit dans ma debian pour jouer un peu avec, par contre l'absence de support de windows va m'empêcher de le mettre en avant auprès de connaissances qui n'ont pas accès à mieux aujourd'hui que Excel/Access et les macros :/
Raptor CS affirme que le microcode est ouvert. Et le POWER est développé par la fondation OpenPOWER, où tout le monde peut devenir membre. Donc ça semble plus ouvert que fermé…
Alors je ne connais pas la relation entre vejmarie et OVH/Octave, mais ayant travaillé un certain temps à OVH je peux donner des pistes d'interprétation.
OVH se vante d'innover notamment sur le matériel, d'embrasser l'open source, de contribuer… Du coup des projet comme coreboot ou linuxboot, qui peuvent apporter moultes avantages pour des grands opérateurs de réseau, devraient intéresser et pousser à contribuer le «n°1 européen du cloud».
Mais à moins d'un changement radical depuis mon départ il y a 3 ans, OVH n'est qu'un intégrateur, gros certes, mais un intégrateur, donc je les vois vraiment mal contribuer à linuxboot. D'autant plus que pour ce qui est du cloud, ils sont maqués depuis longtemps avec VMWare, et le private cloud à base de VMWare étant devenu une belle vache à lait (au sens économique), à moins que VMWare se mette à certifier des machines sous linuxboot pour ESXI… c'est vraiment pas près d'arriver.
Je suis très preneur d'un journal sur LLVM orienté JIT !
J'aurais mieux fait de fermer ma gueule :)
Ça viendra, mais faut d'abord que je fasse tout un gros dev avec une vraie bibliothèque de JIT pour comparer proprement. Du coup ça va être long. Le cœur du problème pour les cas que j'ai vu : le code est émis en une seule fois (lourdement), et jamais revu après. Et je suis tombé sur au moins un cas où une phase d'optimisation indispensable pour de bonnes perfs est dans l'étape de codegen, qui n'est pas configurable.
Dans le cas qui m'intéresse, PostgreSQL 11, je suis convaincu de l'utilité du JIT par LLVM pour les grosses requêtes où le gain CPU va exploser le temps de compilation requis, mais je suis certain que ça sera en dessous des performances d'un vrai compilateur à la volée, et même dans certains cas en dessous des performances de PG sans compilation (cf. http://www.postgresql-archive.org/PATCH-LLVM-tuple-deforming-improvements-td6029385.html par exemple). Par contre, une solution bien plus légère de compilation/optimisation progressive du bytecode… ça devrait couvrir cette deuxième partie du spectre.
Je pense que les cas de unladden swallow (interpréteur python utilisant LLVM - http://qinsb.blogspot.com/2011/03/unladen-swallow-retrospective.html) ou encore de webkit (abandon de LLVM pour le JIT - https://webkit.org/blog/5852/introducing-the-b3-jit-compiler/) sont assez clairs. Il est des cas que LLVM couvre excellemment, mais il ne faut absolument pas croire qu'il s'agit là du marteau universel. Ce marteau n'existe pas :)
Les langages dynamiques, l'absence d'optimisation progressive avec retour arrière… ce sont des défis que LLVM ne peut pas relever aujourd'hui. LLVM est conçu avec un modèle complètement statique, parfait pour de nombreux langages. Pour Java, à voir, mais je pense que des choses comme invokeddynamic risquent d'y perdre des plumes.
Et si cette JVM de course augmentait tellement les performances des applications que son coût serait inférieure au temps nécessaire à optimiser le code ?
Marmotte + chocolat + aluminium…
Aucune JVM, aucun compilateur au monde ne saura lutter contre le bâclage du développement.
Je vais prendre un exemple tout simple où je ne vois pas comment un outil aurait pu corriger le soucis. C'était il y a quelques années, je travaillais sur un interpréteur (très) mal codé pour un langage basic-esque quelconque (j'insiste sur la deuxième syllabe). Un bytecode était généré en mémoire, puis exécuté dans plusieurs threads en même temps (avec des données différentes). Et le temps d'exécution était linéaire avec le nombre de threads. 1 thread − 10 secondes, 2 threads − 20 secondes, 3 threads − 30 secondes (véridique).
Après quelques heures d'analyse, j'ai trouvé qu'à chaque exécution d'une instruction du bytecode, un lock était pris sur un tableau partagé entre tous les threads. Il a suffit de s'assurer que le tableau soit en lecture seule pour tout le monde pour supprimer le lock et avoir un temps linéaire, mais dans le bon sens.
Je n'ai pas fait de Java depuis trop longtemps pour donner des exemples concrets de synchronized et cie, mais ce genre de situation est bien trop courante et surtout hors d'atteinte des VMs ou des compilateurs. Quand bien même tu prouvais que la variable est effectivement bien en lecture seule passé un certain point, c'est un prédicat trop fragile s'il n'est pas garanti par le code, sinon les performances seront aléatoires : un petit changement casse cette optimisation et c'en est fini.
Et quand bien même cette VM était magiquement rapide… la JVM de base est déjà hyper optimisée mine de rien, je serais vraiment surpris de voir une différence de perfs qui soit significative. Certes c'est beau de dire «on utilise LLVM ça poutre sa race», mais la JVM a eu des années d'optimisation que le mode JIT de LLVM n'a pas eu (et pour l'avoir utilisé, c'est vraiment pas dans l'esprit de LLVM le JIT, j'en ferai un journal à l'occasion). Donc où sont les chiffres ?
Et essayer de prendre la place de Windows, iOS c'est mort aussi. Remplacer les linux, FreeBSD…ce sera difficile aussi.
Mon but dans la vie ? conquérir le monde !
La mode du cloud et du tout dans le navigateur web a cet avantage qu'il est désormais moins pénalisant d'être sur une plateforme exotique : de plus en plus de choses passent, lourdement, mais passent avec un navigateur web.
Du coup, pourquoi faudrait-il avoir pour seul but d'être premier sur un marché ? Nous ne sommes pas sur un projet d'entreprise mais un projet d'individus qui s'amusent. Et ça fait un bien fou…
Le soucis du web c'est que ça t'ajoute des tas de concepts à apprendre en plus de l'apprentissage de la programmation en elle-même.
Alors sur un hello nom, tu as du HTML et du JavaScript, ça peut passer.
Mais prenons un exemple tout simple : je veux afficher à l'écran le contenu d'un fichier (c'est avec ce genre d'exemple que j'apprenais quand j'étais petit). Pour faire ça en web, soit tu passes en 100% client avec des APIs de manipulation de fichier en JS (et je suis pas sûr qu'elles soient simples à manipuler), soit tu passes en client/serveur avec un upload de fichier à gérer. T'as à prendre en compte plein de concepts rigolos pour faire ça proprement. En desktop, avec Lazarus, tu as besoin de glisser sur ta fenêtre 1 bouton, un champ texte, un dialogue d'ouverture de fichiers, et écrire, grosso merdo…
Je ne dis pas que c'est la panacée. Mais ça permet d'apprendre un seul ensemble langage/bibliothèque, sans avoir en plus à y ajouter des notions de client/serveur.
Après quand j'étais vraiment petit, c'était le BASIC Thomson. Là c'était simple, et un casse briques tenait sur une page de code, donc pour apprendre c'était vraiment fun (enfin, je trouvais…)
D’une manière générale, le Web est probablement ce qui est le plus abordable en informatique.
Kof !
Après avoir dit qu'il faut connaître HTML, CSS, JavaScript côté client, plus un autre langage côté serveur… On partage pas le même principe pour «abordable». :)
J'aurais dit la programmation côté bureau avec un environnement comme Lazarus pour un truc abordable (mais la doc pêche, surtout en français). Tu apprends un langage, le Pascal, et tu ne fais du code que pour la logique de l'application. Rien à écrire pour la partie hyper pénible du dessin des interfaces graphiques. Le défaut par contre, c'est où on va après ça. Il me semble qu'on peut faire de l'Android et de l'iOS avec, mais n'ayant ni l'un ni l'autre je n'ai jamais tenté…
Plus sérieusement, étant donné l'architecture complètement différente des itanium par rapport aux x86, je ne suis pas certain que l'on puisse transposer le gain en performances entre les architectures… De plus, selon les logiciels utilisés et le niveau d'optimisation atteint (utiliser complètement le CPU d'un itanium semble être un art obscur) tu pourrais avoir un terrain bien plus favorable à l'HT.
Dans son autre usage, compilation et construction de paquets et de systèmes, j'ai pu mesurer les écarts sur un build complet:
Avec: 1h20
Sans: 1h30
Rien de spectaculaire.
Heu… 12,5% de pertes quand on désactive HT ça te suffit pas (Ou 11,11% de gain, on va pas chipoter) ? L'HT va pas faire un x2 en perfs, mais si l'HT était bien implémenté il serait idiot de ne pas l'activer.
Si encore une fois, la désactivation de l'Hyper-threading pourrait même avoir des effets positifs sur les performances, autant en finir une fois pour toute.
Comme souvent, les performances dépendent du cas envisagé pour la comparaison. L'hyper threading est positif pour les performances sur de nombreux cas, c'est pour cela qu'il est activé par défaut, ils sont pas idiots à ce point.
Vivement les détails sur cette faille en tout cas. Impacte-t-elle uniquement Intel ? Est-ce corrigeable par le microcode ? Le même principe serait-il exploitable contre du SPARC ou du POWER ?
L'intégration de la compilation à la volée avec LLVM des requêtes n'est pas assez mise en avant de manière générale.
Même sur des requêtes en dessous de la seconde, malgré les ~20 ms de compilation, on peut avoir une division par deux du temps d'exécution… C'est bluffant et «magique»…
Il s'appelle NotReleasedYet :)
J'ai prévu de faire un journal sur ça d'ici quelques semaines, le temps de stabiliser et d'implémenter assez de fonctionnalités pour que ça soit «montrable» sans honte…
Je pense que j'étais assez explicite précédemment : je bannis les applications web de ma machine, effectivement. Je préfère Marble à * Maps, mon client Slack en Qt au client Slack web, KMail à GMail, LibreOffice à Google Doc…
On se retrouve avec des "applications" terriblement lentes par rapport aux applications natives. Sur slack par exemple, il m'est arrivé d'attendre une seconde entre ma frappe au clavier et l'affichage dans le champ d'écriture de message. Je ne parle pas de l'envoi hein, juste l'affichage du message en cours de rédaction.
Et je ne vais pas parler de la consommation de RAM. Mon PC a 8GB de RAM, ce n'est pas pour la gâcher avec chaque application qui bouffe la RAM d'une instance de navigateur web.
On prend un afficheur de documents et on le transforme en plateforme d'exécution d'applications… Tout va bien ?
Les lobbys sont normaux et je dirais même nécessaires : ils ne sont fondamentalement que l'expression d'une partie des personnes morales impactées par les politiques. On ne peut avoir des députés et ministres fonctionnant en boucle fermée, sans retour possible de la part des administrés, ça serait catastrophique (et complètement impossible à mettre en place).
Nos parlementaires et nos ministres nationaux, et de fait nos députés européens, les membres du conseil et de la commission, sont tous influençable. Et si on élit des notaires qui se fichent des papiers qu'ils signent, alors on a donné plein pouvoir aux lobbys. Mais une constitution ou un traité ne saura bloquer les lobbys, c'est la nature humaine d'être influençable par ceux qui ont une grosse voix. Le but c'est justement de réussir à parler plus fort qu'eux.
Et c'est pas en pleurnichant sur le fait qu'en face ils sont méchants qu'on fera avancer les choses. Il faudrait qu'on propose des réponses concrètes à ce qui a poussé à ces idées (par ex. comment sauver la presse), et qu'on soit suffisamment nombreux et organisés pour l'exprimer, tous unis.
Mais en tout cas, l'Europe n'est pas plus victime de lobbys que les États qui en sont membres. En France, en Allemagne, en Belgique, dans chaque État, les lobbys sont là pour essayer de faire progresser leurs idées, leurs lois. Par contre il faut avoir un registre ouvert et librement consultable de ces lobbyistes.
Alleluia, nous sommes sur la même longueur d'ongle !
Après je suis méfiant sur les concertations au plus proche des habitants («not in my backyard», facilité de corruption locale par des subventions (coucou EDF, Areva))
Nous avons besoin d'une Europe forte, non libérale, et je doute qu'une démocratie locale résolve change cette orientation. Peut-être une démocratie à la grecque antique, avec nomination aléatoire de représentants ?
[^] # Re: Merci !
Posté par Pinaraf . En réponse au journal Ajouter un service sur le réseau façon Internet, « à l'ancienne ». Évalué à 6.
Hum, je ne vois pas comment tu fais.
Prenons un cas simple : SSH.
Imaginons que tu doives avoir obligatoirement du SFTP sur le port 22 pour un logiciel ne supportant pas autre chose (j'ai déjà vu ça avec des banques), mais que le port 22 est déjà utilisé pour ton SSH normal et que tu ne peux pas le bouger. Comment tu veux faire la distinction sans avoir deux adresses IP ? Au niveau réseau, le nom d'hôte disparait, tu reçois des paquets TCP à destination de 1.2.3.4:22. Éventuellement, ils peuvent contenir une info sur la cible, comme le SNI de HTTPS… Mais donc il faut que ton reverse proxy gère spécifiquement chaque protocole ?
Ça me parait juste infaisable sans avoir des adresses IP en stock… et donc sans IPv6 pour la plupart des gens qui veulent faire de l'auto-hébergement, ou sur le long-terme.
[^] # Re: Merci !
Posté par Pinaraf . En réponse au journal Ajouter un service sur le réseau façon Internet, « à l'ancienne ». Évalué à 5.
Et tu fais quoi pour un service qui ne soit pas en HTTP/HTTPS ? Je sais que c'est plus à la mode, mais y'a quand même des protocoles plus adaptés pour certaines taches que HTTP :)
[^] # Re: L’avenir et le passé
Posté par Pinaraf . En réponse au journal Ajouter un service sur le réseau façon Internet, « à l'ancienne ». Évalué à 5.
Malheureusement, ce que fait systemd est nécessairement invasif. À partir du moment où tu veux gérer les services comme ça, tu te retrouves à intégrer beaucoup de choses… Bon, réimplémenter un client SNTP ou DHCP, faut pas déconner, c'est pas nécessaire.
Une excellente présentation sur ce sujet, sans à mes yeux de fanatisme pro-systemd:
https://www.youtube.com/watch?v=o_AIw9bGogo
# Tant que le fonds fond pas…
Posté par Pinaraf . En réponse au lien Le fonds de développement de Blender a atteint son premier but : 25k€/mois (= 5 devs) . Évalué à 3.
Petite typo, on ne dit pas le fond mais le fonds…
Et super pour blender, en espérant que le fonds ne touche pas le fond :)
# Nul…
Posté par Pinaraf . En réponse au lien Liste à puce des raisons pour lesquelles vous devez arrêter de dire « tiret du 6 » ou « tiret du 8 ». Évalué à 10.
C'est parce que numerama a maintenant ce type de «contenu» que je ne mets plus dans mes catégories importantes de flux RSS…
Donc désormais l'azerty issu de l'IBM PC est l'azerty de Windows, il n'existe plus d'ordinateurs non Apple visibles par les plus jeunes, à part «les vieux Compaq de la salle de technologies du collège» (Compaq, disparu en 2002)…
Leur but semble d'être juste de faire à peu de frais du contenu qui apportera assez de clics pour la pub.
[^] # Re: Pourquoi en basic?
Posté par Pinaraf . En réponse à la dépêche Sortie de Gambas 3.12. Évalué à 3.
Il y a également Lazarus (Freepascal) qui est pas mal du tout en tout intégré. J'attends que Gambas 3.12 soit dans ma debian pour jouer un peu avec, par contre l'absence de support de windows va m'empêcher de le mettre en avant auprès de connaissances qui n'ont pas accès à mieux aujourd'hui que Excel/Access et les macros :/
[^] # Re: telle est la question
Posté par Pinaraf . En réponse au lien Talos 2 - POWER9 : du vrai-vrai open hardware cette fois? . Évalué à 3.
Raptor CS affirme que le microcode est ouvert. Et le POWER est développé par la fondation OpenPOWER, où tout le monde peut devenir membre. Donc ça semble plus ouvert que fermé…
[^] # Re: Octave ?
Posté par Pinaraf . En réponse à la dépêche Un peu d’Open Hardware pour la rentrée (et beaucoup de LinuxBoot). Évalué à 10. Dernière modification le 01 septembre 2018 à 19:31.
Alors je ne connais pas la relation entre vejmarie et OVH/Octave, mais ayant travaillé un certain temps à OVH je peux donner des pistes d'interprétation.
OVH se vante d'innover notamment sur le matériel, d'embrasser l'open source, de contribuer… Du coup des projet comme coreboot ou linuxboot, qui peuvent apporter moultes avantages pour des grands opérateurs de réseau, devraient intéresser et pousser à contribuer le «n°1 européen du cloud».
Mais à moins d'un changement radical depuis mon départ il y a 3 ans, OVH n'est qu'un intégrateur, gros certes, mais un intégrateur, donc je les vois vraiment mal contribuer à linuxboot. D'autant plus que pour ce qui est du cloud, ils sont maqués depuis longtemps avec VMWare, et le private cloud à base de VMWare étant devenu une belle vache à lait (au sens économique), à moins que VMWare se mette à certifier des machines sous linuxboot pour ESXI… c'est vraiment pas près d'arriver.
[^] # Re: Argument fallacieux
Posté par Pinaraf . En réponse au journal quand Oracle fait les affaires de Azul.. Évalué à 10. Dernière modification le 22 août 2018 à 17:31.
J'aurais mieux fait de fermer ma gueule :)
Ça viendra, mais faut d'abord que je fasse tout un gros dev avec une vraie bibliothèque de JIT pour comparer proprement. Du coup ça va être long. Le cœur du problème pour les cas que j'ai vu : le code est émis en une seule fois (lourdement), et jamais revu après. Et je suis tombé sur au moins un cas où une phase d'optimisation indispensable pour de bonnes perfs est dans l'étape de codegen, qui n'est pas configurable.
Dans le cas qui m'intéresse, PostgreSQL 11, je suis convaincu de l'utilité du JIT par LLVM pour les grosses requêtes où le gain CPU va exploser le temps de compilation requis, mais je suis certain que ça sera en dessous des performances d'un vrai compilateur à la volée, et même dans certains cas en dessous des performances de PG sans compilation (cf. http://www.postgresql-archive.org/PATCH-LLVM-tuple-deforming-improvements-td6029385.html par exemple). Par contre, une solution bien plus légère de compilation/optimisation progressive du bytecode… ça devrait couvrir cette deuxième partie du spectre.
Je pense que les cas de unladden swallow (interpréteur python utilisant LLVM - http://qinsb.blogspot.com/2011/03/unladen-swallow-retrospective.html) ou encore de webkit (abandon de LLVM pour le JIT - https://webkit.org/blog/5852/introducing-the-b3-jit-compiler/) sont assez clairs. Il est des cas que LLVM couvre excellemment, mais il ne faut absolument pas croire qu'il s'agit là du marteau universel. Ce marteau n'existe pas :)
Les langages dynamiques, l'absence d'optimisation progressive avec retour arrière… ce sont des défis que LLVM ne peut pas relever aujourd'hui. LLVM est conçu avec un modèle complètement statique, parfait pour de nombreux langages. Pour Java, à voir, mais je pense que des choses comme invokeddynamic risquent d'y perdre des plumes.
# Argument fallacieux
Posté par Pinaraf . En réponse au journal quand Oracle fait les affaires de Azul.. Évalué à 10.
Marmotte + chocolat + aluminium…
Aucune JVM, aucun compilateur au monde ne saura lutter contre le bâclage du développement.
Je vais prendre un exemple tout simple où je ne vois pas comment un outil aurait pu corriger le soucis. C'était il y a quelques années, je travaillais sur un interpréteur (très) mal codé pour un langage basic-esque quelconque (j'insiste sur la deuxième syllabe). Un bytecode était généré en mémoire, puis exécuté dans plusieurs threads en même temps (avec des données différentes). Et le temps d'exécution était linéaire avec le nombre de threads. 1 thread − 10 secondes, 2 threads − 20 secondes, 3 threads − 30 secondes (véridique).
Après quelques heures d'analyse, j'ai trouvé qu'à chaque exécution d'une instruction du bytecode, un lock était pris sur un tableau partagé entre tous les threads. Il a suffit de s'assurer que le tableau soit en lecture seule pour tout le monde pour supprimer le lock et avoir un temps linéaire, mais dans le bon sens.
Je n'ai pas fait de Java depuis trop longtemps pour donner des exemples concrets de synchronized et cie, mais ce genre de situation est bien trop courante et surtout hors d'atteinte des VMs ou des compilateurs. Quand bien même tu prouvais que la variable est effectivement bien en lecture seule passé un certain point, c'est un prédicat trop fragile s'il n'est pas garanti par le code, sinon les performances seront aléatoires : un petit changement casse cette optimisation et c'en est fini.
Et quand bien même cette VM était magiquement rapide… la JVM de base est déjà hyper optimisée mine de rien, je serais vraiment surpris de voir une différence de perfs qui soit significative. Certes c'est beau de dire «on utilise LLVM ça poutre sa race», mais la JVM a eu des années d'optimisation que le mode JIT de LLVM n'a pas eu (et pour l'avoir utilisé, c'est vraiment pas dans l'esprit de LLVM le JIT, j'en ferai un journal à l'occasion). Donc où sont les chiffres ?
[^] # Re: Projet intéressant académiquement
Posté par Pinaraf . En réponse à la dépêche Haiku a 17 ans. Évalué à 7.
Mon but dans la vie ? conquérir le monde !
La mode du cloud et du tout dans le navigateur web a cet avantage qu'il est désormais moins pénalisant d'être sur une plateforme exotique : de plus en plus de choses passent, lourdement, mais passent avec un navigateur web.
Du coup, pourquoi faudrait-il avoir pour seul but d'être premier sur un marché ? Nous ne sommes pas sur un projet d'entreprise mais un projet d'individus qui s'amusent. Et ça fait un bien fou…
# Lecteur de flux RSS…
Posté par Pinaraf . En réponse au journal Recherche sur DLFP. Évalué à 7.
J'utilise mon lecteur de flux RSS pour chercher toutes les publications depuis 2008. C'est en général suffisant. :)
[^] # Re: Apprendre le codage, développeur web, etc ?
Posté par Pinaraf . En réponse à la dépêche 20 ans de LinuxFr.org : entretiens avec les visiteurs (1). Évalué à 4.
Le soucis du web c'est que ça t'ajoute des tas de concepts à apprendre en plus de l'apprentissage de la programmation en elle-même.
Alors sur un hello nom, tu as du HTML et du JavaScript, ça peut passer.
Mais prenons un exemple tout simple : je veux afficher à l'écran le contenu d'un fichier (c'est avec ce genre d'exemple que j'apprenais quand j'étais petit). Pour faire ça en web, soit tu passes en 100% client avec des APIs de manipulation de fichier en JS (et je suis pas sûr qu'elles soient simples à manipuler), soit tu passes en client/serveur avec un upload de fichier à gérer. T'as à prendre en compte plein de concepts rigolos pour faire ça proprement. En desktop, avec Lazarus, tu as besoin de glisser sur ta fenêtre 1 bouton, un champ texte, un dialogue d'ouverture de fichiers, et écrire, grosso merdo…
Je ne dis pas que c'est la panacée. Mais ça permet d'apprendre un seul ensemble langage/bibliothèque, sans avoir en plus à y ajouter des notions de client/serveur.
Après quand j'étais vraiment petit, c'était le BASIC Thomson. Là c'était simple, et un casse briques tenait sur une page de code, donc pour apprendre c'était vraiment fun (enfin, je trouvais…)
[^] # Re: Apprendre le codage, développeur web, etc ?
Posté par Pinaraf . En réponse à la dépêche 20 ans de LinuxFr.org : entretiens avec les visiteurs (1). Évalué à 3.
Kof !
Après avoir dit qu'il faut connaître HTML, CSS, JavaScript côté client, plus un autre langage côté serveur… On partage pas le même principe pour «abordable». :)
J'aurais dit la programmation côté bureau avec un environnement comme Lazarus pour un truc abordable (mais la doc pêche, surtout en français). Tu apprends un langage, le Pascal, et tu ne fais du code que pour la logique de l'application. Rien à écrire pour la partie hyper pénible du dessin des interfaces graphiques. Le défaut par contre, c'est où on va après ça. Il me semble qu'on peut faire de l'Android et de l'iOS avec, mais n'ayant ni l'un ni l'autre je n'ai jamais tenté…
# Joyeux nanniversaire DLFP
Posté par Pinaraf . En réponse à la dépêche 20 ans de LinuxFr.org : entretiens avec les visiteurs (1). Évalué à 10. Dernière modification le 09 juillet 2018 à 15:57.
Encore heureux que le code d'un ERP soit d'excellente facture… :)
[^] # Re: HT et performances...
Posté par Pinaraf . En réponse au journal Rumeurs sur l'hyper-threading - TLBleed . Évalué à 5.
Chanceux, des itanium…
Plus sérieusement, étant donné l'architecture complètement différente des itanium par rapport aux x86, je ne suis pas certain que l'on puisse transposer le gain en performances entre les architectures… De plus, selon les logiciels utilisés et le niveau d'optimisation atteint (utiliser complètement le CPU d'un itanium semble être un art obscur) tu pourrais avoir un terrain bien plus favorable à l'HT.
[^] # Re: HT et performances...
Posté par Pinaraf . En réponse au journal Rumeurs sur l'hyper-threading - TLBleed . Évalué à 7.
Heu… 12,5% de pertes quand on désactive HT ça te suffit pas (Ou 11,11% de gain, on va pas chipoter) ? L'HT va pas faire un x2 en perfs, mais si l'HT était bien implémenté il serait idiot de ne pas l'activer.
# HT et performances...
Posté par Pinaraf . En réponse au journal Rumeurs sur l'hyper-threading - TLBleed . Évalué à 10.
Comme souvent, les performances dépendent du cas envisagé pour la comparaison. L'hyper threading est positif pour les performances sur de nombreux cas, c'est pour cela qu'il est activé par défaut, ils sont pas idiots à ce point.
Vivement les détails sur cette faille en tout cas. Impacte-t-elle uniquement Intel ? Est-ce corrigeable par le microcode ? Le même principe serait-il exploitable contre du SPARC ou du POWER ?
[^] # Re: Retour d'expérience
Posté par Pinaraf . En réponse au journal Sortie de Sailfish OS 2.2.0. Évalué à 3.
J'ai eu un hardreset sur mon Jolla 1 également, mais depuis toutes les mises à jour sont passées sans soucis et je suis actuellement en 2.2.0…
# JIT
Posté par Pinaraf . En réponse au lien Un grand tour des nouveautés de PostgreSQL 11 qui arrive bientôt. Évalué à 5.
L'intégration de la compilation à la volée avec LLVM des requêtes n'est pas assez mise en avant de manière générale.
Même sur des requêtes en dessous de la seconde, malgré les ~20 ms de compilation, on peut avoir une division par deux du temps d'exécution… C'est bluffant et «magique»…
[^] # Re: Et avec Github...
Posté par Pinaraf . En réponse au journal Microsoft rachète Github. Évalué à 7.
Il s'appelle NotReleasedYet :)
J'ai prévu de faire un journal sur ça d'ici quelques semaines, le temps de stabiliser et d'implémenter assez de fonctionnalités pour que ça soit «montrable» sans honte…
[^] # Re: Et avec Github...
Posté par Pinaraf . En réponse au journal Microsoft rachète Github. Évalué à 9.
Je pense que j'étais assez explicite précédemment : je bannis les applications web de ma machine, effectivement. Je préfère Marble à * Maps, mon client Slack en Qt au client Slack web, KMail à GMail, LibreOffice à Google Doc…
[^] # Re: Et avec Github...
Posté par Pinaraf . En réponse au journal Microsoft rachète Github. Évalué à 10.
On se retrouve avec des "applications" terriblement lentes par rapport aux applications natives. Sur slack par exemple, il m'est arrivé d'attendre une seconde entre ma frappe au clavier et l'affichage dans le champ d'écriture de message. Je ne parle pas de l'envoi hein, juste l'affichage du message en cours de rédaction.
Et je ne vais pas parler de la consommation de RAM. Mon PC a 8GB de RAM, ce n'est pas pour la gâcher avec chaque application qui bouffe la RAM d'une instance de navigateur web.
On prend un afficheur de documents et on le transforme en plateforme d'exécution d'applications… Tout va bien ?
[^] # Re: Les fameux «ces gens de l'Europe»
Posté par Pinaraf . En réponse au journal La fin de l'internet est proche!. Évalué à 8.
Les lobbys sont normaux et je dirais même nécessaires : ils ne sont fondamentalement que l'expression d'une partie des personnes morales impactées par les politiques. On ne peut avoir des députés et ministres fonctionnant en boucle fermée, sans retour possible de la part des administrés, ça serait catastrophique (et complètement impossible à mettre en place).
Nos parlementaires et nos ministres nationaux, et de fait nos députés européens, les membres du conseil et de la commission, sont tous influençable. Et si on élit des notaires qui se fichent des papiers qu'ils signent, alors on a donné plein pouvoir aux lobbys. Mais une constitution ou un traité ne saura bloquer les lobbys, c'est la nature humaine d'être influençable par ceux qui ont une grosse voix. Le but c'est justement de réussir à parler plus fort qu'eux.
Et c'est pas en pleurnichant sur le fait qu'en face ils sont méchants qu'on fera avancer les choses. Il faudrait qu'on propose des réponses concrètes à ce qui a poussé à ces idées (par ex. comment sauver la presse), et qu'on soit suffisamment nombreux et organisés pour l'exprimer, tous unis.
Mais en tout cas, l'Europe n'est pas plus victime de lobbys que les États qui en sont membres. En France, en Allemagne, en Belgique, dans chaque État, les lobbys sont là pour essayer de faire progresser leurs idées, leurs lois. Par contre il faut avoir un registre ouvert et librement consultable de ces lobbyistes.
Et d'ailleurs :
http://ec.europa.eu/transparencyregister/public/consultation/displaylobbyist.do?id=789158412311-88
T'as raison, faut bannir les lobbys, y'a des hippies à cheveux gras qui veulent contacter nos députés.
[^] # Re: Les fameux «ces gens de l'Europe»
Posté par Pinaraf . En réponse au journal La fin de l'internet est proche!. Évalué à 2.
Alleluia, nous sommes sur la même longueur d'ongle !
Après je suis méfiant sur les concertations au plus proche des habitants («not in my backyard», facilité de corruption locale par des subventions (coucou EDF, Areva))
Nous avons besoin d'une Europe forte, non libérale, et je doute qu'une démocratie locale résolve change cette orientation. Peut-être une démocratie à la grecque antique, avec nomination aléatoire de représentants ?