Le fameux cycle du hype. Je souhaite à Rust d'arriver rapidement à la 4ème puis à la cinquième phase sans trop souffrir des deux précédentes.
Java, Python et C# en sont déjà passé par là, maintenant ils ont trouvé leur place. Ils ont probablement pris une partie de la place qui était occupée il y a 20 ou 30 ans par C ou C++, qui sont maintenant plutôt utilisés dans les applications ou il y a besoin de performance, alors qu'avant ils étaient utilisés vraiment partout (faute d'avoir beaucoup d'autre choix et parce que le matériel disponible à l'époque faisait que toutes les applications avaient un peu plus besoin de faire attention aux performances).
Il semble qu'on aura une phase de "c'est trop génial ça va tout remplacer" à la sortie de chaque nouveau langage.
Je dirais que le langage est encore relativement jeune et qu'on manque un peu de recul sur les choses qui pourraient mal se passer avec.
Et aussi que c'est compliqué pour l'instant de trouver des gens avec un peu d'expérience en Rust pour bien architecturer les nouveaux projets dès le départ.
C'est sympa de la part de Microsoft de prendre les devants et de faire ces expériences pour nous :)
Au niveau OS, les programme en C allouent leur mémoire dans un seul segment appelé le tas, dont la taille est ajustée avec sbrk(2). Cette taille de tas est augmenté lorsque la mémoire libre n'est pas suffisante; a ma connaissance elle n'est jamais diminuée car cela nécessiterait une défragmentation de l'espace mémoire du processus.
Attention à ne pas mélanger 2 choses: sur un système moderne (après 1990) on a de la mémoire virtuelle et une MMU.
Cela veut dire qu'il faut bien distinguer l'allocation d'espace mémoire dans un processus, et l'allocation de mémoire physique pour remplir cet espace.
L'ajustement de taille avec sbrk, ça permet seulement de réserver de l'espace mémoire, qui du coup ne sera plus disponible pour d'autres choses utilisant de la mémoire (mmap, la pile d'exécution, …). L'espace mémoire étant isolé dans chaque processus, ça n'a pas de sens de libérer de l'espace mémoire à l'usage d'un autre processus.
D'autre part, il y a la mémoire physique. Là, on peut allouer et désallouer page par page (4Ko habituellement, mais on commence à voir des "huge pages" de 1Mo pour réduire la charge de travail du MMU) et les pages libérées peuvent être utilisées par d'autres programmes. Il n'y a pas de problème de fragmentation, les pages sont de taille fixe et peuvent être insérées à n'importe quelle adresse dans l'espace mémoire d'un processus.
Même en ayant réservé de l'espace avec sbrk, on est pas obligé de garder cet espace entièrement rempli de pages mémoires disponibles. On peut allouer les pages pour remplir cet espace au moment ou elles sont utilisées, et les libérer lorsque c'est possible ou nécessaire.
La raison pour laquelle on ne le fait pas immédiatement dès qu'une page est disponible, ce sont les performances. Déjà le fait de reconfigurer le MMU pour ajouter ou enlever une page coûte pas mal de temps, mais en plus, il faut effacer le contenu de la page, afin que une autre application ne puisse pas y trouver des traces de l'occupant précédent (ce serait embêtant pour la sécurité du système). Donc ce mécanisme de remise à disposition de page mémoires peut être déclenché seulement lorsque le système commence à être à court de pages à allouer, il va pouvoir demander aux applications de faire du ménage si elles peuvent et de retourner les pages inutilisées à ce moment là.
J'ai fait du dev en Java pour des cibles embarquées avec quelques centaines de kilo-octets de RAM. Avec un garbage collector.
Et ben on était bien content, non pas parce que c'est rapide, mais surtout parce que ça permettait de déplacer les objets en mémoire de façon transparente pour le code. On pouvait donc défragmenter la mémoire et ainsi libérer de grands espaces contigus pour pouvoir allouer de gros objets.
De la même façon, les stacks pour les threads pouvaient être allouées dynamiquement par tout petits blocs (quelques dizaines ou centaines d'octets à la fois) en fonction des besoins de chaque thread.
La consommation mémoire était donc bien inférieure à un code essayant de faire la même chose en C. Et ça justifiait largement de dédier un peu de puissance CPU au garbage collector.
The Perl 5 team have developed an annual release cycle, where a new version is released in about May of every year. Version 5.36 was released in May 2022 and is very different to version 5.6.0, which was current back in the summer of 2000. In this article, we’ll look at some of the new Perl features that you might have missed.
L'article dit aussi comment activer ces fonctionnalités:
use 5.36; # Turns on all new 5.36 (and earlier) features
Il s'agit donc bien d'un article tout récent sur la version 5.36 de Perl?
Je m'attendais donc à un résumé des fonctionnalités ajoutées ces 20 dernières années. Alors, soit l'article est mal fichu (ce qui est possible, je je suis pas Perl de très près), soit il ne s'est vraiment rien passé de plus intéressant pendant 20 ans?
Qu'est-ce qui a conduit l'auteur de l'article à choisir des choses qui auraient du déjà être faites depuis 40 ans pour présenter les nouveautés du langage? Quelles sont les vraies nouveautés intéressantes qu'il a choisi de ne pas présenter?
Est-ce que finalement, le fait qu'il y ait peu de changements n'est pas le meilleur aspect de Perl, enfin un langage stable avec lequel on peut écrire des logiciels qui continueront à fonctionner sans problème pour des dizaines d'années?
On peut nommer les paramètres des fonctions (ça existe en C, Pascal, … depuis le millénaire précédent), les descripteurs de fichiers ne sont pas forcément des variables globales (ça existe en C, Pascal, … depuis le millénaire précédent), et on a une fonction qui affiche des chaînes de caractères avec un retour à la ligne (ça existe en C, Pascal, … depuis le millénaire précédent). Bienvenue dans les années 80, Perl?
Et la prochaine étape c'est les années 90 avec de la programmation orientée objet.
Je te trouves un peu dur. Netsurf a 15ans, le navigateur de SerenityOS n'en a même pas deux.
Je n'ai pas dit que Serenity faisait un mauvais travail côté technique ou sur aucun autre sujet, juste qu'ils etaient meilleurs en communication. Je dirais plutôt qu'on a des choses à apprendre de ce projet
Libre à toi de porter netsurf si ce n'est pas déjà fait.
Je m'occupe déjà de la version de NetSurf pour Haiku (packaging et développement du code du frontend, malheureusement, je ne peux pas tout faire moi-même…
NetSurf est un moteur de rendu portable, et ils fournissent un "frontend" natif différent pour chaque OS. Certains sont plus avancés que d'autres et proposent plus ou moins de fonctionalités.
Le test acid3 original ne passe pas à plus de 97% suraucun navigateur moderne en raison de protections de sécurité.
Soit Ladybird n'est pas sécurisé contre les attaques cross-origin, soit ils ont utilisé une version modifiée du test.
De plus, ce test ne fait pas tout et le rendu sur des "vraies" pages est beaucoup plus décevant. Souvent moins bon que NetSurf qu'il est dommage de voir complètement ignoré alors qu'ils font un très bon travail sur le développement d'un moteur léger et performant depuis plus d'une dizaine d'années… L'équipe autour de Serenity est visiblement plutôt douée en terme de communication, on entend beaucoup parler d'eux :)
Je ne comprend pas bien quelle est la proposition. Est-ce que c'est de dire à Debian, Ubuntu, Arch, etc d'abandonner leurs formats de paquets et de compiler leurs propres Flatpaks? Auquel cas ça ne résoud pas vraiment les problèmes soulevés: on pourra toujours avoir la mauvaise version d'une lib, un exécutable qui a le même nom qu'un autre, etc.
Ou bien est-ce que l'idée c'est de laisser les développeurs d'applications faire leur packaging et de retirer les applis du dépôt des distributions? Auquel cas, qui va s'occuper des mises à jour de sécurité et du support LTS? Bon l'auteur parle de Arch donc je suppose que le support LTS avec une version fixe de tout les paquets et seulement des mises à jour de sécurité ne l'intéresse pas.
Mon expérience là dessus c'est que la seule façon de passer le relais c'est de démissionner et de dire que si personne ne se porte volontaire l'association sera dissoute.
Sous la menace on finit par trouver des volontaires. Et il vaut mieux le faire avant d'être en burn-out. Un truc qui marche pas mal c'est de renouveler une partie du bureau tous les 3 ans: un an pour apprendre, un an pour faire, un an pour transmettre. J'ai fait partie d'associations ou ce mandat de 3 ans éta?t noté dans les statuts justement pour éviter que tout le monde repose sur le bureau existant.
Le passage de relais n'est pas facile et le nouveau bureau ne fera pas forcément les choses comme vous les auriez faites/sera moins impliqué/etc. Si ça ne vous convient pas, acceptez le fait que c'est votre association et que vous êtes président à vie.
Le tour de force de Rust c'est d'arriver à faire "presque aussi bien" que Ada de ce point de vue (toutes proportions gardées, mais en comparant au C et C++) mais avec uniquement des vérifications à la compilation et pas à l'exécution.
Ce qui change pas mal du point de vue des performances.
C'est aussi vrai qu'on a pas forcément besoin de tant de performances partout. Mais parfois oui.
On peut donc penser que Rust se trouvera une place confortable quelque part entre Ada (très sécurisé mais moins performant) et C++ (plutôt pas sécurisé, mais possibilités d'optimisations importantes).
Interrupteur étant sur le réseau personnel et fonctionnant avec une plateforme cloud du fabricant, qu'il y a-t-il pas un risque ?
Oui.
Au niveau du fonctionnement, en général, la prise va se connecter au "cloud" du fabricant (ce sera peut être juste un serveur, peut être un cloud sous-traité chez Azure, AWS ou autre), ainsi c'est une connexion sortante et il n'y a pas besoin de configurer de pare-feu pour ça.
L'application Android se connecte au même cloud et c'est ce dernier qui relaie les messages.
Les risques sont:
Quelqu'un pourrait prendre le contrôle à distance de la prise s'il trouve un moyen de contourner les protections mises en place. Si rien n'est open source il faudra faire confiance au fabricant pour avoir tout bien chiffré et sécurisé.
Si le fabricant décide d'arrêter son service de cloud, plus rien ne fonctionne.
Il existe aussi des systèmes qui ne dépendent pas du cloud, par exemple https://energenie.com/item.aspx?id=7416 qui se pilote avec une interface web embarquée (un simple navigateur web suffit) ou via des requêtes REST. Par défaut ce n'est pas accessible de l'extérieur du réseau sur lequel c'est connecté.
(je ne recommande pas spécifiquement ce modèle pour d'autres raisons: a priori il a une durée de vie d'environ 2 ans, après quoi, les relais qui connectent/déconnectent les prises ne fonctionne plus correctement).
L'avantage par rapport à Telegram: le serveur est en logiciel libre, pour Telegram ce n'est pas le cas. Tu n'as donc absolument aucune idée de ce qui est fait avec tes messages côté serveur.
De plus, il y a plusieurs serveurs et tu peux aussi héberger le tien. Dans un contexte professionnel, on a fait ça dans mon entreprise il y a quelques temps (serveur interne pas connecté avec le reste du réseau XMPP). Alors bien sûr, dans ce cas, c'est plus d'infrastructure à mettre en place, mais ça permet d'avoir la main sur tout le service et d'être sûr que les messages ne sont pas diffusés et stockés n'importe où.
Justement, avec du HTML bien fait ça ne devrait poser aucun problème.
On devrait avoir des emails qui ressemblent à ça. Pas des trucs qui clignotent comme un sapin de Noël.
Et du coup ça se redimensionne bien à la taille de la police de caractères et à la taille de la fenêtre dans laquelle on l'affiche. Où à la taille du papier si on l'imprime.
Ce n'est pas le cas avec les emails au format texte où c'est l'expéditeur qui choisit combien de caractères par ligne il veut mettre. Par exemple sur mon téléphone, si quelqu'un envoie un mail avec une ligne un peu trop longue, mon téléphone réduit la taille du texte pour faire rentrer cette ligne sur une ligne, et tant pis si ça donne une taille de texte microscopique. Ou alors, il ne le fait pas, et il faut faire défiler le mail de gauche à droite pour le lire.
On peut commencer à se dire qu'on va reformater le texte et ajouter ou supprimer des retours à la ligne là ou ça va bien mais, ce n'est pas comme ça que les mails au format texte sont supposés fonctionner. D'où l'introduction du HTML qui permet de
transporter du texte en indiquant clairement les endroits ou il y a des paragraphes normaux, et les endroits ou il y a un schéma en ASCII art par exemple, qu'il ne faut surtout pas transformer sous peine de les rendre incompréhensibles.
les liens dans les emails sont presque toujours du spam
Je dirais qu'on se rend pas compte à quel point on utilise souvent des liens dans des emails. Moi c'est tout le temps (aussi bien en envoi qu'en réception) et ça m'embêterait bien de pas pouvoir faire autrement.
Je pense pas que le problème soit technique, pouvoir envoyer des mails au format HTML, c'est super, et ça peut s'afficher beaucoup mieux que le format texte préhistorique avec ses retours à la ligne tout moisis (tu as toi-même constaté ce problème malgré la tentative d'activer une option pour contourner le souci).
On peut faire du HTML léger avec juste quelques tags là ou c'est utile.
ça me rappelle les débats sur UTF-8 qui faisait perdre quelques octets par rapport aux encodages historiques. Certes, mais ça ouvre tellement de possibilités et simplifie tellement de choses.
Faire de la frugalité en HTML ne pose pas vraiment problème, en fait.
Pour ma part travailler chez moi ça voudrait dire partager l'espace (limité) dans mon appartement avec ma colocataire. Ce qui, en plus des problèmes d'organisation et de vie commune, pose aussi des problèmes de confidentialite des données.
Il faudrait donc que je déménage dans un logement avec une ou deux pièces en plus, ou alors que je travaille dans mon lit (pas bon pour mon dos). Et les 10€ par mois d'indemnité téléravail proposés par mon entreprise (pour 2 jours par semaine) ne permettent pas de financer ça (ça paie même pas la différence de facture d'électricité). Donc ce serait surtout des économie pour l'entreprise et un report des coûts sur les employés.
J'ai eu aussi des problèmes de droit à la déconnexion avec mon chef qui m'appelle 2h après la fin de ma journée de travail pour "juste une petite question", ou juste de mon propre fait defaire un "je finis jutse un truc" jusqu'à 23h… ou encore les mails et appels téléphoniques qui continuent d'arriver pendant la pause déjeuner.
Côté transports je suis privilégié avec seulement 10 minutes de vélo, certes.
Bref, dans mon cas le fait d'avoir un endroit dédié pour le travail ou je peux laisser tous mes problèmes professionnels le soir est essentiel à mon bon équilibre. Tant mieux pour vous si vous vous portez mieux sans, mais c'est pas le cas de tout le monde.
Et ceci indépendament des aspects "sociabilisation". Y'a des jours ou je suis tout seul dans mon openspace avec tous les collègues en télétravail et je prèfére toujours ça plutot que de travailler chez moi.
En effet, l'article ne dit rien sur le ressenti des employé.es chez Apple. Certes, l'entreprise a continué a fonctionner et a gagné plein de sous.
Il y a probablement des gens très content de faire du télétravail et d'autres beaucoup moins. Ça dépend de la culture d'entreprise, de l'aménagement des bureaux, de la distance à parcourir pour s'y rendre, du moyen de transport utilisé, de la sympathie des collègues, de la place disponible chez soi hour travailler, de la façon dont on gère la déconnection, et des goûts personnels de chacun.
Aucune info là-dessus dans l'article. Qui sait, peut-être que les employés d'Apple ont vraiment demandé en majorité (mais certainement pas à l'unanimité) à revenir sur place?
Soit on fait du matériel super-compliqué qui est facile à programmer, mais qui coûte cher et qui est peu flexible.
Soit on fait du matériel simple, pas cher, qui peut faire plein de trucs, mais qui demande beaucoup de logiciel pour fonctionner.
Comme la deuxième solution coûte moins cher pour le même résultat, c'est celle là qui est utilisée.
Il y a quelques dizaines d'années, le compromis était différent parce que les machines avaient peu de CPU et de mémoire. Aujourd'hui ces ressources sont en général largement disponibles. Il existe toujours du matériel de lapremière catégorie, par exemple des interfaces réseau qui font tout plein de trucs en interne. Sauf qu'en fait, elles contienne simplement un CPU spécialisé, pour toujours la même raison: c'est moins cher et plus flexible.
Je ne vois pas bien comment on peut vérifier la validité d'un diplôme si on ne fait pas confiance à l'université qui l'a délivré.
On peut donc avoir une université qui signe tous ses diplômes chaque année et publie les clés permettant de vérifier cette signature. C'est une bête signature numérique et il y a pas besoin de blockchain.
C'est bien ce qui a déjà été dit: la blockchain permet de faire des trucs en se passant d'un tiers de confiance, mais c'est une solution en quête d'un problème, parce que c'est beaucoup plus simple d'avoir un tiers de confiance. Sauf peut-être si on est libertarien ou complotiste
ReactOS avance doucement et on est pas tellement en concurrence. La technodiversité, c'est bien, et avoir plusieurs choix de système permet de stimuler le développement et de motiver les différentes équipes. Et à chacun de trouver son système préféré en fonction de ses besoins!
est ce que les logiciels ordinaires (libreoffice, gimp, openshot, vlc, thundie, firefox, opera, brave, falkon et autres vivaldi) pourraient tourner dessus?
Pas tous, pour l'instant.
Libreoffice est disponible ainsi que la plupart des logiciels basés sur Qt. Les logiciels basés sur GTK devraient arriver petit à petit. Pour les navigateurs web par contre, c'est compliqué, les moteurs sont très complexes et utilisent beaucoup de fonctionalités du système à tous les niveaux. Sans compter que, par exemple, Google qui maintient Blink (et donc Chromium, Vivaldi, Opera…) est carrément hostile au fait de le voir fonctionner sur des systèmes autres que Linux, Windows et MacOS et rejette les patch à cet effet. Pour Firefox, personne ne s'est lancé dans un portage récemment à ma connaissance.
Le mieux pour voir les logiciels actuellement disponibles sans installer Haiku, c'est de regarder le site Haiku Depot Server qui est une interface web pour les dépôts de logiciels.
Pour ma part j'utilise Haiku autant que possible, cependant je ne pense pas qu'il soit raisonnable pour le moment de l'utiliser comme unique système.
En vrai ça pourrait être utile si l'ordre entre les éléments n'est pas un ordre total. Dans ce cas il peut en effet y avoir plusieurs maximums (éléments qui sont sont supérieurs à tous les autres, soit n'ont pas de comparaison définie avec les autres).
En effet, je compare le C (avec ni exceptions ni destructeurs) avec le C++ (avec exceptions et destructeurs). Voyons la solution intermédiaire ou on aurait droit aux destructeurs mais pas aux exceptions.
Ok, on passe de:
faire_un_truc();
à:
if(faire_un_truc())return;
En admettant qu'on enlève les accolades pour gagner un maximum, on est quand même à 50% des lignes qui ne sont là que pour la gestion d'erreur. Et ça c'est dans un code simple ou il n'y a pas de boucles ou autres structures de contrôle compliquées.
Mais, si on écrit le code comme ça, au-delà du bête calcul sur le nombre de lignes utiles, tout le code qui fait des trucs est "caché" dans des if() qui vérifient si les fonctions ont fonctionné. Et là on est dans un cas ou la fonction retourne juste un bool pour dire si elle a fonctionné. Mettons qu'on veut par exemple ouvrir un fichier.
Et ça c'est juste en regardant une fonction de très près. La classe ou structure Fichier va être plus compliquée: il faut une méthode Ouvrir qui retourne une erreur, il faut un destructeur qui vérifie si le fichier est vraiment ouvert avant de le fermer.
Et là on a toujours une seule ressource dans cette fonction. Quand il y en a 2 ou plus, la complexité de la gestion d'erreur va augmenter. Il y a le risque d'oublier un cas d'erreur et de ne pas mettre un if là ou il faudrait, et de se retrouver avec un objet dans un état invalide (on peut avoir un objet Fichier qui ne correspond pas à un vrai fichier, soit parce qu'on n'a pas encore appelé la méthode Ouvrir, soit parce que la méthode a rencontré une erreur).
[^] # Re: La fin de la "stabilite" des standards ?
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au lien It's time to stop using C and C++ for new projects, says Microsoft Azure CTO. Évalué à 5.
Le fameux cycle du hype. Je souhaite à Rust d'arriver rapidement à la 4ème puis à la cinquième phase sans trop souffrir des deux précédentes.
Java, Python et C# en sont déjà passé par là, maintenant ils ont trouvé leur place. Ils ont probablement pris une partie de la place qui était occupée il y a 20 ou 30 ans par C ou C++, qui sont maintenant plutôt utilisés dans les applications ou il y a besoin de performance, alors qu'avant ils étaient utilisés vraiment partout (faute d'avoir beaucoup d'autre choix et parce que le matériel disponible à l'époque faisait que toutes les applications avaient un peu plus besoin de faire attention aux performances).
Il semble qu'on aura une phase de "c'est trop génial ça va tout remplacer" à la sortie de chaque nouveau langage.
# Est-ce que c'est pas un peu tôt?
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au lien It's time to stop using C and C++ for new projects, says Microsoft Azure CTO. Évalué à 3.
Je dirais que le langage est encore relativement jeune et qu'on manque un peu de recul sur les choses qui pourraient mal se passer avec.
Et aussi que c'est compliqué pour l'instant de trouver des gens avec un peu d'expérience en Rust pour bien architecturer les nouveaux projets dès le départ.
C'est sympa de la part de Microsoft de prendre les devants et de faire ces expériences pour nous :)
[^] # Re: Le but d’un GC n’a jamais été les performances
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal Performances et GC : détruisons les mythes. Évalué à 10.
Attention à ne pas mélanger 2 choses: sur un système moderne (après 1990) on a de la mémoire virtuelle et une MMU.
Cela veut dire qu'il faut bien distinguer l'allocation d'espace mémoire dans un processus, et l'allocation de mémoire physique pour remplir cet espace.
L'ajustement de taille avec sbrk, ça permet seulement de réserver de l'espace mémoire, qui du coup ne sera plus disponible pour d'autres choses utilisant de la mémoire (mmap, la pile d'exécution, …). L'espace mémoire étant isolé dans chaque processus, ça n'a pas de sens de libérer de l'espace mémoire à l'usage d'un autre processus.
D'autre part, il y a la mémoire physique. Là, on peut allouer et désallouer page par page (4Ko habituellement, mais on commence à voir des "huge pages" de 1Mo pour réduire la charge de travail du MMU) et les pages libérées peuvent être utilisées par d'autres programmes. Il n'y a pas de problème de fragmentation, les pages sont de taille fixe et peuvent être insérées à n'importe quelle adresse dans l'espace mémoire d'un processus.
Même en ayant réservé de l'espace avec sbrk, on est pas obligé de garder cet espace entièrement rempli de pages mémoires disponibles. On peut allouer les pages pour remplir cet espace au moment ou elles sont utilisées, et les libérer lorsque c'est possible ou nécessaire.
La raison pour laquelle on ne le fait pas immédiatement dès qu'une page est disponible, ce sont les performances. Déjà le fait de reconfigurer le MMU pour ajouter ou enlever une page coûte pas mal de temps, mais en plus, il faut effacer le contenu de la page, afin que une autre application ne puisse pas y trouver des traces de l'occupant précédent (ce serait embêtant pour la sécurité du système). Donc ce mécanisme de remise à disposition de page mémoires peut être déclenché seulement lorsque le système commence à être à court de pages à allouer, il va pouvoir demander aux applications de faire du ménage si elles peuvent et de retourner les pages inutilisées à ce moment là.
# L'abstraction c'est bien
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal Performances et GC : détruisons les mythes. Évalué à 10.
J'ai fait du dev en Java pour des cibles embarquées avec quelques centaines de kilo-octets de RAM. Avec un garbage collector.
Et ben on était bien content, non pas parce que c'est rapide, mais surtout parce que ça permettait de déplacer les objets en mémoire de façon transparente pour le code. On pouvait donc défragmenter la mémoire et ainsi libérer de grands espaces contigus pour pouvoir allouer de gros objets.
De la même façon, les stacks pour les threads pouvaient être allouées dynamiquement par tout petits blocs (quelques dizaines ou centaines d'octets à la fois) en fonction des besoins de chaque thread.
La consommation mémoire était donc bien inférieure à un code essayant de faire la même chose en C. Et ça justifiait largement de dédier un peu de puissance CPU au garbage collector.
[^] # Re: Toujours pas convaincu
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au lien This is not your grandfather’s Perl. Évalué à 3.
J'ai lu l'introduction de l'article qui dit ceci:
L'article dit aussi comment activer ces fonctionnalités:
Il s'agit donc bien d'un article tout récent sur la version 5.36 de Perl?
Je m'attendais donc à un résumé des fonctionnalités ajoutées ces 20 dernières années. Alors, soit l'article est mal fichu (ce qui est possible, je je suis pas Perl de très près), soit il ne s'est vraiment rien passé de plus intéressant pendant 20 ans?
Qu'est-ce qui a conduit l'auteur de l'article à choisir des choses qui auraient du déjà être faites depuis 40 ans pour présenter les nouveautés du langage? Quelles sont les vraies nouveautés intéressantes qu'il a choisi de ne pas présenter?
Est-ce que finalement, le fait qu'il y ait peu de changements n'est pas le meilleur aspect de Perl, enfin un langage stable avec lequel on peut écrire des logiciels qui continueront à fonctionner sans problème pour des dizaines d'années?
# Toujours pas convaincu
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au lien This is not your grandfather’s Perl. Évalué à 3.
Pas plus convaincu que après le débat dans le lien précédent à ce sujet.
On peut nommer les paramètres des fonctions (ça existe en C, Pascal, … depuis le millénaire précédent), les descripteurs de fichiers ne sont pas forcément des variables globales (ça existe en C, Pascal, … depuis le millénaire précédent), et on a une fonction qui affiche des chaînes de caractères avec un retour à la ligne (ça existe en C, Pascal, … depuis le millénaire précédent). Bienvenue dans les années 80, Perl?
Et la prochaine étape c'est les années 90 avec de la programmation orientée objet.
[^] # Re: Moteur!
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au lien Ladybird: un nouveau brouteur multiplateforme. Évalué à 6. Dernière modification le 15 septembre 2022 à 09:00.
Je n'ai pas dit que Serenity faisait un mauvais travail côté technique ou sur aucun autre sujet, juste qu'ils etaient meilleurs en communication. Je dirais plutôt qu'on a des choses à apprendre de ce projet
Je m'occupe déjà de la version de NetSurf pour Haiku (packaging et développement du code du frontend, malheureusement, je ne peux pas tout faire moi-même…
[^] # Re: Moteur!
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au lien Ladybird: un nouveau brouteur multiplateforme. Évalué à 6.
NetSurf est un moteur de rendu portable, et ils fournissent un "frontend" natif différent pour chaque OS. Certains sont plus avancés que d'autres et proposent plus ou moins de fonctionalités.
[^] # Re: Moteur!
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au lien Ladybird: un nouveau brouteur multiplateforme. Évalué à 8.
Le test acid3 original ne passe pas à plus de 97% suraucun navigateur moderne en raison de protections de sécurité.
Soit Ladybird n'est pas sécurisé contre les attaques cross-origin, soit ils ont utilisé une version modifiée du test.
De plus, ce test ne fait pas tout et le rendu sur des "vraies" pages est beaucoup plus décevant. Souvent moins bon que NetSurf qu'il est dommage de voir complètement ignoré alors qu'ils font un très bon travail sur le développement d'un moteur léger et performant depuis plus d'une dizaine d'années… L'équipe autour de Serenity est visiblement plutôt douée en terme de communication, on entend beaucoup parler d'eux :)
# Mouais
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au lien Traditional Packaging is not Suitable for Modern Applications. Évalué à 8.
Je ne comprend pas bien quelle est la proposition. Est-ce que c'est de dire à Debian, Ubuntu, Arch, etc d'abandonner leurs formats de paquets et de compiler leurs propres Flatpaks? Auquel cas ça ne résoud pas vraiment les problèmes soulevés: on pourra toujours avoir la mauvaise version d'une lib, un exécutable qui a le même nom qu'un autre, etc.
Ou bien est-ce que l'idée c'est de laisser les développeurs d'applications faire leur packaging et de retirer les applis du dépôt des distributions? Auquel cas, qui va s'occuper des mises à jour de sécurité et du support LTS? Bon l'auteur parle de Arch donc je suppose que le support LTS avec une version fixe de tout les paquets et seulement des mises à jour de sécurité ne l'intéresse pas.
[^] # Re: Idem ici
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal De la difficulté de faire vivre une association. Évalué à 5.
Mon expérience là dessus c'est que la seule façon de passer le relais c'est de démissionner et de dire que si personne ne se porte volontaire l'association sera dissoute.
Sous la menace on finit par trouver des volontaires. Et il vaut mieux le faire avant d'être en burn-out. Un truc qui marche pas mal c'est de renouveler une partie du bureau tous les 3 ans: un an pour apprendre, un an pour faire, un an pour transmettre. J'ai fait partie d'associations ou ce mandat de 3 ans éta?t noté dans les statuts justement pour éviter que tout le monde repose sur le bureau existant.
Le passage de relais n'est pas facile et le nouveau bureau ne fera pas forcément les choses comme vous les auriez faites/sera moins impliqué/etc. Si ça ne vous convient pas, acceptez le fait que c'est votre association et que vous êtes président à vie.
[^] # Re: C++ oh mon cher vieux C++ ...
Posté par pulkomandy (site web personnel, Mastodon) . En réponse à la dépêche Nous avons lu pour vous : Embracing Modern C++ Safely. Évalué à 5.
Le tour de force de Rust c'est d'arriver à faire "presque aussi bien" que Ada de ce point de vue (toutes proportions gardées, mais en comparant au C et C++) mais avec uniquement des vérifications à la compilation et pas à l'exécution.
Ce qui change pas mal du point de vue des performances.
C'est aussi vrai qu'on a pas forcément besoin de tant de performances partout. Mais parfois oui.
On peut donc penser que Rust se trouvera une place confortable quelque part entre Ada (très sécurisé mais moins performant) et C++ (plutôt pas sécurisé, mais possibilités d'optimisations importantes).
# Risque
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au message Prise intelligente ?. Évalué à 5.
Oui.
Au niveau du fonctionnement, en général, la prise va se connecter au "cloud" du fabricant (ce sera peut être juste un serveur, peut être un cloud sous-traité chez Azure, AWS ou autre), ainsi c'est une connexion sortante et il n'y a pas besoin de configurer de pare-feu pour ça.
L'application Android se connecte au même cloud et c'est ce dernier qui relaie les messages.
Les risques sont:
Il existe aussi des systèmes qui ne dépendent pas du cloud, par exemple https://energenie.com/item.aspx?id=7416 qui se pilote avec une interface web embarquée (un simple navigateur web suffit) ou via des requêtes REST. Par défaut ce n'est pas accessible de l'extérieur du réseau sur lequel c'est connecté.
(je ne recommande pas spécifiquement ce modèle pour d'autres raisons: a priori il a une durée de vie d'environ 2 ans, après quoi, les relais qui connectent/déconnectent les prises ne fonctionne plus correctement).
[^] # Re: Alternative à WhatsApp
Posté par pulkomandy (site web personnel, Mastodon) . En réponse à la dépêche Lettre d'information XMPP de juillet 2022. Évalué à 4.
L'avantage par rapport à Telegram: le serveur est en logiciel libre, pour Telegram ce n'est pas le cas. Tu n'as donc absolument aucune idée de ce qui est fait avec tes messages côté serveur.
De plus, il y a plusieurs serveurs et tu peux aussi héberger le tien. Dans un contexte professionnel, on a fait ça dans mon entreprise il y a quelques temps (serveur interne pas connecté avec le reste du réseau XMPP). Alors bien sûr, dans ce cas, c'est plus d'infrastructure à mettre en place, mais ça permet d'avoir la main sur tout le service et d'être sûr que les messages ne sont pas diffusés et stockés n'importe où.
[^] # Re: vraiment?
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal "Use plaintext email" ? Vraiment ?. Évalué à 2.
Justement, avec du HTML bien fait ça ne devrait poser aucun problème.
On devrait avoir des emails qui ressemblent à ça. Pas des trucs qui clignotent comme un sapin de Noël.
Et du coup ça se redimensionne bien à la taille de la police de caractères et à la taille de la fenêtre dans laquelle on l'affiche. Où à la taille du papier si on l'imprime.
Ce n'est pas le cas avec les emails au format texte où c'est l'expéditeur qui choisit combien de caractères par ligne il veut mettre. Par exemple sur mon téléphone, si quelqu'un envoie un mail avec une ligne un peu trop longue, mon téléphone réduit la taille du texte pour faire rentrer cette ligne sur une ligne, et tant pis si ça donne une taille de texte microscopique. Ou alors, il ne le fait pas, et il faut faire défiler le mail de gauche à droite pour le lire.
On peut commencer à se dire qu'on va reformater le texte et ajouter ou supprimer des retours à la ligne là ou ça va bien mais, ce n'est pas comme ça que les mails au format texte sont supposés fonctionner. D'où l'introduction du HTML qui permet de
transporter du texte en indiquant clairement les endroits ou il y a des paragraphes normaux, et les endroits ou il y a un schéma en ASCII art par exemple, qu'il ne faut surtout pas transformer sous peine de les rendre incompréhensibles.
# vraiment?
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal "Use plaintext email" ? Vraiment ?. Évalué à 10.
Je dirais qu'on se rend pas compte à quel point on utilise souvent des liens dans des emails. Moi c'est tout le temps (aussi bien en envoi qu'en réception) et ça m'embêterait bien de pas pouvoir faire autrement.
Je pense pas que le problème soit technique, pouvoir envoyer des mails au format HTML, c'est super, et ça peut s'afficher beaucoup mieux que le format texte préhistorique avec ses retours à la ligne tout moisis (tu as toi-même constaté ce problème malgré la tentative d'activer une option pour contourner le souci).
On peut faire du HTML léger avec juste quelques tags là ou c'est utile.
ça me rappelle les débats sur UTF-8 qui faisait perdre quelques octets par rapport aux encodages historiques. Certes, mais ça ouvre tellement de possibilités et simplifie tellement de choses.
Faire de la frugalité en HTML ne pose pas vraiment problème, en fait.
[^] # Re: le télétravail, ce n'est pas non plus toujours la panacée
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au lien Apple demande de retourner 3 jours par semaine en apotravail : encore une boite qui n'a rien appris. Évalué à 10.
Pour ma part travailler chez moi ça voudrait dire partager l'espace (limité) dans mon appartement avec ma colocataire. Ce qui, en plus des problèmes d'organisation et de vie commune, pose aussi des problèmes de confidentialite des données.
Il faudrait donc que je déménage dans un logement avec une ou deux pièces en plus, ou alors que je travaille dans mon lit (pas bon pour mon dos). Et les 10€ par mois d'indemnité téléravail proposés par mon entreprise (pour 2 jours par semaine) ne permettent pas de financer ça (ça paie même pas la différence de facture d'électricité). Donc ce serait surtout des économie pour l'entreprise et un report des coûts sur les employés.
J'ai eu aussi des problèmes de droit à la déconnexion avec mon chef qui m'appelle 2h après la fin de ma journée de travail pour "juste une petite question", ou juste de mon propre fait defaire un "je finis jutse un truc" jusqu'à 23h… ou encore les mails et appels téléphoniques qui continuent d'arriver pendant la pause déjeuner.
Côté transports je suis privilégié avec seulement 10 minutes de vélo, certes.
Bref, dans mon cas le fait d'avoir un endroit dédié pour le travail ou je peux laisser tous mes problèmes professionnels le soir est essentiel à mon bon équilibre. Tant mieux pour vous si vous vous portez mieux sans, mais c'est pas le cas de tout le monde.
Et ceci indépendament des aspects "sociabilisation". Y'a des jours ou je suis tout seul dans mon openspace avec tous les collègues en télétravail et je prèfére toujours ça plutot que de travailler chez moi.
[^] # Re: le télétravail, ce n'est pas non plus toujours la panacée
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au lien Apple demande de retourner 3 jours par semaine en apotravail : encore une boite qui n'a rien appris. Évalué à 2.
En effet, l'article ne dit rien sur le ressenti des employé.es chez Apple. Certes, l'entreprise a continué a fonctionner et a gagné plein de sous.
Il y a probablement des gens très content de faire du télétravail et d'autres beaucoup moins. Ça dépend de la culture d'entreprise, de l'aménagement des bureaux, de la distance à parcourir pour s'y rendre, du moyen de transport utilisé, de la sympathie des collègues, de la place disponible chez soi hour travailler, de la façon dont on gère la déconnection, et des goûts personnels de chacun.
Aucune info là-dessus dans l'article. Qui sait, peut-être que les employés d'Apple ont vraiment demandé en majorité (mais certainement pas à l'unanimité) à revenir sur place?
[^] # Re: Sans contrainte ,pas de plaisir !! :-)
Posté par pulkomandy (site web personnel, Mastodon) . En réponse à la dépêche Une histoire de carte son sous Linux (la GoXLR). Évalué à 5.
Soit on fait du matériel super-compliqué qui est facile à programmer, mais qui coûte cher et qui est peu flexible.
Soit on fait du matériel simple, pas cher, qui peut faire plein de trucs, mais qui demande beaucoup de logiciel pour fonctionner.
Comme la deuxième solution coûte moins cher pour le même résultat, c'est celle là qui est utilisée.
Il y a quelques dizaines d'années, le compromis était différent parce que les machines avaient peu de CPU et de mémoire. Aujourd'hui ces ressources sont en général largement disponibles. Il existe toujours du matériel de lapremière catégorie, par exemple des interfaces réseau qui font tout plein de trucs en interne. Sauf qu'en fait, elles contienne simplement un CPU spécialisé, pour toujours la même raison: c'est moins cher et plus flexible.
[^] # Re: blockchain et crypto-monnaie sont deux choses différentes
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal Ethereum prépare son passage de Proof of Work à Proof of Stake. Évalué à 10.
Je ne vois pas bien comment on peut vérifier la validité d'un diplôme si on ne fait pas confiance à l'université qui l'a délivré.
On peut donc avoir une université qui signe tous ses diplômes chaque année et publie les clés permettant de vérifier cette signature. C'est une bête signature numérique et il y a pas besoin de blockchain.
C'est bien ce qui a déjà été dit: la blockchain permet de faire des trucs en se passant d'un tiers de confiance, mais c'est une solution en quête d'un problème, parce que c'est beaucoup plus simple d'avoir un tiers de confiance. Sauf peut-être si on est libertarien ou complotiste
[^] # Re: pour remplacer reactos : haiku?
Posté par pulkomandy (site web personnel, Mastodon) . En réponse à la dépêche Haiku a (presque) 21 ans. Évalué à 4.
ReactOS avance doucement et on est pas tellement en concurrence. La technodiversité, c'est bien, et avoir plusieurs choix de système permet de stimuler le développement et de motiver les différentes équipes. Et à chacun de trouver son système préféré en fonction de ses besoins!
[^] # Re: pour remplacer reactos : haiku?
Posté par pulkomandy (site web personnel, Mastodon) . En réponse à la dépêche Haiku a (presque) 21 ans. Évalué à 6.
Pas tous, pour l'instant.
Libreoffice est disponible ainsi que la plupart des logiciels basés sur Qt. Les logiciels basés sur GTK devraient arriver petit à petit. Pour les navigateurs web par contre, c'est compliqué, les moteurs sont très complexes et utilisent beaucoup de fonctionalités du système à tous les niveaux. Sans compter que, par exemple, Google qui maintient Blink (et donc Chromium, Vivaldi, Opera…) est carrément hostile au fait de le voir fonctionner sur des systèmes autres que Linux, Windows et MacOS et rejette les patch à cet effet. Pour Firefox, personne ne s'est lancé dans un portage récemment à ma connaissance.
Le mieux pour voir les logiciels actuellement disponibles sans installer Haiku, c'est de regarder le site Haiku Depot Server qui est une interface web pour les dépôts de logiciels.
Pour ma part j'utilise Haiku autant que possible, cependant je ne pense pas qu'il soit raisonnable pour le moment de l'utiliser comme unique système.
[^] # Re: Juste mon point de vue
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal De l'influence néfaste de Google sur les développeurs C++. Évalué à 2.
En vrai ça pourrait être utile si l'ordre entre les éléments n'est pas un ordre total. Dans ce cas il peut en effet y avoir plusieurs maximums (éléments qui sont sont supérieurs à tous les autres, soit n'ont pas de comparaison définie avec les autres).
[^] # Re: Pas de fumée sans feu
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal De l'influence néfaste de Google sur les développeurs C++. Évalué à 4. Dernière modification le 08 août 2022 à 11:10.
En effet, je compare le C (avec ni exceptions ni destructeurs) avec le C++ (avec exceptions et destructeurs). Voyons la solution intermédiaire ou on aurait droit aux destructeurs mais pas aux exceptions.
Ok, on passe de:
à:
En admettant qu'on enlève les accolades pour gagner un maximum, on est quand même à 50% des lignes qui ne sont là que pour la gestion d'erreur. Et ça c'est dans un code simple ou il n'y a pas de boucles ou autres structures de contrôle compliquées.
Mais, si on écrit le code comme ça, au-delà du bête calcul sur le nombre de lignes utiles, tout le code qui fait des trucs est "caché" dans des if() qui vérifient si les fonctions ont fonctionné. Et là on est dans un cas ou la fonction retourne juste un bool pour dire si elle a fonctionné. Mettons qu'on veut par exemple ouvrir un fichier.
Version C++ avec exceptions et destructeurs:
Si ça marche pas, la fonction lève une exception.
Version C sans rien:
Version C++ sans les exceptions:
Et ça c'est juste en regardant une fonction de très près. La classe ou structure Fichier va être plus compliquée: il faut une méthode Ouvrir qui retourne une erreur, il faut un destructeur qui vérifie si le fichier est vraiment ouvert avant de le fermer.
Et là on a toujours une seule ressource dans cette fonction. Quand il y en a 2 ou plus, la complexité de la gestion d'erreur va augmenter. Il y a le risque d'oublier un cas d'erreur et de ne pas mettre un if là ou il faudrait, et de se retrouver avec un objet dans un état invalide (on peut avoir un objet Fichier qui ne correspond pas à un vrai fichier, soit parce qu'on n'a pas encore appelé la méthode Ouvrir, soit parce que la méthode a rencontré une erreur).
# Coquilles
Posté par pulkomandy (site web personnel, Mastodon) . En réponse à la dépêche Ysabeau, un chouette caractère. Évalué à 2. Dernière modification le 08 août 2022 à 10:56.
Quelques erreurs se sont glissées dans le texte: