pulkomandy a écrit 1928 commentaires

Le problème est de savoir quand on est en train de faire un truc "un peu sérieux" ou un truc "vite fait et jetable".

Ça m'est arrivé plusieurs fois de me dire "ça va je peux faire ça en 3 lignes de bash" et de me retrouver des mois plus tard à regretter de pas avoir fait du Python. Maintenant, j'arrête d'écrire du bash dès que le script dépasse 3 lignes, c'est le moment ou il est encore facile de le convertir en Python avant qu'il ne soit trop tard.

À partir de quand un traitement de données devient-il "un peu sérieux"?

La séparation se fait assez bien (j'ai plein de projets qui ne concernent pas directement Haiku) et de toutes façons, quand on fait des choses intéressantes on ne voit pas le temps passer. Et il y avait peu de comptes à rendre pour Haiku, à part un décomptage des heures passées. Mais Haiku ne pouvait pas me financer à plein temps, et j'avais dû trouver un autre client (enfin, disons qu'on m'a proposé autre chose) pour compléter. Et là c'est devenu un peu compliqué de jongler entre les deux projets.

Mon travail salarié actuel n'est pas moins intéressant. Je suis responsable technique d'une équipe et on me laisse suffisament de liberté sur les choix techniques, et il y a d'autres gens qui s'occupent des choses que je n'aime pas faire (les réunions interminables avec les clients et fournisseurs, la négociation des contrats, …). Alors certes, il m'arrive souvent de râler sur Linux, Yocto, ou d'autres trucs mal fichus, mais globalement, ça marche quand même pas si mal que ça, et pour ce qu'on fait avec (du système embarqué), ça convient très bien.

Mais surtout, j'ai droit à plein de congés payés, et je reçois mon salaire à une date fixe tous les mois sans avoir à rédiger des factures. Et un salaire plus élevé, aussi. À l'éhoque ou je travaillais pour Haiku, ma compagne payait la moitié du loyer de notre logement. En ce moment j'habite tout seul chez moi et le budget serait un peu plus compliqué à gérer à moins de négocier un salaire plus haut. Enfin, plein de petits trucs qui font que finalement le salariat, ça me convient plutôt mieux, en tout cas avec mon employeur actuel.

• La vidéo complète: https://www.youtube.com/watch?v=Vj04MKykmnQ
• Les sources publiées: https://community.umidigi.com/forum.php?mod=viewthread&tid=20572

Le travail est déjà en cours pour l'intégration dans PostMarketOS.

Oui, je fais partie de la liste des précédents contrats: en 2009 via le Google Summer of Code (3 mois), en 2010 (2 mois) pour travailler sur l'internationalisation, et en 2014 (1 an) pour le navigateur web.

En ce moment j'ai un emploi à plein temps, intéressant sur le plan technique et plus stable que ce que peut proposer Haiku, et c'est moins compliqué d'être salarié que auto-entrepreneur (Haiku inc ne pouvant pas embaucher directement une personne à l'étranger facilement, c'était la solution retenue).

Donc pour l'instant je fais autre chose.

Si les finances de Haiku permettent un jour d'embaucher une deuxième personne, ce sera peut être moi, mais pour l'instant on en est pas là.

Surtout que si tu as juste besoin de retrouver le nom d'une option, tu trouveras ta réponse plus vite dans le --help de la commande plutôt que dans sa page de man.

Ce qui permet d'avoir une page de man un peu plus détaillée pour les gens qui ne connaîssent pas du tout la commande ou qui ont besoin de détails plus précis.

C'est dommage si la page de man ne dit pas plus de choses que le --help.

Des exemples seraient bienvenus pour des commandes un peu plus complexes (grep, sed, …)

On en trouve pas mal dans la documentation de Linux proprement dit (epoll, par exemple) et des APIs de systemd (sd_notify, les APIs pour récupérer les logs de journalctl). Dans ces cas là il n'y a en général aucune autre documentation disponible, et quand la page de man n'existe pas ou ne donne pas d'exemple, ça devient vite compliqué.

Un cas que j'ai à traiter en ce moment, c'est la configuration des ports CAN sous linux en utilisant les sockets netlink. On trouve quelques infos sur SocketCAN dans la doc du noyau, il y a un peu de documentation sur netlink dans les pages de man, mais au final je n'ai pas eu d'autre choix que de tracer l'exécution de la commande ip avec strace pour voir exactement ce qu'elle fait, et reproduire les mêmes appels dans mon application. Un exemple m'aurait probablement fait gagner pas mal de temps (j'ai aussi essayé de lire le code de la commande ip, mais je me suis perdu dans plein de niveaux d'abstraction dont je n'avais pas besoin)

Oui, j'ai un clavier qui débloque.

