pulkomandy a écrit 1703 commentaires

Chez Haiku on stocke ces infos dans des attributs étendus de chaque fichier.

Avantages:
- Pas de fichier "caché" qui traîne dans le dossier
- Si on déplace un fichier dans un autre dossier ou sur un autre disque, ses attributs sont déplacés avec et il y a pas besoin de les regénérer
- Ces attributs sont de toutes façons lus par le navigateur de fichiers pour afficher d'autres informations, donc ça ne rajoute pas beaucoup d'accès disque
- N'importe quelle application peut facilement écrire ces attributs lorsqu'elle enregistre un fichier (par exemple, un émulateur peut enregistrer une miniature de l'écran de la machine émulée dans un fichier de sauvegarde de l'état de la dite machine)

Inconvénients:
- Ça ne fonctionne pas sur les systèmes de fichiers ou il y a trop de limites sur les attributs étendus (par exemple ext4 ou ils ont une taille maximale plutôt réduite)

Ça n'empêche pas de le faire fonctionner sur un ordinateur moderne, mais seulement pour une utilisation personnelle et non-commerciale et sans pouvoir redistribuer le résultat.

J'imagine qu'on pourrait distribuer des patchs de ce code avec un script qui vient télécharger l'archive mise à disposition par le computer history museum, pour compiler l'ensemble?

Sinon, il y a un certains nombre d'autres logiciels: premières versions de Word et de Photoshop par exemple.

Certains sous des licences similaires d'autres sont vraiment libres: https://computerhistory.org/playlists/source-code/

Par exemple, le client mail Eudora est sous licence BSD.

ça n'a pas d'impact sur le code

ça a un impact sur les optimisations que le compilateur va pouvoir faire, et sur les warnings ou erreurs qu'il va pouvoir émettre. Par exemple si une fonction marquée "noreturn" contient le mot clé "return" on peut s'attendre à un avertissement du compilateur.

Si quelqu'un peut corriger cet exemple, je pense qu'il fallait lire:

#include <stdio.h>

int main(void)
{
    const char* source = {
        #embed __FILE__ suffix(, '0') // On ajoute un '0' à la fin pour pouvoir utiliser la chaîne de caractères avec puts
    ;}
    puts(source);
    return 0;
}

Je crois qu'il y a eu une erreur de manipulation quelque part lors de la rédaction de la dépêche, et que le suffixe aurait du être un 0. Je ne sais pas comment il a été remplacé par ce truc bizarre…

Il y a aussi un autre problème pénible à cause de ça.

Si on a des fonctions de ce type:

    // Par exemple pour supprimer un élément dans une 
    // structure de donnée, soit en connaissant sa position,
    // soit en ayant un pointeur sur l'élément concerné
    void RemoveItem(int32_t index);
    void RemoveItem(void* item);

La ligne de code suivante est ambiguë:

    RemoveItem(NULL);

Et, plus gênant, celle-ci aussi:

    RemoveItem(0); // Le 0 est un int mais peut aussi être
        // casté en void* de façon implicite, sinon le NULL
        // ne fonctionnerait pas

En principe, avoir nullptr à la place de NULL permettrait d'éviter ce problème. Mais pour l'instant, NULL reste disponible et les règles de conversion pour qu'il continue à fonctionner restent disponibles aussi.

Je suppose qu'on peut se retrouver dans le même type de situation avec les generics en C?

Bon, déjà ce code ne compile pas parce que l'opérateur != n'est pas défini entre 2 structures.

Mais admettons qu'on veuille les comparer avec un memcmp par exemple.

