freem a écrit 5019 commentaires

Je sais que les UUID, c'est solide. Enfin, probablement, puisque tout le monde semble aimer ça, et que je n'ai aucune envie de chercher une explication pour comprendre comment ils sont générés…

Mais franchement, vous ne trouvez pas ça totalement illisible?

Personnellement, je préfère utiliser les LABELS, au moins on peut leur donner des noms cohérents, lisibles, aisés à se souvenir et il est même humainement possible de les écrire en moins de 10s.
Pour GPT, je crois que les part-labels font la même chose, mais je reconnais ne pas connaître la différence.

Bon, cela dit, il y a le risque de collision si on donne le même label à deux partitions, j'imagine que ça pourrait servir de vecteur d'attaque (dans le cas ou l'on s'amuse à séparer / et /usr, j'imagine)?
En tout cas, je préfère prendre le risque, si c'est pour avoir un système que je peux maintenir.

Cela dit, l'aléatoire est super frustrant quand toutes les probabilités sont vers une victoire éclatante et qu'on se retrouve à perdre son unité sans blesser l'ennemi…

Le pire, pour moi, c'est quand tu as très peu de chances de tuer l'adversaire avec une unité (en ayant du backup au cas ou le rng fasse des siennes), et que tu veux préparer le kill pour une autre, histoire de faire monter de niveau et donc, soigner (entres autres) de manière quasi assurée (genre plus de 95% de chances), et que bien évidemment tout rare: soit une unité tue alors que tu ne veux absolument pas, soit celle pour laquelle tu préparais le kill meurt dans l'action, soit l'unité de l'IA survit, te foutant dans une merde noire.
Et que ça, sa se produit plusieurs fois dans un scénario court (je dois avoir la poisse contre les IAs).

Ceci dit, j'ai trouvé un mod qui me permets de rager moins (de perdre la face contre une IA juste à cause du rng, je reconnais que ça me fait rager), et qui en théorie n'altère pas les chances de gagner/perdre une partie: «Randomized Damage Mod». En gros, ça distribue les dégâts plutôt que de les appliquer de manière booléenne.
Honnêtement, ça change beaucoup le jeu, mais je le trouve du coup plus agréable moi, j'ai moins l'impression de jouer à pile ou face, les décisions tactiques ont plus d'impact.

C'est un client pour jouer, avec sûrement pas mal de dette technique.

Mouai.
Steam date de 2003, les archi 64 n'étaient certes pas encore populaires à l'époque, mais existaient déjà.
Et franchement, porter un code haut niveau de 32 bits à 64 bits, ça me semble nettement moins complexe que de porter de windows à Linux.

Du coup, comment justifier, malgré le portage à un OS totalement différent, en effet…

Comment le justifier ?

Déjà, par l'intégration au système.

Sinon, je ne connais pas les détails pour windows, mais de nos jours sur Debian, Ubuntu, et donc probablement sur SteamOS, avoir un seul paquet 32 bits implique d'installer toutes ses dépendances en 32 bits, ce qui fait pas mal de doublons.
Donc, performance de 2 points de vue:
* disque dur (et si tu me dis que nos disques durs de nos jours ne voient pas la différence,
* bande passante

Pour ce qui est des performances, si elles ne sont pas importantes, expliques-moi pourquoi Steam dépends de libgl1-mesa-dri (et libtxc)? Ce paquet, de mémoire, permets l'utilisation d'OpenGL (et txc la compression des textures).
Je note aussi une dépendance à xz-utils, qui sert pour compresser (encore).

Pour toi, la performance n'a peut-être aucun intérêt, et d'ailleurs, la performance en CPU d'un client 32 bits pourrait même bien être parfois supérieure à celle d'un client 64 bits (à priori, dans les binaires 64bits, les pointeurs pèsent 8 octets chacun, contre 4 dans les 32 bits, qui vont donc moins saturer les caches pour rien, la plupart des applications n'ayant pas besoin d'adresser 4Gio de ram), mais steam est un outil qui tourne en arrière-plan (mais est actif) en même temps que des jeux vidéos, applications souvent gourmandes.
Donc, pomper le moins possible pour laisser de la place aux jeux me semble utile (pour le disque, je t'accorde qu'en regard de l'espace occupé par les jeux c'est négligeable, surtout qu'on peut l'étendre. C'est moins vrai pour l'usage CPU des caches, ceci dit).

Le fait d'utiliser des builds x86 de bibliothèques implique aussi de s'exposer à plus de risque de bugs, puisqu'il y a de moins en moins de machines x86 vendues (je suis pas sûr que du matériel x86 neuf soit encore vendus, en fait) et donc très probablement moins de tests et d'attention accordés à cette architecture.

Pour finir, il y a probablement au moins autant d'intérêt à porter Steam en 64 bits, que Skype, qui a probablement une dette technique équivalente, puisque 1ère version la même année (2003) selon wikipedia.

i permet d'établir une communication bidirection avec HTTP. Au lieu d'avoir juste de requête/réponse, on maintiens la connexion (ce qui est déjà le cas au niveau TCP) et on permet le fullduplexe

Donc, on prend du TCP qui est full-duplex et à une connexion établie, pour construire un protocole déconnecté et half-duplex, sur lequel on construit un protocol full-duplex connecté?

Je t'avoue, pour moi, ça ressemble à forcer une technologie (HTTP) pour faire des choses qu'elle n'est pas censée faire.

Tout ces trucs là cherchent à remplacer des techniques comme le (long) polling. Quand il y a une pratique aussi répandu et autant de gens qui cherchent à y répondre c'est qu'il y a un besoin réel AMHA.

Je ne nie pas le besoin, mais le fait de faire les websockets sur http, en fait, de tout faire par http, me semble une aberration.

Tout ces trucs là cherchent à remplacer des techniques comme le (long) polling.

La seule chose qui fait que le polling soit exposé aux développeurs utilisant TCP, àmha, c'est qu'il n'existe pas de lib standardisée. Il n'y a pour moi pas besoin d'aller pondre une surcouche à HTTP qui contourne les limitations du protocole pour lui faire faire ce pour quoi il n'est pas conçu (Hyper Text Transfert Protocol, c'est clair pour moi, c'est pas conçu pour établir un flux continu. Si l'outil n'est pas bon, on en prend un autre, on ne le détourne pas).

les utilisateurs de systèmes GNU/Linux, adhèrent à l’installation et l’utilisation de logiciels privatifs tels que Steam

Vu le 0 pointé (évalué par moi) de l'intégration de steam sur le système, ça me paraît peu probable.
Perso, j'ai bien installé ce truc (mon frère m'a payé en cadeau un jeu dessus, que j'apprécie, du coup je fait ce compromis.), mais vue la situation, je préfère largement utiliser un compte utilisateur dédié, j'ai trop peur qu'il ne foute la merde dans mes données… Et puis, ce truc n'est même pas capable d'installer ou de lancer les jeux via wine, ce qui fait qu'il faut l'installer lui-même via wine (ce qui m'amène sont lot de galères d'ailleurs), ce qui fait s'apercevoir qu'ils ne sont même pas foutus de le compiler en 64 bits pour windows (il faut wine32). Nous sommes en 2018, je connais plus d'un logiciel windows dont l'installateur est capable d'installer le bon build en fonction que le kernel soit 32 ou 64, mais pas eux manifestement. Triste.

Mais bref.

Pour en revenir de l'intérêt de publier un jeu libre sur steam, je dirais que ça permets de toucher plus facilement la grande majorité des joueurs qui n'est pas libriste et ne voit aucun problème à passer par cette usine à gaz.
Le fait que wesnoth soit sur Steam, ça va me permettre par exemple de faire passer l'info à mon frère et un certain nombre de gens avec qui j'étais en contact il y a quelques années, facilement.
J'aurai pu passer le lien, surtout que mon frère apprécie déjà Wesnoth (je lui en avais fait la pub il y a quelques années), mais je pense que signaler qu'il est dispo via steam va permettre aussi de faire de la pub. Par exemple, sur steam, le jeu est très bien noté, la quasi totalité des commentaires semblent super positifs (je ne suis pas trop sûr de moi, je ne suis pas super familier de l'interface).
Autre point: si c'était bien intégré avec mon système (et si je faisais confiance à steam pour tourner h24), peut-être que je pourrais ainsi signaler quand je joue à un jeu libre (pour le moment, ceci dit, je ne connais que endless sky et wesnoth (depuis aujourd'hui pour ce dernier), sur steam) et donc ça permettrait potentiellement d'augmenter l'activité sur ces jeux.
Et ça, honnêtement, Wesnoth en aurait bien besoin: quand je lance le jeu, je ne vois que très très peu de parties multijoueur, le lobby semble moribond (peut-être que je tombe systématiquement sur des heures creuses, vu que je joue moi-même de plus en plus rarement, mais ça me semble peu probable).

Pour moi, on peut ne pas aimer steam (je n'aime pas perso), mais je pense que c'est un moyen de diffuser l'information comme un autre.
Ça fait doublon avec nos gestionnaires de paquets? Oui, clairement (mais, il ne fait que ça, pour le coup, il embarque aussi du code pour signaler aux contacts si on le souhaite à quel jeu on joue, pour échanger, pour évaluer, etc. Je laisse à l'appréciation du lecteur le soin de considérer que ce sont de bonnes choses ou non…).
Mais ce ne sont pas les 1ers, de nos jours la plupart des langages semblent avoir un gestionnaire de paquets aussi, donc… bof, yet another one.
La principale différence est qu'il n'est pas libre. Ce qui m'en touche une sans faire bouger l'autre, parce que du code sur un serveur distant, qu'il soit GPL (je n'ai pas dit AGPL), BSD-2 ou proprio, c'est du pareil au même: je n'y ai pas accès. Et ça inclue le JS que les serveurs web nous balancent (enfin, si, la on peut avoir accès, au même titre qu'on peut reverser un binaire…).

Par exemple, Steam ne propose pas de télécharger les codes sources :(

D'ailleurs, je me demande à quel point c'est compatible avec une licence type GPL, ça? Cette licence est suffisamment complexe pour que je n'aie vraiment aucune idée des obligations du fournisseur d'un binaire… qu'ils doivent pouvoir fournir les sources si demandées, ok, mais je ne sais pas si ils sont obligés d'indiquer autrement que par la licence que celles-ci sont dispo.
Et d'ailleurs, c'est la communauté wesnoth qui fournit le binaire j'imagine, donc eux servent probablement juste de proxy, comment ça interagit avec GPL?

Tu fais bien de parler de jugement vu la suite de ton commentaire…

N'est-ce pas? :)

c'est tout de même bien tranché tu ne trouve pas ?

Si. Mais, si ça me permets de lever le débat, quitte à avoir tort et le reconnaître en public, ça vaut le coup (en même temps, même si j'y tiens, ce n'est que mon identité de geek, tu me diras).
Notes, je ne reconnais pas encore avoir tort sur la totalité (hé, si je m'éclate sur linuxfr, c'est bien parce que l'on peut trouver des gens pour débattre et nous convaincre quand on se plante).

Les gestionnaires de fenêtres qui maintiennent des sessions sont totalement bloated

À ce niveau, mon problème principal, c'est que je ne sais pas définir précisément ce qu'est une session. Sérieusement. Je suis au courant des problèmes d'i3, ou du moins de certains. Par exemple, il est très difficile et très aléatoire de répartir comme on le veut un groupe d'applications dans un workspace.
Je me plante peut-être, mais, pour moi, ce point particulier est lié au fait qu'i3 ne permette pas d'«opérations atomiques». Évidemment, c'est facile à dire, mais pas à faire.
Ce qui ne m'empêchera pas de penser (et, espérons-le, un jour d'agir?) que le gestionnaire de session et le gestionnaire de fenêtres sont aussi des choses distinctes.
Pour être franc, je pense que je manque de recul sur la réflexion qu'il doit y avoir encore gestionnaire de session, gestionnaire de fenêtre, décorateur de fenêtre (pour le coup, i3 (que j'utilise au quotidien) est un bloatware: il fait wm, décorateur, et gère en partie les sessions puisqu'il colle toujours une status bar avec des info obligatoires… entres autres, mais c'est le plus proche de mon équilibre perso)…

C'est simple une fonctionnalité existante est mieux qu'une fonctionnalité théorique.

Totalement vrai. Je te citerais peut-être, si d'une part tu me le permets (très probable), et d'autre part je m'en souviens (peu probable).

Effectivement c'est selon toi donc pas la peine de commencer en étant aussi tranché :)

Heh. +1.

Hum hum… Tu as des cas un peu répandu où tu va nous donner un lien d'un rapport de bug plus ou moins obscure ?

C'est vrai, je n'ai aucun bug report ni report à citer
Mais, que se passe-t-il si un thread plante? Sur ce point de la discussion, j'ai tout à gagner: soit je me plante, et j'apprend comment une application récupère d'un crash de thread (big win), soit je gagne un échange sur dlfp (peu probable) qui fera réfléchir avant d'utiliser du multi-thread (encore pire).
D'un autre côté, il est simple de protéger une IPC contre un crash des interlocuteurs, et au niveau code, c'est quasi trivial de savoir qui bug, alors que du multi-thread… c'est pénible à lire, pénible à debug, pénible à maintenir.

Le multi-processus consomme beaucoup plus de ressource.

C'est un fait. Relativement à un thread, il faut sauvegarder beaucoup plus d'informations. D'un autre côté, c'est de toute façon fait par le kernel, vu que de toute façon les processus résident quelque part?
Cela dit, sur nos systèmes de bureautique, cette consommation de ressources supplémentaires est-elle significative? On parle de quelques kibi octets, la on l'on dispose de plusieurs de gibi octets. À moins que tu ne parles de performances CPU? Dans ce cas, le problème vient-il des erreurs de cache? De cycles gâchés?

Je t'avoue, moi, je ne sais pas, à quel point un multi-thread est plus lent, sur un système moderne, qu'un mécanisme d'IPC, comparé au temps d'exécution total.
Cela dis, si tu as de la doc, je la dévorerai (enfin, un peu comme pour le vin, seulement si elle est bonne :p).

ils ont pris une bibliothèque qui fait déjà bien le job

Laquelle? Est-ce vraiment son job, ou son job est-il plutôt de permettre de tisser des relations entres les données, «bêtement»? Est-il possible d'interagir simplement de l'extérieur sur cette BDDR?
Bon, j'avoue, sur le dernier point, c'est un fantasme de ma part que je n'ai vu nulle part, mais je pense que mon niveau de confiance dans un brouteur qui fait ça augmenterait sensiblement, et serait pour moi un vrai argument d'usage. Bon, clairement, ça ne parlera jamais à Mme Michu… Mais, Firefox, leur pub initiale, ça a été les geeks, pas doubleclick.com.

quant à la performance

Bon, sur la perf, je me couche aussi, il faut dire que c'est dire complexe: une recherche à chaud ou à froid? Sur un SSH ou HDD? IL y a des chances que le choix d'un SGBDR soit justement pour la perf à froid sur un HDD monolithique (sur un fichier non fragmenté ou à faible fragmentation, les performances à priori approchent celles d'un SSD, et un SGBDR sera traditionnellement prévu pour… ce qui me fait penser que c'est p'tet juste un workaround? D'ailleurs, je me demande, ça donne quoi sur des SSD?)

Mettre à disposition des gens de quoi devenir acteur du web et comprendre/maitriser ce qu'ils ont devant eux ne me paraît pas choquant.

Je n'ai pas dis que ça me choquait. Ce que je mettais en doute ici, c'est le fait de mettre ça en exergue comme une fonctionnalité importante.
Soyons honnêtes: si tu veux faire adopter le panda roux, tu ne mettras quand même pas ça en exergue, si?
Et perso, j'aurai tendance à considérer ce genre d'outils comme des plug-ins, vu qu'ils ne concernent réellement qu'un très faible nombre d'utilisateurs, alors que d'autres sont utilisés en masse et sont des plug-ins, justement.
Je trouve que ça fait tâche.

Que ce soir l'un ou l'autre ils ont pété une fois la compatibilité en 15 ans, c'est ce que tu appel « ne pas arrêter de casser » ?

Ok, je te l'accorde, il s'agit ici d'une impression globale, tirée de diverses lectures. En gros, de l'image qu'ils me renvoient, en tant que développeur, pas web mais surtout Freem.
Comme toutes les images, elles peut être erronnée.

Tu entends quoi par « pas fait pour » ? C'est des usages décrit par des différents standards tous très largement reconnus. Les serveurs sont développé avec ces usages en tête et les client aussi. Donc qu'est-ce qui n'est pas fait pour quoi ? Le fait que ça n'a pas était imaginé à la base ne l'empêche pas d'évoluer. Tu as vu la sécurité sur SMTP ou sur FTP, je trouve que HTTP et le web s'en sort pas si mal.

Dis-moi, c'est quoi, les websockets?

Pourquoi ne pas utiliser uzbl ou surf ? Ils font juste ce que tu semble attendre d'un navigateur.

Dans le cas d'uzbl, parce qu'il porte très mal son nom. Pour surf, je pense l'avoir essayé, mais je ne me souviens pas, tu fais très bien de me rappeller son existence.

Alors, demi-hors-sujet, parce que je n'ai pas encore 35 ans.
Cela dit, je pense pouvoir apporter un témoignage, à prendre pour ce qu'il est, et qui, à mon sens, renforce celui de fanto30.

Pour commencer, niveau cursus scolaire, je n'ai que le baccalauréat, STI électronique (ancien bac F2) de validé. J'ai un niveau (donc, pas obtenu) officiel de BTS IRIS, successeur du BTS informatique industrielle. Il s'agit principalement de programmation, notamment en C++. Il peut peut être intéressant de noter que j'avais déjà un très bon niveau (ahem… pour un étudiant, hein!) en C en arrivant et j'avais déjà commencé à lire des docs sur le C++. Le shell du DOS ne me cachait plus rien depuis quelques années déjà, et j'avais mes notions de reverse engineering de binaire.
Voilà pour les études que j'affiche sur le CV (je n'affiche pas vraiment le côté cracker, ou du moins, plus maintenant). Ah, non, il y a bien une formation de 4 mois, d'administrateur réseau et bases des données que j'affiche aussi, mais je doute que ça vaille son pesant d'encre, si imprimé… :)

Certes, je suis jeune (enfin, par rapport à vous deux), mais sans diplômes, ça a été un «peu pénible», au début, dans un monde on l'on considère les diplômes à ce point. Je vous passe les désagréments, mais sachez que je n'ai jamais été viré contre ma volonté d'un CDI. J'en suis à mon 3ème.

Le 1er CDI, je suis parti parce que travaillant dans une petite SSII (moins de 10 personnes, plutôt orientée gestion système et réseau que développement, pour faire simple) je n'avais plus rien à faire pendant trop longtemps.
Ceci dit, les leçons que j'en ai retenu, tant au niveau humain que développeur, furent intéressantes.
La première: j'ai appris qu'un développeur (un ingénieur logiciel) ne sait pas nécessairement gérer un projet, même s'il peut être compétent dans son domaine (dans mon cas, les collègues me considéraient compétents en C++, devant moi. Derrière, je ne sais pas.).
La seconde: ne pas oublier la distinction entre collègues et amis, ou entre travail et vie privée. Les conséquences de celle-ci ne sont toujours pas finies, mais bon, vous savez probablement déjà mieux que moi les emmerdes que ça peut apporter de mélanger ça.

Le 2nd CDI, j'étais dans une grosse SSII, et je suis parti avant la fin de ma période d'essais, pour les raisons suivantes:
La première: la gestion de l'infrastructure m'empêchait littéralement de travailler, le jour ou je suis parti j'ai tout de même eu le matériel et le logiciel pour compiler le projet sur lequel je devais bosser, après 3 mois (c'est à dire que j'avais déjà démissionné, et j'aurais pu ne rien essayer, mais je voulais éviter qu'un éventuel successeur ait les mêmes problèmes que moi. Et puis, ne pas savoir pourquoi un code ne compile pas, c'est frustrant. En l'occurrence, il s'agissait d'une installation de windows foireuse, probablement).
La seconde: j'avais la sensation de ne pas pouvoir faire avancer les choses. Que j'allais n'être qu'un numéro, une ressource. Ça peut convenir à certains, mais, pour moi, l'informatique, c'est avant tout une passion, et même s'il est vrai que je gagne ma vie plus que des gens mieux mieux diplomés que moi, l'argent n'est pas mon leitmotiv. Il me faut apprendre, toucher à des choses de plus en larges, et apprendre encore, et ça, à mes yeux, ça vaut plus que quelques centaines d'euros mensuels.

Mon CDI actuel, le plus intéressant pour l'OP je pense, je suis dans une petite boîte, de moins de 10 employés, qui ne voulais pas à la base créer des logiciels, mais à du le faire pour piloter les produits qu'elle développe.
Il y a pas mal de choses à dire, tant en bien qu'en mal. Je vais commencer par le mal, parce que c'est plus simple et aussi parce que ça peut peut-être casser des mythes qui feraient que l'OP ne se sentirait pas adapté:

• nous n'avons, à l'heure actuelle, aucune infrastructure réseau. Notre réseau, c'est littéralement un tas de PC reliés par des cascades de switchs à NAS et un routeur de particulier.
• nous, les développeurs, n'avons aucune visibilité sur ce qui va nous tomber sur le coin de la gueule demain. Le chef décrète, car il est propriétaire et le commercial unique. Nous essayons de négocier avec lui les fonctionnalités. Nous nous démerdons avec les sous-traitants et les fournisseurs (bon, je dresse un tableau noir ici: lui aussi gère une partie de la R&D hein).
• la plupart d'entre nous (les développeurs notamment) sont des alternants et des stagiaires. J'ai, en fait, été le 1er développeur avec de l'expérience (j'ai du mal avec ce mot…) embauché. À bien y réfléchir, je suis d'ailleurs le seul, et la raison est évidente: je n'ai pas de diplôme officiel, j'ai juste bourlingué. L'une des conséquences, c'est que je ne sais pas trop combien demander en salaire, je me rabaisse peut-être (m'enfin, 1800€ net mensuel, pour un type qui n'a que le bac, je trouve pas ça si crade à l'embauche en province, sachant que depuis mon patron m'a monté de 100 balles brut sans que je lui demande, entres autres.). Cela dit, et ce point sera intéressant pour l'OP, mon patron à embauché (sans mon avis, faut bien le dire) quelqu'un pour me seconder, qui à la 50aine passée. Cette personne a, à priori, bossé en tant que dev il y a plus de 20 ans, et m'a été «mise sur le dos» comme j'aurais dis à l'époque, en tant que stagiaire. Je suis un geek, un pur, un dur. Transmettre mes connaissances, de base, je sais pas faire. Surtout devant certaines questions ou je brûlais d'envie de sortir un bon vieux "RTFM" des familles. Bref, il est vrai que j'aurai pu faire la totalité de ce qu'il a fait en moins de temps qu'il ne m'a fallu pour lui expliquer comment le faire (en même temps, je n'étais pas prêt à former quelqu'un, et j'étais… ah, zut, je suis toujours… dans un état d'urgence par rapport au projet en question), mais, force est de reconnaître, cette personne sera un aide très utile, et je pense que le fait d'avoir bossé dans d'autres milieux est la raison pour laquelle elle à pu apprendre aussi vite (ceci dit, j'ai la désagréable impression qu'il m'a fallu faire mes preuves devant lui à cause de notre différence d'âge, ça reste à prouver, faudra que je demande frontalement quand on sera enfin au calme)