(et j'ai fait exprès pour le titre, hein)

J'anticipe parce que forcément quelqu'un va râler: c'est un fil Twitter. Merci de grouper les commentaires inutiles à ce sujet en-dessous de celui-ci.

Fait gaffe, t'as pas de return TRUE à la fin de AddSysROMObjects() :P

Ah oui j'ai brutalement découpé un petit morceau de la fonction pour faire cet exemple , en vrai elle est un peu plus longue et il y a bien le return à la fin.

Et je soupçonne que Group devrait être écrit ’group’ :)

En effet.

Ce code vient de http://ace.cpcscene.net (dont j'ai pas trop parlé ici parce que c'est pas libre, choix de l'auteur original). Je m'occupe du portage pour Haiku et le mélange des conventions de codage n'est pas simple. Le code original est en C pour MorphOS avec une UI implémentée en C orienté objet avec plein de macros. L'interface graphique pour Haiku est écrite en partant de ces fichiers et en remplaçant tout ça par du C++ et en adaptant en partie le style. D'où parfois des variables ou paramètres qui ont gardé les conventions de la version originale. J'essaie de rester proche de l'original car ça me facilite la comparaison avec les versions suivantes pour intégrer les changements.

On ne voit pas sur la capture d'écran le mélange de tabulations et d'espaces pour l'indentation, aussi…

D'où l'intérêt d'avoir une bonne coloration syntaxique pour s'y retrouver, au moins le temps que je fasse un peu de nettoyage ;)

On peut supposer que c'est pas trop dans les habitudes de Doctolib et dans leur culture d'entreprise de gérer ce genre de pics d'activité. Après tout, ça ne fait que quelques mois qu'ils gèrent les rendez-vous pour la vaccination, et je ne vois pas de précédent où ils auraient reçu une telle activité. Forcément il y a des mauvaises surprises à l'arrivée, dans ce cas.

Il y a deux exemples dans le README du dépôt github dont le lien est à la fin du journal (avec un avant/après pour voir la différence).

(et n'en fait rien, mais ça n'est pas un problème de syntaxe)

Je n'ai jamais eu ce cas dans du code sur lequel je travaille.

Mais, effectivement, la détection est basée sur des expressions régulières et très approximatives.

Parmi les choses qui peuvent poser problème:
- Déclarer une variable dans les parenthèses d'une boucle for demande de gérer un cas particulier
- Les instanciations de templates en C++ qui peuvent contenir un mélange de types et de valeurs
- Les déclarations de fonctions avec des paramètres non nommés (int fonction(int);) qui sont compliqués à distinguer d'un appel de fonction
- Les conventions de formatage qui utilisent des retours à la ligne à des endroits un peu inhabituels:

    int
    fonction(int)
    {
        return 42;
    }

• Les extensions au langage C, par exemple l'utilisation de __attribute__ ou aussi en C++ les mot clés const, override, final qui peuvent se trouver à la fin d'une déclaration de fonction
• Les lambdas en C++ (j'ai pas encore essayé de voir si c'était possible).

Et sûrement plein d'autres auxquels je n'ai pas encore pensé. Donc, oui, c'est clairement pas parfait. Mais pour mon usage, l'amélioration de la lisibilité est quand même globalement positive.

Ça existe aussi: https://github.com/jeaye/color_coded

Gros problème avec cette approche: impossible de colorer correctement un fichier qui ne compile pas et qui ne peut donc pas être analysé par clang. Et donc impossible d'avoir la coloration d'une ligne de code qu'on est en train d'écrire.

Ce qui fait que ça risque de clignoter dans tous les sens selon que le code compile ou pas.

C'était dans ma TODO list depuis longtemps.

Le problème était que j'avais un fichier forké à partir d'une version de vim de 1998 avec plein de modifications pas très bien documentées, et c'était compliqué de reporter les changements sur la version actuelle du fichier qui a beaucoup évolué. Maintenant que c'est découpé dans un fichier séparé, ce sera plus simple.

