Moonz a écrit 3542 commentaires

Parce que master est supposé être périodiquement renvoyé sur origin. Or, si un cycle pull — merge — push ne pose aucun souci, un cycle pull — rebase — push peut très bien changer le hash d’un commit qui a déjà été push, ce que le remote origin apprécie moyennement.

Un rebase qui pète la synchro entre ton dépôt local et la branche distante t’oblige à supprimer la branche distante, ce qui est rarement un problème pour les branches de fonctionnalité (qui sont d’ailleurs assez souvent purement locales jusqu’au tout dernier moment), mais qui pour master peut être catastrophique quand plusieurs devs bossent sur le même origin/master.

Github marche bien quand on est toujours dedans

Github marche aussi très bien pour les mainteneurs qui décident de mettre en place à côté des canaux plus classiques type mailing-list. Github marche bien aussi quand on est pas toujours dedans.

Que certains mainteneurs décident de se passer de ces canaux plus classique n’est pas la faute de github mais bien plus la supériorité du workflow github du point de vue des-dits mainteneurs. Et que ce soit github ou autre (oui, je reconnais parfaitement que certains mainteneurs préfèrent d’autres workflows que github :)), ça me paraît normal que ce sot le mainteneur qui définisse le workflow qu’il préfère — après tout c’est lui qui a à gérer des patchs tous les jours.

J'ai essayé l'autre jour de patcher des bugs dans un projet hébergé par github. Au début, je fais un rapport de bug, me disant que je vais y uploader mon patch (correctement formaté avec git format-patch origin/master). Ah pas possible. On peut seulement uploader des images. Sérieux?!

Gist est fait pour ce genre de choses.

(on peut même pas faire une demande par commits, mais pour tous les commits d'une branche donné. Uh?!). Sérieux, on trouve ça plus simple?!?

Ben… oui.

Dans le workflow git (git en général, pas github) conseillé par 99% des gens (statistiques Bullshit©), les patchs sont supposés se faire dans des branches à part, et les merge se faire en mergant des branches, pas des patchs individuels à coup de cherry-pick. Et c’est pas pour faire joli :
- c’est vachement plus simple pour rebase (rebase sur master c’est une très très mauvaise idée)
- c’est vachement plus simple pour gérer les dépendances entre fonctionnalités
- c’est vachement plus simple pour git log branch1..branch2

combien de fois (des dizaines!) je me suis retrouvé sur un projet github à me demander s'il s'agit de l'upstream ou non. Pour des petits projets, un moteur de recherche peut répondre plusieurs pages github et la première n'est régulièrement pas l'upstream.

Heu… tu vas sur https://github.com/joincamp/flp.mobi/ par exemple, et juste en dessous du nom tu as « forked from fmap/flp.mobi ». Tu vas sur https://github.com/joincamp/flp.mobi/network/members et tu as le graphe des forks, avec l’upstream en tant que racine de l’arbre. Le seul truc un peu mal fait c’est que c’est pas clair du tout pour un mainteneur de dire « je passe la maintenance à x » (je sais même pas si c’est possible autrement que par un README en fait). Mais c’est pas tellement dramatique dans la mesure ou tu peux autoriser celui à qui tu passes le lead à push dans ton dépot :)

Pareil ici.

Mon but c’est d’avoir un environnement qui me convient. Quand je rencontre un bug dans un logiciel que j’utilise, je corrige et j’envoie le patch upstream, quand une fonctionnalité me manque idem, et quand je trouve pas de projet qui correspond à mon besoin je code et je met sur mon github.

J’ajouterai que github est une petite révolution pour ce genre de petites contributions. Je fork, je corrige, je clique sur pull request, et c’est fait.

Tu as plein de mécanismes :

• Mémoire partagée
• Pipes anonymes
• Sockets unix
• Partage de descripteurs de fichiers
• msgsnd/mq_send

Et j’en oublie certainement. Tu as aussi des API multiplateformes comme 0MQ (même si de base la plupart des mécanismes ci-dessus se retrouvent de toute façon sur tous les OS majeurs).

Je vais citer un autre DLFPien qui arrive à mieux mettre en mots que moi :

Universel ne veut pas dire "accepté par tous". Universel signifie "dont la portée est générale", et autres sens plus précis encore.

Tu auras beau me parler des paraplégiques, des culs-de-jatte et des unijambistes, je continuerai à dire que l’homme est bipède. Pour contrer la proposition « pour l’espèce humaine prospérité & paix sont un bien », il ne s’agit pas de montrer des contre-exemple individuels, mais de montrer, par exemple, que la guerre est tellement mieux que la paix que les pays en guerre ont généralement un solde migratoire positif, ou que les gens fuient en masse l’horrible prospérité européenne pour aller se réfugier dans la douce pauvreté africaine.

De plus il ne faut pas confondre les intentions et les actes, ce sont les actes qui comptent, pour 100 poseurs « la guerre est noble, c’est ça qui révèle la grandeur ou la couardise chez l’individu » combien vont effectivement s’engager en tant que combattant dans un conflit, pour 100 poseurs « la richesse ne fait pas le bonheur » combien abandonnent toutes leurs possession pour aller vivre en ascètes ?

Dans le monde javascript (puisqu’on parle de XMLHttpRequest à la base) le synchrone est l’exception, l’asynchrone la règle.

Linus n’a que le « pouvoir » de décider ce qui est dans son dépôt git. Appeler ça « tout pouvoir » c’est un point de vue assez capillotracté quand même.

Pour ce qui est du noyau qui sera utilisé en vrai sur le poste utilisateur, c’est décidé par :
- Linus,
- La distribution (qui décide ou non de patcher certains trucs. Et qui peut choisir comme base autre base que Linus, comme grsec par exemple)
- L’administrateur (qui décide d’installer un noyau ck, par exemple. Et qui peut choisir sa distribution)

Les humains preferent vivre dans un quartier ou ils se font pas tirer dessus, et ils preferent avoir de la bouffe dans leur assiette que pas de bouffe.

Donc on est d’accord : la paix et la prospérité sont des biens pour les êtres humains. Or toutes les règles de conduites possibles ne sont pas également capables de conduire à la paix et à la prospérité.

Sauf nodejs, twisted, libevent,…

Tu n’as pas besoin de threads pour ne pas te bloquer : asyncio + select/epoll/autre mécanisme similaire fourni par l’OS.

De même, si Go peut utiliser plusieurs threads il peut aussi très bien tourner avec GOMAXPROCS=1 sans pour autant bloquer bêtement toutes les goroutines sur une IO/synchronisation…

J’ai un peu passé l’âge des trolls sur internet, mais j’aime bien les machines à voyager dans le temps et tu écris ce que j’aurais écrit il y a 10 ans :)