Maintenant, les choses que j'apprécie:

• il ne s'agit pas d'une SSII. Nous vendons les produit que nous concevons, et ça implique que le patron est réceptif au fait que l'on essaie de faire des choses pérennes.
• il y a des tas de choses à faire. Trop pour une seule personne. Ça implique que si cette personne sait ce qu'il y a faire, et parviens à convaincre le chef, cette personne va se retrouver à faire un grand nombre de choses bien distinctes. Dans mon cas, je travaille sur notre infra réseau interne, sur l'infra réseau des produits que l'on vends, et sur une partie de l'électronique. Vu que, gamin, je rêvais d'être inventeur, je me sens quasi comblé :)
• encore une fois, une petite boîte. On cottoie les collègues, tous les collègues, y compris le chef. Je garde une certaine déférence envers lui et sa femme, mais on est loin de la relation impersonnelle malgré tout.

Conclusion, je rejoins mon prédécesseur sur 2 points:

• plus simple d'être débutant mais éclectique dans une petite boîte
• le taf est quand même vachement plus simpa quand on ne fait le même à longueur d'année, mais ça demande une souplesse d'esprit que tout le monde n'a pas. Si tu penses à changer de métier, et fais l'effort d'apprendre les bases, je ne suis pas inquiet pour toi, et te souhaite bon courage.

