Non, Linux ne renvoie pas NULL par défaut quand il n'a pas de mémoire pour un malloc. Il tue un process pour faire de la place.
Le principe, c'est de supposer que les applications vont demander plus de mémoire que ce qu'elles ont vraiment besoin. Du coup, on leur dit "ouais ouais, c'est bon voilà tes 12Go de RAM" et en vrai on alloue de la mémoire physique que quand l'application fait effectivement un accès à cette mémoire.
Si l'application effectivement n'utilise pas tout ce qu'elle a demandé, on est gagnant, on arrive à faire croire à l'application que la mémoire dont elle n'a pas besoin est libre. Mais si l'application finit par utiliser cette mémoire, ben on ne peut plus gérer l'erreur proprement puisque c'était sensé être fait au moment du malloc.
Ce principe s'appelle "overcommit". C'est l'équivalent du surbooking pour les compagnies aériennes (qui partent du principe qu'il y a toujours une ou deux personnes qui vont réserver une place mais ne pas arriver à l'embarquement).
Pourquoi Linux fait ça? Parce que les gens qui ont écrit les applications ont été larges dans leurs demandes de mémoire, plutôt que de calculer leurs besoins au plus juste. Et maintenant que ça marche comme ça, pourquoi les applications s'embêteraient à calculer leurs besoins au plus juste et à gérer correctement les erreurs d'allocation?
Ici on a un gitlab, des merge requests qui conservent l'historique, et des intégrateurs qui font leur travail pour vérifier que le code est bien écrit, commenté et documenté. Sinon, il n'est pas intégré.
Il faut peut-être aller expliquer leur travail à vos intégrateurs.
On a déjà bien assez de dette technique comme ça, on a tout intérêt à ce que au moins le code qu'on écrit soit propre. On est prestataires (grosse équipe, une quarantaine de personnes sur différents projets) et le dépôt git est évidemment synchronisé chez le client toutes les nuits, de façon à ce qu'il aie accès à l'historique (sauf les branches "internes" qui restent chez nous avec les devs en cours pas encore livrés). Si vos prestataires vous envoie le code en vrac par mail et sans contrôle de sources, vous avez là aussi un problème.
On ne développe pas de code sur nos propres machines, mais sur un serveur partagé avec un environnement de travail maîtrisé. Ce qui fait que formater un PC n'est jamais un problème, et aussi qui permet au client de savoir exactement dans quelle configuration on travaille et de reproduire l'environnement chez lui si nécessaire.
Pour les commits, on ne garde pas tout, l'idée est que le développeur fait son développement et prend le temps de découper ça en commits "atomiques" apportant chacun une fonctionnalité précise, et étant fonctionnel et indépendant des commits suivants. Gitlab ni Github ne mettent pas vraiment cette façon de travailler, si j'avais le choix je pencherais plutôt pour un outil comme Gerrit, qui permet de faire une revue de code en travaillant sur un commit à la fois.
Mais de toutes façons, les développements sont découpés en tâches qui peuvent être complétées en quelques jours, au pire une à deux semaines si vraiment ça se passe mal. Les revues et intégrations sont donc très fréquentes et concernent peu de commits à la fois. Les commits de développement sont au nom de l'auteur, le commit d'intégration au nom du relecteur/intégrateur. Tout est donc tracé.
L'historique git est un outil précieux pour comprendre le fonctionnement du code, et s'il est bien tenu, souvent plus efficace que des commentaires ou de la documentation d'architecture.
L'histoire de l'informatique elle-même est déjà courte. On a clairement pas 1 siècle de recul comme on peut avoir en électricité/électronique, par exemple. Et c'est vrai qu'en plus, les ingénieurs manquent souvent de bagage pour en tirer les leçons.
Parfois cela fonctionne, par exemple XML est déjà une versions très simplifiée de SGML et c'était nécessaire. ASN1 est peut être un peu à part, c'est un standard venu des télécommunications et bien que l'idée soit très intéressante, je n'ai pas trouvé les implémentations convaincantes en terme de simplicité d'utilisation ni de performances (je l'ai utilisé dans un contexte Python et C embarqué).
L'équilibre entre réinventer la roue et empiler des couches de dette technique est difficile à trouver. Mais une bonne connaissance de l'historique (du projet, et de l'informatique en général) permet souvent d'y voir plus clair et de prendre de meilleures décisions. On apprend beaucoup en lisant le code et la documentation des personnes qui sont passées avant nous, finalement.
Dans Haiku on a pas d'OOM killer. On a un malloc() qui renvoie NULL quand y'a pas de mémoire disponible, et des applications qui gèrent l'erreur. L'utilisateur a donc une chance d'enregistrer son travail avant qu'une application soit détruite.
Je ne devrais pas avoir à me préoccuper de surveiller l'occupation mémoire de mon PC en me disant "merde, si je dépasse trop, ça va me tuer mon programme et détruire mes données". C'est le travail du système de faire ça, et de faire en sorte que quoi qu'il arrive, les fichiers sur lesquels je travaille sont sauvegardés et que mon travail n'est pas perdu.
Facile, je n'ai pas envie de contribuer à Linux et je travaille beaucoup sur Haiku où les buts sont d'avoir du code propre et lisible, un environnement accueillant, et un produit efficace.
Je contribue aussi un petit peu à NetSurf, un navigateur web avec une approche raisonnable et des besoins en ressources beaucoup plus faibles que les concurrents.
Et bien sur mon éditeur préféré, c'est vim, parce qu'il prend moins d'1Mo sur mon disque dur, fonctionne sur toutes les plateformes dont j'ai besoin, et sait faire tout ce qui est nécessaire, mais pas plus.
Au FOSDEM cette année il y avait une conférence sur un travail similaire pour les BSD, avec un dépôt git remontant jusqu'aux toutes premières versions d'UNIX des années 70 (dont certaines ont dû être récupérées à partir de listings sur papier).
Non ce n'est pas drôle. Je trouve ça insupportable d'utiliser un ordinateur moderne. Tous ces gigahertz et giga octets de RAM et pourtant ça se traîne toujours autant. Il s'est passé quoi?
Oui, Linux tue des process au hasard par conception: https://doc.ubuntu-fr.org/oomkiller
Non, ce n'est pas normal que ça fonctionne comme ça. Oui, c'est désactivable, mais c'est toujours le comportement par défaut.
J'ai la chance dans certains de mes projets de pouvoir faire les choses proprement. C'est plus long. Mais le résultat c'est du code propre, maintenable, et efficace. Et sur d'autres projets, je dois aller au plus court, faire du code sale, et savoir que je vais perdre du temps plus tard, beaucoup de temps, pour le réparer. Et non, je ne suis pas fier de mon travail dans ces conditions.
Pas très efficace la protection pour le coup, je suis dans l'UE et j'ai eu droit à cette boite de dialogue en installant un autre navigateur. Qui s'occupe de porter plainte au lieu de raler sur les forums?
Signal /et/ Telegram? être "simple pour nos parents" ça commence par ne pas embrouiller les gens avec deux applications qui font presque la même chose, non?
(et au passage, il y a un t en trop à "choix applicatif réfléchit")
Chez Haiku, les noms des softs sont en général clairs et ennuyeux (MediaPlayer, ShowImage, Colors, Debugger, …). Par contre on s'est un peu amusé avec les icônes qui permettent à chaque logiciel d'avoir sa propre identité. Peut être une piste à creuser.
On avait une page avec plein d'icônes mais apparament elle n'est plus en ligne. Il va falloir remettre ça en place.
Il y a toujours un avant/après dans ces journaux. Mais Apple ne dois pas faire de keynotes assez souvent; les moules oublient d'une fois sur l'autre comment ça marche.
Bonjour, je vais essayer de répondre même si je ne suis responsable que d'un petit morceau du port pour Haiku et que j'ai peu touché au coeur de NetSurf.
NetSurf est le seul choix raisonable pour certaines des plateformes ciblées: MiNT, RiscOS, KolibriOS ou AmigaOS 3 par exemple. Avoir un navigateur qui sait prendre en charge les CSS sur ces systèmes est déjà très bien. Cependant, je pense que peu de monde utilise ces systèmes comme principale machine.
Sous Haiku, on dispose de navigateurs basés sur WebKit, autrement plus compliqués, et NetSurf est un bon complément quand on tombe sur un site web un peu récalcitrant.
Il trouve également une utilisation dans les systèmes embarqués, et ira peut être plus loin de ce côté quand il disposera d'un moteur Javascript. Il existe une version de NetSurf qui a juste besoin d'un framebuffer pour faire le rendu, donc très facile à porter même sur un système très minimaliste. On pourrait donc imaginer écrire une application embarquée en HTML, CSS et JavaScript, ou même, grâce à la modularité de NetSurf, remplacer le JavaScript et écrire une application C avec un rendu en HTML/CSS.
NetSurf est rapide pour le rendu sur les machines ciblées. La plupart des autres navigateurs vont s'attendre à disposer d'accélération 3D pour réaliser certains effets graphiques, et tenter de faire tout le rendu en logiciel peut être un gros problème (j'en sais quelque chose, puisque la version de WebKit pour Haiku fonctionne ainsi). Je ne sais pas dans quelle mesure l'intégration de Javascript changera les choses pour NetSurf, car actuellement le DOM (le modèle de la page) est statique et donc le rendu peut être fait en une seule fois. Avec Javascript, la page peut être modifiée à tout moment et cela a de nombreuses conséquences.
Je n'ai pas branché mon Amiga depuis bien longtemps, et il a plus de RAM que ça (poussé à 128Mo mais avec un vénérable 68040 à 40MHz). Ilfaudra que je voie ce que ça donne. Si j'ai le temps un jour je me lancerai peut être à faire fonctionner NetSurf sous Windows 3.11 avec Win32S, par curiosité archéologique :)
Le choix de la licence est un peu personnel, ça dépend de ce que tu veux que ce projet devienne.
La GPL n'est pas vraiment pertinente vu qu'il s'agit d'un site web (légalement, les visiteurs ne sont pas considérés comme des utilisateurs et donc le système de copyleft de la GPL ne s'applique pas). Si tu veux une licence copyleft, la licence Affero est donc un bon choix.
Sinon, une licence MIT, simple, efficace, et bien connue. Elle semble être une bonne façon de laisser quelqu'un d'autre (ou une plus grosse équipe) prendre le code et en faire ce qu'ils veulent. Il faudra leur faire confiance pour que leurs évolutions restent libres, par contre, car il n'y aura pas d'obligation contractuelle.
Merci en tout cas de publier les sources, même si elles ne sont pas "présentables". J'espère que ton travail ne sera pas perdu et connaîtra une nouvelle vie grâce à ça.
Encore une généralisation. Tous les logiciels FLOSS seraient pareil, développés par les mêmes 12 hackers socialement incapables avec un humour de merde.
Je sais pas, faisons un tour parmi les logiciels propriétaires. Pas les gros trucs développés par Apple ou Google, qui eux aussi ont parfois des logos pas si moches que ça (encore que ça vieillit pas toujours très bien). Mais prenons plutôt du bon vieux shareware:
Bon, la liste est sûrement très longue mais je n'utilise plus assez Windows pour en connaître tant que ça. Donc, en dehors des gros trucs qui ont des sous pour se payer un designer, il y a des trucs moches et pas libre partout. Et niveau interface utilisateur, y'a qu'à regarder n'importe quelle UI d'antivirus ou de driver d'imprimante.
Le problème est ailleurs: il n'y a pas assez de designers qui contribuent aux logiciels libres. On ne peut pas demander aux développeurs de faire le job, il faut quelqu'un qui connaisse le métier. En attendant, on se débrouille comme on peut. Et non, on est pas forcément tous fiers d'avoir des logos moches.
Il y a toujours dans Debian des paquets -off (pour "offensive") avec des fortunes insultantes ou inappropriées, et une partie des questions de purity (le quizz qui évalue la "pureté" d'une personne):
J'utilise de plus en plus YouCompleteMe, qui fonctionne sous forme d'un démon en arrière plan (lancé par vim de façon transparente) et fournit à la fois le soulignement des erreurs de syntaxe et autres problèmes, et la complétion automatique.
Je ne l'ai testé qu'en C et C++ pour l'instant, mais il sait faire ça pour plusieurs langages, dont Python.
Essaie d'installer Windows XP sur un PC moderne qu'on rigole un peu. Normalement il va te demander d'insérer la disquette avec les drivers de ton contrôleur SATA.
Faire du warmup avant de lancer l'interprétation, c'est un peu contradictoire avec vouloir faire du JIT, quand même.
L'idée du JIT, c'est de pouvoir profiler le code et prendre des décisions à la volée. Genre si y'a un if() qui n'est que très rarement exécuté, le remplacer par un traitement similaire à celui d'une exception.
Sinon, tu fait une bonne vieille étape de compilation au démarrage et on en parle plus.
De mémoire, la VM .net de microsoft a un cache disque du code compilé/optimisé par le JIT, donc c'est vraiment seulement le tout premier lancement de l'appli qui est lent.
Et d'autre part, je suis surpris qu'on trouve encore des garbage collectors "stop the world". On sait faire des trucs qui tournent en tâche de fond sans avoir besoin de geler complètement le programme, non?
Mais avoir un bon navigateur web, c'est pas évident non plus. Le port de WebKit sur Haiku nous a fait trouver plein de bugs et de limitations dans nos APIs, et c'est un travail conséquent juste de garder notre version à jour avec les nouveaux développement.
Le HTML5 change en permanence, donc il faut régulièrement ajouter de nouvelles fonctionnalités pour que la dernière web app à la mode puisse se lancer correctement. Actuellement on est en train de travailler sur Web Crypto pour pouvoir utiliser WhatsApp, par exemple.
Même après une pause de 17 ans, on peut toujours reprendre le code source d'un logiciel et le faire évoluer. C'est ce que fait le projet HaikuArchives et on a pu récupérer des centaines de logiciels de cette façon.
Il y en a encore plein d'autres dont nous n'avons pas pu récupérer les sources. Je pense par exemple à SynC Modular, qui est un logiciel de synthèse musicale dont on a pas encore réussi à contacter l'auteur pour obtenir une copie du code. Et là, ce sera difficile de faire quoi que ce soit, il faudra donc le remplacer…
Rien ne t'empêche d'avoir une couleur différente pour chaque caractère du nom de ta variable, avec une signification différente.
Mais pour moi, du code propre et bien rédigé doit pouvoir se lire sans coloration syntaxique. La coloration, c'est pratique pour essayer de démêler un code illisible.
On tourne en rond, quelqu'un a déjà donné ce lien.
La réponse reste la même: ce genre d'infos devrait être encodé dans le type de la variable, pas dans son nom. Pour reprendre l'exemple du blog, il faudrait une classe UnsafeString, et les chaînes non sûres devraient être stockées dans des variables de ce type.
Après, on peut, au choix, mettre un operator= (ou un opérateur de cast, ou…) qui va faire la conversion de façon transparente (mais il faut bien réfléchir), ou ajouter la méthode .Encode() pour que ce soit explicite.
Et du coup, ce n'est plus au développeur de vérifier ce genre de choses: le compilateur va faire le job tout seul. Le mauvais code fonctionnera quand même dans le premier cas (on va juste perdre en performance avec des conversions inutiles de partout), et ne compilera même pas dans le second.
Par contre, et c'est ce dont on débat ici, il n'est pas question d'avoir un type différent pour une variable locale et un membre d'une classe. Donc, dans ce cas, avoir un préfixe peut faire sense (encore que, utiliser systématiquement this-> n'est pas forcément une mauvaise idée, quoi qu'un peu verbeuse).
[^] # Re: Tiens, à propos, comment-vous gérez vos repos, vous ?
Posté par pulkomandy (page perso) . En réponse au journal Remonter l'historique du noyau avec git depuis le début. Évalué à 3 (+1/-0).
Oui, c'est pas impossible à faire avec Gitlab mais c'est pénible.
Gerrit permet aussi de merger un commit avant que les suivants ne soient prêts, par exemple.
Ce n'est pas forcément moins souple, c'est juste une façon différente de travailler.
[^] # Re: TL ; DR
Posté par pulkomandy (page perso) . En réponse au lien Software disenchantment. Évalué à 5 (+4/-1).
Non, Linux ne renvoie pas NULL par défaut quand il n'a pas de mémoire pour un malloc. Il tue un process pour faire de la place.
Le principe, c'est de supposer que les applications vont demander plus de mémoire que ce qu'elles ont vraiment besoin. Du coup, on leur dit "ouais ouais, c'est bon voilà tes 12Go de RAM" et en vrai on alloue de la mémoire physique que quand l'application fait effectivement un accès à cette mémoire.
Si l'application effectivement n'utilise pas tout ce qu'elle a demandé, on est gagnant, on arrive à faire croire à l'application que la mémoire dont elle n'a pas besoin est libre. Mais si l'application finit par utiliser cette mémoire, ben on ne peut plus gérer l'erreur proprement puisque c'était sensé être fait au moment du malloc.
Ce principe s'appelle "overcommit". C'est l'équivalent du surbooking pour les compagnies aériennes (qui partent du principe qu'il y a toujours une ou deux personnes qui vont réserver une place mais ne pas arriver à l'embarquement).
Pourquoi Linux fait ça? Parce que les gens qui ont écrit les applications ont été larges dans leurs demandes de mémoire, plutôt que de calculer leurs besoins au plus juste. Et maintenant que ça marche comme ça, pourquoi les applications s'embêteraient à calculer leurs besoins au plus juste et à gérer correctement les erreurs d'allocation?
[^] # Re: Tiens, à propos, comment-vous gérez vos repos, vous ?
Posté par pulkomandy (page perso) . En réponse au journal Remonter l'historique du noyau avec git depuis le début. Évalué à 6 (+5/-1).
Ici on a un gitlab, des merge requests qui conservent l'historique, et des intégrateurs qui font leur travail pour vérifier que le code est bien écrit, commenté et documenté. Sinon, il n'est pas intégré.
Il faut peut-être aller expliquer leur travail à vos intégrateurs.
On a déjà bien assez de dette technique comme ça, on a tout intérêt à ce que au moins le code qu'on écrit soit propre. On est prestataires (grosse équipe, une quarantaine de personnes sur différents projets) et le dépôt git est évidemment synchronisé chez le client toutes les nuits, de façon à ce qu'il aie accès à l'historique (sauf les branches "internes" qui restent chez nous avec les devs en cours pas encore livrés). Si vos prestataires vous envoie le code en vrac par mail et sans contrôle de sources, vous avez là aussi un problème.
On ne développe pas de code sur nos propres machines, mais sur un serveur partagé avec un environnement de travail maîtrisé. Ce qui fait que formater un PC n'est jamais un problème, et aussi qui permet au client de savoir exactement dans quelle configuration on travaille et de reproduire l'environnement chez lui si nécessaire.
Pour les commits, on ne garde pas tout, l'idée est que le développeur fait son développement et prend le temps de découper ça en commits "atomiques" apportant chacun une fonctionnalité précise, et étant fonctionnel et indépendant des commits suivants. Gitlab ni Github ne mettent pas vraiment cette façon de travailler, si j'avais le choix je pencherais plutôt pour un outil comme Gerrit, qui permet de faire une revue de code en travaillant sur un commit à la fois.
Mais de toutes façons, les développements sont découpés en tâches qui peuvent être complétées en quelques jours, au pire une à deux semaines si vraiment ça se passe mal. Les revues et intégrations sont donc très fréquentes et concernent peu de commits à la fois. Les commits de développement sont au nom de l'auteur, le commit d'intégration au nom du relecteur/intégrateur. Tout est donc tracé.
L'historique git est un outil précieux pour comprendre le fonctionnement du code, et s'il est bien tenu, souvent plus efficace que des commentaires ou de la documentation d'architecture.
[^] # Re: TL ; DR
Posté par pulkomandy (page perso) . En réponse au lien Software disenchantment. Évalué à 4 (+4/-2).
L'histoire de l'informatique elle-même est déjà courte. On a clairement pas 1 siècle de recul comme on peut avoir en électricité/électronique, par exemple. Et c'est vrai qu'en plus, les ingénieurs manquent souvent de bagage pour en tirer les leçons.
Parfois cela fonctionne, par exemple XML est déjà une versions très simplifiée de SGML et c'était nécessaire. ASN1 est peut être un peu à part, c'est un standard venu des télécommunications et bien que l'idée soit très intéressante, je n'ai pas trouvé les implémentations convaincantes en terme de simplicité d'utilisation ni de performances (je l'ai utilisé dans un contexte Python et C embarqué).
L'équilibre entre réinventer la roue et empiler des couches de dette technique est difficile à trouver. Mais une bonne connaissance de l'historique (du projet, et de l'informatique en général) permet souvent d'y voir plus clair et de prendre de meilleures décisions. On apprend beaucoup en lisant le code et la documentation des personnes qui sont passées avant nous, finalement.
[^] # Re: TL ; DR
Posté par pulkomandy (page perso) . En réponse au lien Software disenchantment. Évalué à 2 (+3/-3).
Dans Haiku on a pas d'OOM killer. On a un malloc() qui renvoie NULL quand y'a pas de mémoire disponible, et des applications qui gèrent l'erreur. L'utilisateur a donc une chance d'enregistrer son travail avant qu'une application soit détruite.
Je ne devrais pas avoir à me préoccuper de surveiller l'occupation mémoire de mon PC en me disant "merde, si je dépasse trop, ça va me tuer mon programme et détruire mes données". C'est le travail du système de faire ça, et de faire en sorte que quoi qu'il arrive, les fichiers sur lesquels je travaille sont sauvegardés et que mon travail n'est pas perdu.
[^] # Re: TL ; DR
Posté par pulkomandy (page perso) . En réponse au lien Software disenchantment. Évalué à 3 (+3/-2).
Facile, je n'ai pas envie de contribuer à Linux et je travaille beaucoup sur Haiku où les buts sont d'avoir du code propre et lisible, un environnement accueillant, et un produit efficace.
Je contribue aussi un petit peu à NetSurf, un navigateur web avec une approche raisonnable et des besoins en ressources beaucoup plus faibles que les concurrents.
Et bien sur mon éditeur préféré, c'est vim, parce qu'il prend moins d'1Mo sur mon disque dur, fonctionne sur toutes les plateformes dont j'ai besoin, et sait faire tout ce qui est nécessaire, mais pas plus.
[^] # Re: En fabriquer un dépôt git pour l'historique?
Posté par pulkomandy (page perso) . En réponse au journal Remonter l'historique du noyau avec git depuis le début. Évalué à 10 (+8/-0).
Au FOSDEM cette année il y avait une conférence sur un travail similaire pour les BSD, avec un dépôt git remontant jusqu'aux toutes premières versions d'UNIX des années 70 (dont certaines ont dû être récupérées à partir de listings sur papier).
[^] # Re: TL ; DR
Posté par pulkomandy (page perso) . En réponse au lien Software disenchantment. Évalué à 4 (+5/-3).
Non ce n'est pas drôle. Je trouve ça insupportable d'utiliser un ordinateur moderne. Tous ces gigahertz et giga octets de RAM et pourtant ça se traîne toujours autant. Il s'est passé quoi?
Oui, Linux tue des process au hasard par conception: https://doc.ubuntu-fr.org/oomkiller
Non, ce n'est pas normal que ça fonctionne comme ça. Oui, c'est désactivable, mais c'est toujours le comportement par défaut.
J'ai la chance dans certains de mes projets de pouvoir faire les choses proprement. C'est plus long. Mais le résultat c'est du code propre, maintenable, et efficace. Et sur d'autres projets, je dois aller au plus court, faire du code sale, et savoir que je vais perdre du temps plus tard, beaucoup de temps, pour le réparer. Et non, je ne suis pas fier de mon travail dans ces conditions.
[^] # Re: Pub
Posté par pulkomandy (page perso) . En réponse au journal Windows 10 fait la publicité de Edge pendant l'installation de Firefox et Chrome !. Évalué à 2 (+0/-0).
Pas très efficace la protection pour le coup, je suis dans l'UE et j'ai eu droit à cette boite de dialogue en installant un autre navigateur. Qui s'occupe de porter plainte au lieu de raler sur les forums?
# Choix d'applications réfléchi
Posté par pulkomandy (page perso) . En réponse au journal première beta de /e/. Évalué à 7 (+5/-0).
Signal /et/ Telegram? être "simple pour nos parents" ça commence par ne pas embrouiller les gens avec deux applications qui font presque la même chose, non?
(et au passage, il y a un t en trop à "choix applicatif réfléchit")
# Haiku (oui je fais de la pub)
Posté par pulkomandy (page perso) . En réponse au journal De l'importance de bien nommer ses logiciels…. Évalué à 6 (+4/-0).
Chez Haiku, les noms des softs sont en général clairs et ennuyeux (MediaPlayer, ShowImage, Colors, Debugger, …). Par contre on s'est un peu amusé avec les icônes qui permettent à chaque logiciel d'avoir sa propre identité. Peut être une piste à creuser.
On avait une page avec plein d'icônes mais apparament elle n'est plus en ligne. Il va falloir remettre ça en place.
[^] # Re: Ou est le journal troll habituel ?
Posté par pulkomandy (page perso) . En réponse au journal Nouveau coup de tonnerre attendu. Évalué à 10 (+8/-0).
SPOILERS
Il y a toujours un avant/après dans ces journaux. Mais Apple ne dois pas faire de keynotes assez souvent; les moules oublient d'une fois sur l'autre comment ça marche.
[^] # Re: Impressionnant
Posté par pulkomandy (page perso) . En réponse à la dépêche Le navigateur Web NetSurf publie sa version 3.8. Évalué à 5 (+3/-0).
Bonjour, je vais essayer de répondre même si je ne suis responsable que d'un petit morceau du port pour Haiku et que j'ai peu touché au coeur de NetSurf.
NetSurf est le seul choix raisonable pour certaines des plateformes ciblées: MiNT, RiscOS, KolibriOS ou AmigaOS 3 par exemple. Avoir un navigateur qui sait prendre en charge les CSS sur ces systèmes est déjà très bien. Cependant, je pense que peu de monde utilise ces systèmes comme principale machine.
Sous Haiku, on dispose de navigateurs basés sur WebKit, autrement plus compliqués, et NetSurf est un bon complément quand on tombe sur un site web un peu récalcitrant.
Il trouve également une utilisation dans les systèmes embarqués, et ira peut être plus loin de ce côté quand il disposera d'un moteur Javascript. Il existe une version de NetSurf qui a juste besoin d'un framebuffer pour faire le rendu, donc très facile à porter même sur un système très minimaliste. On pourrait donc imaginer écrire une application embarquée en HTML, CSS et JavaScript, ou même, grâce à la modularité de NetSurf, remplacer le JavaScript et écrire une application C avec un rendu en HTML/CSS.
NetSurf est rapide pour le rendu sur les machines ciblées. La plupart des autres navigateurs vont s'attendre à disposer d'accélération 3D pour réaliser certains effets graphiques, et tenter de faire tout le rendu en logiciel peut être un gros problème (j'en sais quelque chose, puisque la version de WebKit pour Haiku fonctionne ainsi). Je ne sais pas dans quelle mesure l'intégration de Javascript changera les choses pour NetSurf, car actuellement le DOM (le modèle de la page) est statique et donc le rendu peut être fait en une seule fois. Avec Javascript, la page peut être modifiée à tout moment et cela a de nombreuses conséquences.
Je n'ai pas branché mon Amiga depuis bien longtemps, et il a plus de RAM que ça (poussé à 128Mo mais avec un vénérable 68040 à 40MHz). Ilfaudra que je voie ce que ça donne. Si j'ai le temps un jour je me lancerai peut être à faire fonctionner NetSurf sous Windows 3.11 avec Win32S, par curiosité archéologique :)
# Errata
Posté par pulkomandy (page perso) . En réponse à la dépêche Le navigateur Web NetSurf publie sa version 3.8. Évalué à 2 (+0/-0).
On m'informe que l'entreprise qui a sponsorisé NetSurf s'appelle Codethink, sans T majuscule. Si quelqu'un peut corriger, ça serait super.
# Licence
Posté par pulkomandy (page perso) . En réponse à la dépêche Libération du code source de muzi.ch, quelle licence ?. Évalué à 10 (+12/-0).
Le choix de la licence est un peu personnel, ça dépend de ce que tu veux que ce projet devienne.
La GPL n'est pas vraiment pertinente vu qu'il s'agit d'un site web (légalement, les visiteurs ne sont pas considérés comme des utilisateurs et donc le système de copyleft de la GPL ne s'applique pas). Si tu veux une licence copyleft, la licence Affero est donc un bon choix.
Sinon, une licence MIT, simple, efficace, et bien connue. Elle semble être une bonne façon de laisser quelqu'un d'autre (ou une plus grosse équipe) prendre le code et en faire ce qu'ils veulent. Il faudra leur faire confiance pour que leurs évolutions restent libres, par contre, car il n'y aura pas d'obligation contractuelle.
Merci en tout cas de publier les sources, même si elles ne sont pas "présentables". J'espère que ton travail ne sera pas perdu et connaîtra une nouvelle vie grâce à ça.
# Mouais
Posté par pulkomandy (page perso) . En réponse au lien De la laideur des logos et interfaces dans le libre. Évalué à 10 (+9/-0).
Encore une généralisation. Tous les logiciels FLOSS seraient pareil, développés par les mêmes 12 hackers socialement incapables avec un humour de merde.
Je sais pas, faisons un tour parmi les logiciels propriétaires. Pas les gros trucs développés par Apple ou Google, qui eux aussi ont parfois des logos pas si moches que ça (encore que ça vieillit pas toujours très bien). Mais prenons plutôt du bon vieux shareware:
https://www.anvilstudio.com (une enclume sur un clavier de piano)
https://www.entechtaiwan.com/util/multires.shtm (des engrenages tout moches)
https://antibody-software.com/web/software/software/wizmouse-makes-your-mouse-wheel-work-on-the-window-under-the-mouse/ (euh… je n'arrive même pas à comprendre ce que c'est)
Bon, la liste est sûrement très longue mais je n'utilise plus assez Windows pour en connaître tant que ça. Donc, en dehors des gros trucs qui ont des sous pour se payer un designer, il y a des trucs moches et pas libre partout. Et niveau interface utilisateur, y'a qu'à regarder n'importe quelle UI d'antivirus ou de driver d'imprimante.
Le problème est ailleurs: il n'y a pas assez de designers qui contribuent aux logiciels libres. On ne peut pas demander aux développeurs de faire le job, il faut quelqu'un qui connaisse le métier. En attendant, on se débrouille comme on peut. Et non, on est pas forcément tous fiers d'avoir des logos moches.
# Paquets -off
Posté par pulkomandy (page perso) . En réponse au lien Weboob a failli changer de nom dans Debian. Évalué à 5 (+3/-0). Dernière modification le 27/08/18 à 11:37.
Il y a toujours dans Debian des paquets -off (pour "offensive") avec des fortunes insultantes ou inappropriées, et une partie des questions de purity (le quizz qui évalue la "pureté" d'une personne):
https://packages.debian.org/search?keywords=-off&searchon=names&suite=stable§ion=all
Et je viens de découvrir cowsay-off, avec de l'ASCII art zoophile. Classe.
Alors bon, le nom du paquet weboob, c'est peut-être pas le truc le plus important?
# YouCompleteMe
Posté par pulkomandy (page perso) . En réponse au journal vim: Au revoir syntastic, bonjour ALE. Évalué à 3 (+1/-0).
J'utilise de plus en plus YouCompleteMe, qui fonctionne sous forme d'un démon en arrière plan (lancé par vim de façon transparente) et fournit à la fois le soulignement des erreurs de syntaxe et autres problèmes, et la complétion automatique.
Je ne l'ai testé qu'en C et C++ pour l'instant, mais il sait faire ça pour plusieurs langages, dont Python.
[^] # Re: Windows XP
Posté par pulkomandy (page perso) . En réponse au journal quand Oracle fait les affaires de Azul.. Évalué à 3 (+3/-2).
Essaie d'installer Windows XP sur un PC moderne qu'on rigole un peu. Normalement il va te demander d'insérer la disquette avec les drivers de ton contrôleur SATA.
[^] # Re: Argument fallacieux
Posté par pulkomandy (page perso) . En réponse au journal quand Oracle fait les affaires de Azul.. Évalué à 6 (+4/-0).
Faire du warmup avant de lancer l'interprétation, c'est un peu contradictoire avec vouloir faire du JIT, quand même.
L'idée du JIT, c'est de pouvoir profiler le code et prendre des décisions à la volée. Genre si y'a un if() qui n'est que très rarement exécuté, le remplacer par un traitement similaire à celui d'une exception.
Sinon, tu fait une bonne vieille étape de compilation au démarrage et on en parle plus.
De mémoire, la VM .net de microsoft a un cache disque du code compilé/optimisé par le JIT, donc c'est vraiment seulement le tout premier lancement de l'appli qui est lent.
Et d'autre part, je suis surpris qu'on trouve encore des garbage collectors "stop the world". On sait faire des trucs qui tournent en tâche de fond sans avoir besoin de geler complètement le programme, non?
[^] # Re: Projet intéressant académiquement
Posté par pulkomandy (page perso) . En réponse à la dépêche Haiku a 17 ans. Évalué à 3 (+2/-1).
Mais avoir un bon navigateur web, c'est pas évident non plus. Le port de WebKit sur Haiku nous a fait trouver plein de bugs et de limitations dans nos APIs, et c'est un travail conséquent juste de garder notre version à jour avec les nouveaux développement.
Le HTML5 change en permanence, donc il faut régulièrement ajouter de nouvelles fonctionnalités pour que la dernière web app à la mode puisse se lancer correctement. Actuellement on est en train de travailler sur Web Crypto pour pouvoir utiliser WhatsApp, par exemple.
[^] # Re: Logiciels disponibles
Posté par pulkomandy (page perso) . En réponse à la dépêche Haiku a 17 ans. Évalué à 4 (+2/-0).
Même après une pause de 17 ans, on peut toujours reprendre le code source d'un logiciel et le faire évoluer. C'est ce que fait le projet HaikuArchives et on a pu récupérer des centaines de logiciels de cette façon.
Il y en a encore plein d'autres dont nous n'avons pas pu récupérer les sources. Je pense par exemple à SynC Modular, qui est un logiciel de synthèse musicale dont on a pas encore réussi à contacter l'auteur pour obtenir une copie du code. Et là, ce sera difficile de faire quoi que ce soit, il faudra donc le remplacer…
[^] # Re: Logiciels disponibles
Posté par pulkomandy (page perso) . En réponse à la dépêche Haiku a 17 ans. Évalué à 2 (+1/-1).
On dit Haiku, pas HaikuOS :)
Sinon il faut dire aussi LinuxOS et WindowsOS, question de cohérence :p
[^] # Re: Pourquoi un tiret bas?
Posté par pulkomandy (page perso) . En réponse au journal Ⓒ✙✙ Le tiret bas (underscore) au début des variables membres ?. Évalué à 3 (+3/-2).
Rien ne t'empêche d'avoir une couleur différente pour chaque caractère du nom de ta variable, avec une signification différente.
Mais pour moi, du code propre et bien rédigé doit pouvoir se lire sans coloration syntaxique. La coloration, c'est pratique pour essayer de démêler un code illisible.
[^] # Re: Pourquoi un tiret bas?
Posté par pulkomandy (page perso) . En réponse au journal Ⓒ✙✙ Le tiret bas (underscore) au début des variables membres ?. Évalué à 6 (+5/-1). Dernière modification le 20/08/18 à 16:36.
On tourne en rond, quelqu'un a déjà donné ce lien.
La réponse reste la même: ce genre d'infos devrait être encodé dans le type de la variable, pas dans son nom. Pour reprendre l'exemple du blog, il faudrait une classe UnsafeString, et les chaînes non sûres devraient être stockées dans des variables de ce type.
Après, on peut, au choix, mettre un operator= (ou un opérateur de cast, ou…) qui va faire la conversion de façon transparente (mais il faut bien réfléchir), ou ajouter la méthode .Encode() pour que ce soit explicite.
Et du coup, ce n'est plus au développeur de vérifier ce genre de choses: le compilateur va faire le job tout seul. Le mauvais code fonctionnera quand même dans le premier cas (on va juste perdre en performance avec des conversions inutiles de partout), et ne compilera même pas dans le second.
Par contre, et c'est ce dont on débat ici, il n'est pas question d'avoir un type différent pour une variable locale et un membre d'une classe. Donc, dans ce cas, avoir un préfixe peut faire sense (encore que, utiliser systématiquement this-> n'est pas forcément une mauvaise idée, quoi qu'un peu verbeuse).