pulkomandy a écrit 1728 commentaires

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.

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.

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 :)

On m'informe que l'entreprise qui a sponsorisé NetSurf s'appelle Codethink, sans T majuscule. Si quelqu'un peut corriger, ça serait super.

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:

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.

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&section=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?

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…

On dit Haiku, pas HaikuOS :)
Sinon il faut dire aussi LinuxOS et WindowsOS, question de cohérence :p

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).

Ce n'est pas parce qu'un logiciel a commencé à être développé il y a 17 ans qu'il est obsolète. Je ne comprend pas cette manie de vouloir tout réécrire à partir de zéro tous les 5 ans.

Comme l'a dit devnewton plus bas, en 2003 on avait plein d'environnements de bureau sympa sous Linux, mais ils ont tous décidé de tout jeter et de recommencer. C'est pas comme ça qu'on arrivera à quoi que ce soit.

L'API de Haiku a pas mal changé par rapport à celle de BeOS, et les habitudes au niveau des interfaces utilisateur aussi. Mais ça reste quand même largement moins cher de mettre à jour une application existante que de refaire tout le dev.

Chez moi, les variables membres sont préfixées par un f (comme "field"), les statiques par un s, et les constantes par un k. Et les méthodes ont des noms qui commencent par une majuscule, donc pas de conflit possible lors de la complétion.

    struct Limit
    {
        int32_t fQuantity;
        double  fPrice;
        bool    fActive;
    };


    class MyClass
    {
         public:
             double  Volume() const;

         private:
             int32_t fQuantity;
             double  fPrice;
             bool    fAsActive;

             static const double kTaxes;
    };


    double MyClass::Volume() const
    {
         double volume = fPrice * fQuantity * (1 + kTaxes);
         return volume;
    }

Et puis franchement, y'a vraiment pas beaucoup de caractères réservés dans les noms des identifiers, pourquoi vouloir justement utiliser ceux-là? Pourquoi pas un ‿ par exemple?

En ce qui me concerne, Haiku est mon système principal depuis quelques années et j'ai vraiment du mal à utiliser Windows et même GNU/Linux (ou j'ai réussi à avoir un système qui fonctionne à peu près comme je veux après plusieurs années à ajuster des fichiers de configuration).

Même si on ne remplace pas Windows sur les PC de bureau, ça fonctionne au moins sur ma machine et c'est dans mon intérêt qu'il y aie plus d'utilisateurs et j'espère, plus de contributeurs. Même si les ambitions ne sont pas forcément gigantesques.

Le côté expérience est également un point important. J'ai appris plein de choses sur le C++ en travaillant dans Haiku, mais aussi sur la façon de gérer un projet libre avec des contributeurs bénévoles, un management sans chef de projet, ce qui a ses avantages et ses inconvénients. Et aussi l'encadrement d'étudiants dans le cadre du Google Summer of Code et du Google Code-In, qui nous oblige à réfléchir à la façon dont de nouveaux contributeurs peuvent aborder le projet.

Il y a aussi un peu un intérêt historique à découvrir le fonctionnement de ces applications BeOS, qui parfois ont essayé de faire des choix différents, en profitant d'être sur une plateforme toute nouvelle, qui pouvait se permettre de bousculer un peu les habitudes. On peut donc avoir un regard avec un peu de recul sur ce qui a marché ou pas.

Le projet HaikuArchives essaie de récupérer le code source d'un grand nombre d'applications pour BeOS. On assure la maintenance de ces applications mais pour les tenur vraiment à jour ce serait un travail beaucoup plus important, donc on fait le minimum pour l'instant…

En parallèle, on a des applications Qt qui sont portées avec une assez bonne intégration (c'est ce qui nous permet d'avoir LibreOffice, par exemple). Mais ces applications ne sont pas "natives", et ne s'intègrent jamais parfaitement dans l'environnement de Haiku, donc on les considère comme une étape de transition, ça permet de combler les trous quand une application native pour Haiku n'existe pas encore.

On pourrait faire la même chose avec GTK, mais pour l'instant on considère plus important le travail sur l'OS et les applications natives.

Je vais répondre en reprenant la description présente sur le site de Haiku:

Haiku is an open-source operating system that specifically targets personal computing. Inspired by the BeOS, Haiku is fast, simple to use, easy to learn and yet very powerful.