Bon, je sais, ce ne sont pas nos ancêtres puisqu'ils ne respectaient pas la loi (contrairement à nous libristes qui utilisons la loi pour nous défendre, en théorie), ceci dit, il me semble que justement ils ont forcé la loi à ouvrir des bandes de fréquence utilisables par tout le monde.

Ceci étant dit, il est évident pour moi que nos mondes ne sont pas si éloignés que ça: quand je zonais sur la ml internationale de debian ou quand je lisais l'interface d'aptitude comme un dictionnaire (oui, il m'est arrivé de lire le dico pendant des heures perdues, et alors?) j'ai trouvé pas mal de traces de la présence de radioamateurs dans le logiciel libre.
Je n'y avais pas prêté attention plus que ça jusque maintenant, mais effectivement, le radioamateurisme (attention, j'ai lu que les connaissances nécessaires pour être radioamateur ne sont pas si triviales que ça, notamment avec la connaissance du morse?) peut être lié à nos envies de communications libres.

En tout cas, à titre personnel, je serais très heureux de lire d'autres journaux sur le sujet, que ce soient les points techniques ou sociaux, car j'ai cru comprendre qu'il n'était pas impossible de discuter avec des gens distants de plusieurs centaines de kilomètres, ce qui, dans ma vieille europe natale, implique un nombre de cultures assez impressionnant quand on y pense.