Alors petite question à mon moi d’il y a 10 ans : si on refuse l’hypothèse d’une loi/morale propre à l’espèce humaine (peu importe le nom, l’idée étant : une « bonne » façon de se conduire pour un groupe humain), comment expliquer l’observation empirique quasi-universelle que les flux migratoires se font des
- territoires en guerre vers les territoires en paix
- sociétés pauvres vers les sociétés riches
?

Programmation événementielle

Bon, puisque tu sembles avoir du mal à voir où se trouve le problème :

Mon impression, c'est que le message ne t'as pas plu donc tu essayes comme tu peux d'humilier son auteur avec tes connaissances

Traduction : tu es de mauvaise foi ; tu es incapable de te maîtriser ; tu es incapable de te montrer rationnel.

Bizarrement ça passe mal.

Bizarrement la quasi-totalité des messages de k-dyson utilisent la même rhétorique et passent très mal.

Drôle de coïncidence quand même.

MultiDeskOS

Sous Android Google a déjà un monopole des crapware.

Pour les vrais innovations selon tes termes, du devrais regarder le noyau type NT et tout ce qui a été fait avec SMB puis ensuite Active Directory

SMB: 1990
NFS: 1984

LDAP: 1971
AD: 1999

Ou alors j’ai pas bien compris les termes…

Gentoo n’impose rien du tout, j’y utilisais déjà initng il y a des années.

En quoi la place occupée sur le disque dur est-elle un problème ?

La taille sur le disque est à peu près proportionnelle à la taille du code, qui est elle-même à peu près proportionnelle au nombre de bugs.

Ne pas mettre par défaut c’est pas « laisser tomber » hein, Gnome est toujours là.

Est-ce qu'on fait un OS différent par pays? Non, on a un coeur et des paramètres de langue et région.

Bonne chance pour trouve le moindre « cœur commun » entre le français et le cantonnais.

"La ligne de commande reste indispensable pour automatiser tout ce qui est répétitif" est montrer ta non connaissance absolue du planificateur de tâche de Windows (entre autres)

Répétitif ≠ périodique.

La façon normale ou du moins celle qui est prônée pour l'avenir c'est QML avec QtQuick

Tu es sûr ?

J’ai à peine survolé le sujet, mais tous les tutoriaux QML que je vois c’est pour faire des trucs assez « primitifs » (dessine un rectangle, un rond, du texte…). Jamais vu un tutorial pour faire une application « classique » du genre KeePassX en QML avec les widgets standards de Qt (QListView par exemple).

Le gros souci de la version Java, c’est qu’il faut en faire un programme, donc :
- Un .java, avec tout le boilerplate autour (class/public static void main/les import)
- En faire un .jar
- À l’utilisation java -jar …

Bref pour un one-liner dans le genre Java c’est clairement overkill indépendamment de la question de la lisibilité du code.

Non, FileNotFound

T'as eu la même réaction quand SysV s'est imposé ?

SysV a longtemps été certes dominant mais jamais en situation de monopole. Cf init-ng et mudur par exemple (pour ceux que j’utilisais avant la systemd-mania).

De la diversité pour un système d'init. Comment dire… Tout ce que je demande à un système d'init (en gros), c'est que la machine boot sans problème. Au delà, qu'il soit SysV ou systemd importe peu.

C’est très très réducteur comme vue. Et tu n’y crois pas d’ailleurs toi-même :

• de même pour l'usage des cgroups par l'user-space

De fait si tout ce qu’on demandait à un système d’init « c’est que la machine boot sans problèmes » pourquoi s’embêter à remplacer sysvinit ? Aux dernières nouvelles les machines bootaient sans problèmes avec sysvinint hein…

d'éviter d'écrire 1000 fois a peu près le même script d'init pour le service X

systemd changera rien à l’affaire tant que la moitié des distribs nommeront apache apache2, l’autre moitié httpd, et quelques autres apache ou httpd2

Et dans l’hypothèse où les distribs arrivent à se mettre d’accord pour ce genre de choses les scripts sysv sont tout aussi portables

• N'importe qui ayant accès aux logs peut les modifier et effacer ses traces (ce qui n'est pas le cas avec journald)
• on ne peut pas mettre un core dump ou un dump de firmware avec les logs. Oh, on peut mettre ça à côté, mais ce n'est pas dans le journal binaire, le même journal qu'on veut pouvoir être lisible avec journalctl sur un autre système et authentifier facilement.
• on a pas un standard de notation des dates/heures, ce qui est particulièrement énèrvant quand on a des tonnes de log

Ça c’est pas des arguments logs textuels vs logs binaires mais format standardisé vs sans format

Moi c'est echo xterm >> ~/.bashrc (piqué de mon prof de C quand j’étais étudiant)