La spécification dit (le dernier brouillon, je n'ai pas la spécification officielle), dans le chapitre 6.7.10 :

If an object that has automatic storage duration is initialized with an empty initializer, its value is the same as the initialization of a static storage duration object.

Et donc en cherchant un peu plus loin les règles pour les objets concernés par "static storage duration" :

If an object that has static or thread storage duration is not initialized explicitly, or is initialized with an empty initializer, then default initialization:
— if it is an aggregate, every member is initialized (recursively) according to these rules, and any padding is initialized to zero bits;

La réponse est donc oui, le padding est bien initialisé à 0.

Il s'agit en fait d'un "transpileur" qui convertit le bytecode java (fichiers .class) en assembleur pour chaque architecture ciblée. Il ne permet pas de se dispenser d'un compilateur existant qui va convertir le code source Java en fichier .class

Avantages de cette approche:
- ça marche avec n'importe quel langage qui peut se compiler vers un fichier .class
- pas besoin de parser le code source

Par contre il y a beaucoup de limitations, par exemple:
- pas de "garbage collection" (la mémoire est allouée et jamais libérée)
- les opcodes pour les switch/case et quelques autres ne sont pas disponibles
- on ne peut pas créer d'objets avec "new" ni utiliser de méthodes virtuelles

On est donc loin de pouvoir compiler le premier programme Java venu avec cette solution.

Mais pratique pour installer un télescope pas gêné par la pollution lumineuse: il suffit de se placer sur le bord de la Terre, et de construire un mur de l'autre côté.

Ou même d'aller s'installer en-dessous de la Terre vu qu'il n'y a personne?

Pas forcément.

Par exemple si le fichier JSON peut être affiché sous forme d'un formulaire:

• Les clés servent à définir les étiquettes de chaque champ
• Les valeurs sont le contenu des champs
• Les "commentaires" peuvent être affichés sous forme de documentation

Dans ce type d'usage, le commentaire est donc une vraie donnée qui peut être exploitée par les outils manipulant le fichier. C'est mieux de faire comme ça que de parser des commentaires qui seraient présents dans le fichier (ce qui s'est passé quand il y avait des commentaires dans la spécification JSON: certains outils ont commencé à les utiliser comme métadonnées ou annotations).

les signes de l'astrologie astro celte, astro maya , zodiaque et phase de la lune , aucune prédiction de madame soleil bien sur, je dois avouer que mettre ces éléments avec le calendrier Unix me semble un peu bizarre, mais soit c'est le choix de l'autrice

C'est pour utiliser les outils psss et lsss de Brendan Gregg, qui ajoutent à ps et ls respectivement les signes du zodiaque de la date de création des processus et fichiers.

Oups, je me suis embrouillé. Mes cours d'économie et de comptabilité sont bien loin.

J'ai écrit le titre à partir d'un mail reçu de la Maif qui dit "Nous avons décidé d’allouer désormais 10% de notre résultat annuel à la planète." et j'ai confondu "résultat" avec "chiffre d'affaire", je pense que je me serai pas trompé si ça avait été "bénéfice". Ensuite j'ai trouvé une source publique annonçant l'information pour pouvoir la partager ici, que j'ai lue plus rapidement parce que j'avais déjà les informations.

Encore du ménage à faire dans les étiquettes, je pense:

Dérèglement climatique -> seulement 2 contenus à migrer dans Réchauffement climatique

Catastrophhe climatique -> seulement 1 contenu, même chose

Urgence climatique -> Seulement 6 contenus, même chose

Ce n'est pas (que) du greenwashing:

Le risque climatique est aujourd'hui "le risque numéro 1 pour les assureurs de particuliers" dit-il. "Si nous ne prenons pas garde, le risque que des assureurs se retirent de zones géographiques entière existe"

Mais il est peut-être un peu tard…

Oui enfin quand j'ai commencé à faire du web à la fin des années 1990 (j'avais 12 ans) on avait Claris Homepage et un client FTP graphique comme CuteFTP. Nul besoin d'apprendre le Markdown ou à manipuler une ligne de commande. Et c'est tant mieux, parce que je me serai probablement pas lancé là dedans, et le prof d'école primaire qui avait eu l'idée de monter un site web non plus…

On a donc bien régressé depuis en termes de facilité d'utilisation. Et encore, à l'époque il y avait quelques chances de trouver quelqu'un avec quelques connaissances en ligne de commande MS-DOS pas loin, alors qu'aujourd'hui, ce n'est plus vraiment dans les connaissances nécessaires à l'utilisation d'un ordinateur.

Pas de façon vraiment exploitable actuellement. Il y a eu différents projets dans ce but: BlueEyedOS, Cosmoe et V\OS, mais ils sont soit abandonnés soit pas encore utilisables.

Il y a également Haiku on Genode qui utilise une partie des sources de Haiku avec un noyau Genode. Ça a l'air d'être assez avancé mais je ne sais pas si ce sera diffusé ou si ça restera pour un usage interne chez TuneTracker Systems, qui utilisait Haiku en remplacement de BeOS mais ont rencontré trop de problèmes d'instabilités ou de compatibilité matérielle.

La mise à jour en haut de page indique que overleaf est une bonne solution qui est apparue entretemps, et qu'elle convient très bien pour les textes courts.

Je crois que pour l'écriture, édition et mise en page d'un livre entier, surtout un livre un peu compliqué avec illustrations, figures, tableaux, etc; quel que soit l'outil choisi, il y aura forcément des points de frustration avec n'importe quel outil. La tâche est juste trop complexe.

The text below was written in the years 2010 to 2015

Cette ligne a donc probabement été écrite en 2010, alors que LibreOffice n'avait pas encore sorti une seule version car le projet venait de démarrer.

Cela n'a simplement pas été mis à jour depuis.

C'eft grâce à ce qui est expliqué dans le chapitre "Couches de compatibilité X11 et Wayland" qui permet de recompiler beaucoup d'applications existantes.

C'est pratique mais un peu en contradiction avec l'objectif du hrojet qui est d'avoir un système et un ensembled'applications cohérents, unifiés et très inter-opérables, ce qui n'est pas possible en mélangeant les toolkits graphiques de cette façon. On verra si cette approche permet d'avoir plus d'utilisateurs qui vont ensuite attirer plus de développeurs, ou si au contraire elle va offrir une solution "de facilité" au détriment des applications conçues spécifiquement pour Haiku

Oui c'est bien ça, et gcc2 est donc la version utilisée par BeOS, dont la dernière version date de 2001 ou un peu avant.

Gcc3 est une version majeure en raison de gros changements pas rétrocompatibles. Pour l'instant il n'y a pas d'autres solutions pour la compatibilité binaire.

On a pas de développeurs installés dans ces pays actuellement. Et on a pas de département des resources humaines pour aller y chercher des gens.

Les contrats proposés par Haiku inc sont plutôt attribués aux développeurs qui contribuent déjà activement au projet sur leur temps libre, pour leur permettre de le faire à plein temps. C'est la solution la plus efficace en terme de rapport argent dépensé vs. code produit et intégré dans le projet.

De plus, le paiement est bien en-dessous du prix du marché ce qui fait que ça aurait peu de chances d'attirer des personnes extérieures (et ce ne serait pas très sérieux de publier des offres d'emploi sous-payées sous prétexte qu'on a pas beaucoup de sous).

Les paramètres écologiques ne rentrent pas vraiment dans la balance du point de vue de l'association Haiku, ou en tout cas pas en priorité. De plus, il n'y a pas de détails sur le style de vie du développeur embauché qui permette de calculr son empreinte carbone/déchets/pollution personelle.

En fait le budget de 20000$ a été bouclé juste quelques heures avant la fin de l'année. Mais ce serait mieux d'avoir plus (avec 20000$ on ne peut pas financer durablement un développeur à plein temps vivant aux USA)

L'étiquette applisportables semble utilisée pour des applications Android. Je m'attendais plutôt à la voir utilisée pour des applications portables (d'un OS à un autre, voir aussi portabilite, ou d'une machine à une autre en les installant sur une clé USB, voir portabilisation).

Mais "portabilite" manque d'un accent et "portabilisation" me semble être un néologisme pas terrible. Est-ce que quelqu'un a mieux à proposer?

D'abord le lien original (pas via hackernews) ou cela a été annoncé: https://matrix.org/blog/2022/12/25/the-matrix-holiday-update-2022

La situation est donc que Element finance en très grande partie la fondation Matrix et que dans les faits ce sont en fait les développeurs de Element qui contribuent aussi beaucoup au code et à la spécification de Matrix.

Je ne sais pas si ce déséquilibre est volontaire ou pas, en tout cas on a l'impression que Matrix et Element sont très très liés, un peu comme la fondation Mozilla avec Mozilla corporation? Et on peut se poser des questions sur la position que prendra la fondation Matrix si Element est en difficulté. Un peu comme les débats qu'on a vu passer récemment autour de The Document Foundation qui pourrait prendre des décisions ne convenant pas à tous les participants à la communauté LibreOffice.

Du c^oté de la fondation Matrix, la tentative de rééquilibrer les choses d'un point de vue financier est ceci: https://matrix.org/blog/2022/12/01/funding-matrix-via-the-matrix-org-foundation

En gros, la fondation recherche des gens (ou plut^ot des entreprises et des associations) pour prendre part aux décisions et au développement. Mais en contrepartie il faudra payer (et pas qu'un peu). Il faudra voir si cette offre trouve son public et si ça permettra de rééquilibrer les choses, parce que pour l'instant, au niveau de la gouvernance, on ne peut pas vraiment dire que ça soit un succès pour la décentralisation. Ou si au contraire, personne ne voudra payer et que finalement Element se trouve bien seul pour financer le développement, la spécification et la promotion de Matrix.

J'ai pas le temps de vous faire une dépêche là tout de suite, on voit ça la semaine prochaine!