[presqu-edit]
Du coup, je me dis, mais, c'est quoi, le débit? Ok, il faut être compact au maximum, par respect pour les autres, mais du coup, du texte, ou de la donnée, ça doit être plus compact que de la voix? On pourrait imaginer des jeux video (en tour par tour) via ce medium? Si c'est le cas, comment ça se fait que nos industriels n'y aient pas pensé?

Je suis curieux, du coup.

Veux-tu dire que mozilla utilise gratuitement et sans retour des softs libres en demandant qu'on lui paye ce qu'elle fait?

il n'est pas développé par un géant de l'Internet

Euh… et alors?

D'une part, c'est faux, puisque comme tu lu soulignes plus loin, firefox descend de netscape, qui n'a pas vraiment été un outsider, juste un perdant. Qui a regagné en popularité en libérant son code, et donc en récupérant la sympathie et les contributions des libristes de l'époque.
Je pense que, à l'époque, netscape à été un des géants de l'internet, à l'échelle de l'époque.

D'autre part, on s'en fout, que ça soit codé par un géant. Ce qui importe, c'est que le code soit libre, non?

D'ailleurs c'est Chromium qui n'apporte rien car il a été développé après Firefox.

Ah… hé ben, si, il apporte. Et beaucoup, même.

Depuis 1998 (hé oui, ça date, KHTML, racine de chromium), il a apporté une alternative supplémentaire dans l'interprétation du «standard HTML». Certes, ça fait chier les dev web, mais ça permets de ne pas enfermer le web dans une vision unique. M'enfin, de nos jours, c'est l'inverse, et en plus, vue la direction, je me dis que que c'est pas si bien que ça…

