Sur ST les samples sont joués au CPU, en écrivant dans les registres de volume de l'AY. En général ceci est fait à partir d'une interruption timer pour gérer la fréquence. Ces registres de volume étant seulement sur 4 bits, ça limite un peu les choses.
Sur Atari STe, il y a en plus de la puce (qui est un YM2149, presque la même chose que l'AY-3-8912 mais pas tout à fait), deux canaux DMA pour les samples.
Précision sur l'Amiga: les canaux DMA n'utilisent certes pas le CPU, mais font des accès à la chipram, ce qui empêche le CPU d'y accéder en même temps. Ce dernier est donc tout de même ralenti, à moins de s'arranger pour travailler uniquement en fastram (la mémoire étendue isolée du chipset et inaccessible par les canaux DMA).
HivelyTracker ne permet pas d'utiliser des samples si je me souviens bien. Il est dérivé de AHX (pour Amiga) et fonctionne avec un synthétiseur en temps réel.
Pour protrekkr, en effet je pense que la version de hitchhikr est la plus à jour (elle était hébergée sur Google Code il me semble, avant que ça ferme). Je ne sais pas si des évolutions sont nécessaires. Peut-être que le programme fait tout ce qu'on attend de lui et qu'il n'y a pas tellement besoin de changements?
hitchhikr pourra faire la maintenance si nécessaire, ou bien je peux aussi m'en occuper (en tant que responsable du port vers Haiku, j'ai déjà un peu touché à son code).
Ben oui, le financement participatif ne supprime pas le besoin de faire du marketing et de la publicité. Il permet juste de regrouper les gens qui ont un besoin commun mais qui ne sont pas prêts à en assurer le coût à 100%.
Il y a plein de variantes. Par exemple les "bounties", typquement sur le site bountysource, ou on peut mettre des promesses de dons sur une fonctionnalité. Le développeur qui l'implémente récupère le pactole. Personellement ce fonctionnement en mode "chasseur de primes" ne me plaît pas trop (je ne dirai pas non si par hasard je résoud un bug et que j'apprends que quelqu'un avait misé de l'argent dessus, mais bon).
Tu as aussi Liberapay qui lui se place dans un mode d'économie du don: un développeur (ou n'importe qui, la plateforme est ouverte à tous) reçoit des dons anonymes et donc nécessairement sans contrepartie. Mais les gens sont-ils prêt à financer ça sans contrepartie? Il faut aller le leur expliquer et là encore, ça demande du temps. Mais au moins on est pas obligé, on peut aussi s'inscrire sur Liberapay et juste attendre que les dons arrivent.
Tu as encore les sites du type Patreon, ou l'idée est que les gens donnent de l'argent pour financer le travail de quelqu'un (développeur, artiste, …) et en échange vont avoir accès à un genre de "zone VIP" avec un apperçu du travail en avant-première, etc. Dans ce cas on retombe dans l'inconvénient des campagnes de type Kickstarter: faire vivre ce genre de plateforme demande du temps de la part de la personne financée.
De façon générale, si tu as un logiciel générique qui répond à un besoin récurrent d'entreprises, tu peux t'en sortir en vendant le support, le déploiement, et le développement pour personnaliser ce logiciel pour les besoins exacts de chaque client.
C'est possiblement moins de rentrée d'argent que si tu vendais le logiciel tel quel avec une licence par nombre de postes installés ou je ne sais quoi. Mais d'un autre côté ça peut permettre d'être moins cher qu'un concurrent qui développerait un truc à partir de zéro pour chaque client.
Il y a quelques mois, Mozilla avait présenté une taxonomie des projets libres, avec plusieurs types de projets selon la gouvernance, le financement, etc. C'est probablement bon à relire pour voir les modèles qui semblent les plus pertinents du point de vue de la perrenité et de l'efficacité.
On en arrive là parce que le modèle communautaire n'a pas marché. Quand on est une entreprise et qu'on veut faire du logiciel libre et le diffuser gratuitement, il faut bien trouver un "modèle d'affaires" (business model), une façon de faire rentrer des sous.
Il y a des projets pleinement communautaires, parce qu'ils sont gros, et que du coup plusieurs entreprises/fondations/… peuvent y contribuer. Je pense à Linux, à WebKit, à clang par exemple.
Et il y a des projets plus petits, portés par une seule entreprise dont c'est le métier principal. On pourrait se dire "ils pourraient fournir le logiciel libre gratuitement, et vendre le support". Oui mais voilà, quand en plus on est sur un mode "service" (comme github ou gitlab), on est quand même un peu obligé de fournir du support sur le produit.
Ils pourraient aussi facturer les nouveaux développement à la première personne qui les demande (ou bien en partageant via des bounties/crowdfunding), mais ça serait très cher, et si la personne qui paie sait que ça finira par être libre, elle peut aussi bien décider d'attendre que quelqu'un paie à sa place.
En ce qui me concerne, je travaille dans une entreprise qui utilise beaucoup de logiciel libre. Gitlab (déployé en interne), Linux, iptables, …
Cependant, jusqu'à maintenant on n'a que peu contribué. Notre démarche va être (on y réfléchit) d'avoir des développeurs avec un peu de temps réservé (par exemple une journée par mois) pour contribuer à du logiciel libre. Les logiciels ont vraiment besoin de contributeurs, et faire en sorte que les entreprises paient avec du temps de leurs employés, plutôt qu'avec de l'argent, ça serait peut être intéressant. Pour le projet libre qui récupère les contributions, pour l'employé qui peut faire du logiciel libre, et pour l'entreprise qui bénéficie des nouvelles fonctionnalités ainsi réalisées, d'employés contents qui sont plus motivés, et de retombées en terme d'image de marque.
Si plus de monde se met à faire ce genre de choses, alors on pourra avoir du logiciel communautaire bien maintenu. Sinon, à un moment donné il va falloir se décider à passer à la caisse. Et si une entreprise voit qu'elle ne récupère pas de contributions valables en publiant ses sources, il est probable qu'elle arrête de s’embarrasser avec ça. C'est là qu'on tombe dans le modèle "open core". Du Libre en version "on aimerait bien, mais ça paie pas les salaires à la fin du mois".
A moins d'avoir des développeurs super forts (ou d'aimer les régressions), optimiser le code nécessite de le comprendre et de pouvoir faire des changements profonds sans avoir peur de tout casser.
Ce n'est pas parce qu'un algorithme est complexe que le code doit être illisible. Il doit être possible d'écrire les choses de façon modulaire et réutilisable, ce qui permet en plus d'appliquer le même algorithme (ou quelques morceaux) pour optimiser d'autres choses.
C'est très pénible (mais pas impossible) à faire en C, et plus confortable en C++ (pas de commentaire sur les autres langages que je ne connaît pas assez bien pour en juger).
Si ton code est un tas de spaghetti, tu ne peux pas le modifier facilement pour le rendre plus efficace. S'il est propre et bien architecturé, tu peux remplacer une structure de données ou un algorithme sans devoir tout remettre en question.
Non, Linux ne renvoie pas NULL par défaut quand il n'a pas de mémoire pour un malloc. Il tue un process pour faire de la place.
Le principe, c'est de supposer que les applications vont demander plus de mémoire que ce qu'elles ont vraiment besoin. Du coup, on leur dit "ouais ouais, c'est bon voilà tes 12Go de RAM" et en vrai on alloue de la mémoire physique que quand l'application fait effectivement un accès à cette mémoire.
Si l'application effectivement n'utilise pas tout ce qu'elle a demandé, on est gagnant, on arrive à faire croire à l'application que la mémoire dont elle n'a pas besoin est libre. Mais si l'application finit par utiliser cette mémoire, ben on ne peut plus gérer l'erreur proprement puisque c'était sensé être fait au moment du malloc.
Ce principe s'appelle "overcommit". C'est l'équivalent du surbooking pour les compagnies aériennes (qui partent du principe qu'il y a toujours une ou deux personnes qui vont réserver une place mais ne pas arriver à l'embarquement).
Pourquoi Linux fait ça? Parce que les gens qui ont écrit les applications ont été larges dans leurs demandes de mémoire, plutôt que de calculer leurs besoins au plus juste. Et maintenant que ça marche comme ça, pourquoi les applications s'embêteraient à calculer leurs besoins au plus juste et à gérer correctement les erreurs d'allocation?
Ici on a un gitlab, des merge requests qui conservent l'historique, et des intégrateurs qui font leur travail pour vérifier que le code est bien écrit, commenté et documenté. Sinon, il n'est pas intégré.
Il faut peut-être aller expliquer leur travail à vos intégrateurs.
On a déjà bien assez de dette technique comme ça, on a tout intérêt à ce que au moins le code qu'on écrit soit propre. On est prestataires (grosse équipe, une quarantaine de personnes sur différents projets) et le dépôt git est évidemment synchronisé chez le client toutes les nuits, de façon à ce qu'il aie accès à l'historique (sauf les branches "internes" qui restent chez nous avec les devs en cours pas encore livrés). Si vos prestataires vous envoie le code en vrac par mail et sans contrôle de sources, vous avez là aussi un problème.
On ne développe pas de code sur nos propres machines, mais sur un serveur partagé avec un environnement de travail maîtrisé. Ce qui fait que formater un PC n'est jamais un problème, et aussi qui permet au client de savoir exactement dans quelle configuration on travaille et de reproduire l'environnement chez lui si nécessaire.
Pour les commits, on ne garde pas tout, l'idée est que le développeur fait son développement et prend le temps de découper ça en commits "atomiques" apportant chacun une fonctionnalité précise, et étant fonctionnel et indépendant des commits suivants. Gitlab ni Github ne mettent pas vraiment cette façon de travailler, si j'avais le choix je pencherais plutôt pour un outil comme Gerrit, qui permet de faire une revue de code en travaillant sur un commit à la fois.
Mais de toutes façons, les développements sont découpés en tâches qui peuvent être complétées en quelques jours, au pire une à deux semaines si vraiment ça se passe mal. Les revues et intégrations sont donc très fréquentes et concernent peu de commits à la fois. Les commits de développement sont au nom de l'auteur, le commit d'intégration au nom du relecteur/intégrateur. Tout est donc tracé.
L'historique git est un outil précieux pour comprendre le fonctionnement du code, et s'il est bien tenu, souvent plus efficace que des commentaires ou de la documentation d'architecture.
L'histoire de l'informatique elle-même est déjà courte. On a clairement pas 1 siècle de recul comme on peut avoir en électricité/électronique, par exemple. Et c'est vrai qu'en plus, les ingénieurs manquent souvent de bagage pour en tirer les leçons.
Parfois cela fonctionne, par exemple XML est déjà une versions très simplifiée de SGML et c'était nécessaire. ASN1 est peut être un peu à part, c'est un standard venu des télécommunications et bien que l'idée soit très intéressante, je n'ai pas trouvé les implémentations convaincantes en terme de simplicité d'utilisation ni de performances (je l'ai utilisé dans un contexte Python et C embarqué).
L'équilibre entre réinventer la roue et empiler des couches de dette technique est difficile à trouver. Mais une bonne connaissance de l'historique (du projet, et de l'informatique en général) permet souvent d'y voir plus clair et de prendre de meilleures décisions. On apprend beaucoup en lisant le code et la documentation des personnes qui sont passées avant nous, finalement.
Dans Haiku on a pas d'OOM killer. On a un malloc() qui renvoie NULL quand y'a pas de mémoire disponible, et des applications qui gèrent l'erreur. L'utilisateur a donc une chance d'enregistrer son travail avant qu'une application soit détruite.
Je ne devrais pas avoir à me préoccuper de surveiller l'occupation mémoire de mon PC en me disant "merde, si je dépasse trop, ça va me tuer mon programme et détruire mes données". C'est le travail du système de faire ça, et de faire en sorte que quoi qu'il arrive, les fichiers sur lesquels je travaille sont sauvegardés et que mon travail n'est pas perdu.
Facile, je n'ai pas envie de contribuer à Linux et je travaille beaucoup sur Haiku où les buts sont d'avoir du code propre et lisible, un environnement accueillant, et un produit efficace.
Je contribue aussi un petit peu à NetSurf, un navigateur web avec une approche raisonnable et des besoins en ressources beaucoup plus faibles que les concurrents.
Et bien sur mon éditeur préféré, c'est vim, parce qu'il prend moins d'1Mo sur mon disque dur, fonctionne sur toutes les plateformes dont j'ai besoin, et sait faire tout ce qui est nécessaire, mais pas plus.
Au FOSDEM cette année il y avait une conférence sur un travail similaire pour les BSD, avec un dépôt git remontant jusqu'aux toutes premières versions d'UNIX des années 70 (dont certaines ont dû être récupérées à partir de listings sur papier).
Non ce n'est pas drôle. Je trouve ça insupportable d'utiliser un ordinateur moderne. Tous ces gigahertz et giga octets de RAM et pourtant ça se traîne toujours autant. Il s'est passé quoi?
Oui, Linux tue des process au hasard par conception: https://doc.ubuntu-fr.org/oomkiller
Non, ce n'est pas normal que ça fonctionne comme ça. Oui, c'est désactivable, mais c'est toujours le comportement par défaut.
J'ai la chance dans certains de mes projets de pouvoir faire les choses proprement. C'est plus long. Mais le résultat c'est du code propre, maintenable, et efficace. Et sur d'autres projets, je dois aller au plus court, faire du code sale, et savoir que je vais perdre du temps plus tard, beaucoup de temps, pour le réparer. Et non, je ne suis pas fier de mon travail dans ces conditions.
Pas très efficace la protection pour le coup, je suis dans l'UE et j'ai eu droit à cette boite de dialogue en installant un autre navigateur. Qui s'occupe de porter plainte au lieu de raler sur les forums?
Signal /et/ Telegram? être "simple pour nos parents" ça commence par ne pas embrouiller les gens avec deux applications qui font presque la même chose, non?
(et au passage, il y a un t en trop à "choix applicatif réfléchit")
Chez Haiku, les noms des softs sont en général clairs et ennuyeux (MediaPlayer, ShowImage, Colors, Debugger, …). Par contre on s'est un peu amusé avec les icônes qui permettent à chaque logiciel d'avoir sa propre identité. Peut être une piste à creuser.
On avait une page avec plein d'icônes mais apparament elle n'est plus en ligne. Il va falloir remettre ça en place.
Il y a toujours un avant/après dans ces journaux. Mais Apple ne dois pas faire de keynotes assez souvent; les moules oublient d'une fois sur l'autre comment ça marche.
Bonjour, je vais essayer de répondre même si je ne suis responsable que d'un petit morceau du port pour Haiku et que j'ai peu touché au coeur de NetSurf.
NetSurf est le seul choix raisonable pour certaines des plateformes ciblées: MiNT, RiscOS, KolibriOS ou AmigaOS 3 par exemple. Avoir un navigateur qui sait prendre en charge les CSS sur ces systèmes est déjà très bien. Cependant, je pense que peu de monde utilise ces systèmes comme principale machine.
Sous Haiku, on dispose de navigateurs basés sur WebKit, autrement plus compliqués, et NetSurf est un bon complément quand on tombe sur un site web un peu récalcitrant.
Il trouve également une utilisation dans les systèmes embarqués, et ira peut être plus loin de ce côté quand il disposera d'un moteur Javascript. Il existe une version de NetSurf qui a juste besoin d'un framebuffer pour faire le rendu, donc très facile à porter même sur un système très minimaliste. On pourrait donc imaginer écrire une application embarquée en HTML, CSS et JavaScript, ou même, grâce à la modularité de NetSurf, remplacer le JavaScript et écrire une application C avec un rendu en HTML/CSS.
NetSurf est rapide pour le rendu sur les machines ciblées. La plupart des autres navigateurs vont s'attendre à disposer d'accélération 3D pour réaliser certains effets graphiques, et tenter de faire tout le rendu en logiciel peut être un gros problème (j'en sais quelque chose, puisque la version de WebKit pour Haiku fonctionne ainsi). Je ne sais pas dans quelle mesure l'intégration de Javascript changera les choses pour NetSurf, car actuellement le DOM (le modèle de la page) est statique et donc le rendu peut être fait en une seule fois. Avec Javascript, la page peut être modifiée à tout moment et cela a de nombreuses conséquences.
Je n'ai pas branché mon Amiga depuis bien longtemps, et il a plus de RAM que ça (poussé à 128Mo mais avec un vénérable 68040 à 40MHz). Ilfaudra que je voie ce que ça donne. Si j'ai le temps un jour je me lancerai peut être à faire fonctionner NetSurf sous Windows 3.11 avec Win32S, par curiosité archéologique :)
Le choix de la licence est un peu personnel, ça dépend de ce que tu veux que ce projet devienne.
La GPL n'est pas vraiment pertinente vu qu'il s'agit d'un site web (légalement, les visiteurs ne sont pas considérés comme des utilisateurs et donc le système de copyleft de la GPL ne s'applique pas). Si tu veux une licence copyleft, la licence Affero est donc un bon choix.
Sinon, une licence MIT, simple, efficace, et bien connue. Elle semble être une bonne façon de laisser quelqu'un d'autre (ou une plus grosse équipe) prendre le code et en faire ce qu'ils veulent. Il faudra leur faire confiance pour que leurs évolutions restent libres, par contre, car il n'y aura pas d'obligation contractuelle.
Merci en tout cas de publier les sources, même si elles ne sont pas "présentables". J'espère que ton travail ne sera pas perdu et connaîtra une nouvelle vie grâce à ça.
Encore une généralisation. Tous les logiciels FLOSS seraient pareil, développés par les mêmes 12 hackers socialement incapables avec un humour de merde.
Je sais pas, faisons un tour parmi les logiciels propriétaires. Pas les gros trucs développés par Apple ou Google, qui eux aussi ont parfois des logos pas si moches que ça (encore que ça vieillit pas toujours très bien). Mais prenons plutôt du bon vieux shareware:
Bon, la liste est sûrement très longue mais je n'utilise plus assez Windows pour en connaître tant que ça. Donc, en dehors des gros trucs qui ont des sous pour se payer un designer, il y a des trucs moches et pas libre partout. Et niveau interface utilisateur, y'a qu'à regarder n'importe quelle UI d'antivirus ou de driver d'imprimante.
Le problème est ailleurs: il n'y a pas assez de designers qui contribuent aux logiciels libres. On ne peut pas demander aux développeurs de faire le job, il faut quelqu'un qui connaisse le métier. En attendant, on se débrouille comme on peut. Et non, on est pas forcément tous fiers d'avoir des logos moches.
Il y a toujours dans Debian des paquets -off (pour "offensive") avec des fortunes insultantes ou inappropriées, et une partie des questions de purity (le quizz qui évalue la "pureté" d'une personne):
J'utilise de plus en plus YouCompleteMe, qui fonctionne sous forme d'un démon en arrière plan (lancé par vim de façon transparente) et fournit à la fois le soulignement des erreurs de syntaxe et autres problèmes, et la complétion automatique.
Je ne l'ai testé qu'en C et C++ pour l'instant, mais il sait faire ça pour plusieurs langages, dont Python.
[^] # Re: Trackers <3
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal OpenMPT 1.28 : OPL & concours. Évalué à 3.
Sur ST les samples sont joués au CPU, en écrivant dans les registres de volume de l'AY. En général ceci est fait à partir d'une interruption timer pour gérer la fréquence. Ces registres de volume étant seulement sur 4 bits, ça limite un peu les choses.
Sur Atari STe, il y a en plus de la puce (qui est un YM2149, presque la même chose que l'AY-3-8912 mais pas tout à fait), deux canaux DMA pour les samples.
Précision sur l'Amiga: les canaux DMA n'utilisent certes pas le CPU, mais font des accès à la chipram, ce qui empêche le CPU d'y accéder en même temps. Ce dernier est donc tout de même ralenti, à moins de s'arranger pour travailler uniquement en fastram (la mémoire étendue isolée du chipset et inaccessible par les canaux DMA).
[^] # Re: Liste non exhaustive
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal OpenMPT 1.28 : OPL & concours. Évalué à 4.
HivelyTracker ne permet pas d'utiliser des samples si je me souviens bien. Il est dérivé de AHX (pour Amiga) et fonctionne avec un synthétiseur en temps réel.
Pour protrekkr, en effet je pense que la version de hitchhikr est la plus à jour (elle était hébergée sur Google Code il me semble, avant que ça ferme). Je ne sais pas si des évolutions sont nécessaires. Peut-être que le programme fait tout ce qu'on attend de lui et qu'il n'y a pas tellement besoin de changements?
hitchhikr pourra faire la maintenance si nécessaire, ou bien je peux aussi m'en occuper (en tant que responsable du port vers Haiku, j'ai déjà un peu touché à son code).
[^] # Re: Faire la différence
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal De l'avenir des projets communautaires face aux sirènes de la finance. Évalué à 3.
Ben oui, le financement participatif ne supprime pas le besoin de faire du marketing et de la publicité. Il permet juste de regrouper les gens qui ont un besoin commun mais qui ne sont pas prêts à en assurer le coût à 100%.
Il y a plein de variantes. Par exemple les "bounties", typquement sur le site bountysource, ou on peut mettre des promesses de dons sur une fonctionnalité. Le développeur qui l'implémente récupère le pactole. Personellement ce fonctionnement en mode "chasseur de primes" ne me plaît pas trop (je ne dirai pas non si par hasard je résoud un bug et que j'apprends que quelqu'un avait misé de l'argent dessus, mais bon).
Tu as aussi Liberapay qui lui se place dans un mode d'économie du don: un développeur (ou n'importe qui, la plateforme est ouverte à tous) reçoit des dons anonymes et donc nécessairement sans contrepartie. Mais les gens sont-ils prêt à financer ça sans contrepartie? Il faut aller le leur expliquer et là encore, ça demande du temps. Mais au moins on est pas obligé, on peut aussi s'inscrire sur Liberapay et juste attendre que les dons arrivent.
Tu as encore les sites du type Patreon, ou l'idée est que les gens donnent de l'argent pour financer le travail de quelqu'un (développeur, artiste, …) et en échange vont avoir accès à un genre de "zone VIP" avec un apperçu du travail en avant-première, etc. Dans ce cas on retombe dans l'inconvénient des campagnes de type Kickstarter: faire vivre ce genre de plateforme demande du temps de la part de la personne financée.
[^] # Re: Et vous, vous faites quoi?
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal De l'avenir des projets communautaires face aux sirènes de la finance. Évalué à 2.
De façon générale, si tu as un logiciel générique qui répond à un besoin récurrent d'entreprises, tu peux t'en sortir en vendant le support, le déploiement, et le développement pour personnaliser ce logiciel pour les besoins exacts de chaque client.
C'est possiblement moins de rentrée d'argent que si tu vendais le logiciel tel quel avec une licence par nombre de postes installés ou je ne sais quoi. Mais d'un autre côté ça peut permettre d'être moins cher qu'un concurrent qui développerait un truc à partir de zéro pour chaque client.
Il y a quelques mois, Mozilla avait présenté une taxonomie des projets libres, avec plusieurs types de projets selon la gouvernance, le financement, etc. C'est probablement bon à relire pour voir les modèles qui semblent les plus pertinents du point de vue de la perrenité et de l'efficacité.
# Liste non exhaustive
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal OpenMPT 1.28 : OPL & concours. Évalué à 5.
Dans les trackers libres et toujours plus ou moins vivants, il y a aussi:
Et encore plein d'autres
# Et vous, vous faites quoi?
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal De l'avenir des projets communautaires face aux sirènes de la finance. Évalué à 10.
On en arrive là parce que le modèle communautaire n'a pas marché. Quand on est une entreprise et qu'on veut faire du logiciel libre et le diffuser gratuitement, il faut bien trouver un "modèle d'affaires" (business model), une façon de faire rentrer des sous.
Il y a des projets pleinement communautaires, parce qu'ils sont gros, et que du coup plusieurs entreprises/fondations/… peuvent y contribuer. Je pense à Linux, à WebKit, à clang par exemple.
Et il y a des projets plus petits, portés par une seule entreprise dont c'est le métier principal. On pourrait se dire "ils pourraient fournir le logiciel libre gratuitement, et vendre le support". Oui mais voilà, quand en plus on est sur un mode "service" (comme github ou gitlab), on est quand même un peu obligé de fournir du support sur le produit.
Ils pourraient aussi facturer les nouveaux développement à la première personne qui les demande (ou bien en partageant via des bounties/crowdfunding), mais ça serait très cher, et si la personne qui paie sait que ça finira par être libre, elle peut aussi bien décider d'attendre que quelqu'un paie à sa place.
En ce qui me concerne, je travaille dans une entreprise qui utilise beaucoup de logiciel libre. Gitlab (déployé en interne), Linux, iptables, …
Cependant, jusqu'à maintenant on n'a que peu contribué. Notre démarche va être (on y réfléchit) d'avoir des développeurs avec un peu de temps réservé (par exemple une journée par mois) pour contribuer à du logiciel libre. Les logiciels ont vraiment besoin de contributeurs, et faire en sorte que les entreprises paient avec du temps de leurs employés, plutôt qu'avec de l'argent, ça serait peut être intéressant. Pour le projet libre qui récupère les contributions, pour l'employé qui peut faire du logiciel libre, et pour l'entreprise qui bénéficie des nouvelles fonctionnalités ainsi réalisées, d'employés contents qui sont plus motivés, et de retombées en terme d'image de marque.
Si plus de monde se met à faire ce genre de choses, alors on pourra avoir du logiciel communautaire bien maintenu. Sinon, à un moment donné il va falloir se décider à passer à la caisse. Et si une entreprise voit qu'elle ne récupère pas de contributions valables en publiant ses sources, il est probable qu'elle arrête de s’embarrasser avec ça. C'est là qu'on tombe dans le modèle "open core". Du Libre en version "on aimerait bien, mais ça paie pas les salaires à la fin du mois".
[^] # Re: TL ; DR
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au lien Software disenchantment. Évalué à 3.
A moins d'avoir des développeurs super forts (ou d'aimer les régressions), optimiser le code nécessite de le comprendre et de pouvoir faire des changements profonds sans avoir peur de tout casser.
Ce n'est pas parce qu'un algorithme est complexe que le code doit être illisible. Il doit être possible d'écrire les choses de façon modulaire et réutilisable, ce qui permet en plus d'appliquer le même algorithme (ou quelques morceaux) pour optimiser d'autres choses.
C'est très pénible (mais pas impossible) à faire en C, et plus confortable en C++ (pas de commentaire sur les autres langages que je ne connaît pas assez bien pour en juger).
Si ton code est un tas de spaghetti, tu ne peux pas le modifier facilement pour le rendre plus efficace. S'il est propre et bien architecturé, tu peux remplacer une structure de données ou un algorithme sans devoir tout remettre en question.
[^] # Re: Tiens, à propos, comment-vous gérez vos repos, vous ?
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal Remonter l'historique du noyau avec git depuis le début. Évalué à 4.
Oui, c'est pas impossible à faire avec Gitlab mais c'est pénible.
Gerrit permet aussi de merger un commit avant que les suivants ne soient prêts, par exemple.
Ce n'est pas forcément moins souple, c'est juste une façon différente de travailler.
[^] # Re: TL ; DR
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au lien Software disenchantment. Évalué à 6.
Non, Linux ne renvoie pas NULL par défaut quand il n'a pas de mémoire pour un malloc. Il tue un process pour faire de la place.
Le principe, c'est de supposer que les applications vont demander plus de mémoire que ce qu'elles ont vraiment besoin. Du coup, on leur dit "ouais ouais, c'est bon voilà tes 12Go de RAM" et en vrai on alloue de la mémoire physique que quand l'application fait effectivement un accès à cette mémoire.
Si l'application effectivement n'utilise pas tout ce qu'elle a demandé, on est gagnant, on arrive à faire croire à l'application que la mémoire dont elle n'a pas besoin est libre. Mais si l'application finit par utiliser cette mémoire, ben on ne peut plus gérer l'erreur proprement puisque c'était sensé être fait au moment du malloc.
Ce principe s'appelle "overcommit". C'est l'équivalent du surbooking pour les compagnies aériennes (qui partent du principe qu'il y a toujours une ou deux personnes qui vont réserver une place mais ne pas arriver à l'embarquement).
Pourquoi Linux fait ça? Parce que les gens qui ont écrit les applications ont été larges dans leurs demandes de mémoire, plutôt que de calculer leurs besoins au plus juste. Et maintenant que ça marche comme ça, pourquoi les applications s'embêteraient à calculer leurs besoins au plus juste et à gérer correctement les erreurs d'allocation?
[^] # Re: Tiens, à propos, comment-vous gérez vos repos, vous ?
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal Remonter l'historique du noyau avec git depuis le début. Évalué à 8.
Ici on a un gitlab, des merge requests qui conservent l'historique, et des intégrateurs qui font leur travail pour vérifier que le code est bien écrit, commenté et documenté. Sinon, il n'est pas intégré.
Il faut peut-être aller expliquer leur travail à vos intégrateurs.
On a déjà bien assez de dette technique comme ça, on a tout intérêt à ce que au moins le code qu'on écrit soit propre. On est prestataires (grosse équipe, une quarantaine de personnes sur différents projets) et le dépôt git est évidemment synchronisé chez le client toutes les nuits, de façon à ce qu'il aie accès à l'historique (sauf les branches "internes" qui restent chez nous avec les devs en cours pas encore livrés). Si vos prestataires vous envoie le code en vrac par mail et sans contrôle de sources, vous avez là aussi un problème.
On ne développe pas de code sur nos propres machines, mais sur un serveur partagé avec un environnement de travail maîtrisé. Ce qui fait que formater un PC n'est jamais un problème, et aussi qui permet au client de savoir exactement dans quelle configuration on travaille et de reproduire l'environnement chez lui si nécessaire.
Pour les commits, on ne garde pas tout, l'idée est que le développeur fait son développement et prend le temps de découper ça en commits "atomiques" apportant chacun une fonctionnalité précise, et étant fonctionnel et indépendant des commits suivants. Gitlab ni Github ne mettent pas vraiment cette façon de travailler, si j'avais le choix je pencherais plutôt pour un outil comme Gerrit, qui permet de faire une revue de code en travaillant sur un commit à la fois.
Mais de toutes façons, les développements sont découpés en tâches qui peuvent être complétées en quelques jours, au pire une à deux semaines si vraiment ça se passe mal. Les revues et intégrations sont donc très fréquentes et concernent peu de commits à la fois. Les commits de développement sont au nom de l'auteur, le commit d'intégration au nom du relecteur/intégrateur. Tout est donc tracé.
L'historique git est un outil précieux pour comprendre le fonctionnement du code, et s'il est bien tenu, souvent plus efficace que des commentaires ou de la documentation d'architecture.
[^] # Re: TL ; DR
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au lien Software disenchantment. Évalué à 6.
L'histoire de l'informatique elle-même est déjà courte. On a clairement pas 1 siècle de recul comme on peut avoir en électricité/électronique, par exemple. Et c'est vrai qu'en plus, les ingénieurs manquent souvent de bagage pour en tirer les leçons.
Parfois cela fonctionne, par exemple XML est déjà une versions très simplifiée de SGML et c'était nécessaire. ASN1 est peut être un peu à part, c'est un standard venu des télécommunications et bien que l'idée soit très intéressante, je n'ai pas trouvé les implémentations convaincantes en terme de simplicité d'utilisation ni de performances (je l'ai utilisé dans un contexte Python et C embarqué).
L'équilibre entre réinventer la roue et empiler des couches de dette technique est difficile à trouver. Mais une bonne connaissance de l'historique (du projet, et de l'informatique en général) permet souvent d'y voir plus clair et de prendre de meilleures décisions. On apprend beaucoup en lisant le code et la documentation des personnes qui sont passées avant nous, finalement.
[^] # Re: TL ; DR
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au lien Software disenchantment. Évalué à 3.
Dans Haiku on a pas d'OOM killer. On a un malloc() qui renvoie NULL quand y'a pas de mémoire disponible, et des applications qui gèrent l'erreur. L'utilisateur a donc une chance d'enregistrer son travail avant qu'une application soit détruite.
Je ne devrais pas avoir à me préoccuper de surveiller l'occupation mémoire de mon PC en me disant "merde, si je dépasse trop, ça va me tuer mon programme et détruire mes données". C'est le travail du système de faire ça, et de faire en sorte que quoi qu'il arrive, les fichiers sur lesquels je travaille sont sauvegardés et que mon travail n'est pas perdu.
[^] # Re: TL ; DR
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au lien Software disenchantment. Évalué à 4.
Facile, je n'ai pas envie de contribuer à Linux et je travaille beaucoup sur Haiku où les buts sont d'avoir du code propre et lisible, un environnement accueillant, et un produit efficace.
Je contribue aussi un petit peu à NetSurf, un navigateur web avec une approche raisonnable et des besoins en ressources beaucoup plus faibles que les concurrents.
Et bien sur mon éditeur préféré, c'est vim, parce qu'il prend moins d'1Mo sur mon disque dur, fonctionne sur toutes les plateformes dont j'ai besoin, et sait faire tout ce qui est nécessaire, mais pas plus.
[^] # Re: En fabriquer un dépôt git pour l'historique?
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal Remonter l'historique du noyau avec git depuis le début. Évalué à 10.
Au FOSDEM cette année il y avait une conférence sur un travail similaire pour les BSD, avec un dépôt git remontant jusqu'aux toutes premières versions d'UNIX des années 70 (dont certaines ont dû être récupérées à partir de listings sur papier).
[^] # Re: TL ; DR
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au lien Software disenchantment. Évalué à 4.
Non ce n'est pas drôle. Je trouve ça insupportable d'utiliser un ordinateur moderne. Tous ces gigahertz et giga octets de RAM et pourtant ça se traîne toujours autant. Il s'est passé quoi?
Oui, Linux tue des process au hasard par conception: https://doc.ubuntu-fr.org/oomkiller
Non, ce n'est pas normal que ça fonctionne comme ça. Oui, c'est désactivable, mais c'est toujours le comportement par défaut.
J'ai la chance dans certains de mes projets de pouvoir faire les choses proprement. C'est plus long. Mais le résultat c'est du code propre, maintenable, et efficace. Et sur d'autres projets, je dois aller au plus court, faire du code sale, et savoir que je vais perdre du temps plus tard, beaucoup de temps, pour le réparer. Et non, je ne suis pas fier de mon travail dans ces conditions.
[^] # Re: Pub
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal Windows 10 fait la publicité de Edge pendant l'installation de Firefox et Chrome !. Évalué à 2.
Pas très efficace la protection pour le coup, je suis dans l'UE et j'ai eu droit à cette boite de dialogue en installant un autre navigateur. Qui s'occupe de porter plainte au lieu de raler sur les forums?
# Choix d'applications réfléchi
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal première beta de /e/. Évalué à 7.
Signal /et/ Telegram? être "simple pour nos parents" ça commence par ne pas embrouiller les gens avec deux applications qui font presque la même chose, non?
(et au passage, il y a un t en trop à "choix applicatif réfléchit")
# Haiku (oui je fais de la pub)
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal De l'importance de bien nommer ses logiciels…. Évalué à 6.
Chez Haiku, les noms des softs sont en général clairs et ennuyeux (MediaPlayer, ShowImage, Colors, Debugger, …). Par contre on s'est un peu amusé avec les icônes qui permettent à chaque logiciel d'avoir sa propre identité. Peut être une piste à creuser.
On avait une page avec plein d'icônes mais apparament elle n'est plus en ligne. Il va falloir remettre ça en place.
[^] # Re: Ou est le journal troll habituel ?
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal Nouveau coup de tonnerre attendu. Évalué à 10.
SPOILERS
Il y a toujours un avant/après dans ces journaux. Mais Apple ne dois pas faire de keynotes assez souvent; les moules oublient d'une fois sur l'autre comment ça marche.
[^] # Re: Impressionnant
Posté par pulkomandy (site web personnel, Mastodon) . En réponse à la dépêche Le navigateur Web NetSurf publie sa version 3.8. Évalué à 5.
Bonjour, je vais essayer de répondre même si je ne suis responsable que d'un petit morceau du port pour Haiku et que j'ai peu touché au coeur de NetSurf.
NetSurf est le seul choix raisonable pour certaines des plateformes ciblées: MiNT, RiscOS, KolibriOS ou AmigaOS 3 par exemple. Avoir un navigateur qui sait prendre en charge les CSS sur ces systèmes est déjà très bien. Cependant, je pense que peu de monde utilise ces systèmes comme principale machine.
Sous Haiku, on dispose de navigateurs basés sur WebKit, autrement plus compliqués, et NetSurf est un bon complément quand on tombe sur un site web un peu récalcitrant.
Il trouve également une utilisation dans les systèmes embarqués, et ira peut être plus loin de ce côté quand il disposera d'un moteur Javascript. Il existe une version de NetSurf qui a juste besoin d'un framebuffer pour faire le rendu, donc très facile à porter même sur un système très minimaliste. On pourrait donc imaginer écrire une application embarquée en HTML, CSS et JavaScript, ou même, grâce à la modularité de NetSurf, remplacer le JavaScript et écrire une application C avec un rendu en HTML/CSS.
NetSurf est rapide pour le rendu sur les machines ciblées. La plupart des autres navigateurs vont s'attendre à disposer d'accélération 3D pour réaliser certains effets graphiques, et tenter de faire tout le rendu en logiciel peut être un gros problème (j'en sais quelque chose, puisque la version de WebKit pour Haiku fonctionne ainsi). Je ne sais pas dans quelle mesure l'intégration de Javascript changera les choses pour NetSurf, car actuellement le DOM (le modèle de la page) est statique et donc le rendu peut être fait en une seule fois. Avec Javascript, la page peut être modifiée à tout moment et cela a de nombreuses conséquences.
Je n'ai pas branché mon Amiga depuis bien longtemps, et il a plus de RAM que ça (poussé à 128Mo mais avec un vénérable 68040 à 40MHz). Ilfaudra que je voie ce que ça donne. Si j'ai le temps un jour je me lancerai peut être à faire fonctionner NetSurf sous Windows 3.11 avec Win32S, par curiosité archéologique :)
# Errata
Posté par pulkomandy (site web personnel, Mastodon) . En réponse à la dépêche Le navigateur Web NetSurf publie sa version 3.8. Évalué à 2.
On m'informe que l'entreprise qui a sponsorisé NetSurf s'appelle Codethink, sans T majuscule. Si quelqu'un peut corriger, ça serait super.
# Licence
Posté par pulkomandy (site web personnel, Mastodon) . En réponse à la dépêche Libération du code source de muzi.ch, quelle licence ?. Évalué à 10.
Le choix de la licence est un peu personnel, ça dépend de ce que tu veux que ce projet devienne.
La GPL n'est pas vraiment pertinente vu qu'il s'agit d'un site web (légalement, les visiteurs ne sont pas considérés comme des utilisateurs et donc le système de copyleft de la GPL ne s'applique pas). Si tu veux une licence copyleft, la licence Affero est donc un bon choix.
Sinon, une licence MIT, simple, efficace, et bien connue. Elle semble être une bonne façon de laisser quelqu'un d'autre (ou une plus grosse équipe) prendre le code et en faire ce qu'ils veulent. Il faudra leur faire confiance pour que leurs évolutions restent libres, par contre, car il n'y aura pas d'obligation contractuelle.
Merci en tout cas de publier les sources, même si elles ne sont pas "présentables". J'espère que ton travail ne sera pas perdu et connaîtra une nouvelle vie grâce à ça.
# Mouais
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au lien De la laideur des logos et interfaces dans le libre. Évalué à 10.
Encore une généralisation. Tous les logiciels FLOSS seraient pareil, développés par les mêmes 12 hackers socialement incapables avec un humour de merde.
Je sais pas, faisons un tour parmi les logiciels propriétaires. Pas les gros trucs développés par Apple ou Google, qui eux aussi ont parfois des logos pas si moches que ça (encore que ça vieillit pas toujours très bien). Mais prenons plutôt du bon vieux shareware:
https://www.anvilstudio.com (une enclume sur un clavier de piano)
https://www.entechtaiwan.com/util/multires.shtm (des engrenages tout moches)
https://antibody-software.com/web/software/software/wizmouse-makes-your-mouse-wheel-work-on-the-window-under-the-mouse/ (euh… je n'arrive même pas à comprendre ce que c'est)
Bon, la liste est sûrement très longue mais je n'utilise plus assez Windows pour en connaître tant que ça. Donc, en dehors des gros trucs qui ont des sous pour se payer un designer, il y a des trucs moches et pas libre partout. Et niveau interface utilisateur, y'a qu'à regarder n'importe quelle UI d'antivirus ou de driver d'imprimante.
Le problème est ailleurs: il n'y a pas assez de designers qui contribuent aux logiciels libres. On ne peut pas demander aux développeurs de faire le job, il faut quelqu'un qui connaisse le métier. En attendant, on se débrouille comme on peut. Et non, on est pas forcément tous fiers d'avoir des logos moches.
# Paquets -off
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au lien Weboob a failli changer de nom dans Debian. Évalué à 5. Dernière modification le 27 août 2018 à 11:37.
Il y a toujours dans Debian des paquets -off (pour "offensive") avec des fortunes insultantes ou inappropriées, et une partie des questions de purity (le quizz qui évalue la "pureté" d'une personne):
https://packages.debian.org/search?keywords=-off&searchon=names&suite=stable§ion=all
Et je viens de découvrir cowsay-off, avec de l'ASCII art zoophile. Classe.
Alors bon, le nom du paquet weboob, c'est peut-être pas le truc le plus important?
# YouCompleteMe
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal vim: Au revoir syntastic, bonjour ALE. Évalué à 3.
J'utilise de plus en plus YouCompleteMe, qui fonctionne sous forme d'un démon en arrière plan (lancé par vim de façon transparente) et fournit à la fois le soulignement des erreurs de syntaxe et autres problèmes, et la complétion automatique.
Je ne l'ai testé qu'en C et C++ pour l'instant, mais il sait faire ça pour plusieurs langages, dont Python.