Il y a quelques drivers qu'on a pas pris la peine de porter en 64bit parce que la combinaison CPU 64 bit + carte graphique Ati Mach64 (par exemple) nous semblait suffisamment improbable pour justifier d'y passer du temps, et aussi parce que personne parmi les développeurs ne dispose d'une machine permettant de tester le résultat (je pourrais essayer cela dit, j'ai une carte mère avec un CPU 64bit et un port PCI et peut être quelques cartes graphiques sous la main quelque part…).
Pas de différence dans le cas de machines "normales", du coup.
Ben je sais pas, ils sont dans /boot/packages dans l'image de la Beta et Installer propose une liste de "optional packages" à partir de ça pour les activer à l'installation. Il y a au moins tous les outils de dev et quelques autres trucs.
Ah oui j'avais oublié un truc: Wonderbrush n'est pas encore disponible en 64bit, c'est peut être ça?
Mais alors que le guide est installé, les applications ne le sont pas (ou alors bien planquées).
Pas dans la version live car cela augmente les besoins en RAM (problèmes de performance sur lequel on doit se pencher). Elles sont installées lorsqu'on installe le DVD vers une partition sur disque, par contre.
De façon générale le process d'installation a besoin d'être revu: pour le choix des paquets, pour le partitionnement automatique des disques, pour l'installation du bootloader EFi, et quelques autres détails. Bref, y'a encore du travail!
Quant aux sources, j'imagine que vous en avez discuté, mais garder une image iso avec les sources sur le serveur ne suffit-il pas ?
Non, la GPL dit bien que les sources doivent être disponibles "par le même moyen". Donc si on vend/donne des DVDs par la poste ou sur un stand au FOSDEM, les sources doivent être disponibles au même endroit, et un lien vers un serveur ne suffit pas. Problème qui a été corrigé dans la GPL3 pour autoriser spécifiquement la méthode "lien vers un serveur" cela dit, donc on pourrait peut être faire ça. Va falloir revérifier toutes les licenses du code inclus…
En fait ce qui prend le plus de place c'est le code source qui est inclus (fourni dans /boot/sources) pour nous simplifier la vie sur la distribution de DVDs en respectant la GPL.
La GPL impose quand on distribue un logiciel d'offrir la distribution des sources correspondantes par le même moyen pendant 5 ans. Ça voudrait dire que dans 5 ans quelqu'un pourrait nous demander un DVD avec les sources de la version qu'on vient de publier maintenant. Comme on a pas envie de s'embêter avec ça, le plus simple est de mettre les sources directement sur le même DVD.
Il y a également quelques éléments en plus: le guide d'utilisateur (traduit dans 20 langues), et quelques applications comme Wonderbrush, ainsi que tous les outils de développement préinstallés (puisque c'est une version beta qui s'adresse plus aux développeurs qu'aux utilisateurs). On a encore du travail à faire sur la gestion de ces paquets supplémentaires dans l'Installeur, on a fait une partie pour cette version mais ce n'est pas encore complètement satisfaisant (pas de gestion des dépendances, pas de regroupement des paquets par catégorie, …). Une fois fait, on pourra remplir le DVD avec plein d'applications sympa. Ou alors, on se débarasse au maximum des morceaux en GPL pour ne plus avoir à livrer autant de code source et pouvoir à nouveau tout rentrer sur un CD!
Ouais, "données collectées il y a 9 mois", et ça rentre pas autant dans les détails. Et il y a aussi des soucis avec les gens qui changent d'adresse mail qui ne sont pas forcément correctement identifiés (avec repostat j'ai un fichier mailmap pour rattraper ça), et sur un projet qui existe depuis bientôt 20 ans, il y a forcément des gens qui ont changé d'adresse une fois ou deux en cours de route.
Les stats pour FreeBSD sont assez clairement incorrectes, aussi: https://www.openhub.net/p/freebsd (écrit principalement en C++? Pas de code ni de contributeurs avant 2020?)
Et puis aussi y'a des watermarks sur tous les graphes :)
Non, 2 ou 3 personnes, dont moi-même et deux autres que je connaît personellement (les noms sont dans les pages de statistiques que j'ai liées).
On a effectivement travaillé avec TuneTracker Systems (qui utilise toujours Haiku), et un peu avec iz mais je ne sais pas s'ils ont finalement migré de BeOS à Haiku ou à autre chose. En tout cas, aucune des deux n'a les moyens actuellement d'avoir un petite équipe qui contribue à Haiku, et on a des contacts directs avec les développeurs (on assure le support comme on peut pour qu'ils puissent continuer à utiliser Haiku).
De là à dire que Haiku est soutenu… ça doit se compter en centaines de dollars sur 20 ans, ça fait pas cher le soutien. On aurait pu facturer bien plus un vrai contrat de support.
Cela dit il y en a beaucoup moins qui sont actifs de façon régulière, je pense environ une dizaine, et on peut voir par exemple qu'en 2019, un seul développeur est responsable de 42% des changements, donc il y a 2 ou 3 personnes qui font la majorité du travail (cela dit, il y a aussi des gens qui font moins de changement mais s'attaquent à des problèmes demandant beaucoup plus de temps d'investigation, par exemple).
A ceci s'ajoute le travail sur le packaging des applications, là aussi une soixantaine de personnes environ (pas forcément les mêmes) avec une poignée de contributeurs beaucoup plus actifs que les autres: http://pulkomandy.tk/stats_hp/authors.html
Enfin il y a toutes les personnes qui travaillent sur le développement d'applications natives, là c'est plus compliqué d'avoir des jolis graphiques, car chaque application a son propre dépôt Git.
Je ne sais pas dire si c'est comparable à d'autres projets libres, je serais intéressé à voir ce genre de statistiques dans d'autres projets. Peut être que je devrais faire un journal sur repostat, l'outil qui sert à les générer et dans lequel j'ai du mettre les doigts pour corriger quelques soucis.
Pour l'instant le nombre de rapports de bugs ouverts dans la version R1 continue d'augmenter, il est donc difficile de projeter une date. Cependant il est possible d'utiliser les versions beta qui sont déjà plutôt stables même s'il y a des problèmes connus, en attendant.
Ou PulseAudio/Jack1/Jack2/Alsa/OSS/esd/pipewire si tu es pessimiste… (et j'en ai probablement loupé quelques uns).
Dans Haiku il n'y a que le Media Kit mais y'a encore du travail pour avoir un truc vraiment fonctionnel: la partie encodage est cassée, les drivers marchent pas partout et pas tout le temps, la latence est vraiment pas terrible, … bref c'est une version beta.
Ah c'est une bonne idée d'avoir mis le logo, mais il y a une version pour les fond blancs qui fonctionnera probablement mieux pour Linuxfr: Logo Haiku pour fond blanc
Surtout, il y a des gens qui ont essayé de le compiler et il semblerait qu'il manque des morceaux, si j'en crois par exemple le README dans ce fork: https://github.com/dspinellis/GW-BASIC
Alors, dire que la seule différence entre les domaines gratuits et payants est qu'il faut renouveler le domaine tous les ans, c'est un peu trompeur. Par exemple pour un domaine gratuit, il est obligatoire d'y héberger un site web accessible en http, sans quoi le domaine est supprimé au bout de 15 jours.
Le but étant que ces domaines soient référencés au maximum, afin de pouvoir les revendre plus cher par la suite dès qu'ils sont inutilisés ou suspendus pour d'autres raisons (hébergement de malware, pornographie, … par exemple). Ce n'est bien entendu pas le cas pour les domaines payants, pour lesquels le fonctionnement est celui d'un nom de domaine classique.
Ah non ce sont les "game engines" qui sont interdits. Un "moteur de jeu" ça ne pose aucun problème? :o)
Bon en vrai ils ont défini ce qu'ils entendent par "game engine product" dans la license:
“Game Engine Product” shall mean software used for video game development. This includes both the content authoring software and the software used to show the created content.
C'est donc plus basé sur l'utilisation à laquelle c'est destiné que sur le nom qu'on lui donne.
On fait ça aussi. Le lecteur d'image ShowImage recopie certaines données EXIF dans ces attributs, et pour la musique il faut utiliser, par exemple, ArmyKnife. Ces attributs sont en plus indexés, ce qui fait qu'on peut les utiliser pour générer des playlists dynamiques ou bien retrouver des photos en utilisant ces données (il faudrait qu'on mette un geohash ou ce genre de chose pour que ça soit vraiment intéressant, cela dit).
Pour les icônes, effectivement c'est "marginal", mais avoir les icônes qui s'affichent instantanément dans la DeskBar pour toutes les applications, c'est quand même plus propre. Et comme de toutes façons il n'y a pas vraiment d'autres métadonnées à stocker pour une application en général, et que l'espace disponible est assez large, ça ne coûte pas grand chose (un inode est par défaut à 2 ou 4Ko, et l'icône utilise en général quelques centaines d'octets, donc il reste largement la place pour les autres métadonnées éventuelles).
"moisi" peut-être aujourd'hui, mais à l'époque ou ce format a été conçu, ça a vraiment fait une grosse différence avec Zeta, une version de BeOS qui avait elle choisi d'utiliser des icônes en SVG. Le stockage et les processeurs ayant fait des progrès depuis 20 ans, ça se voit probablement moins sur un ordinateur moderne.
Ces attributs sont stockés dans l'inode d'en-tête du fichier qui ne peut pas contenir de données, c'est donc de la place qui était autrement "perdue". Et de toutes façons on y stocke déjà d'autres trucs (type mime,etc).
Ce n'est pas clair dans l'article mais le stockage de l'icône dans un attribut est loin d'être systématique: en gros c'est pour les applications et quelques dossiers du système. Pour les fichiers ayant un icône générique correspondant à leur type, on stocke le type mime en attribut et ça permet de retrouver l'icône approprié dans la base mime du système. On a aucun intérêt à dupliquer l'icône par défaut dans tous les fichiers.
Oui, et OpenBSD a l'air de bien fonctionner sur SPARC64 également (y compris les machines les plus récentes de chez Fujitsu qui continue pour le moment à vendre du matériel avec l'architecture SPARC).
Pour FreeBSD, les machines sun4v n'ont apparament jamais été vraiment fonctionnelles, et donc ce port n'était utilisable que pour les machines fabriquées avant 2000 et utilisant encore sun4u. Je suppose que le travail en cours dans FreeBSD pour se débarasser complètementde gcc et utiliser clang ne doit pas aider s'il n'y a personne pour tenir le code spécifique au SPARC à jour.
"10 ans d'empoisonnement de l'éducation, invasion de la vie privée, et menaces sur la sécurité", dit le message.
On se demande bien pourquoi il faudrait publier les sources de cette version obsolète. Il vaudrait mieux que Microsoft continue de publier les sources des versions actuelles, comme ils ont déjà un peu commencé à le faire par petits morceaux.
Donc oui, anti-Windows mais on veut bien les sources quand même. Sans aucun plan pour en faire quoi que ce soit, cela dit, parce qu'il ne faut pas exagérer. Si ça venait par exemple de ReactOS avec un plan pour faire quelque chose des sources une fois publiées, pourquoi pas, mais là, je vois pas bien l'intérêt du truc.
La page Wikipedia qui traite de l'"upcycling" a été créée en 2007. Si c'est créé pour l'occasion, c'est une belle anticipation, puisque Windows 7 a été publié seulement 2 ans après.
Haiku utilise WebKit et notre navigateur a besoin d'environ 32Mo de mémoire au démarrage, ce qui me semble assez raisonnable.
Sous Linux, il faut voir que WebKit réserve beaucoup d'espace mémoire sans forcément l'utiliser tout de suite. Du coup ça ne consomme pas vraiment de mémoire, en fait. C'est juste que les chiffres indiqués par les outils de mesure ne sont pas ce qu'on croit.
De plus, il n'est pas si compliqué que ça de configurer WebKit pour être moins gourmand. Le JIT pour Javascript peut être désactivé, les trucs qui réservent beaucoup d'espace mémoire sont configurables, etc. Sinon il ne pourrait pas fonctionner sur l'Apple Watch, par exemple.
Je ne sais pas comment c'est mais j'imagine que c'est grandement robotisé. Derrière on parle d'information ultra util a beaucoup de site.
Y'a plein de bouts super importants de l'Internet qui sont maintenus à la main par un type dans son garage…
Dernièrement on a entendu parler de la liste de diffusion Yahoo Groups qui permet aux opérateurs téléphoniques anglais de tenir leurs bases de données à jour pour assurer la portabilité des numéros de téléphone, par exemple. Mais c'est loin d'être le seul cas.
Dans l'exemple donné dans le journal, il est indiqué (dans la capture d'écran) que l'"application" lampe de poche s'exécute dans le même processus que tout plein d'autres trucs, avec lesquels elle semble partager les permissions. Du coup, je suppose que c'est "normal" d'avoir toute cette liste.
[^] # Re: Contenu du CD d'installation
Posté par pulkomandy (site web personnel, Mastodon) . En réponse à la dépêche Haiku R1 bêta 2. Évalué à 3.
Il y a quelques drivers qu'on a pas pris la peine de porter en 64bit parce que la combinaison CPU 64 bit + carte graphique Ati Mach64 (par exemple) nous semblait suffisamment improbable pour justifier d'y passer du temps, et aussi parce que personne parmi les développeurs ne dispose d'une machine permettant de tester le résultat (je pourrais essayer cela dit, j'ai une carte mère avec un CPU 64bit et un port PCI et peut être quelques cartes graphiques sous la main quelque part…).
Pas de différence dans le cas de machines "normales", du coup.
[^] # Re: Contenu du CD d'installation
Posté par pulkomandy (site web personnel, Mastodon) . En réponse à la dépêche Haiku R1 bêta 2. Évalué à 3.
Ben je sais pas, ils sont dans /boot/packages dans l'image de la Beta et Installer propose une liste de "optional packages" à partir de ça pour les activer à l'installation. Il y a au moins tous les outils de dev et quelques autres trucs.
Ah oui j'avais oublié un truc: Wonderbrush n'est pas encore disponible en 64bit, c'est peut être ça?
[^] # Re: Contenu du CD d'installation
Posté par pulkomandy (site web personnel, Mastodon) . En réponse à la dépêche Haiku R1 bêta 2. Évalué à 4.
Pas dans la version live car cela augmente les besoins en RAM (problèmes de performance sur lequel on doit se pencher). Elles sont installées lorsqu'on installe le DVD vers une partition sur disque, par contre.
De façon générale le process d'installation a besoin d'être revu: pour le choix des paquets, pour le partitionnement automatique des disques, pour l'installation du bootloader EFi, et quelques autres détails. Bref, y'a encore du travail!
Non, la GPL dit bien que les sources doivent être disponibles "par le même moyen". Donc si on vend/donne des DVDs par la poste ou sur un stand au FOSDEM, les sources doivent être disponibles au même endroit, et un lien vers un serveur ne suffit pas. Problème qui a été corrigé dans la GPL3 pour autoriser spécifiquement la méthode "lien vers un serveur" cela dit, donc on pourrait peut être faire ça. Va falloir revérifier toutes les licenses du code inclus…
[^] # Re: Contenu du CD d'installation
Posté par pulkomandy (site web personnel, Mastodon) . En réponse à la dépêche Haiku R1 bêta 2. Évalué à 7.
En fait ce qui prend le plus de place c'est le code source qui est inclus (fourni dans /boot/sources) pour nous simplifier la vie sur la distribution de DVDs en respectant la GPL.
La GPL impose quand on distribue un logiciel d'offrir la distribution des sources correspondantes par le même moyen pendant 5 ans. Ça voudrait dire que dans 5 ans quelqu'un pourrait nous demander un DVD avec les sources de la version qu'on vient de publier maintenant. Comme on a pas envie de s'embêter avec ça, le plus simple est de mettre les sources directement sur le même DVD.
Il y a également quelques éléments en plus: le guide d'utilisateur (traduit dans 20 langues), et quelques applications comme Wonderbrush, ainsi que tous les outils de développement préinstallés (puisque c'est une version beta qui s'adresse plus aux développeurs qu'aux utilisateurs). On a encore du travail à faire sur la gestion de ces paquets supplémentaires dans l'Installeur, on a fait une partie pour cette version mais ce n'est pas encore complètement satisfaisant (pas de gestion des dépendances, pas de regroupement des paquets par catégorie, …). Une fois fait, on pourra remplir le DVD avec plein d'applications sympa. Ou alors, on se débarasse au maximum des morceaux en GPL pour ne plus avoir à livrer autant de code source et pouvoir à nouveau tout rentrer sur un CD!
[^] # Re: Il y a actuellement un flou assez important sur ce qui vient après cette version R1
Posté par pulkomandy (site web personnel, Mastodon) . En réponse à la dépêche Haiku R1 bêta 2. Évalué à 6.
Je pense qu'on va garder notre launch_daemon pour la gestion des services et de l'init :)
[^] # Re: Logo
Posté par pulkomandy (site web personnel, Mastodon) . En réponse à la dépêche Haiku R1 bêta 2. Évalué à 3.
En PNG: https://raw.githubusercontent.com/haiku/haiku/master/data/artwork/HAIKU logo - black on transparent - big.png
En SVG: https://raw.githubusercontent.com/haiku/haiku/master/data/artwork/HAIKU logo - black.svg
[^] # Re: Persévérance et intérêt
Posté par pulkomandy (site web personnel, Mastodon) . En réponse à la dépêche Haiku R1 bêta 2. Évalué à 6.
Ouais, "données collectées il y a 9 mois", et ça rentre pas autant dans les détails. Et il y a aussi des soucis avec les gens qui changent d'adresse mail qui ne sont pas forcément correctement identifiés (avec repostat j'ai un fichier mailmap pour rattraper ça), et sur un projet qui existe depuis bientôt 20 ans, il y a forcément des gens qui ont changé d'adresse une fois ou deux en cours de route.
Les stats pour FreeBSD sont assez clairement incorrectes, aussi:
https://www.openhub.net/p/freebsd (écrit principalement en C++? Pas de code ni de contributeurs avant 2020?)
Et puis aussi y'a des watermarks sur tous les graphes :)
[^] # Re: Persévérance et intérêt
Posté par pulkomandy (site web personnel, Mastodon) . En réponse à la dépêche Haiku R1 bêta 2. Évalué à 10.
Non, 2 ou 3 personnes, dont moi-même et deux autres que je connaît personellement (les noms sont dans les pages de statistiques que j'ai liées).
On a effectivement travaillé avec TuneTracker Systems (qui utilise toujours Haiku), et un peu avec iz mais je ne sais pas s'ils ont finalement migré de BeOS à Haiku ou à autre chose. En tout cas, aucune des deux n'a les moyens actuellement d'avoir un petite équipe qui contribue à Haiku, et on a des contacts directs avec les développeurs (on assure le support comme on peut pour qu'ils puissent continuer à utiliser Haiku).
De là à dire que Haiku est soutenu… ça doit se compter en centaines de dollars sur 20 ans, ça fait pas cher le soutien. On aurait pu facturer bien plus un vrai contrat de support.
[^] # Re: Persévérance et intérêt
Posté par pulkomandy (site web personnel, Mastodon) . En réponse à la dépêche Haiku R1 bêta 2. Évalué à 10.
Bonjour,
D'après les statistiques sur les dépôts Git, une soixantaine de contributeurs font au moins un changement par an: http://pulkomandy.tk/stats/authors.html
Cela dit il y en a beaucoup moins qui sont actifs de façon régulière, je pense environ une dizaine, et on peut voir par exemple qu'en 2019, un seul développeur est responsable de 42% des changements, donc il y a 2 ou 3 personnes qui font la majorité du travail (cela dit, il y a aussi des gens qui font moins de changement mais s'attaquent à des problèmes demandant beaucoup plus de temps d'investigation, par exemple).
A ceci s'ajoute le travail sur le packaging des applications, là aussi une soixantaine de personnes environ (pas forcément les mêmes) avec une poignée de contributeurs beaucoup plus actifs que les autres: http://pulkomandy.tk/stats_hp/authors.html
Enfin il y a toutes les personnes qui travaillent sur le développement d'applications natives, là c'est plus compliqué d'avoir des jolis graphiques, car chaque application a son propre dépôt Git.
Je ne sais pas dire si c'est comparable à d'autres projets libres, je serais intéressé à voir ce genre de statistiques dans d'autres projets. Peut être que je devrais faire un journal sur repostat, l'outil qui sert à les générer et dans lequel j'ai du mettre les doigts pour corriger quelques soucis.
Pour l'instant le nombre de rapports de bugs ouverts dans la version R1 continue d'augmenter, il est donc difficile de projeter une date. Cependant il est possible d'utiliser les versions beta qui sont déjà plutôt stables même s'il y a des problèmes connus, en attendant.
[^] # Re: Intéressant
Posté par pulkomandy (site web personnel, Mastodon) . En réponse à la dépêche Haiku R1 bêta 2. Évalué à 9.
Ou PulseAudio/Jack1/Jack2/Alsa/OSS/esd/pipewire si tu es pessimiste… (et j'en ai probablement loupé quelques uns).
Dans Haiku il n'y a que le Media Kit mais y'a encore du travail pour avoir un truc vraiment fonctionnel: la partie encodage est cassée, les drivers marchent pas partout et pas tout le temps, la latence est vraiment pas terrible, … bref c'est une version beta.
# Logo
Posté par pulkomandy (site web personnel, Mastodon) . En réponse à la dépêche Haiku R1 bêta 2. Évalué à 5. Dernière modification le 15 septembre 2024 à 19:27.
Ah c'est une bonne idée d'avoir mis le logo, mais il y a une version pour les fond blancs qui fonctionnera probablement mieux pour Linuxfr: Logo Haiku pour fond blanc
[^] # Re: Quelle générosité
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au lien Microsoft continue sa libération du code source des applications stratégiques. Évalué à 2.
Surtout, il y a des gens qui ont essayé de le compiler et il semblerait qu'il manque des morceaux, si j'en crois par exemple le README dans ce fork: https://github.com/dspinellis/GW-BASIC
# Tu as ce pour quoi tu payes
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal Domaine en .TK. Évalué à 2.
Alors, dire que la seule différence entre les domaines gratuits et payants est qu'il faut renouveler le domaine tous les ans, c'est un peu trompeur. Par exemple pour un domaine gratuit, il est obligatoire d'y héberger un site web accessible en http, sans quoi le domaine est supprimé au bout de 15 jours.
Le but étant que ces domaines soient référencés au maximum, afin de pouvoir les revendre plus cher par la suite dès qu'ils sont inutilisés ou suspendus pour d'autres raisons (hébergement de malware, pornographie, … par exemple). Ce n'est bien entendu pas le cas pour les domaines payants, pour lesquels le fonctionnement est celui d'un nom de domaine classique.
[^] # Re: ajout à la licence apache 2.0
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au lien Le moteur et l'éditeur de jeu Defold édités par King deviennent open source… mais pas libres. Évalué à 2. Dernière modification le 19 mai 2020 à 14:44.
Ah non ce sont les "game engines" qui sont interdits. Un "moteur de jeu" ça ne pose aucun problème? :o)
Bon en vrai ils ont défini ce qu'ils entendent par "game engine product" dans la license:
C'est donc plus basé sur l'utilisation à laquelle c'est destiné que sur le nom qu'on lui donne.
[^] # Re: Bonne idée ?
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au lien Comment afficher les icônes super vite (Haiku Vector Icon Format). Évalué à 2.
On fait ça aussi. Le lecteur d'image ShowImage recopie certaines données EXIF dans ces attributs, et pour la musique il faut utiliser, par exemple, ArmyKnife. Ces attributs sont en plus indexés, ce qui fait qu'on peut les utiliser pour générer des playlists dynamiques ou bien retrouver des photos en utilisant ces données (il faudrait qu'on mette un geohash ou ce genre de chose pour que ça soit vraiment intéressant, cela dit).
Pour les icônes, effectivement c'est "marginal", mais avoir les icônes qui s'affichent instantanément dans la DeskBar pour toutes les applications, c'est quand même plus propre. Et comme de toutes façons il n'y a pas vraiment d'autres métadonnées à stocker pour une application en général, et que l'espace disponible est assez large, ça ne coûte pas grand chose (un inode est par défaut à 2 ou 4Ko, et l'icône utilise en général quelques centaines d'octets, donc il reste largement la place pour les autres métadonnées éventuelles).
[^] # Re: Bonne idée ?
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au lien Comment afficher les icônes super vite (Haiku Vector Icon Format). Évalué à 4.
"moisi" peut-être aujourd'hui, mais à l'époque ou ce format a été conçu, ça a vraiment fait une grosse différence avec Zeta, une version de BeOS qui avait elle choisi d'utiliser des icônes en SVG. Le stockage et les processeurs ayant fait des progrès depuis 20 ans, ça se voit probablement moins sur un ordinateur moderne.
[^] # Re: Bonne idée ?
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au lien Comment afficher les icônes super vite (Haiku Vector Icon Format). Évalué à 5.
Ces attributs sont stockés dans l'inode d'en-tête du fichier qui ne peut pas contenir de données, c'est donc de la place qui était autrement "perdue". Et de toutes façons on y stocke déjà d'autres trucs (type mime,etc).
Ce n'est pas clair dans l'article mais le stockage de l'icône dans un attribut est loin d'être systématique: en gros c'est pour les applications et quelques dossiers du système. Pour les fichiers ayant un icône générique correspondant à leur type, on stocke le type mime en attribut et ça permet de retrouver l'icône approprié dans la base mime du système. On a aucun intérêt à dupliquer l'icône par défaut dans tous les fichiers.
[^] # Re: J'ai moinssé
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal Vélib' et open data. Évalué à 8.
Je crois que c'était fait exprès pour piquer les yeux des gens allergiques à l'écriture inclusive encore plus fort.
[^] # Re: Cela concerne uniquement la SPARC sur FreeBSD ?
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au lien Sparc RISC, c'est fini … et dire que c'était l'archi de mes premiers amours. Évalué à 2.
Oui, et OpenBSD a l'air de bien fonctionner sur SPARC64 également (y compris les machines les plus récentes de chez Fujitsu qui continue pour le moment à vendre du matériel avec l'architecture SPARC).
Pour FreeBSD, les machines sun4v n'ont apparament jamais été vraiment fonctionnelles, et donc ce port n'était utilisable que pour les machines fabriquées avant 2000 et utilisant encore sun4u. Je suppose que le travail en cours dans FreeBSD pour se débarasser complètementde gcc et utiliser clang ne doit pas aider s'il n'y a personne pour tenir le code spécifique au SPARC à jour.
[^] # Re: Taxation
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal JSON est dans les airs. Évalué à 10.
[^] # Re: Esprit potache es-tu là ?
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au lien signer la pétition pour libérer Windows 7. Évalué à 9.
"10 ans d'empoisonnement de l'éducation, invasion de la vie privée, et menaces sur la sécurité", dit le message.
On se demande bien pourquoi il faudrait publier les sources de cette version obsolète. Il vaudrait mieux que Microsoft continue de publier les sources des versions actuelles, comme ils ont déjà un peu commencé à le faire par petits morceaux.
Donc oui, anti-Windows mais on veut bien les sources quand même. Sans aucun plan pour en faire quoi que ce soit, cela dit, parce qu'il ne faut pas exagérer. Si ça venait par exemple de ReactOS avec un plan pour faire quelque chose des sources une fois publiées, pourquoi pas, mais là, je vois pas bien l'intérêt du truc.
[^] # Re: Esprit potache es-tu là ?
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au lien signer la pétition pour libérer Windows 7. Évalué à 5.
La page Wikipedia qui traite de l'"upcycling" a été créée en 2007. Si c'est créé pour l'occasion, c'est une belle anticipation, puisque Windows 7 a été publié seulement 2 ans après.
[^] # Re: Une arme noble d'une époque civilisée
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal KHTML c'est fini. Évalué à 7.
Haiku utilise WebKit et notre navigateur a besoin d'environ 32Mo de mémoire au démarrage, ce qui me semble assez raisonnable.
Sous Linux, il faut voir que WebKit réserve beaucoup d'espace mémoire sans forcément l'utiliser tout de suite. Du coup ça ne consomme pas vraiment de mémoire, en fait. C'est juste que les chiffres indiqués par les outils de mesure ne sont pas ce qu'on croit.
De plus, il n'est pas si compliqué que ça de configurer WebKit pour être moins gourmand. Le JIT pour Javascript peut être désactivé, les trucs qui réservent beaucoup d'espace mémoire sont configurables, etc. Sinon il ne pourrait pas fonctionner sur l'Apple Watch, par exemple.
[^] # Re: IPv6, aide nous.
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal GeoIP change de licence à cause de la réglementation. Évalué à 5.
Y'a plein de bouts super importants de l'Internet qui sont maintenus à la main par un type dans son garage…
Dernièrement on a entendu parler de la liste de diffusion Yahoo Groups qui permet aux opérateurs téléphoniques anglais de tenir leurs bases de données à jour pour assurer la portabilité des numéros de téléphone, par exemple. Mais c'est loin d'être le seul cas.
# Processus partagé
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal Si tu frottes la lampe, tu peux demander ce que tu veux. Évalué à 6.
Dans l'exemple donné dans le journal, il est indiqué (dans la capture d'écran) que l'"application" lampe de poche s'exécute dans le même processus que tout plein d'autres trucs, avec lesquels elle semble partager les permissions. Du coup, je suppose que c'est "normal" d'avoir toute cette liste.