Ensuite, il a apporté une saine concurrence, de la même façon que clang à mis un coup de pied au cul à gcc, dont les performances se sont drastiquement améliorées depuis.

Au niveau interface de config, FF copiait avant IE, maintenant chrome. Damn. Encore une amélioration de chromium. Ou chrome. Je m'y perds.

Chromium à aussi apporté l'embarquement aisé des contenus web dans les applications, la ou seul mozilla est capable d'utiliser leur usine à gaz moteur de rendu. Un soft libre que personne ne peut réutiliser vs un soft libre relativement aisé à embarquer? Par étonnant de mozilla perde.

Si pour toi, tout ça n'est rien, alors, je ne peux pas grand chose pour toi.

Quoique, il me reste ceci: au tableau des fonctionnalités, depuis 10 ans, je ne vois rien. Rien de rien qui soit apporté par firefox. Ma référence en terme de progrès technologique sur les navigateurs, ça a été opera, jusqu'à la 12. Browser peu usité, mais qui savait qui étaient ses utilisateurs et s'adressait à eux. Pas libre, c'est vrai. Par contre, il respectait mieux les standards (en tout cas, il supportant l'imbrication HMTL/SVG sans plug-in bien avant les autres, même s'il restait quelques manques. C'est la raison qui m'a fait changer, pour un projet de dev qui n'a jamais aboutit :p), et donc à mon sens était plus interopérable quand je l'ai connu.
Encore de nos jours, Firefox nécessite un plug-in pour mettre les diverses barres sur le côté, tandis que le successeur d'opera le fait nativement. Mais, se base sur chromium.