Il y avait (et je pense qu'il y a toujours) des bugs dans certains cas, surtout sur le code C++ (je viens de modifier les patterns pour accepter les "::" dans les types et dans les noms de fonctions, par exemple). Et il n'y a pas seulement des ratages sur la surbrillance des types, mais aussi (surtout) ça cause des régressions sur d'autres choses. Même si pour moi, avoir la coloration des types est plus importante que les autres trucs qui sont cassés, il est probable que tout le monde ne sera pas d'accord.

Je ne pense pas que ce sera accepté par vim en l'état, et il faudra que j'essaie de corriger au moins les plus gros problèmes. Je vais installer cette nouvelle version sur mes différentes machines perso et pro et la tester pendant quelques jours pour voir ou ça en est, avant de proposer l'intégration dans vim.

C'est un truc de cryptomonnaies décentralisées-mais-en-fait-non qui s'est fait voler des millions de dollars en crytocoins. Et qui essaie de négocier avec les pirates pour les récupérer.

Rien de très intéressant, donc.

Oui du côté de Qt il n'y a plus d'acivité sur WebKit.

Il faut donc plutôt regarder du côté de GTK avec Epiphany/Gnome Browser? C'est vrai que les autres navigateurs (Midori, Kazehakaze, …) n'ont pas l'air très actifs.

La version GTK de WebKit est maintenue par Igalia qui l'utilise dans différents projets pour des applications embarquées. Donc pour l'instant du côté du moteur et de son intégration avec Linux il n'y a pas trop de soucis à se faire. Et WebKit est un projet beaucoup plus ouvert à la collaboration entre différentes entités et à la portabilité sur différentes plateformes. Du côté de Blink/Chromium, par exemple, il n'y a pas de support des systèmes BSD; alors que chez WebKit c'est le cas et ils sont plutôt réceptifs à l'idée d'intégrer même la version pour Haiku (si on avait le temps de leur envoyer nos patchs…). WebKit est aussi porté sur d'autres systèmes plus exotiques comme MorphOS.

son absence totale de concurrence sérieuse sur le créneau des navigateurs pas basés sur Chrome

WebKit ne compte pas, alors? C'est pourtant un moteur qui fonctionne plutôt bien.

C'est un peu plus spécifique et ce n'est pas un organisme public, muis il exste déjà le groupe européen d'intérêt pour les risques liés aux tableurs (European spreadsheet risks intrest group, EUSPRIG).

Leurs rapports se trouvent ici: http://www.eusprig.org/horror-stories.htm

Nous avions déposé la marque Haiku mais seulement dans la catégorie "systèmes d'exploitation". Et en plus, la marque déposée a expiré en 2018 car l'association Haiku inc a oublié de la renouveler.

C'est vrai, mais il y a de nouveaux projets de systèmes "alternatifs", en particulier on entend pas mal parler de SerenityOS et Redox OS

Au début de Liberapay il y avait vraiment une notion de porte-monnaie dans le site, et on pouvait le remplir puis étaler les dons et les répartir comme on voulait. On pouvait même re-donner l'argent qu'on avait reçu, sans aucun frais. Mais ils se sont fait jeter par l'entreprise qui traitait les paiements (Mangopay) et ils ont migré sur Stripe et Paypal qui ne permettent pas ce genre de choses.

Mais la présentation des choses dans Liberapay est resté comme avant alors que ça ne correspond plus du tout à ce qu'il se passe vraiment. Donc maintenant, en vrai, Liberapay c'est plutôt pour donner une fois par an, et avoir un rappel ou un renouvellement automatique des dons. Et découvrir quels projets ou développeurs acceptent des dons.

Je trouve que c'est dommage de persister à présenter l'ancien mode de fonctionnement qui n'existe plus. Ça embrouille tout le monde.

Ça dépend aussi ce qu'on entend par régulièrement.

Du point de vue d'une association, par exemple, la comptabilité se fait sur l'année, donc le truc optimal c'est de faire un don par an. D'un côté le budget est facile à prévoir, de l'autre ça fait moins de transactions et donc moins de frais (surtout si ça passe par Paypal ou ce genre de services).

Par contre si c'est un don directement à un développeur, c'est probable qu'il fasse son budget mois par mois pour payer son loyer, ses factures, etc. Et dans ce cas les dons à l'année ne sont peut être pas assez fréquents (mais ça dépend sûrement des gens, y'en a qui ont peut être des sous de côté pour attendre les dons de l'année suivante).

En général c'est important surtout si le don est "gros" par rapport au budget du destinataire. C'est différents si c'est 10€ dans le budget d'une grosse association qui emploie un développeur à plein temps (budget de quelques dizaine de milliers d'euros par an), ou si c'est 100€ dans le budget d'un petit projet qui ne sait pas s'il va pouvoir payer son hébergement web jusqu'à la fin de l'année. Dans le premier cas il y a pas vraiment de questions à se poser, dans le deuxième, ça risque de mettre des gens en difficulté s'ils ne s'y attendaient pas. Mais il suffit d'être clair sur le fait qu'il s'agit d'un don ponctuel, je pense?

En fait c'est marrant mais même si on a très peu d'argent pour nous (pour du financement de salaire, je veux dire), on en a pas mal pour du communautaire (on explique ça en fin de l'article).

Ça m'intrigue un peu ça. En effet l'article dit que ce n'est pas possible d'utiliser ces dons pour payer un contributeur, mais n'explique pas pourquoi.

Qu'est-ce qui pose problème? On le fait régulièrement (enfin, pas aussi souvent qu'on voudrait) chez Haiku et ça fonctionne plutôt bien, et il me semble que c'est le cas aussi pour ReactOS.

En fait elle était déjà en cours de modération avant la publication du lien.

J'essaierai la prochaine fois de l'envoyer en modération un peu plus en avance pour qu'elle puisse être relue plus tranquillement, et publiée dès l'annonce officielle :)

Bonjour, les commentaires racistes ne sont en effet pas les bienvenus sur le forum et les canaux de discussion de Haiku. Conformément aux règles de modération indiquées sur cette page: https://www.haiku-os.org/community/organization/policies/ l'équipe de modération peut prendre toutes les décisions qui semblent appropriées.