L'objectif est donc de fournir un système open source, taillé spécialement pour l'informatique personelle (on entend par là: pas les smartphones, pas l'embarqué, et pas les serveurs). On le voudrait rapide, simple à utiliser et à apprendre, mais cependant puissant (que je traduirait plutôt par flexible).

Un certains nombres de contributeurs à Haiku ne croient pas à "Linux sur le Desktop". Les contraintes sont différentes entre un système embarqué, un serveur, et un PC de bureau, et il nous semble difficile d'arriver à répondre à tous ces besoins à la fois de façon optimale. L'adaptabilité d'un système GNU/Linux à tous ces marchés le force à faire des compromis pour aller plus dans un sens que dans un autre. Et actuellement, on a avec Android des gens qui poussent le support des smartphones, et avec RedHat des gens qui poussent plutôt le côté serveurs. Il y a Ubuntu qui essaie de s'attaquer au segment du desktop, mais je ne sais pas si ça durera encore longtemps. Visiblement leur succès n'a pas été aussi grand qu'attendu.

Il y a donc toujours une place pour un système libre sur ce marché.

Maintenant, la question qui fache, c'est comment on s'y prend pour arriver à prendre cette place avec Haiku. On va avoir besoin de faire évoluer encore plein de choses. Certaines ne posent pas vraiment question, par exemple, il va falloir mettre des efforts sur l'accélération 3D, un meilleur support des imprimantes, améliorer encore le port de LibreOffice. Mais à un peu plus long terme, on a un gros travail à faire pour prendre des décisions importantes pour la version "R2" de Haiku. Quelques exemples: doit-on remplacer les APIs de BeOS par celles de Qt (éventuellement avec quelques extensions)? Combien de temps va-t-on encore s'embêter à maintenir une version à base de gcc2 pour faire fonctionner les applications BeOS? Comment procèdera-t-on pour faire une transition en douceur? Jusqu'à quel point doit-on assurer la maintenance des vieilles applications BeOS? Doit-on conserver le système de fichiers BFS, essayer d'utiliser un système concurrent (par exemple ZFS, XFS ou btrfs), ou bien doit-on développer notre propre système de fichiers pour conserver les particularités de BFS (en particulier l'indexation des attributs étendus)? Jusqu'à quel point doit-on encourager le portage et l'intégration d'applications Qt et est-ce qu'il ne vaudrait pas mieux pousser les gens à écrire des applicatons natives?

Pour l'instant, ces sujets n'ont pas vraiment été abordés. La priorité est d'arriver à faire une version R1, et ensuite de voir si on arrive à construire un écosystème d'applications autour de notre OS. Si vous avez déjà vu ce qu'on démontre sur notre stand, il y a beaucoup d'idées intéressantes (gérer les mails ou une collection de medias avec des attributs étendus, par exemple), mais souvent on fait ça sous forme de démo bricolée avec le navigateur de fichier. La technologies est là mais ça manque souvent d'une interface utilisateur vraiment bien pensée, et au final personne n'utilise vraiment toutes ces belles fonctions. Je pense que le gros du travail va se trouver là dans les années à venir. Et une fois qu'on aura plein d'applications modernes, on aura un peu plus de recul sur les évolutions à apporter à l'API (même si on a déjà quelques idées).

Voilà, c'est ma vision des choses. Cependant j'en ai pas forcément beaucoup discuté avec tous les autres contributeurs du projet, et nous n'avons donc pas forcément fait converger nos idées sur ces différents points, pour l'instant.

Pour Cosmoe, une partie du code devra être modifiée pour fournir les mêmes APIs de façons différente. Par exemple, les BMessages et une grande partie du Media Kit sont implémenté dans Haiku via les "ports", une IPC qui n'existe pas dans POSIX. Mais il est possible de réaliser la même chose en utilisant d'autres IPCs. On est curieux de voir ce que cela donnera au niveau des performances.

D'autres choses sont et resteront impossibles sur un noyau Linux, par exemple la possibilité d'ouvrir un fichier en connaissant uniquement son numéro d'inode (ce qui est possible dans l'API de BeOS mais un gros trou de sécurité).

La notion de window manager est plus ou moins présente. Il ne s'agit pas d'un exécutable séparé, mais plutôt d'un add-on du serveur graphique (appelé "decorator"). Cela dit, l'un ou l'autre choix est valable et n'a pas vraiment d'influence sur l'API publique.

Pour les drivers, en dehors du problème des licences, les deux gros soucis du côté de Linux sont que le code est souvent assez peu lisible (peu de commentaires, etc), et que les API internes ont tendance à beaucoup changer d'une version à l'autre. FreeBSD est, en comparaison, relativement stable, ce qui nous permet de suivre plus facilement leurs évolutions.

On regarde quand même du côté de Linux, par exemple pour les drivers graphiques. Supposément, Gallium3D permet d'avoir des drivers en userland, portables d'un OS à l'autre, mais ça n'a pas l'air d'avoir vraiment marché comme ça. On va peut-être s'inspirer de ce qu'on fait FreeBSD ou DragonFlyBSD pour récupérer les pilotes Linux.

En ce qui concerne les licences, d'une part, certains pilotes Linux sont sous licence BSD, ce qui nous va très bien (par exemple pour les cartes graphiques Intel, il me semble). D'autre part, même si un pilote est sous GPL, il peut être compilé indépendament du noyau et installé séparément, donc ce ne serait pas forcément un problème (l'avantage d'avoir une ABI propre et stable pour les pilotes de périphériques ;) ).

La version anglaise dit la même chose:

A registry hive is a group of keys, subkeys, and values in the registry that has a set of supporting files that contain backups of its data.

Donc ce n'est pas une traduction bizarre. La base de registre est découpée en plusieurs ruches.
Je ne connaissais pas ce terme, moi non plus.

Tu installes mupdf et tu pourras utiliser des commandes vim du type 42g pour aller à la page 42 ou /mot pour chercher un mot (puis n pour passer au résultat suivant). Je ne peux plus m'en passer pour naviguer dans des PDFs.

C'est assez peu mentionné, mais les "anciens" compteurs électroniques (la génération avant Linky) permettait de récupérer ces infos directement chez soit, via un port série situé directement sur le compteur. Pourquoi il faudrait envoyer cette information au fournisseur d'énergie puis… leur demander pour y avoir accès? (accès qu'ils pourraient très bien rendre payant, d'ailleurs).

Donc le côté éducation/information, ça existait déjà, mais ça n'intéressait pas grand monde.

L'intérêt du relevé heure par heure, c'est que le fournisseur d'énergie va pouvoir facturer ça comme il veut (par exemple Direct Energie propose des heures "super creuses" à certaines périodes). On est plus limité à un modèle heures pleines/heures creuses avec des horaires fixes imposés par le distributeur d'énergie.