Parce que le Web il s’est vraiment bien étoffé ces dernières années,

Par chance, tu n'émets aucun jugement sur ce point.

Pour les onglets, en fait, c'était une erreur. Ça permets d'utiliser le multi-thread et de contourner les gestionnaires de fenêtres pourris? Certes. Mais en fait, le multi-thread pour les onglets, c'est pas cool, ça propage les emmerdes. Les wm pourris? Ben, ça devrais pas être le problème du brouteur, selon moi.

Du coup, ben, on mets les onglets dans des processus différents, et le fait d'avoir des onglets combats le gestionnaire de fenêtre. Anti-feature, pour moi.

des favoris

C'est quoi, un favori? Un lien stocké sur le disque dur? Comment te dire…. je doute que le fait que le brouteur le gère via un SGBDR (parce que, oui, la plupart le font via des SGBDR à vue de ldd) soit super portable|performant|efficace.
À moins que, par favoris, tu parles de faire une recherche google sur le nom d'un site en espérant tomber sur le bon, comme le font la majorité des gens que je cottoie?

des outils de développement

Ce qui est totalement inutile pour 95% de leurs utilisateurs. Minimum.

etc…

Tu aurais pu continuer, je serais curieux de trouver un truc réellement bien.
Les vidéos, peut-être? Ah, le truc qui fait ronfler mon PC comme pas permis avec firefox alors que préalablement téléchargée (ou en cours de dl) et lue par mpv, il reste froid?
Les liens intelligents, qui ne servent qu'a duper l'utilisateur final?
Zut, je n'arrive pas à continuer ta liste avec un exemple réellement utile.

