freem a écrit 5059 commentaires

Mais le but du logiciel est d'être un outil.

Et l'art n'est pas un outil, peut-être?

Moi, en tant que dev, je suis capable de reconnaître les divers styles des contributeurs à un logiciel en lisant le source.
Parfois même, ne utilisant le soft!

Ceci dit, je suis un codeur, système, qui plus est (donc peu versé dans l'apparence).

Je te fiches mon billet que si tu colles ma belle soeur, qui a des études de beaux-arts dans les pattes (ouai, parce qu'en plus, moi, je sui auto-didacte, ça aide pas) ben elle peut reconnaître les artistes d'une photo à l'oeil, pour peut qu'ils soient connus.

Pour moi, l'art, c'est juste la sublimation d'un outil. Si tu sublimes un logiciel, il deviendra oeuvre d'art. De la même façon qu'une photo de famille n'est pas nécessairement une oeuvre d'art.

Du coup, c'est quoi, l'art?

Ces œuvres ont été dans tous les cas été probablement modifiées des milliers de fois par les nombreux conteurs puisque les plus vieux écrits datent d'après la création originelle.
Mais il n'y a même pas besoin d'aller aussi loin pour en voir des exemples, comme on l'a montré plus haut avec des œuvres contemporaines retouchées.

Hé, j'ai envie de faire une citation chinoise ici: "qui se couche avec le cul qui gratte, se lève avec le doigt qui pue".

Fort à propos, je pense, je m'en vais donc trolliférer sous d'autres threads :)

Une perche qui traine dans une image, ou une faute dans un texte, n'est pas un bug au sens logiciel du terme.

En effet, ni une perche qui traîne, ni une faute, ne sont des cafards…

Bon dieu, un bug, au "sens logiciel" du terme, c'est ce qu'on appelle en français: une anomalie, un défaut. Tu l'accuses de troller, mais tu te défends avec une mauvaise foi assez impressionnante.

De mon point de vue, l'œuvre devrait tomber immédiatement dans le domaine public à la mort de quelqu'un, mais la loi ne va généralement pas dans ce sens.

c'est difficile a dire, ça.

Moi, je suis d'accord, je compte nier l'héritage de mes parents, je considère que le plus précieux, ils me l'ont donné de leur vivant. Je vais donc refuser leur héritage matériel, quitte a y perdre des photos et, surtout, un poster anniversaire des 200 ans de la DDHC.
Mais, mes idéaux sont plus précieux à mes yeux (pour l'instant) que le souvenir d'un "trésor" (soyons sérieux, ce n'est pas de l'or, ce n'est un trésor que par le symbole que ce poster incarne).

Si tes parents, demains, meurent, refuseras-tu leur héritage matériel? Ou, demanderais-tu à tes filles et fils de le faire?
J'en doute.

Je suis sûr d'en choque plus d'un ici, mais dire que toute création d'une personne doit à sa mort revenir au domaine public, signifie la suppression de la notion d'héritage.
Faire le distinguo entre l'art et le matériel est déséquilibré. Passer du temps a créer une toile, ou passer du temps a créer une voiture, ou les plans d'une invention, c'est du pareil au même pour moi.

Les notions de brevets et de proprieté intellectuelle ont justement été créés pour éviter l'oubli.
Il est important de se rappeler que ces choses ont été créées afin de rémunérer ceux qui contribuent au futur, pas leurs descendances qui ne servent potentiellement à rien (genre, moi, j'ai été moins utile à la société que mon père, je ne mérite donc pas ce que j'hériterais quand il partiras, j'en ais d'ailleurs assez honte pour être résolu à ne pas accepter le bénéfice matériel qui en résultera… on en reparleras… ou pas en vrai…. quand je devrais accuser le choc…).
En fait, non, la notion de P.I. n'as pas été faite pour les rémunérer.
Elle a été faite pour rassurer les créateurs sur le fait qu'ils ne créeront pas pour être exploités par les marchands de tapis.
On voit, de nos jours, que ces lois ont été détournées en faveur non pas des créateurs, mais de leurs ayants droits. Ce qui à la base impliquait juste les héritiers (la notion de privilège est directement liée à la notion d'héritage hein) mais vu que de no jours un humain peut céder ses droits à une entité morale, ben, on a des droits qui sont liés à des sociétés, qui évidemment ne meurent jamais.
Ca ne protègent donc plus les créateurs, mais ceux qui rachètent leurs idées novatrives. Les génies meurent de faim, et la finance en tire le bénéfice.

Les parodies sont déjà autorisés quelque soit la licence.

Raté.

On peut très bien imaginer un pays fictif ou celle-ci seraient interdites. Et en pratique, il suffirait d'un rien pour que ce soit le cas en france, compte tenu du fait que la descendance hérite du privilège d'interdire les dérivés de l'oeuvre originelle.

Je ne répond pas forcément au bon niveau de l'arbre, mais…

Comme je l'ai écrit ci-dessus, je pense que l'art et le logiciel sont deux choses différentes. L'art vise souvent à créer quelque chose de personnel (un livre, un tableau) dans lequel on met sa notion de perfection, pas un outil qui va être utilisé par d'autres. Je peux comprendre qu'on souhaite mettre une clause "non modifiable" dans ce cas.

Je vois les logiciels comme un truc très personnel aussi.

Tu considère les outils comme conçus pour les autres. Je pense que c'est faux.
Un outils est d'abord conçu par une entité, pour celle-ci. Si cette entité, qu'elle soit homme ou société, en partage les plans, la façon de produire, d'autres pourront s'en servir pour leurs besoins et éventuellement partager les plans qui en résultent.

Dans l'art…. bah, c'est la même chose. Un art, c'est avant tout une technique maîtrisée pour pouvoir transmettre des sensations pour moi. Je ne vois pas en quoi c'est incompatible avec l'idée de partage d'information?

C'est quoi la diffence, entre anti-économiste et anti-militariste?

Le point inmportant est, "sans sections invariantes". Pourquoi la FSF aurait-elle intégré ça si ce n'est pour s'en servir? Pourquoi Debian aurait-elle mis la doc de GCC en non-free?
Et justement, je suis prêt à parier ma tournée (de bière à minima décente, dans les environs de rouen) que la doc de GCC en contiens au moins une.
Ouai, j'ai confiance. En Debian. Pas en la FSF.

Désolé, mais je considère personnellement que Debian a l'approche la plus pragmatique et la plus "pure". Et ça rejoins mon commentaire initial: a chacun sa version, on se regroupe par affinités, pas par pensées uniques.
Je considère souvent zenitram comme pertinent, je suis pourtant rarement en accord ses opinions (tu sais, zeni, tu es bien pratique :p).

Je pense que Trisquel intègre la doc de gcc, dans son dépôt main.

Alors, trisquel prouve que la FSF à une définition du libre qui n'est pas universelle ni même un consensus, et de facto, je m'opposerais à ce que la vision de la FSF soit l'image du libre, car mon idéal est plus proche de celui de Ian (on ne cite pas assez souvent le nom de cette personnalité qui je pense a révolutionné le libre mais était trop silencieux).

Donc, tout ce qui est libre doit être gratuit?

Donc en fait tout le monde (meme l'ISO) fait en sorte que ces languages soient librement implementable de facon gratuite et legale a 100%.

Comme tu dis. Le fait de faire des drafts est peut-être juste un contournement du problème d'avoir un standard gratuit.
Pas libre, gratuit.
La gratuité permets aux gens de construire des extensions qui, si elles elles sont efficaces et dans les bonnes licences, peuvent être intégrées aux standards internationaux (rien que ça… c'est vrai que ça manque d'ambition). C'est pas libre, parce que pour moi, un standard c'est l'opposé du libre: on définit une interface qui ne doit pas être modifiable, sinon on pète l'interrop, ce qui est pour moi plus grave qu'enfreindre les 4 libertés.

Pour moi, et c'est mon opinion très personnelle, l'inter-opérabilité est la chose la plus importante.
Le logiciel libre est un moyen d'y accéder, mais ce n'est pas le seul.
Sincèrement, les faits sont la, quand je suis passé de firefox 3.x à opera 9 (je crois) la raison était que opera respectait plus les standards, malgré le fait que le soft ne soit pas libre.
Hors, pour moi, avoir des logiciels interopérable rend plus libre qu'avoir accès au source, parce qu'un source en spagetti, bah, t'a beau y avoir accès, légalement et moralement, tu peux rien en faire. C'est la toute la blague du libre.

et sa documentation en sois aussi.

Bah non, elle utilise une licence qui n'est pas reconnue comme libre, du fait qu'elle permette de figer tout ou partie de la doc, ce qui est contraire au droit de modifier nécessaire pour se prétendre libre.

Quant à la doc de C++, c'est un autre sujet, le comité ISO n'a pas la prétention de défendre le libre.
Ceci étant dit, je n'arrive pas à retrouver rapidement sous quelle licence est le langage C++.
Je ne me souviens plus non plus de quelle fut la conclusion lors du jugement Oracle vs Google pour l'API Java, si une API est brevetable ou non…

Open-Source en C/C++ et ne pas payer de licence

Ce n'est pas parce que c'est libre qu'il n'y a pas besoin d'acheter une licence, en théorie.

D'un avis personnel c'est scandaleux pour ne pas dire un non-sens.

Pas du mien, parce que le fait que le C++ soit un standard probablement déposé fait que l'on sait qu'un code conforme fonctionnera avec tout compilateur conforme, et il y a peu de langages avec autant d'implémentations différentes que C ou dans une moindre mesure C++.
En fait, je pense pouvoir citer facilement 5 fournisseurs (dont un mort) de compilos C++. Pour les autres langages, à l'exception du bourne shell, je suis incapable de monter au-delà de 2 (Java, pour le coup, mais je pense qu'il doit y en avoir plus que ça).

httt c'est Heir To The Throne j'imagine, la campagne de base? Celle ou l'on joue Conrad pour reprendre le trône?
J'ai pas souvenir d'un scénar ou l'on perde tant d'unités que ça, mais faut dire qu'une campagne de plus de 15 scénars, ça deviens tellement long que les vétérans, à part les fidèles (sans entretien) on s'en tape un peu…

qui aujourd'hui partitionne son disque en plusieurs morceaux alors qu'il y a LVM ?

Moi, parce qu'au moins une partition GPT sera reconnue avec n'importe quel OS, alors que LVM je n'en suis pas sûr ([edit]ah, bah apparemment LVM marche sur plusieurs, bon à savoir).

En fait, je reconnais ne pas connaître les avantages de LVM.

Et puis j'ajoute ça dans le fstab et c'est marre

C'est ce que je fais aussi, pour le coup. Je précisais juste (pour l'avoir découvert récemment, hein) que GPT inclue un système d'étiquetage à priori (/dev/disk/by-partlabel/*).

Juste pour info, la doc de GCC est accessible dans Debian uniquement si les dépôts non-free sont activés. Et ce qui est amusant, c'est que la FSF reproche justement à Debian d'avoir cette section :) (me demande du coup, trisquel intègre-t-elle cette fameuse doc?).

Ma question : auriez vous une idées des commandes/manip qui pourrait m'éclairer sur ce qu'il se passe et donc sur ce que je dois y faire ?

La commande pour gérer les options de démarrage d'UEFI, c'est efibootmgr. Sa manpage est l'une des rares avec des exemples, du coup, je te conseilles sa lecture.

Sinon, je regarderais aussi avant tout si tu n'as pas écrasé la partition par erreur, et si tu as vraiment une partition EFI, juste pour vérifier.

Autre solution: il faudrait que les unités ne soient pas soignées quand elles évoluent, de sorte qu'une contre attaque soit possible.

Dans le cas que tu décris, si n'y avais pas ce auto-heal (qui tranche pas mal avec le "dans un vrai combat tout ne se passe pas comme prévu": dans un vrai combat, tuer un ennemi ne vous soigne pas ni ne vous rend plus fort) ou si la différence entre 2 niveaux était moins drastique.
Le fait qu'un niveau 2 puisse détruire assez aisément 2 niveaux 1 du même type n'aide pas non plus.

Après, il arrive de faire des parties longues en multi. Il reste toujours des world conquest, par exemple, qui ne sont pas des parties courtes, ou des RPG.
Mais clairement, les grandes cartes officielles ne me semblent pas super jouées.

À vue de nez, je dirais même que la carte officielle la plus jouée quand j'étais régulièrement dans le lobby, c'était "la croix de l'isard", mais je n'ai pas de chiffres officiels, et mes impressions remontent maintenant à plusieurs années.
Les autres sont jouées aussi, mais plutôt dans le ladder, donc très majoritairement des 1 vs 1, quand on est sûr que l'adversaire ne va quitter en milieu de partie (ce sont des parties avec classement après tout).

mais rarement une partie complète.

La plupart des parties de wesnoth sont des one-shots sur des cartes petites ou moyennes, et perdre une seule unité qui aurait du évoluer sans un enchaînement super improbable peut retourner une partie.
Pour ce qui est des campagnes, c'est sûr, il suffit de ne pas risque le chef, il reste lvl 0 ou 1 toute la campagne et on gagne sans trop de soucis.
Enfin, ça ne fonctionne que dans les campagne solo, parce que dans les campagnes multi que j'ai jouées, les joueurs font face à une vague largement plus puissante que leurs propres forces, sur un terrain aléatoire.
Pour gagner dans ces conditions, il faut analyser le terrain correctement, placer ses troupes correctement (en perdre plein, mais garder les unités clé en vie voire les faire évoluer).

tu peux perdre/gagner un combat entre deux unités

Le problème, c'est que dans des parties réellement difficiles, il n'y a pas de combat entre 2 unités. Ce sont des combats entre des armées. Qu'une unité rate toutes ses attaques alors qu'elle à 95% de chances de tuer passe encore. Quand ça arrive 3 fois d'affilées, bloquant le mouvement final que tu avais prévu, que tu parviens à compenser les trous, mais qu'a son tour l'IA détruise par chance plusieurs de tes unités qui compensent les trous crées par la survie miraculeuse de son unité, ben, si, ça change une partie.

Ça m'est arrivé plus d'une fois, assez pour me tuer une partie du plaisir (parce que je ne joue plus qu'avec les modes les plus difficiles, depuis le temps). Plaisir que j'ai justement pu retrouver avec le mod dont j'ai parlé plus haut, qui ne supprime pas le hasard, mais diminue considérablement les chances de miracles.

Après, je ne demanderais pas aux devs de l'intégrer dans le jeu par défaut, je signalais juste son existence pour ceux qui sont comme moi :)

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?