Je contribue depuis quelques années au projet Haiku (www.haiku-os.org). C'est un projet qui a fait le choix d'une license (très) libre (la license MIT), mais aussi de déposer la marque "Haiku".
Le but n'est pas d'empêcher les gens de modifier le logiciel, bien au contraire. On fournit tous les outils pour compiler le système avec ou sans la marque (toutes les apparitions du nom et du logo de Haiku peuvent être enlevées avec une simple option du script de configuration).
ça permet à tout le monde de faire ce qu'il veut avec le code du projet: distribuée des versions plus ou moins modifiées, récupérer des morceaux du code pour en faire complètement autre chose, etc. Par contre, le nom "Haiku" nous appartient, et c'est normal que les projets qui font des modifications aient des noms différents, simplement pour que tout le monde s'y retrouve. Je ne pense pas que ça soit une très grosse contrainte. Et dans tous les cas, n'importe qui peut demander la permission d'utiliser le nom, qui en général ne pose pas de problèmes. C'est par exemple le cas de la distribution "discover Haiku" (http://www.discoverhaiku.com/), vendue par une entreprise indépendante du projet Haiku. Tous les bénéfices de la vente de "Discover Haiku" (sous la forme d'une clé USB) n'iront pas forcément au projet Haiku. ça ne pose pas de problèmes du moment qu'ils ont demandé la permission, mais si quelqu'un le faisait sans demander et dans le but de ramasser des sous en se faisant passer pour le projet Haiku, ça serait quand même pas terrible.
Donc, on a une protection en déposant la marque, et ensuite, on a des exceptions qui donnent à des gens le droit de l'utiliser. C'est exactement le même principe de fonctionnement que la license GPL, qui utilise le droit du copyright pour d'abord dire ce qu'on n'a pas le droit de faire, et ensuite donner des droits bien précis aux gens qui sont prêts à respecter les règles. Moi ça me semble tout à fait raisonable?
Il y a eu plein d'autres projet rejetés pour le GSoC cette année, y compris certains plus petits et qui participaient aussi depuis longtemps. Une des raisons est qu'il y a beaucoup de bonnes candidatures et pas de place pour tout le monde. Du coup, certains projets ne sont acceptés qu'un an sur deux, par exemple.
Je ne pense pas qu'il y aie derrière une volonté stratégique de la part de Google.
Le site du fork en question: http://kolibrios.org/fr/
Il me semble que la communauté de KolibriOS est un peu plus impliquée dans le libre, avec une participation régulière au Google Summer of Code et au moins quelques uns des développeurs assez présents sur les canaux IRC de Freenode. Je n'y ai jamais vu de développeur de MenuetOS.
Je n'ai pas tous les détails, alors, je vous laisse vous faire un avis.
Dans d'autres pays d'Europe il y a moins de SSII mais beaucoup de dévelopeurs en freelance. La raison c'est, je pense, que c'est quand même un peu plus compliqué/plus cher/moins confortable en France de monter sa boîte tout seul.
Et puis c'est pas forcément mal, une SSII: c'est pour le client un moyen d'avoir une solution sur mesure, plutôt qu'un logiciel générique. Est-ce que le problème ne serait pas ailleurs?
La plupart de ces appareils électroniques chinois n'ont pas passé les tests pour les normes CE, FCC, et autres. C'est encore un coût en moins pour les entreprises qui conçoivent et fabriquent ces appareils.
ça ne les empêche pas forcément de fonctionner, on trouve du bon, mais aussi du très mauvais (composants électroniques factices, par exemple, ou chargeurs de téléphones portables avec une conception électronique dangereuse).
Le BASIC du Thomson TO8 a des instructions "turtle" pour utiliser une tortue comme en Logo. Je ne sais pas si c'est le cas d'autres versions du BASIC Microsoft, mais en tout cas, la tortue en BASIC, ça existe!
Le site passera en mode "lecture seule", puis dans un deuxième temps en mode "archive", proposant de télécharger une archive de chaque projet pour en extraire les données et les remettre en ligne ailleurs.
Ils ont également fourni des outils pour faciliter la migration sur d'autres plateformes (sans avoir besoin d'être administrateur du projet du côté google code).
De plus, avec un hébergement décentralisé (git ou mercurial par exemple), on peut de toutes façons retrouver tout l'historique du repo à partir d'un checkout des sources, donc il y a peu de chance d'avoir des choses définitivement perdues.
Conclusion: ça se passe beaucoup mieux que lors de la fermeture de berlios ou d'opensvn.
Ils ne sont pas partis d'un cadavre, ils ont développé tout ça y'a 10 ans quand Sourceforge, c'était cool, et que gitlab, ça n'existait pas. Et maintenant ça tourne, alors pourquoi migrer?
L'exercice est intéressant en tout cas, même si le résultat n'est pas forcément utilisable. ça permet de voir dans quelle mesure les langages de programmation existants sont plus ou moins influencés par l'anglais, par les notations mathématiques, etc.
Si on regarde les conventions de codage et de nommage souvent utilisées, on va trouver des choses du genre:
- une fonction doit être nommée par un verbe
- une variable doit être nommée par un nom
- utilisation de la notation hongroise pour marquer le type ou le rôle d'un objet dans son nom
Pourquoi ne pas inclure ces conventions directement dans un langage de programmation? Et du coup, est-ce qu'on ne pourrait pas enlever les mots clés utilisés actuellement pour exprimer la même chose?
Là, on se rapproche peut-être du BASIC, ou a$ est une chaîne de caractères, a% est un entier, etc (et le suffixe suffit au compilateur pour connaître le type des variables).
En utilisant le Latin dans Perligata, on obtient un langage assez verbeux, mais qui a la particularité d'identifier le rôle des objets utilisés par leurs déclinaisons et autres suffixes, plutôt que par leur position dans la phrase. Après, on peut "optimiser" le langage de programmation obtenu et utiliser des suffixes symboliques et plus concis, en essayant de conserver cette idée que l'ordre des mots n'est pas important.
Donc, le passage par l'Esperanto ou une autre langue permet peut-être d'exprimer des concepts d'une façon différente de l'Anglais, et du coup, d'arriver à un langage de programmation qui fonctionne différement, et éventuellement qui sera plus facile à prendre en main, même si au final on y met quand même de la notation symbolique.
L'anglais est concis en programmation parce que beaucoup de développeurs ont l'habitude de réfléchir en anglais, et de nommer les choses dans cette langue. Du coup dans les autres langues on a que des traductions, pas toujours heureuses, des concepts anglais.
Il est donc intéressant de voir ce qu'il peut se passer si on essaie de travailler avec un autre langage. L'utilisation de déclinaisons en Latin, et de préfixes et suffixes en Esperanto, par exemple (voir les commentaires au dessus et en dessous) permettent une conception assez différente d'un langage de programmation. Les mots dans ces langues sont "fortement typés" (verbe, sujet, complément) et du coup Lingua::Romana::Perligata arrive à se passer complètement de notations symboliques (du genre = pour l'affectation). ça ne serait pas possible avec l'anglais comme base car il y aurait souvent des ambiguïtés (sujet/complément en particulier).
C'est donc intéressant juste pour voir ce qu'il en ressort, à condition que ça soit un peu plus que juste un rechercher/remplacer des mots clés du langage et des noms de fonctions des bibliothèques standard.
J'ai entendu parler de Purism (https://puri.sm/) avec un projet de laptop entièrement libre (pas de blob firmware, etc) et avec du matériel qui n'a pas l'air mal. C'est encore en précommande, et je ne sais pas ce que ça donnera au niveau de la qualité et de la solidité (mais ils ont pas l'air d'etre du genre à faire des compromis). A surveiller, en tout cas…
Ce n'est pas impossible d'avoir un GC dans un système temps réel (ou n'importe quel autre système de gestion dynamique des allocations mémoire). ça complique un peu les choses, il faut avoir un GC exécutable de façon planifiée et avec un temps 'exécution borné, mais dont on est sur qu'il peut libérer au moins autant de mémoire qu'il en a été allouée depuis sa dernière exécution.
Le but du C est d'etre proche du matériel. Et toutes les architectures ne font pas la meme chose en cas d'overflow. ça peut faire un modulo, ou bien ça peut déclencher une exception matérielle. Dans le deuxième cas, tout le programme s'arrete (sauf si on intercepte le signal, etc). Donc: comportement indéfini pour tout le programe dans la norme C. Dans le cas contraire, soit certaines machines devraient intercepter le signal et faire le calcul du modulo, soit les autres devraient intercepter les overflows et lever une "exception" (ah mais ça n'existe pas en C ça).
Il y a pour cela plein de langages de plus haut niveau tout à fait appropriés et que le C n'essaie pas de remplacer. Avec des solutions différentes selon les cas: une machine virtuelle connue et maitrisée pour Java (avec un comportement bien défini), un système d'exception qui permet d'intercepter le problème en Ada, etc.
Sur les machines ou l'overflow d'un entier déclenche une erreur matérielle, Rust va devoir l'intercepter et reprendre l'exécution du programme. C n'a pas besoin de le faire. D'ou une simplification du runtime pour le C quelle que soit l'architecture cible.
En plus de ça, un git qui forcerait tout en minuscules ne serait pas pratique. On a besoin de versionner des fichiers avec des noms localisés et sensibles à la casse dans certains cas, et c'est bien que les outils puissent le gérer correctement.
Il y a plein de problèmes de ce genre avec git (par exemple, s'il y a un caractère non-ASCII dans le nom d'un fichier, pour que ça marche correctement sous Mac OS X qui code cela différement, il y a une option). Même chose pour l'encodage des caractères de fin de ligne, git peut les convertir automatiquement, ou pas, et c'est une option, configurable globalement ou par dépôt.
D'autres logiciels ont le même genre de problèmes, par exemple zip et unzip qui doivent convertir des noms de fichiers entre l'encodage "natif" du système et celui de la destination (ça peut être ASCII vers EBCDIC et inversement, une des codepages spécifiques de Windows vers de l'UTF8 et inversement, etc).
Sans ça, on reste avec le plus grand sous ensemble commun, c'est à dire que de l'ASCII, en minuscules, sans caractères spéciaux, et probablement avec des noms en 8.3 pour que tout le monde soit content. C'est bien, mais on est plus en 1980, et pouvoir nommer ses fichiers librement, c'est bien pratique.
Sinon, il y a Haiku qui est libre et qui fait les 2: une API stable et assez riche pour qu'on puisse developper des applications qui n'ont pas d'autres dependances que l'OS ; et aussi un gestionnaire de paquets qui permet d'avoir plusieurs versions d'une bibliotheque installees en fonction des besoins des applications. Et le tout avec un gestionnaire de paquets qui fait les mises a jour tout seul quand on le lui demande, en plus.
Mais justement, speedtest est parfait pour tester le lien ADSL ou fibre entre la maison et l'operateur auquel on s'interesse ici. Tandis que iperf permet de tester en plus le lien operateur <> internet (et c'est un autre probleme)
Forcent, oui. Tu crées un objet BApplication, 1 thread. Tu crées un objet BWindow, 1 thread (+ 1 du coté du serveur graphique pour le rendu). Après on peut faire exprès de ne pas se servir du thread de la BApplication et faire tous les traitements dans le thread de la fenetre pour avoir une UI lente. Mais il faut faire exprès (et encore, de toutes façon le système envoie des messages à ces deux threads selon les cas donc il faudrait les rediriger de l'un vers l'autre).
Dans la plupart des autres frameworks, c'est l'inverse. On peut faire une UI réactive avec un thread dédié aux traitements longs, mais il faut le faire exprès.
Un autre détail: par défaut le thread fenetre a une priorité supèrieure, et donc le système est plus réactif. Là encore, sur les autres systèmes, on peut le faire, mais ça n'est pas le cas par défaut.
Dans Haiku on essaie pas de révolutionner l'informatique, on essaie de faire un système qui "juste marche". Pour ça on a les memes solutions et bonnes pratiques que tout le monde, mais on essaie de faire en sorte que la bonne solution soit également la plus simple à mettre en œuvre.
ça avance. Mais ce n'est pas une question de légèreté, c'est une question de réactivité. Même sur un Pi avec 512Mio de RAM, Haiku peut tourner sans problème. Par contre, sans accélération de l'affichage, ça va pas être si intéressant que ça. Le Pi a un GPU très puissant, et il faudrait l'exploiter au maximum pour le rendu graphique ce qui permettrait de libérer le CPU pour des choses importantes.
Sous Linux ça devient de plus en plus difficile. Pour que ça marche bien on a besoin d'un serveur graphique qui coordonne toutes les opérations de dessin. X le fait, mais comme il ne fait pas d'antialiasing, c'est moche, et du coup les toolkits majeurs (Qt, GTK) n'utilisent plus X et font le rendu côté client. Et du coup il y a Wayland qui se prépare et qui supprime définitivement le rendu côté serveur.
Dans le cas de Haiku, c'est toujours app_server qui fait le rendu pour les applications natives, et donc si on fait un backend de l'app_server qui utilise le GPU pour le tracé 2D (par exemple via OpenVG), toutes les applications en bénéficieront. Mais ça reste pas mal de travail à faire.
Pour le port ARM lui même, ça avance doucement (le kernel se lance, maintenant il faut modifier le pilote USB qui n'est pas capable de fonctionner sans un bus PCI, de façon a faire marcher le stockage de masse USB et pouvoir charger le reste du système de fichiers pour booter plus loin). Par contre on cible pour le moment les ARMv7 ce qui exclut le Raspberry Pi. Il y a un peu de support à faire pour ARMv6 (pour les opérations atomiques, qui n'ont pas d'instruction dédiée et doivent être implémentées autrement, si je me souviens bien). Le manque de support du Pi dans QEMU est aussi un peu embêtant pour démarrer le travail.
"aucune", c'est pas tout à fait vrai. Il y a un support minimal t il ya eu dernièrement quelques corrections. Mais ça reste un des points qui ne sont pas prévus pour la version R1 de Haiku, c'est prévu pour plus tard (sauf si quelqu'un se lance là dedans…)
Il y a des réflexions en cours sur la façon de faire, on a des permissions de type UNIX mais il faut voir ce qu'on en fait, peut etre qu'elles seront utilisées pour sandboxer les applications comme dans Android.
Pour l'instant, le truc qui coince c'est la compatibilité binaire avec BeOS qui nous force à utiliser un gcc 2.95.3 (avec pas mal de patchs…). C'est la principale raison qui motive cette tentative de faire une version 1 rapidement (c'est dans la roadmap du projet, la version 1 doit etre compatible avec BeOS). Une fois qu'on a sorti cette version 1, on pourra enfin démarrer le travail de mise à jour de l'API (il y a eu des améliorations, mais on commence à atteindre les limites de ce qui peut etre fait sans casser la compatibilité).
Comme à ce moment là il y aura une version stable et supportée de Haiku, de nouvelles applications pourront etre développées, et (on espère) remplaceront les quelques applications BeOS pour lesquelles il n'y a pas encore d'alternative crédible. Ensuite il n'y aura plus de problème pour casser la compatibilité et on pourra avancer.
Cela ne s'applique que pour la version x86 (et pas les versions x86_64 et ARM) de Haiku, c'est la seule ou la compatibilité est assurée. On a aussi un compilateur gcc4 pour compiler les applications modernes, bien sur. Donc, actuellement on peut remplacer gcc4 par clang (et ne pas avoir de compatiblité gcc2). Il reste un peu de travail pour:
- Améliorer le code en supprimant les warnings levés par clang (mais ce n'est pas toujours possible si le code doit continuer à compiler avec gcc2)
- Supprimer ou réduire le plus possible l'utilisation des extensions de gcc (idem)
- Tester le système ainsi compilé et vérifier qu'il n'y a pas de régressions (a priori non, ça a l'air de tourner comme il faut), et que le code généré est au moins aussi performant (ça n'est pas nécessairement le cas, la plupart des benchmarks de clang le teste avec un jeu d'instruction moderne (SSE, SSE2, SSSE, …) mais Haiku est toujours compilé pour une cible 586 (MMX, et rien d'autre) (pour la version x86 uniquement).
Donc, ça fonctionne déjà, mais c'est peu testé, donc il semble raisonable de sortir une version R1 dont on est surs qu'elle est stable et de faire ce changement ensuite (pour la version R1.1 ou R2, par exemple).
Si je n'étais pas contributeur Haiku, je ne pense pas que je serais contributeur Linux. Donc, avoir un projet comme Haiku pour les développeurs de noyau qui ont envie de faire du C++ augmente le pool de dévloppeurs de logiciels libres. C'est plutot cool, non?
Je prend des exemples dans le noyau, parce qu'on est en train de le comparer à Linux (qui est seulement un noyau). Mais le même raisonnement s'applique à d'autres parties du système: là ou on utilise des bibliothèques externes (il n'y a pas que WebKit, mais aussi par exemple freetype et ffmpeg), elles sont systématiquement enveloppées dans une API en C++ qui s'intègre avec le reste du système.
Comme je l'ai dit, le choix de ne pas utiliser Linux a été fait en 2001. Les choses ont changé aujourd'hui et si le projet commençait maintenant, on ferait peut etre un choix différent. Mais là, on essaie surtout de sortir une version 1 "finie" afin de pouvoir passer à la suite. Et donc, je ne vois pas l'interet de passer du temps à changer de noyau maintenant alors qu'on en a un qui marche quand meme pas si mal que ça. Une fois la version 1 sortie, oui, pourquoi pas. Mais je trouve ça dommage pour les développeurs qui sont intéressés pour travailler sur un noyau en C++ (et qui potentiellement ne sont pas intéressés pour contribuer à Linux en C, ni aux autres parties de Haiku qui ne sont pas le noyau). Cosmoe est là, il attend son heure, et si ça intéresse assez de gens qui s'y mette sérieusement, ça peut faire un système utilisable sans avoir trop d'efforts à faire. En attendant, on continue à utiliser notre propre noyau.
# Un autre exemple
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal Quand le libre est un faux nez pour de la vraie propriété intellectuelle. Évalué à 8.
Bonjour,
Je contribue depuis quelques années au projet Haiku (www.haiku-os.org). C'est un projet qui a fait le choix d'une license (très) libre (la license MIT), mais aussi de déposer la marque "Haiku".
Le but n'est pas d'empêcher les gens de modifier le logiciel, bien au contraire. On fournit tous les outils pour compiler le système avec ou sans la marque (toutes les apparitions du nom et du logo de Haiku peuvent être enlevées avec une simple option du script de configuration).
ça permet à tout le monde de faire ce qu'il veut avec le code du projet: distribuée des versions plus ou moins modifiées, récupérer des morceaux du code pour en faire complètement autre chose, etc. Par contre, le nom "Haiku" nous appartient, et c'est normal que les projets qui font des modifications aient des noms différents, simplement pour que tout le monde s'y retrouve. Je ne pense pas que ça soit une très grosse contrainte. Et dans tous les cas, n'importe qui peut demander la permission d'utiliser le nom, qui en général ne pose pas de problèmes. C'est par exemple le cas de la distribution "discover Haiku" (http://www.discoverhaiku.com/), vendue par une entreprise indépendante du projet Haiku. Tous les bénéfices de la vente de "Discover Haiku" (sous la forme d'une clé USB) n'iront pas forcément au projet Haiku. ça ne pose pas de problèmes du moment qu'ils ont demandé la permission, mais si quelqu'un le faisait sans demander et dans le but de ramasser des sous en se faisant passer pour le projet Haiku, ça serait quand même pas terrible.
Donc, on a une protection en déposant la marque, et ensuite, on a des exceptions qui donnent à des gens le droit de l'utiliser. C'est exactement le même principe de fonctionnement que la license GPL, qui utilise le droit du copyright pour d'abord dire ce qu'on n'a pas le droit de faire, et ensuite donner des droits bien précis aux gens qui sont prêts à respecter les règles. Moi ça me semble tout à fait raisonable?
[^] # Re: Merci !
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal Retour sur les décisions, les projets et les polémiques de Mozilla des dernières années. Évalué à 3.
Il y a eu plein d'autres projet rejetés pour le GSoC cette année, y compris certains plus petits et qui participaient aussi depuis longtemps. Une des raisons est qu'il y a beaucoup de bonnes candidatures et pas de place pour tout le monde. Du coup, certains projets ne sont acceptés qu'un an sur deux, par exemple.
Je ne pense pas qu'il y aie derrière une volonté stratégique de la part de Google.
[^] # Re: ambiance sur le projet...
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal MenuetOS : 1.0. Évalué à 4.
Le site du fork en question: http://kolibrios.org/fr/
Il me semble que la communauté de KolibriOS est un peu plus impliquée dans le libre, avec une participation régulière au Google Summer of Code et au moins quelques uns des développeurs assez présents sur les canaux IRC de Freenode. Je n'y ai jamais vu de développeur de MenuetOS.
Je n'ai pas tous les détails, alors, je vous laisse vous faire un avis.
[^] # Re: Et à coté de ça
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal L'Armée Française et ses logiciels, bis repetita.... Évalué à 1.
Haiku, inc: entre 25000 et 35000 dollars par an.
[^] # Re: Alternatives à roundcube
Posté par pulkomandy (site web personnel, Mastodon) . En réponse à la dépêche Debian 8 : Jessie l’écuyère est en selle !. Évalué à -3.
J'utilise maintenant Rainloop, qui est simple et efficace: http://www.rainloop.net/
[^] # Re: On dit pas SSII, mais ESN
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal sous-developpeurs-SSII. Évalué à 4.
Il y a un outil (libre) pour t'aider à faire le tri: http://joblint.org/
[^] # Re: Mauvais clients
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal techos bradés. Évalué à 2.
Dans d'autres pays d'Europe il y a moins de SSII mais beaucoup de dévelopeurs en freelance. La raison c'est, je pense, que c'est quand même un peu plus compliqué/plus cher/moins confortable en France de monter sa boîte tout seul.
Et puis c'est pas forcément mal, une SSII: c'est pour le client un moyen d'avoir une solution sur mesure, plutôt qu'un logiciel générique. Est-ce que le problème ne serait pas ailleurs?
# Certifications
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal Arduino et AliExpress. Évalué à 2.
La plupart de ces appareils électroniques chinois n'ont pas passé les tests pour les normes CE, FCC, et autres. C'est encore un coût en moins pour les entreprises qui conçoivent et fabriquent ces appareils.
ça ne les empêche pas forcément de fonctionner, on trouve du bon, mais aussi du très mauvais (composants électroniques factices, par exemple, ou chargeurs de téléphones portables avec une conception électronique dangereuse).
[^] # Re: Objectif, en pratique?
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal Ming Tea. Évalué à 1.
Le BASIC du Thomson TO8 a des instructions "turtle" pour utiliser une tortue comme en Logo. Je ne sais pas si c'est le cas d'autres versions du BASIC Microsoft, mais en tout cas, la tortue en BASIC, ça existe!
[^] # Re: quelques pépites perdues à jamais
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal Fermeture progressive de Google Code. Évalué à 2.
Le site passera en mode "lecture seule", puis dans un deuxième temps en mode "archive", proposant de télécharger une archive de chaque projet pour en extraire les données et les remettre en ligne ailleurs.
Ils ont également fourni des outils pour faciliter la migration sur d'autres plateformes (sans avoir besoin d'être administrateur du projet du côté google code).
De plus, avec un hébergement décentralisé (git ou mercurial par exemple), on peut de toutes façons retrouver tout l'historique du repo à partir d'un checkout des sources, donc il y a peu de chance d'avoir des choses définitivement perdues.
Conclusion: ça se passe beaucoup mieux que lors de la fermeture de berlios ou d'opensvn.
[^] # Re: Et SourceSup
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal Fermeture progressive de Google Code. Évalué à 2.
Ils ne sont pas partis d'un cadavre, ils ont développé tout ça y'a 10 ans quand Sourceforge, c'était cool, et que gitlab, ça n'existait pas. Et maintenant ça tourne, alors pourquoi migrer?
[^] # Re: Intérêt
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal Et vous, à votre avis, pour où commencer une quête pour une chaîne de compilation espérantophone ?. Évalué à 3.
L'exercice est intéressant en tout cas, même si le résultat n'est pas forcément utilisable. ça permet de voir dans quelle mesure les langages de programmation existants sont plus ou moins influencés par l'anglais, par les notations mathématiques, etc.
Si on regarde les conventions de codage et de nommage souvent utilisées, on va trouver des choses du genre:
- une fonction doit être nommée par un verbe
- une variable doit être nommée par un nom
- utilisation de la notation hongroise pour marquer le type ou le rôle d'un objet dans son nom
Pourquoi ne pas inclure ces conventions directement dans un langage de programmation? Et du coup, est-ce qu'on ne pourrait pas enlever les mots clés utilisés actuellement pour exprimer la même chose?
Là, on se rapproche peut-être du BASIC, ou a$ est une chaîne de caractères, a% est un entier, etc (et le suffixe suffit au compilateur pour connaître le type des variables).
En utilisant le Latin dans Perligata, on obtient un langage assez verbeux, mais qui a la particularité d'identifier le rôle des objets utilisés par leurs déclinaisons et autres suffixes, plutôt que par leur position dans la phrase. Après, on peut "optimiser" le langage de programmation obtenu et utiliser des suffixes symboliques et plus concis, en essayant de conserver cette idée que l'ordre des mots n'est pas important.
Donc, le passage par l'Esperanto ou une autre langue permet peut-être d'exprimer des concepts d'une façon différente de l'Anglais, et du coup, d'arriver à un langage de programmation qui fonctionne différement, et éventuellement qui sera plus facile à prendre en main, même si au final on y met quand même de la notation symbolique.
[^] # Re: Intérêt
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal Et vous, à votre avis, pour où commencer une quête pour une chaîne de compilation espérantophone ?. Évalué à 2.
L'anglais est concis en programmation parce que beaucoup de développeurs ont l'habitude de réfléchir en anglais, et de nommer les choses dans cette langue. Du coup dans les autres langues on a que des traductions, pas toujours heureuses, des concepts anglais.
Il est donc intéressant de voir ce qu'il peut se passer si on essaie de travailler avec un autre langage. L'utilisation de déclinaisons en Latin, et de préfixes et suffixes en Esperanto, par exemple (voir les commentaires au dessus et en dessous) permettent une conception assez différente d'un langage de programmation. Les mots dans ces langues sont "fortement typés" (verbe, sujet, complément) et du coup Lingua::Romana::Perligata arrive à se passer complètement de notations symboliques (du genre = pour l'affectation). ça ne serait pas possible avec l'anglais comme base car il y aurait souvent des ambiguïtés (sujet/complément en particulier).
C'est donc intéressant juste pour voir ce qu'il en ressort, à condition que ça soit un peu plus que juste un rechercher/remplacer des mots clés du langage et des noms de fonctions des bibliothèques standard.
# Lingua::Romana::Perligata
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal Et vous, à votre avis, pour où commencer une quête pour une chaîne de compilation espérantophone ?. Évalué à 5.
ça me fait penser à Lingua::Romana::Perligata, un module Perl qui permet de programmer en… Latin:
http://www.csse.monash.edu.au/~damian/papers/HTML/Perligata.html
Un exemple est donné sur cette page avec l'algorithme du cribble d'Erathostène:
# Purism
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal Superfish ou: j'ai rien compris au logiciel propriétaire. Évalué à 1.
J'ai entendu parler de Purism (https://puri.sm/) avec un projet de laptop entièrement libre (pas de blob firmware, etc) et avec du matériel qui n'a pas l'air mal. C'est encore en précommande, et je ne sais pas ce que ça donnera au niveau de la qualité et de la solidité (mais ils ont pas l'air d'etre du genre à faire des compromis). A surveiller, en tout cas…
[^] # Re: Un langage complexe ?
Posté par pulkomandy (site web personnel, Mastodon) . En réponse à la dépêche Le langage Rust en version 1.0 alpha, on arrête de tout casser !. Évalué à 2.
Ce n'est pas impossible d'avoir un GC dans un système temps réel (ou n'importe quel autre système de gestion dynamique des allocations mémoire). ça complique un peu les choses, il faut avoir un GC exécutable de façon planifiée et avec un temps 'exécution borné, mais dont on est sur qu'il peut libérer au moins autant de mémoire qu'il en a été allouée depuis sa dernière exécution.
ça a été fait par exemple ici avec du Java: http://www.ghs.com/news/20100302_IS2T_java_support.html
[^] # Re: Une chose que j'ai oublié d'ajouter
Posté par pulkomandy (site web personnel, Mastodon) . En réponse à la dépêche Le langage Rust en version 1.0 alpha, on arrête de tout casser !. Évalué à 10.
Le but du C est d'etre proche du matériel. Et toutes les architectures ne font pas la meme chose en cas d'overflow. ça peut faire un modulo, ou bien ça peut déclencher une exception matérielle. Dans le deuxième cas, tout le programme s'arrete (sauf si on intercepte le signal, etc). Donc: comportement indéfini pour tout le programe dans la norme C. Dans le cas contraire, soit certaines machines devraient intercepter le signal et faire le calcul du modulo, soit les autres devraient intercepter les overflows et lever une "exception" (ah mais ça n'existe pas en C ça).
Il y a pour cela plein de langages de plus haut niveau tout à fait appropriés et que le C n'essaie pas de remplacer. Avec des solutions différentes selon les cas: une machine virtuelle connue et maitrisée pour Java (avec un comportement bien défini), un système d'exception qui permet d'intercepter le problème en Ada, etc.
Sur les machines ou l'overflow d'un entier déclenche une erreur matérielle, Rust va devoir l'intercepter et reprendre l'exécution du programme. C n'a pas besoin de le faire. D'ou une simplification du runtime pour le C quelle que soit l'architecture cible.
[^] # Re: Est-ce vraiment une vulnérabilité de git ?
Posté par pulkomandy (site web personnel, Mastodon) . En réponse à la dépêche Vulnérabilité dans Git et Mercurial sur certains systèmes de fichiers (FAT, NTFS, HFS+, etc.). Évalué à 5.
En plus de ça, un git qui forcerait tout en minuscules ne serait pas pratique. On a besoin de versionner des fichiers avec des noms localisés et sensibles à la casse dans certains cas, et c'est bien que les outils puissent le gérer correctement.
Il y a plein de problèmes de ce genre avec git (par exemple, s'il y a un caractère non-ASCII dans le nom d'un fichier, pour que ça marche correctement sous Mac OS X qui code cela différement, il y a une option). Même chose pour l'encodage des caractères de fin de ligne, git peut les convertir automatiquement, ou pas, et c'est une option, configurable globalement ou par dépôt.
D'autres logiciels ont le même genre de problèmes, par exemple zip et unzip qui doivent convertir des noms de fichiers entre l'encodage "natif" du système et celui de la destination (ça peut être ASCII vers EBCDIC et inversement, une des codepages spécifiques de Windows vers de l'UTF8 et inversement, etc).
Sans ça, on reste avec le plus grand sous ensemble commun, c'est à dire que de l'ASCII, en minuscules, sans caractères spéciaux, et probablement avec des noms en 8.3 pour que tout le monde soit content. C'est bien, mais on est plus en 1980, et pouvoir nommer ses fichiers librement, c'est bien pratique.
[^] # Re: Probablement bientôt?!
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal Sans OS. Évalué à 3.
Sinon, il y a Haiku qui est libre et qui fait les 2: une API stable et assez riche pour qu'on puisse developper des applications qui n'ont pas d'autres dependances que l'OS ; et aussi un gestionnaire de paquets qui permet d'avoir plusieurs versions d'une bibliotheque installees en fonction des besoins des applications. Et le tout avec un gestionnaire de paquets qui fait les mises a jour tout seul quand on le lui demande, en plus.
[^] # Re: Débit symétrique
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal Numéricable et moi.. Évalué à 4.
Mais justement, speedtest est parfait pour tester le lien ADSL ou fibre entre la maison et l'operateur auquel on s'interesse ici. Tandis que iperf permet de tester en plus le lien operateur <> internet (et c'est un autre probleme)
[^] # Re: Eh ben...
Posté par pulkomandy (site web personnel, Mastodon) . En réponse à la dépêche Haiku se lâche enfin. Évalué à 10.
Forcent, oui. Tu crées un objet BApplication, 1 thread. Tu crées un objet BWindow, 1 thread (+ 1 du coté du serveur graphique pour le rendu). Après on peut faire exprès de ne pas se servir du thread de la BApplication et faire tous les traitements dans le thread de la fenetre pour avoir une UI lente. Mais il faut faire exprès (et encore, de toutes façon le système envoie des messages à ces deux threads selon les cas donc il faudrait les rediriger de l'un vers l'autre).
Dans la plupart des autres frameworks, c'est l'inverse. On peut faire une UI réactive avec un thread dédié aux traitements longs, mais il faut le faire exprès.
Un autre détail: par défaut le thread fenetre a une priorité supèrieure, et donc le système est plus réactif. Là encore, sur les autres systèmes, on peut le faire, mais ça n'est pas le cas par défaut.
Dans Haiku on essaie pas de révolutionner l'informatique, on essaie de faire un système qui "juste marche". Pour ça on a les memes solutions et bonnes pratiques que tout le monde, mais on essaie de faire en sorte que la bonne solution soit également la plus simple à mettre en œuvre.
[^] # Re: Eh ben...
Posté par pulkomandy (site web personnel, Mastodon) . En réponse à la dépêche Haiku se lâche enfin. Évalué à 10.
ça avance. Mais ce n'est pas une question de légèreté, c'est une question de réactivité. Même sur un Pi avec 512Mio de RAM, Haiku peut tourner sans problème. Par contre, sans accélération de l'affichage, ça va pas être si intéressant que ça. Le Pi a un GPU très puissant, et il faudrait l'exploiter au maximum pour le rendu graphique ce qui permettrait de libérer le CPU pour des choses importantes.
Sous Linux ça devient de plus en plus difficile. Pour que ça marche bien on a besoin d'un serveur graphique qui coordonne toutes les opérations de dessin. X le fait, mais comme il ne fait pas d'antialiasing, c'est moche, et du coup les toolkits majeurs (Qt, GTK) n'utilisent plus X et font le rendu côté client. Et du coup il y a Wayland qui se prépare et qui supprime définitivement le rendu côté serveur.
Dans le cas de Haiku, c'est toujours app_server qui fait le rendu pour les applications natives, et donc si on fait un backend de l'app_server qui utilise le GPU pour le tracé 2D (par exemple via OpenVG), toutes les applications en bénéficieront. Mais ça reste pas mal de travail à faire.
Pour le port ARM lui même, ça avance doucement (le kernel se lance, maintenant il faut modifier le pilote USB qui n'est pas capable de fonctionner sans un bus PCI, de façon a faire marcher le stockage de masse USB et pouvoir charger le reste du système de fichiers pour booter plus loin). Par contre on cible pour le moment les ARMv7 ce qui exclut le Raspberry Pi. Il y a un peu de support à faire pour ARMv6 (pour les opérations atomiques, qui n'ont pas d'instruction dédiée et doivent être implémentées autrement, si je me souviens bien). Le manque de support du Pi dans QEMU est aussi un peu embêtant pour démarrer le travail.
[^] # Re: Permissions
Posté par pulkomandy (site web personnel, Mastodon) . En réponse à la dépêche Haiku se lâche enfin. Évalué à 10.
"aucune", c'est pas tout à fait vrai. Il y a un support minimal t il ya eu dernièrement quelques corrections. Mais ça reste un des points qui ne sont pas prévus pour la version R1 de Haiku, c'est prévu pour plus tard (sauf si quelqu'un se lance là dedans…)
Il y a des réflexions en cours sur la façon de faire, on a des permissions de type UNIX mais il faut voir ce qu'on en fait, peut etre qu'elles seront utilisées pour sandboxer les applications comme dans Android.
[^] # Re: Clang ?
Posté par pulkomandy (site web personnel, Mastodon) . En réponse à la dépêche Haiku se lâche enfin. Évalué à 10.
Pour l'instant, le truc qui coince c'est la compatibilité binaire avec BeOS qui nous force à utiliser un gcc 2.95.3 (avec pas mal de patchs…). C'est la principale raison qui motive cette tentative de faire une version 1 rapidement (c'est dans la roadmap du projet, la version 1 doit etre compatible avec BeOS). Une fois qu'on a sorti cette version 1, on pourra enfin démarrer le travail de mise à jour de l'API (il y a eu des améliorations, mais on commence à atteindre les limites de ce qui peut etre fait sans casser la compatibilité).
Comme à ce moment là il y aura une version stable et supportée de Haiku, de nouvelles applications pourront etre développées, et (on espère) remplaceront les quelques applications BeOS pour lesquelles il n'y a pas encore d'alternative crédible. Ensuite il n'y aura plus de problème pour casser la compatibilité et on pourra avancer.
Cela ne s'applique que pour la version x86 (et pas les versions x86_64 et ARM) de Haiku, c'est la seule ou la compatibilité est assurée. On a aussi un compilateur gcc4 pour compiler les applications modernes, bien sur. Donc, actuellement on peut remplacer gcc4 par clang (et ne pas avoir de compatiblité gcc2). Il reste un peu de travail pour:
- Améliorer le code en supprimant les warnings levés par clang (mais ce n'est pas toujours possible si le code doit continuer à compiler avec gcc2)
- Supprimer ou réduire le plus possible l'utilisation des extensions de gcc (idem)
- Tester le système ainsi compilé et vérifier qu'il n'y a pas de régressions (a priori non, ça a l'air de tourner comme il faut), et que le code généré est au moins aussi performant (ça n'est pas nécessairement le cas, la plupart des benchmarks de clang le teste avec un jeu d'instruction moderne (SSE, SSE2, SSSE, …) mais Haiku est toujours compilé pour une cible 586 (MMX, et rien d'autre) (pour la version x86 uniquement).
Donc, ça fonctionne déjà, mais c'est peu testé, donc il semble raisonable de sortir une version R1 dont on est surs qu'elle est stable et de faire ce changement ensuite (pour la version R1.1 ou R2, par exemple).
[^] # Re: Eh ben...
Posté par pulkomandy (site web personnel, Mastodon) . En réponse à la dépêche Haiku se lâche enfin. Évalué à 10.
Si je n'étais pas contributeur Haiku, je ne pense pas que je serais contributeur Linux. Donc, avoir un projet comme Haiku pour les développeurs de noyau qui ont envie de faire du C++ augmente le pool de dévloppeurs de logiciels libres. C'est plutot cool, non?
Je prend des exemples dans le noyau, parce qu'on est en train de le comparer à Linux (qui est seulement un noyau). Mais le même raisonnement s'applique à d'autres parties du système: là ou on utilise des bibliothèques externes (il n'y a pas que WebKit, mais aussi par exemple freetype et ffmpeg), elles sont systématiquement enveloppées dans une API en C++ qui s'intègre avec le reste du système.
Comme je l'ai dit, le choix de ne pas utiliser Linux a été fait en 2001. Les choses ont changé aujourd'hui et si le projet commençait maintenant, on ferait peut etre un choix différent. Mais là, on essaie surtout de sortir une version 1 "finie" afin de pouvoir passer à la suite. Et donc, je ne vois pas l'interet de passer du temps à changer de noyau maintenant alors qu'on en a un qui marche quand meme pas si mal que ça. Une fois la version 1 sortie, oui, pourquoi pas. Mais je trouve ça dommage pour les développeurs qui sont intéressés pour travailler sur un noyau en C++ (et qui potentiellement ne sont pas intéressés pour contribuer à Linux en C, ni aux autres parties de Haiku qui ne sont pas le noyau). Cosmoe est là, il attend son heure, et si ça intéresse assez de gens qui s'y mette sérieusement, ça peut faire un système utilisable sans avoir trop d'efforts à faire. En attendant, on continue à utiliser notre propre noyau.