un système de plugins…

Ah, oui! Les plug-ins. Tu veux dire, le mécanisme dont l'API n'arrête manifestement pas de casser chez mozilla, dont on parle?
Oh, merde, je vais trop loin la.
En fait, ça n'aurait pas été un journal sur mozilla, je n'aurai probablement rien dit contre les plug-ins. Sauf que la, on parle de mozilla, justement.
Les gens qui publient un navigateur internet supportant en built-in des choses non-libres qui ont fait controverse (non-libre, par exemple), tout en forçant leurs utilisateurs à recourrir à des plug-ins pour bloquer DNS, ou accéder à une configuration potable, je trouve ça douteux.

et avec JS+Moteur de rendu ça représente un « système d’applications » complet, relativement universel et ouvert.

Oui, ça, c'est balèze. Surtout que le web, plus le temps passe, plus ça fait n'importe quoi au travers de formats et de protocoles pas conçus pour (chiffrement, communications asynchrones, notamment).
Et le tout, avec des conventions pour le moins fluctuantes.
Tu vois, je déteste les navigateurs web, que je considère comme merdiques sur pas mal de sujets, mais j'ai un grand respect envers ceux qui les implémentent, parce qu'ils arrivent à améliorer des usines à gaz sur lesquelles, je pense que je toucherait la moindre ligne, je te ferais exploser paluel, hein.
Honnêtement, le web est devenu trop complexe. Je crains qu'il ne soit plus aisé de maîtriser le C++ (du C++03 au C++17, en passant par le C++11) que HTML5.

Reste à savoir à quel point on veut être naïf.
Personnellement, j'ai lu des informations au sujet d'échelon et autres depuis plus de 15 ans, sans forcer les chercher. Coupler ces informations à mes sujets d'intérêt (l'informatique notamment) m'a permis de déduire que ces informations n'étaient pas improbables.
Aborder ce type de sujet en public, jusqu'a peu, c'était passer pour un adepte de la théorie du complot. Jusqu'a ce qu'un certain Mr. Snowden dévoile que, ben, la théorie en question est en bonne partie fondée.

Je ne dis pas qu'il faut croire tout ce qui attire la méfiance envers les organisations, juste qu'il ne faut pas espérer plus de morale de leur part que l'on ne peut en trouver dans le pire individu les constituant.
J'hésite… je vais chercher mon point godwin ou pas? Oups, trop tard.

Du coup, toi, comment ça se passe niveau économique, tes softs?

En vis-tu?
Si non, aimerais-tu en vivre?
Si oui, comment?

Parce que bon, zenitram pour le coup, pose bien la question de comment vivre en produisant du code libre. Moi, perso, je doute fortement que l'on puisse vivre d'un jeu (par exemple) dont la totalité des ressources soient libres: des serveurs apparaitraient rapidement en guise de fork, sans valeur ajoutée autre que faire un truc gratuit «pour le fun».

Pour des outils destinés à des professionnels, c'est peut-être plus jouable, grâce au support utilisateur.
Sauf que, le support, ça implique pas mal de formation et de hotline, pas vraiment tasse de thé du dev traditionnel (en tout cas, pas la mienne). Et puis, ça ne concerne que peu le développement en lui-même, au final, ce n'est pas vivre du code libre, mais vivre de l'assistance sur un logiciel libre, le dév passant à l'as, alors que c'est ce qui nécessaite le plus d'investissement (former à un outil déjà développé, ça ne nécessite que d'apprendre à l'utiliser, y'a 0 conception, et la conception est juste super chère).

La publicité, que ce soit sur le site, dans l'installateur ou dans le produit final, si elle peut être court-circuitée par contributions directe, ne me semble pas si choquante que ça.
De toute façon, si le logiciel est vraiment libre, l'utilisateur que ça dérange peut choper le code, éventuellement le patcher, et l'avoir sans pub.
Sauf que, moi, tant que ça reste raisonnable (chose difficile à évaluer unanimement, vu que nos valeurs diffèrent), je ne le ferais pas. Ni n'utiliserais de bloqueurs de pubs (même si, le sujet m'intéresse puisque l'on ne peut au final pas savoir si un site, par exemple, mérite son financement ou non avant de l'avoir consulté, ce qui est différent d'un article IRL que l'on peut souvent au moins voir sans devoir donner d'infos à notre sujet autres que l'apparence).

