C'est vrai. Je pense que c'est fait exprès, mais c'est un mauvais choix à mon avis.
De mémoire, le but était de mieux toucher les gens qui se baladent juste sur le web, au détriment de la partie de leurs utilisateurs qui considèrent qu'un album est un tout.
Fait bien longtemps que j'y suis pas allé pour le coup. Ni sur dogmazic d'ailleurs.
C'est valable pour toutes les forges ça, le fait de pas pouvoir migrer les tickets par exemple (c'est la 2nd plus grosse fonctionnalité d'une forge après tout).
La seule solution au final, c'est d'embarquer les tickets dans le repo. De ce point de vue, fossil est très intéressant. Le problème, c'est juste qu'il faut apprendre a utiliser un nouvel outil, ce qui va freiner les premières contributions de la majorité des contributeurs.
Pour les autres DVCS (et notamment git), il existe divers projets pour ça, mais même si j'aime énormément l'idée (bien plus que de devoir me taper l'UI de github, tu peux me croire), je garde mes doutes sur les implémentations (par exemple, devoir installer la pile ruby pour ça me gêne énormément).
Il faudrait que je reprenne un peu le temps de regarder d'ailleurs.
Il est quand même moins probable que, par exemple, google oublie de payer son domaine que toi ou moi. Ou que leur compte bancaire soit fermé suite a bronsonisation du propriétaire.
Pour le fait de leur politique, c'est clairement un fait, surtout pour google. D'ailleurs ils avaient leur propre forge pendant un temps, mais je pense que peu de monde avait vraiment envie d'héberger leur code chez eux, pour entre autres cette raison que tu cites.
D'une manière ou d'une autre, il n'y a vraiment que la réplication qui puisse freiner le problème de la disparition des sources.
Le fait que ce soit maintenant impossible ou presque de faire des recherches par album.
Leur "nouveau" site est anti-ergonomique pour qui veut écouter un album, mais, j'accepte que c'est un choix.
Pour ce qui est de Dogmazic, en revanche, ça s'est amélioré, même si c'est toujours pas ça (c'est un peu de ma faute, je pourrais p'tet aider, même si je suis une bite ((ouai, c'est fait exprès pour rappeler que non, les références au mâle ne sont pas toujours positives)) en frontal).
Il faut dire que dogmazic est un site commercial, ils ont besoin de revenus, et c'est normal. Je ne leur en veux pas.
D'un autre côté, ni l'un ni l'autre ne suivent vraiment le libre, dans le sens ou il est rare que les sources (partitions, paroles, etc) soient fournies avec.
Il s'agit d'ailleurs d'un problème récurrent pour les gens qui font des jeux vidéo libres (je ne fais que contribuer): rares sont les ressources.
Personnellement ça m'est déjà arrivé de renoncer à rapport un bug ou de proposer un correctif, par ce que j'étais en train de faire autre chose en même temps et que j'avais la flemme de créer un compte sur un n-ième site (oui je sais, c'est pas bien).
Pareil.
D'un autre côté, j'ai le même effet maintenant avec github en vrai, parce que j'ai tendance a caler mon patch dans (ou en pièce jointe à) la réponse, et a chaque fois, même si ça améliore les choses, il faut faire 20 aller-retours pour qu'il soit accepté, pour des questions de code-style (jamais documenté), qui auraient été plus rapidement patchées via un simple de l'auteur.
Pour moi, ce n'est pas que MS soit l'actuel proprio de GH le problème, le problème c'est la bureaucratie inhérence à la façon de gérer les projets par "push-request".
Ça ne date pas du rachat, hein.
Mais ça a toujours été plus proche de la cathédrale que du bazar sur lequel, notamment, linux et ses distributions sont bâties.
Et dans le cas des cathédrales, les BSDs ont prouvé qu'héberger sa forge est efficace, mais ce type de forges se basent sur les échanges de mails.
Je sais que je diverge du sujet initial, mais, la dépendance aux interfaces web je la vit assez mal perso, et toi?
La migration sous Gitlab n'a pas l'air si simple, si on en croit le projet PeerTube,
Et qu'en est-il de l'inverse?
De GL ou GH vers d'autres forges moins populaires?
Qu'en est-il aussi des raisons? Techniques? Une BDD c'est toujours chiant a migrer c'est évident, les logiciels sont pas conçus de la même manière…
Par ailleurs, le fait d'avoir l'intégralité des projets centralisée facilite grandement l'analyse statistique des projets, sans avoir a dupliquer une multitude de dépôts de sources différentes.
Hein?
on ne peut pas lancer sa propre instance de Github, contrairement à Gitlab
Et tu ne peux pas instancier ton instance gitlab chez toi sans faire tourner de code proprio. A moins que, et ça me surprendrais, l'instance publique ne fasse tourner que du code sous Affero GPL?
Enfin, je me permets de penser que si, le fait d'appartenir à Microsoft, dont l'historique anti-LL est particulièrement lourd, est un problème. Malgré la communication intense que cette entreprise déploie pour nous convaincre que "Microsoft loves Linux"…
Ça s'appelle du bullshit chez moi. Moi, je suis un techie bas de gamme, je n'accepte que les arguments efficaces, mes parents ont oublié de m'installer le plugin pour regarder la marque avant de critiquer.
Github est aujourd'hui en situation de quasi monopole pour l'hébergement des projets libres.
Ben, tout le monde a tapé sur Sourceforge (qui héberge cela dis toujours les gros fichiers de bien des projets dont le dev se fait sur GH ou GL hein…) donc on l'exclue.
Y'a quoi d'autre? GitLab? Pas monopole, certes, mais mais 100% libre non plus, leur plateforme n'utilise pas la version libre.
Au final, le but des utilisateurs de GH, c'est de réduire le taux d'emmerdement des nouveaux contributeurs et des développeurs.
Pas besoin d'un Nième compte, pas besoin de s'emmerder a déployer une archi, quitte a se retrouver prisonnier d'une interface qui… disons, «force» une politique de développement.
Sur ce point, je préférais perso sourceforge: il était simple d'avoir des mailings lists publiques, ce qui impliquais donc que les contributeurs n'étaient pas traqués par le site.
Il y avait aussi des forums, bien plus simple d'accès aux béotiens, et bien d'autres fonctionnalités que GH est loin d'égaler a mes yeux.
Github appartient à Microsoft, qui le rentabilisera d'une façon ou d'une autre.
Lol.
Qui le rentabiliseras?
Ben oui, mais ou est le problème? L'open source, c'est pas juste du "hey, je paye 1) mon temps et 2) mon fric pour que vous puissiez utiliser mon logiciel! Et en plus, je fait la hotline gratos, et me fais insulter for fun!"
Pour info, la boîte derrière GH n'a jamais publié le code hein, ça n'a jamais rien eu à voir avec du libre.
Ils savent comment rentabiliser, et, en gros, le libre leur sers de pub gratos.
Tout comme ce que faisait sourceforge avant de perdre de la vitesse.
Sauf que, limite, sourceforge est plus libre: le soft d'origine est le même que celui utilisé par savannah. On a pas accès à l'histo de dev, certes, mais on a au moins accès a une partie de l'histoire (ça reste non libre selon moi).
Gitlab est sûrement ce que tu préférerais? C'est du libre en partie seulement.
Surtout ce qui est utilisé par leur forge publique et "gratuite".
Bitbucket?
Comme GH, et a une époque meilleure interface, mais ils ont choisi de la bloat, il faut maintenant plusieurs secondes avec un meilleurs hard et une meilleure connection pour charger chaque page.
Perso j'ai jamais aimé GH, mais je le trouve aujourd'hui plus supportable que la bouse qu'est devenue BB.
S'auto-héberger? T'auras moins de contributeurs, et en plus, faut gérer la technique (déployer une forge logicielle, se protéger contre les attaques, etc) et la loi (GPDR par exemple, mais aussi hadopi et bien d'autres).
Tous ces éléments combinés en font une menace pour l'avenir des logiciels libres. Certains projet sont bloqués sur Github, car leur historique et/ou leur encours de tickets n'est pas facile à migrer sur d'autres plateformes. Mais un "nouveau" (si on peut dire :-)) projet peut, devrait oserais-je dire, opter pour une alternative moins centralisée, monopolistique, aux mains du grand méchant crosoft.
Donne une seul argument réel de menace sur le libre, pour voir? git est, de base, décentralisé.
De nombreux (mais assez a mon goût) projets utilisent GH comme mirroir.
Au pire, même si tu ne me convaincs pas du mal que représentes GH (ça va être dur, je déteste déjà ce site), que proposes-tu?
Dis nous, comment faire?
Comment faire pour gratuitement exposer notre code a nous dev libristes sans mettre 2 ans a attendre l'approbation d'un quelconque projet?
Je t'écoutes, parce que je suis justement en train de monter mon propre serveur pour héberger mes projets perso. Qui n'auront pour seule interface de l'extérieur qu'un simple mail et un http(s) qui crache l'arbo du git.
Surtout quand on voit l'usine à gaz qu'est l'implémentation par debian de rc.d… pour chaque service, ce sont des milliers de lignes de bourne shell qui sont exécutées, réparties dans je ne sais plus combien de fichiers disséminés un peu partout…
Pour le coup, de ce côté, son discours est très étrange…
D'une part, il râle parce qu'avant il fallait jouer avec udev pour avoir des noms fiables:
Le noyau Linux a eu la bonne idée depuis des lustres de nommer les interfaces Ethernet en eth. Premier problème, d'une version à une autre, l'énumération ne se faisait pas forcément dans le même sens.
Puis il râle que udev renomme les interfaces (en accusant une MàJ kernel, quand même…)
Plus récemment, les noms de périphériques ont été changés et ce qui était eth0 a pu devenir au gré d'une mise à jour de noyau enp0s31f6, ce qui était très pratique pour les gens qui utilisaient un firewall bloquant tout par défaut sur une machine à distance. Mais encore, en lisant la documentation et en acceptant d'ouvrir un peu tous les ports le temps de la migration, il était possible de s'en tirer.
Et enfin il râle que systemd re-renomme les interfaces:
Vous noterez qu'il n'y a plus de eth0 mais un lan0. Pourquoi ? Parce que cette saleté de systemd a décidé depuis sa dernière mouture d'entrer en conflit avec le renommage des interfaces par udev
Bon, en fait, je crois que son propos ici c'est que c'est le kernel qui devrais le faire. Ce qui est en soit défendable. Personnellement je ne sais pas vraiment comment udev fait pour exposer les noms des interfaces réseau, donc je ne jugerai pas sur ce point (faudrait que je creuse le sujet un jour).
D'un autre côté, si c'est réparable mais que les pièces sont introuvables (ou fournies par un seul fournisseur, ça reviens presque au même)…
Tant que les interfaces ne sont pas standardisées, ça sera toujours la même merde.
En fait, même juste avoir la documentation technique de l'interface (hard & soft, ce qui inclue le protocole de communication le cas échéant) serait déjà une sacrée évolution! On peut toujours rêver…
Pas trop envie de m'étendre sur mon opinion de systemd, ça n'apporterais rien. Je préfère apporter des solutions aux «problèmes» soulevés par cette personne, ça me semble plus constructif.
Je note personnellement que l'auteur du billet n'est pas aussi compétent qu'il veut le faire croire avec Debian.
1: le meta-paquet "init" dépends, au choix, de:
systemd-sysv aka systemd (oui, le nom est a chier, probablement un héritage du fait que lors de l'introduction ça dépendait de sysv-rc);
sysvinit-core aka sysvinit qui dépend de sysv-rc;
runit-init aka… bah, runit, ui dépend de sysv-rc pour une raison simple: il faut du temps pour implémenter un système d'init complet (de mémoire, dans Jessie systemd-sysv aussi en dépendait);
2: si la séparation de / et /usr lui est si chère, pourquoi ne pas conserver cette séparation?
Pour ce qui est du point 1, le seul truc que je peux regretter est l'absence de nosh dans la liste, j'aurait bien aimé qu'on me mâche le boulot avec celui-la, ça m'aurait permis de le découvrir in-situ.
Parmi ses avantages supposés (de mémoire):
possibilité de convertir les unit systemd en scripts nosh
un "DSL shell" (pour domain specific language shell, l'appellation est de moi)
correction du problème "thundering herd solution" qui est l'apanage des héritiers des daemon tools
mais faut que lise la doc, donc la flemme :)
Je reconnais que, pour ne pas avoir systemd installé par défaut (et donc devoir le désinstaller via apt après l'install) et/ou pour conserver la séparation de / et /usr il faut passer par une procédure plus complexe:
démarrer sur l'iso
ne pas sélectionner "install" mais "rescue"
Une fois dans le "rescue mode", il faut ensuite faire l'installation de la façon qui se fait sur d'autres distributions, qui ciblent des utilisateurs avancés (ça tombe bien, il semble en être un!): préparer le système cible, utiliser deboostrap avec les paramètres qui vont bien, configurer le système, configurer le bootloader.
Oui, c'est compliqué, mais plutôt que râler, il aurait été plus efficace de rappeler que c'est possible, j'ai émis plusieurs journaux sur ce genre de manipulations, donc en fouillant il devrais même ne pas avoir trop de boulot a faire pour construire son propre script.
Mais non, comme «tous» les «anti-systemd»(1) il préfère râler en ignorant (volontairement?) le fait que systemd est loin d'être obligatoire, surtout sur la distribution dont il parle qui propose quand même 2 alternatives pour ceux qui le veulent!
Et, vraiment? 1Go de RAM pour systemd?
Heureusement que ça n'est pas vrai, parce que sinon cette collection d'outils, qui nécessiterait sur mon système l'usage de 14.4Mio de disque, doit leak quelque chose de bien! Pas crédible.
Oui, systemd est plus gourmand en ressources.
C'est normal: il gère réellement les processus, il ne se contente pas de les lancer et faire comme si ça ne plante jamais!
D'ailleurs, c'est encore plus important sur un système embarqué qui va se retrouvé exposé a des conditions bien éloignée du labo. J'ai déjà vu un système freezer par le simple fait de recevoir un appel téléphonique trop près (bon, dans ce cas, c'était le hard qui partait en couilles, certes, il aurait fallu un watchdog hard, mais bon…)!
Par contre, je serais curieux de savoir la consommation mémoire (réelle) de systemd. Dans le cas de runit compilé avec glibc, j'ai:
Dans la plupart des instances de runsv, svlogd, runit et runsvdir, RSS chute a 4 dans le cas d'une compilation avec musl. Je ne sais pas pourquoi certaines instances de runsv montent a plus d'1Mo…
Si quelqu'un peut mesurer l'impact de systemd compilé avec glibc ou mieux, si possible, avec musl?
Bon, sur la plupart des machines, ces quelques megs de mémoire consommés ne sont pas gênant, mais je me dis que sur de l'embarqué très serré (genre, avec moins de 64Mo de RAM, comme certains routeurs ou autres) ça peut compter.
Perso, je vois surtout le fait que je serais capable de lire et maintenir le code de runit si besoin est, alors que ce n'est pas le cas pour systemd.
1: dont, techniquement, je fais partie puisque je n'utilise pas cet init. Cela dis, je préférerais utiliser systemd que revenir à sysvinit + rc.d, sans hésitation, surtout sur des machines sur lesquelles je n'ai pas la possibilité d'avoir un accès physique!
Je trouve l'info intéressante perso, sur le plan scientifique. Je ne sais pas a quoi ça sert, certes, mais ça montre qu'on s'améliore, et ça fait rêver. Je crois que c'est important pour les gens qui veulent ou doivent créer de nouvelles choses, de repousser les limites.
Je doute que la boîte ait disparu de son plein gré, donc, tu ne peux qualifier l'obsolescence de programmée.
Ceci étant dit, a l'origine, la raison d'être des brevets était de justement protéger la civilisation de telles pertes, que les plans soient a tout jamais disponibles, et en échange l'inventeur de la méthode était rémunéré. Il me semble évident que les lois actuelles sont contre cet objectif, vu qu'il semble qu'il n'y ai plus d'obligation de donner les fichiers d'origine a une autorité de contrôle, qui soit capable de les rediffuser en cas de mort de l'inventeur.
C'est bien d'ailleurs pour ça que je pense que le libre est important.
En fait, j'ai une question qui est sûrement très bête.
Il m'est arrivé, comme a d'autres ici je pense, de devoir travailler en "mode sans échecs", "mode mono utilisateur", en gros dans des modes dégradés sur lesquels ont peut faire a peu près tout ce qu'on veut, tant qu'on sait se passer de confort.
Dans mon cas, j'ai utilisé linux pour du… disons, embarqué (ni baremetal, ni temps réel) pour des équipements de ville par exemple, qui ont un écran tactile, dédié a une seule application.
Au début, ma boîte du moment est partie sur l'idée d'utiliser electronJS. Au bout de quelques mois, après le départ du développeur qui avait tout fait, on s'est aperçu qu'il y avait de nombreux crashs (oui, je sais) notamment des SIGILL. Ça, et le fait que Xorg et les scripts que j'ai bricolés étaient assez… aléatoires… concernant la gestion de l'orientation de la dalle graphique et celle de la dalle tactile (non, les dev logiciels ne sont pas les rois).
Ça s'est fini a ce que je doive me farcir la gestion de l'UI, et vu que ni Xorg ni SDL ne permettaient de faire les choses facilement, je suis revenu a du bon vieux framebuffer + libinput (tellement plus simple, d'accéder direct a la mémoire et de faire une lib, dans ces cas, que de passer par 36 couches d'abstractions).
Qu'en est-il également des
Tout ça m'a amené a penser qu'une alternative portable et portée à d'autres systèmes serait plutôt sympa, et je me demandais si Haiku offrait ou planifiait ce genre de choses?
Je me pose aussi la question sur la question des syscalls. J'imagine qu'ils sont en C, sinon ça serait se fermer aux autres langages ou leur ajouter une couche de compat? Si c'est du C++, alors, comment vous gérez l'absence de specs d'ABI? N'y aurat-il qu'un seul compilo "autorisé"?
Navigateurs: le navigateur natif WebPositive (utilisant WebKit) et divers navigateurs utilisant QtWebKit (Otter, Dooble, …). Pas de version de Chrome ou Firefox en vue, il faut demander à Google et Mozilla qu'ils se décident enfin à s'en occuper.
Voila qui m'intrigue.
Je comptais repartir derechef, mais… au final, le moteur de chromium et gecko sont moins simples a embarquer, porter et maintenir que webkit?
Peut-être un effet secondaire de la taille des captures par rapport a la taille du texte? N'est-il pas possible d'avoir des miniatures qui lient vers le lien d'une image plus grosse? (vraies questions, même si je repart derechef)
C'est vraiment si moche? Je serais heureux que tu me montre par l'exemple, ça servira potentiellement a plein de gens.
C'est vrai, qui suis-je au fond, pauvre libriste qui ose publier du code si sale que personne ne publie la version correcte?
C'est triste, mais ici, soit les gens mettent des liens githubs, dont le côté libre est discutable, soit on se fait limite démolir pour avoir osé ne pas être parfait..
Pardon mais moi, j'aime pas le libre parce que c'est du code parfait, mais parce que c'est du code que les autres peuvent améliorer. Sans se baser sur une base propriétaire comme github ou gitlab.
Je veux être libre de filer mon code a qui je veux, c'est a dire: tout le monde, même si c'est mauvais, certains apprendront, et moi je lirais leurs articlcles… techniques, et non politiques, ça me changera!
[^] # Re: Diablo Swing Orchestra
Posté par freem . En réponse à la dépêche Sortie de Cover Thumbnailer v0.10.0. Évalué à 3.
De mémoire, le but était de mieux toucher les gens qui se baladent juste sur le web, au détriment de la partie de leurs utilisateurs qui considèrent qu'un album est un tout.
Fait bien longtemps que j'y suis pas allé pour le coup. Ni sur dogmazic d'ailleurs.
[^] # Re: (HS) Github
Posté par freem . En réponse à la dépêche Sortie de Cover Thumbnailer v0.10.0. Évalué à 3.
C'est valable pour toutes les forges ça, le fait de pas pouvoir migrer les tickets par exemple (c'est la 2nd plus grosse fonctionnalité d'une forge après tout).
La seule solution au final, c'est d'embarquer les tickets dans le repo. De ce point de vue, fossil est très intéressant. Le problème, c'est juste qu'il faut apprendre a utiliser un nouvel outil, ce qui va freiner les premières contributions de la majorité des contributeurs.
Pour les autres DVCS (et notamment git), il existe divers projets pour ça, mais même si j'aime énormément l'idée (bien plus que de devoir me taper l'UI de github, tu peux me croire), je garde mes doutes sur les implémentations (par exemple, devoir installer la pile ruby pour ça me gêne énormément).
Il faudrait que je reprenne un peu le temps de regarder d'ailleurs.
[^] # Re: (HS) Github
Posté par freem . En réponse à la dépêche Sortie de Cover Thumbnailer v0.10.0. Évalué à 3.
Il est quand même moins probable que, par exemple, google oublie de payer son domaine que toi ou moi. Ou que leur compte bancaire soit fermé suite a bronsonisation du propriétaire.
Pour le fait de leur politique, c'est clairement un fait, surtout pour google. D'ailleurs ils avaient leur propre forge pendant un temps, mais je pense que peu de monde avait vraiment envie d'héberger leur code chez eux, pour entre autres cette raison que tu cites.
D'une manière ou d'une autre, il n'y a vraiment que la réplication qui puisse freiner le problème de la disparition des sources.
[^] # Re: MADNESS
Posté par freem . En réponse au sondage et si c'était à refaire ?. Évalué à 2.
C'est un peu le but :)
[^] # Re: Diablo Swing Orchestra
Posté par freem . En réponse à la dépêche Sortie de Cover Thumbnailer v0.10.0. Évalué à 4.
Son évolution, ironiquement.
Le fait que ce soit maintenant impossible ou presque de faire des recherches par album.
Leur "nouveau" site est anti-ergonomique pour qui veut écouter un album, mais, j'accepte que c'est un choix.
Pour ce qui est de Dogmazic, en revanche, ça s'est amélioré, même si c'est toujours pas ça (c'est un peu de ma faute, je pourrais p'tet aider, même si je suis une bite ((ouai, c'est fait exprès pour rappeler que non, les références au mâle ne sont pas toujours positives)) en frontal).
Il faut dire que dogmazic est un site commercial, ils ont besoin de revenus, et c'est normal. Je ne leur en veux pas.
D'un autre côté, ni l'un ni l'autre ne suivent vraiment le libre, dans le sens ou il est rare que les sources (partitions, paroles, etc) soient fournies avec.
Il s'agit d'ailleurs d'un problème récurrent pour les gens qui font des jeux vidéo libres (je ne fais que contribuer): rares sont les ressources.
[^] # Re: (HS) Github
Posté par freem . En réponse à la dépêche Sortie de Cover Thumbnailer v0.10.0. Évalué à 3.
Pareil.
D'un autre côté, j'ai le même effet maintenant avec github en vrai, parce que j'ai tendance a caler mon patch dans (ou en pièce jointe à) la réponse, et a chaque fois, même si ça améliore les choses, il faut faire 20 aller-retours pour qu'il soit accepté, pour des questions de code-style (jamais documenté), qui auraient été plus rapidement patchées via un simple de l'auteur.
Pour moi, ce n'est pas que MS soit l'actuel proprio de GH le problème, le problème c'est la bureaucratie inhérence à la façon de gérer les projets par "push-request".
Ça ne date pas du rachat, hein.
Mais ça a toujours été plus proche de la cathédrale que du bazar sur lequel, notamment, linux et ses distributions sont bâties.
Et dans le cas des cathédrales, les BSDs ont prouvé qu'héberger sa forge est efficace, mais ce type de forges se basent sur les échanges de mails.
Je sais que je diverge du sujet initial, mais, la dépendance aux interfaces web je la vit assez mal perso, et toi?
[^] # Re: Diablo Swing Orchestra
Posté par freem . En réponse à la dépêche Sortie de Cover Thumbnailer v0.10.0. Évalué à 2.
Han j'avais pas tilté!
Bien vu!
D'ailleurs, si tu as un remplaçant pour jamendo, voire un site ou je pourrais retrouver les artistes que j'y ai découvert, je suis preneur…
[^] # Re: (HS) Github
Posté par freem . En réponse à la dépêche Sortie de Cover Thumbnailer v0.10.0. Évalué à 1. Dernière modification le 15 juillet 2020 à 20:45.
Et qu'en est-il de l'inverse?
De GL ou GH vers d'autres forges moins populaires?
Qu'en est-il aussi des raisons? Techniques? Une BDD c'est toujours chiant a migrer c'est évident, les logiciels sont pas conçus de la même manière…
Hein?
Et tu ne peux pas instancier ton instance gitlab chez toi sans faire tourner de code proprio. A moins que, et ça me surprendrais, l'instance publique ne fasse tourner que du code sous Affero GPL?
Ça s'appelle du bullshit chez moi. Moi, je suis un techie bas de gamme, je n'accepte que les arguments efficaces, mes parents ont oublié de m'installer le plugin pour regarder la marque avant de critiquer.
[^] # Re: (HS) Github
Posté par freem . En réponse à la dépêche Sortie de Cover Thumbnailer v0.10.0. Évalué à 4.
Ben, tout le monde a tapé sur Sourceforge (qui héberge cela dis toujours les gros fichiers de bien des projets dont le dev se fait sur GH ou GL hein…) donc on l'exclue.
Y'a quoi d'autre? GitLab? Pas monopole, certes, mais mais 100% libre non plus, leur plateforme n'utilise pas la version libre.
Au final, le but des utilisateurs de GH, c'est de réduire le taux d'emmerdement des nouveaux contributeurs et des développeurs.
Pas besoin d'un Nième compte, pas besoin de s'emmerder a déployer une archi, quitte a se retrouver prisonnier d'une interface qui… disons, «force» une politique de développement.
Sur ce point, je préférais perso sourceforge: il était simple d'avoir des mailings lists publiques, ce qui impliquais donc que les contributeurs n'étaient pas traqués par le site.
Il y avait aussi des forums, bien plus simple d'accès aux béotiens, et bien d'autres fonctionnalités que GH est loin d'égaler a mes yeux.
Lol.
Qui le rentabiliseras?
Ben oui, mais ou est le problème? L'open source, c'est pas juste du "hey, je paye 1) mon temps et 2) mon fric pour que vous puissiez utiliser mon logiciel! Et en plus, je fait la hotline gratos, et me fais insulter for fun!"
Pour info, la boîte derrière GH n'a jamais publié le code hein, ça n'a jamais rien eu à voir avec du libre.
Ils savent comment rentabiliser, et, en gros, le libre leur sers de pub gratos.
Tout comme ce que faisait sourceforge avant de perdre de la vitesse.
Sauf que, limite, sourceforge est plus libre: le soft d'origine est le même que celui utilisé par savannah. On a pas accès à l'histo de dev, certes, mais on a au moins accès a une partie de l'histoire (ça reste non libre selon moi).
Gitlab est sûrement ce que tu préférerais? C'est du libre en partie seulement.
Surtout ce qui est utilisé par leur forge publique et "gratuite".
Bitbucket?
Comme GH, et a une époque meilleure interface, mais ils ont choisi de la bloat, il faut maintenant plusieurs secondes avec un meilleurs hard et une meilleure connection pour charger chaque page.
Perso j'ai jamais aimé GH, mais je le trouve aujourd'hui plus supportable que la bouse qu'est devenue BB.
S'auto-héberger? T'auras moins de contributeurs, et en plus, faut gérer la technique (déployer une forge logicielle, se protéger contre les attaques, etc) et la loi (GPDR par exemple, mais aussi hadopi et bien d'autres).
SourceHut? Faut payer, ou s'auto-héberger.
Donne une seul argument réel de menace sur le libre, pour voir? git est, de base, décentralisé.
De nombreux (mais assez a mon goût) projets utilisent GH comme mirroir.
Au pire, même si tu ne me convaincs pas du mal que représentes GH (ça va être dur, je déteste déjà ce site), que proposes-tu?
Dis nous, comment faire?
Comment faire pour gratuitement exposer notre code a nous dev libristes sans mettre 2 ans a attendre l'approbation d'un quelconque projet?
Je t'écoutes, parce que je suis justement en train de monter mon propre serveur pour héberger mes projets perso. Qui n'auront pour seule interface de l'extérieur qu'un simple mail et un http(s) qui crache l'arbo du git.
[^] # Re: Je ne sais pas si j'oserais…
Posté par freem . En réponse au sondage et si c'était à refaire ?. Évalué à 2. Dernière modification le 15 juillet 2020 à 20:16.
Mais tu ne refais pas la même chose quand tu sais ce qu'il va arriver par expérience, puisque tu n'es pas dans le même état.
[^] # Re: MADNESS
Posté par freem . En réponse au sondage et si c'était à refaire ?. Évalué à 3.
Certes, mais le problème viens du fait que tu ne refais pas dans des conditions identiques :)
Cela dit, bien dit.
[^] # Re: je klaxonne.
Posté par freem . En réponse au sondage et si c'était à refaire ?. Évalué à 2.
klaxonnes-tu?
[^] # Re: le principe "KISS" est-il devenu obsolète?
Posté par freem . En réponse au lien Grandeur et décadence de Linux (et j'ajoute: sic transit Linux regnum). Évalué à 3.
Surtout quand on voit l'usine à gaz qu'est l'implémentation par debian de rc.d… pour chaque service, ce sont des milliers de lignes de bourne shell qui sont exécutées, réparties dans je ne sais plus combien de fichiers disséminés un peu partout…
[^] # Re: circulez...
Posté par freem . En réponse au lien Grandeur et décadence de Linux (et j'ajoute: sic transit Linux regnum). Évalué à 2.
Pour le coup, de ce côté, son discours est très étrange…
D'une part, il râle parce qu'avant il fallait jouer avec udev pour avoir des noms fiables:
Puis il râle que udev renomme les interfaces (en accusant une MàJ kernel, quand même…)
Et enfin il râle que systemd re-renomme les interfaces:
Bon, en fait, je crois que son propos ici c'est que c'est le kernel qui devrais le faire. Ce qui est en soit défendable. Personnellement je ne sais pas vraiment comment udev fait pour exposer les noms des interfaces réseau, donc je ne jugerai pas sur ce point (faudrait que je creuse le sujet un jour).
[^] # Re: arandr / xrandr
Posté par freem . En réponse au message Forcer l'affichage sur 2/3 de l'écran. Évalué à 3.
J'ai trouvé un post qui semble détailler comment faire ici.
En gros, il s'agit d'utiliser la commande
--transformdexrandr.Dans l'exemple donné (qui est compliqué parce qu'il fait d'autres trucs au passage):
xrandr | awk '$2~/connected/{ print $1 }'Bon courage pour trouver la transformation correcte (les joies des transformations matricielles…).
[^] # Re: Conditionnel
Posté par freem . En réponse au lien L’Europe pourrait instaurer un droit à la réparation des smartphones dès 2021. Évalué à 2.
D'un autre côté, si c'est réparable mais que les pièces sont introuvables (ou fournies par un seul fournisseur, ça reviens presque au même)…
Tant que les interfaces ne sont pas standardisées, ça sera toujours la même merde.
En fait, même juste avoir la documentation technique de l'interface (hard & soft, ce qui inclue le protocole de communication le cas échéant) serait déjà une sacrée évolution! On peut toujours rêver…
[^] # Re: le principe "KISS" est-il devenu obsolète?
Posté par freem . En réponse au lien Grandeur et décadence de Linux (et j'ajoute: sic transit Linux regnum). Évalué à 5.
Pas trop envie de m'étendre sur mon opinion de systemd, ça n'apporterais rien. Je préfère apporter des solutions aux «problèmes» soulevés par cette personne, ça me semble plus constructif.
Je note personnellement que l'auteur du billet n'est pas aussi compétent qu'il veut le faire croire avec Debian.
1: le meta-paquet "init" dépends, au choix, de:
2: si la séparation de / et /usr lui est si chère, pourquoi ne pas conserver cette séparation?
Pour ce qui est du point 1, le seul truc que je peux regretter est l'absence de nosh dans la liste, j'aurait bien aimé qu'on me mâche le boulot avec celui-la, ça m'aurait permis de le découvrir in-situ.
Parmi ses avantages supposés (de mémoire):
mais faut que lise la doc, donc la flemme :)
Je reconnais que, pour ne pas avoir systemd installé par défaut (et donc devoir le désinstaller via apt après l'install) et/ou pour conserver la séparation de
/et/usril faut passer par une procédure plus complexe:Une fois dans le "rescue mode", il faut ensuite faire l'installation de la façon qui se fait sur d'autres distributions, qui ciblent des utilisateurs avancés (ça tombe bien, il semble en être un!): préparer le système cible, utiliser
deboostrapavec les paramètres qui vont bien, configurer le système, configurer le bootloader.Oui, c'est compliqué, mais plutôt que râler, il aurait été plus efficace de rappeler que c'est possible, j'ai émis plusieurs journaux sur ce genre de manipulations, donc en fouillant il devrais même ne pas avoir trop de boulot a faire pour construire son propre script.
Mais non, comme «tous» les «anti-systemd»(1) il préfère râler en ignorant (volontairement?) le fait que systemd est loin d'être obligatoire, surtout sur la distribution dont il parle qui propose quand même 2 alternatives pour ceux qui le veulent!
Et, vraiment? 1Go de RAM pour systemd?
Heureusement que ça n'est pas vrai, parce que sinon cette collection d'outils, qui nécessiterait sur mon système l'usage de 14.4Mio de disque, doit leak quelque chose de bien! Pas crédible.
Oui, systemd est plus gourmand en ressources.
C'est normal: il gère réellement les processus, il ne se contente pas de les lancer et faire comme si ça ne plante jamais!
D'ailleurs, c'est encore plus important sur un système embarqué qui va se retrouvé exposé a des conditions bien éloignée du labo. J'ai déjà vu un système freezer par le simple fait de recevoir un appel téléphonique trop près (bon, dans ce cas, c'était le hard qui partait en couilles, certes, il aurait fallu un watchdog hard, mais bon…)!
Par contre, je serais curieux de savoir la consommation mémoire (réelle) de systemd. Dans le cas de runit compilé avec glibc, j'ai:
Dans la plupart des instances de runsv, svlogd, runit et runsvdir, RSS chute a 4 dans le cas d'une compilation avec musl. Je ne sais pas pourquoi certaines instances de runsv montent a plus d'1Mo…
Si quelqu'un peut mesurer l'impact de systemd compilé avec glibc ou mieux, si possible, avec musl?
Bon, sur la plupart des machines, ces quelques megs de mémoire consommés ne sont pas gênant, mais je me dis que sur de l'embarqué très serré (genre, avec moins de 64Mo de RAM, comme certains routeurs ou autres) ça peut compter.
Perso, je vois surtout le fait que je serais capable de lire et maintenir le code de runit si besoin est, alors que ce n'est pas le cas pour systemd.
1: dont, techniquement, je fais partie puisque je n'utilise pas cet init. Cela dis, je préférerais utiliser systemd que revenir à sysvinit + rc.d, sans hésitation, surtout sur des machines sur lesquelles je n'ai pas la possibilité d'avoir un accès physique!
[^] # Re: La vraie informations
Posté par freem . En réponse au lien Record météo : un éclair de 700 km dans le ciel brésilien. Évalué à 3.
Je trouve l'info intéressante perso, sur le plan scientifique. Je ne sais pas a quoi ça sert, certes, mais ça montre qu'on s'améliore, et ça fait rêver. Je crois que c'est important pour les gens qui veulent ou doivent créer de nouvelles choses, de repousser les limites.
[^] # Re: « Sous la pression de grandes marques »
Posté par freem . En réponse au lien Sous la pression de grandes marques, Facebook agit enfin contre les pubs et posts haineux. Évalué à 2.
tu as oublié une partie du titre de l'article: "et tous les messages problématiques". Pas la peine de lire plus loin.
[^] # Re: Logiciels compatibles ?
Posté par freem . En réponse à la dépêche Haiku R1 bêta 2. Évalué à 2.
Merci.
J'allais répondre en long a ce lien, montrant a quel point je suis dépité et amer par rapport a mozilla, jusqu'a lire ça:
Tu es sûr que ce lien est… a jour?
[^] # Re: Proprio = obsolescence programmée
Posté par freem . En réponse au journal Tomtom, sdcard et système embarqué: accéder au système de fichiers. Évalué à 10.
Je doute que la boîte ait disparu de son plein gré, donc, tu ne peux qualifier l'obsolescence de programmée.
Ceci étant dit, a l'origine, la raison d'être des brevets était de justement protéger la civilisation de telles pertes, que les plans soient a tout jamais disponibles, et en échange l'inventeur de la méthode était rémunéré. Il me semble évident que les lois actuelles sont contre cet objectif, vu qu'il semble qu'il n'y ai plus d'obligation de donner les fichiers d'origine a une autorité de contrôle, qui soit capable de les rediffuser en cas de mort de l'inventeur.
C'est bien d'ailleurs pour ça que je pense que le libre est important.
# mode 'brut'
Posté par freem . En réponse à la dépêche Haiku R1 bêta 2. Évalué à 3.
En fait, j'ai une question qui est sûrement très bête.
Il m'est arrivé, comme a d'autres ici je pense, de devoir travailler en "mode sans échecs", "mode mono utilisateur", en gros dans des modes dégradés sur lesquels ont peut faire a peu près tout ce qu'on veut, tant qu'on sait se passer de confort.
Dans mon cas, j'ai utilisé linux pour du… disons, embarqué (ni baremetal, ni temps réel) pour des équipements de ville par exemple, qui ont un écran tactile, dédié a une seule application.
Au début, ma boîte du moment est partie sur l'idée d'utiliser electronJS. Au bout de quelques mois, après le départ du développeur qui avait tout fait, on s'est aperçu qu'il y avait de nombreux crashs (oui, je sais) notamment des SIGILL. Ça, et le fait que Xorg et les scripts que j'ai bricolés étaient assez… aléatoires… concernant la gestion de l'orientation de la dalle graphique et celle de la dalle tactile (non, les dev logiciels ne sont pas les rois).
Ça s'est fini a ce que je doive me farcir la gestion de l'UI, et vu que ni Xorg ni SDL ne permettaient de faire les choses facilement, je suis revenu a du bon vieux framebuffer + libinput (tellement plus simple, d'accéder direct a la mémoire et de faire une lib, dans ces cas, que de passer par 36 couches d'abstractions).
Qu'en est-il également des
Tout ça m'a amené a penser qu'une alternative portable et portée à d'autres systèmes serait plutôt sympa, et je me demandais si Haiku offrait ou planifiait ce genre de choses?
Je me pose aussi la question sur la question des syscalls. J'imagine qu'ils sont en C, sinon ça serait se fermer aux autres langages ou leur ajouter une couche de compat? Si c'est du C++, alors, comment vous gérez l'absence de specs d'ABI? N'y aurat-il qu'un seul compilo "autorisé"?
[^] # Re: Logiciels compatibles ?
Posté par freem . En réponse à la dépêche Haiku R1 bêta 2. Évalué à 2.
Voila qui m'intrigue.
Je comptais repartir derechef, mais… au final, le moteur de chromium et gecko sont moins simples a embarquer, porter et maintenir que webkit?
[^] # Re: Logiciels compatibles ?
Posté par freem . En réponse à la dépêche Haiku R1 bêta 2. Évalué à 2.
Peut-être un effet secondaire de la taille des captures par rapport a la taille du texte? N'est-il pas possible d'avoir des miniatures qui lient vers le lien d'une image plus grosse? (vraies questions, même si je repart derechef)
[^] # Re: Petite review
Posté par freem . En réponse au journal bout de code pour relancer une commande dans certaines conditions. Évalué à 1.
C'est vraiment si moche? Je serais heureux que tu me montre par l'exemple, ça servira potentiellement a plein de gens.
C'est vrai, qui suis-je au fond, pauvre libriste qui ose publier du code si sale que personne ne publie la version correcte?
C'est triste, mais ici, soit les gens mettent des liens githubs, dont le côté libre est discutable, soit on se fait limite démolir pour avoir osé ne pas être parfait..
Pardon mais moi, j'aime pas le libre parce que c'est du code parfait, mais parce que c'est du code que les autres peuvent améliorer. Sans se baser sur une base propriétaire comme github ou gitlab.
Je veux être libre de filer mon code a qui je veux, c'est a dire: tout le monde, même si c'est mauvais, certains apprendront, et moi je lirais leurs articlcles… techniques, et non politiques, ça me changera!