Derrière un logiciel libre, traditionnellement, ce sont des bénévoles qui s'occupent d'une grosse partie de l'archi, mais force est de constater: dans les domaines vraiment pointus (jeux vidéos, CAO, …) les softs libres ne sont que rarement des concurrents à prendre en compte. Le bénévolat, c'est bien, mais ça ne suffit pas toujours à produire des alternatives réellement crédibles.
Je ne pense pas que la réclame soit la solution ultime, mais ce qui me paraît évident, c'est que malgré ses travers elle permets de financer une partie des outils que j'utilise gratuitement, libres ou non.

C'est un plug-in, ok, mais ça ne nous dis pas grand chose…

Un plug-in pour quel logiciel? Ou le logiciel va-t-il chercher ses plug-ins? Qu'entends-tu par plug-in? Un binaire exécutable, une bibliothèque partagée, un script?

Je change l'écran sans toucher à rien d'autres et les couleurs sont complètement différentes.

Le problème ne viens peut-être pas de l'écran lui-même, j'ai déjà eu ce type de symptômes avec des câbles endommagés.

Ça n'a pas de rapport avec ton script que tu « colle dans /etc/init.d ».

Ce n'est pas moi qui ait écrit le script à migrer :)

J'ai pris la totalité de ton paragraphe.

Je faisais référence à moi :)

C'est extrême, si tu veux rester avec le noyau linux, tu peux aussi utiliser void. Mais bon, c'est aussi un bon prétexte pour changer de kernel et voir du neuf.

c'est complètement documenté […] tu trouvera tout ce qu'il faut comme ressources […] avec systemd

Dans ce cas je veux bien un lien qui explique comment changer proprement le tty utilisé par défaut sur un OS. J'insiste sur le proprement, un truc qui risque pas de péter à la moindre MàJ (c'est pratique de virer des mots pour détourner le sens d'une phrase :p).

Pfff bande de petit joueurs qui vous voulez mettre les cafettieres au chomage!

À ton avis, c'est pour quoi, systemd et pulseaudio? (allez, ça faisait longtemps ;))

Sigfox, avec le forfait standard, c'est 4 "downlink messages" de 8 octets par jour. La mise à jour va effectivement être un peu longue…

Effectivement. Mais, comment diantre font nos pauvres développeurs web pour établir leurs websockets? :D (le trolldi, c'est permis)

Non, ces restrictions sont avant tout légales : ces réseaux IoT fonctionnent sur des fréquences en libre accès pour n'importe qui, il faut donc veiller à ne pas trop les occuper. Du coup des régulations sont en place pour éviter que quelqu'un s'octroie la totalité de la bande.

Je n'avais pas du tout pensé à cet aspect.

On apprend plus de ses erreurs que de ses réussites.

C'est sûr, vu que quand on ne fait pas de conneries, il n'y a pas besoin d'apprendre à les réparer… non non, c'est pas en faisant des conneries que j'ai appris quasi-par coeur la liste des services utiles de windows (à l'époque), des paquets «utiles» de ma Debian ou comment récupérer un fichier dans une partition FAT32 à coup d'éditeur héxa :p (sans parler la pléthore de trucs & astuces qui du coup sont utiles même hors des situations d'urgence).

Sinon, moi, j'ai déjà fait un killall -9 ssh sur une machine à laquelle on n'accédait que… via ssh, moi inclut :) (je ne sais plus pourquoi j'avais eu cette drôle d'idée d'ailleurs).

Il faut avouer que sur ce point, les outils du shell sont douteux. On se demande après pourquoi les scripts se remplissent de programmation défensive…

je ne suis pas un vrai sysadmin moi.

Nous somme 2 (au moins) :)

parce que le service informatique est à la rue

Au moins t'en a un, et il t'empêche pas de bosser :D dans ma boîte actuelle, y'en à pas (faut dire, moins de 10 employés aussi), et dans celle dont je suis parti en moins de 3 mois, il m'empêchait littéralement de bosser (grosse boîte, plusieurs centaines de personnes. Veni Vidi Parti.).

ça va encore complexifier ton bousin.

C'était juste une question «pour le sport», et pour contrecarrer un peu l'argument de l'usage des ressources par un agent :)

Si on parle de réseau comme sigfox ou lora, ça va vraiment faire la gueule de faire des mises à jours système dessus

Je ne connais pas sigfox et pas trop lora, mais effectivement, dans le cas de lora, je doute que le débit suffise pour faire des MàJ avec les moyens conventionnels. Peut-être que ça pourrait passer avec des patchs, cela dit.

Après tu peux toujours simplement monter un dépôt de paquet et faire tes actions via les mises à jours automatiques du système, ça marche très bien.

C'est sûr, et j'y ai pensé, mais l'inconvénient dans ce cas c'est si une application part en vrille pas possible de la remonter. D'un autre côté, tu me diras, un système de supervision type daemontools permettrai de la relancer en cas de plantage (reste d'autres problèmes, mais ça fait déjà une bonne classe de problèmes à gérer en moins).

Un dépôt git vide n'est pas un dossier vide.