Pinaraf a écrit 3682 commentaires

Oula faut pas titiller les défenseurs de KDE 1, ils ont une mauvaise fois dont on a plus l'habitude.

Merci :)

Note, je n'ai jamais utilisé KDE 1, j'ai commencé avec le 2.0. C'est juste la comparaison idiote que je trouve… ben… idiote.

Au passage, le saviez-vous ? L'interface de Windows 95 était optionnelle, à l'installation on pouvait choisir de booter sur le "Program Manager" de Windows 3.11…

Il est moins proche que serenity, mais l'explorateur de fichier, les décorations de fenêtre, le menu "démarré" et la barre des tâches sont très inspirés. Vu la capture je dirais qu'ils se sont inspiré mais n'ont pas cherché à reproduire et ont donc fais des choses en plus et rendu les choses paramétrables.

Tout comme Windows 95 était très inspiré d'autres éléments de l'époque, eux-mêmes très inspirés d'autres qui ont précédé… Et c'est le fond de ma réaction au final, je trouve ça insultant pour le projet KDE de systématiquement l'abaisser à une "copie de l'interface de Windows". Il faut être aveugle ou d'extrême mauvaise foi pour dire que la différence entre KDE 1.0 et Windows 95 est minime.

Ou alors à mon tour tiens, je me lance : je trouve que la différence entre Gnome 42 et notepad.exe est minime. (bah oui, à force de retirer des fonctionnalités…)

KDE 1.0 et FVWM95 étaient déjà sur le créneau, la différence avec windows était minime.

Alors pour FVWM95 je ne dirais pas, mais pour KDE 1.0… Je vois toujours pas.

https://llu.is/wp-content/uploads/2009/08/KDE_1.0.jpg

Si ressemble à Windows tout système avec une barre en bas de l'écran… Que dire de par exemple CDE sorti avant Windows 95 ?

C'est juste irréaliste de s'attendre à ce que chaque bootloader fasse tout ce travail sur chaque carte ARM ou RISC-V qui existe.

Alors je ne suis pas beaucoup intervenu dans ce fil, mais note bien que ma déception est quant au choix d'UEFI, pas quant au choix d'avoir un firmware ou non. Je maudis les cartes ARM "nues".
D'ici quelques semaines (le temps de finir le remplacement de mon serveur actuel un peu limite) je n'aurai plus que des cartes ARM64 équipées d'un Petitboot. Et pour le coup, ça me semble répondre au problème bien plus proprement qu'un UEFI : au lieu d'avoir une réinvention de toute la pile de stockage, le réseau, l'affichage et je ne sais combien d'autres pilotes, on prend un noyau Linux et on le colle dans l'EEPROM, et une simple appli en espace utilisateur, remplaçable/bidouillable à souhait, s'occupe d'afficher un menu, charger l'OS cible…

Le but dans Ladybird est de ne pas utiliser QtWebEngine. Et je suppose qu'à la base, le développement de Ladybird permet d'avoir un navigateur dans Serenity sans avoir à supporter l'immensité des dépendances de Blink, WebKit ou Gecko.

Dans la doc où j'ai découvert de projet, il est question d'une image EFI de GRUB, logée dans la partition EFI, et qui serait exécutée par U-Boot. Quand tu as parlé d'UEFI, j'ai pensé que tu parlais du firmware de la carte.

Une image EFI de grub implique qu'un environnement UEFI tourne, avec tous ses "Boot Services" et tout le toutim.
D'ailleurs ton lien sur OpenSBI mentionne bien l'idée de reprendre EDK2, implémentation libre d'UEFI…

L'article parle clairement d'une partition EFI, je suppose pour désigner une partition d'UUID C12A7328-F81F-11D2-BA4B-00A0C93EC93B sur une table GPT, ie une "EFI System Partition".
Si le but est d'utiliser une partition ESP pour ne pas y stocker des exécutables EFI mais plutôt pour y stocker des fichiers arbitraires, mea culpa dans ce cas, mais c'est un détournement dégueulasse.
Je pensais qu'il s'agissait plutôt de ce genre d'utilisation d'u-boot, dans l'exemple ici pour le projet Fedora qui souhaiterait ne pas se poser la question et avoir un environnement UEFI au démarrage, y compris sur les x86 à BIOS…
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/GOETDM5SWINBX5ZDV37SWMHIPRRUVVTT/
Et si on est dans ce cas, je trouve ça terriblement triste. J'ai déjà goûté de loin à de l'OpenFirmware, et de plus près à du PetitBoot, et je trouve PetitBoot extraordinaire par rapport à l'enfer d'un UEFI. (Et quand j'aurai du temps libre, je finirai ce que je compte bidouiller sur PetitBoot et j'en ferai un journal, promis.)
Je ne comprends pas pourquoi on s'imposerait cette calamité sur des plateformes qui n'ont clairement pas mérité ça.

Yay, encore des machines où on va mettre de l'UEFI parce que … parce que quoi en fait ? y'a un Windows RISC-V prévu bientôt, avec uniquement le support de ce firmware ?

Par curiosité, est-ce que le rapport coût/bénéfice est bien raisonnable?

Coût : tu l'as dit.
Bénéfice : ne pas perdre des (gros) clients qui exigent ça parce que c'est dans la liste des cases à cocher…

Donc… oui c'est raisonnable, même si c'est assez idiot d'en arriver à mettre ça en place.

C'est hélas un regrettable oubli, mais moins grave pour les distributions où c'est bien empaqueté.

Idem pour jGnash alors, il n'était pas nécessaire de dire qu'il dépend de Java puisque s'il est bien empaqueté tout roule.
Et c'est la même chose pour tous les autres. Ils vont dépendre de compilateurs, de bibliothèques et d'autres éléments qui font que l'empaquetage doit être bien fait.

Donc : pourquoi faire une différence sur Java ?

Bref, pour moi, c'est justement pareil que d'indiquer qu'il faut Mono (ce n'est pas juste un binaire statique ni un script qu'on passe à un interpréteur.)

Alors pourquoi n'est-il pas indiqué qu'il faut Mono pour Denaro ?
(Et j'ai pas essayé, mais normalement on peut désormais faire des binaires à partir de projets Java…)

C'est amusant ce choix d'écriture.
D'un côté on a diverses applications avec des dépendances, Python, Ruby, Mono… Et de l'autre on a une application qui dépend du JRE, et là, attention : on précise bien qu'il faut le JRE pour elle…

Y'a un ".dmg", ça marche plus sur MacOS ?
https://binary-factory.kde.org/view/MacOS/job/Kate_Release_macos/

Mais c'est bien normale, y'a pas deux souci. J'aime bien l'apprendage des choses sur linuxsaitfaire.

Peux tu me dire ce que tu pointes en particulier ?

J'avais perdu ça dans le message.
Je me suis infligé le documentaire une seconde fois pour trouver ce qui suit.

Montrer ainsi une corrélation est très dangereux.

À partir du moment où tu interroges des personnes largement décriées qui continuent de crier des contre-vérités basées sur des études scientifiques biaisées et amplement "débunkées", tu peux être dans deux cas :
- étudier les dérives de ce genre de personne, avec le bon contexte qui précise qu'elles ne parlent qu'avec des œillères bien particulières,
- propager leurs idées, que ce soit par soutien ou juste parce que ça sert ton contenu.

Ce documentaire est dans le deuxième cas. Et quand on me vend comme mise en bouche de la vidéo une image avec écrit en grand «Science», c'est une fumisterie dangereuse.

J'ai vu ce documentaire y'a quelques jours. Assez vite, pas mal d'éléments ont commencé à me perturber, notamment l'assimilation de la corrélation à une causalité sur certains éléments.
Du coup, un peu de recherche… hooo, dans le lot des gens interrogés, il y a des anti-vaccins notoires, notamment certains illuminés qui accusent les vaccins de provoquer l'autisme (Michel de Lorgeril).

Quand on se permet d'interroger ce genre de personne dans un documentaire, c'est qu'on a abandonné tout sérieux et toute rigueur.

Non, mais rien ne dit qu'il n'y en avait pas, et c'est le sens de ma blague.

Expérience personnelle : dans un taf précédent, on a demandé à des collègues de former des prestas dans le but explicite de délocaliser le travail en Inde (et donc de laisser partir les collègues français). Tu penses que les collègues étaient encore motivés ?

Une des blagues quand j'étais presta est qu'heureusement qu'on était là car les internes ne foutaient pas grand chose.

Les prestas sont arrivés parce que les internes étaient démotivés ?
Ou les internes étaient démotivés parce que les prestas sont arrivés ?

Vous avez 2H.

Ben non c'est une déviance du capitalisme francais parce que les choses ne sont pas identiques ailleurs.

Oui et non. Je ne sais pas pour les services infos dans le reste de l'Europe, mais mes potes de lycée devenus ingénieurs en méca, dont un dans l'automobile, sont largement témoins des déboires qui sont arrivés à leur domaine, et ce dans d'autres pays (Belgique, Allemagne).
De plus en plus les constructeurs automobiles vont sous-traiter des pans entiers de conception. Mais du coup, quand le constructeur A fait appel au sous-traitant X pour la conception d'un nouveau système d'essuie-glace à rayons laser, puis que plus tard B fait appel à X pour un systéme équivalent… on peut arriver à des situations ubuesques où la voiture de B sortira avant celle de A, sans qu'il n'y ait vol de propriété intellectuelle : c'est juste que les équipes de X ont passé du temps à essuyer les plâtres, et cette expérience n'était pas rattachée à l'entreprise A.

Autre facteur d'ailleurs : quand on a tout mis en place pour passer par une ESN… on peut faire jouer la sainte concurrence et passer d'une ESN en France à une ESN en Inde ou un autre pays à bas coût.

Si c'est ca, c'est con mais c'est fascinant.

Exactement. Je t'invite à l'encadrer cette phrase :)

Qui dans l'entreprise fait l'analyse que la seconde ligne compatble qui coute plus chère est nettement mieux?

Personne, puisque ce n'est pas le but.
Ça améliore par contre des indicateurs importants pour les investisseurs, importants pour la bourse.
Le recours aux ESN n'est au final qu'un signe de la déviance du capitalisme. On n'a jamais intégré dans la valeur d'une entreprise l'ancienneté (et donc l'expérience) de ses salariés. Ça n'existe pas.
Par contre, ce qui a été intégré, c'est le risque de devoir payer des indemnités de licenciement XXL aux salariés (XXL, qu'on s'entende bien, reste négligeable par rapport aux sous que se versent la plupart des dirigeants de ces boites).

Alors, je précise immédiatement : je déteste ces arguments.
Ceci dit, voici ce que j'ai pu observer/entendre, notamment dans mes activités de membre d'un CSE :

• «personne n'est irremplaçable», traduit par beaucoup de managers en «on peut prendre n'importe qui avec des contrats externes, pour faire n'importe quelle tâche assurée par quelqu'un en interne» (parce que c'est bien connu, l'expérience, ça ne compte que pour les managers et dirigeants)
• un externe, c'est quelqu'un qui ne compte pas dans les effectifs, qui n'a pas de représentant du personnel, pas de défense en cas de litige…
• en cas de coup dur, les externes disparaissent d'un claquement de doigt, les internes c'est plus compliqué,
• niveau comptable, c'est pas la même ligne du tout, et dans toute l’irrationalité d'un système comptable, vis-à-vis des investisseurs, il vaut mieux payer plus dans cette ligne que de payer plus dans la ligne salaires.

En fait tout se résume au mépris total de l'humain. C'est dans le nom d'ailleurs, «Gestion des Ressources Humaines», pas «Gestion du personnel». Tu es une ressource, pas une personne.

Tout dépend de la communauté existante et de son acceptabilité d'un tel changement.
Sur par exemple le noyau ou le projet PostgreSQL, un tel changement serait extrêmement difficile à faire passer car complètement incompatible avec les usages de la majorité des développeurs (incompatible est encore trop faible comme mot d'ailleurs, on peut même parler de destruction d'outil de travail).

D'ailleurs, dans les plaintes contre la migration de GNOME sur discourse, j'en ai vu une assez intéressante : il s'agissait des développeurs d'evolution… Et effectivement, c'est «amusant» de voir qu'on retire aux développeurs d'un logiciel un outil de communication qu'ils utilisaient avec leur logiciel.

Discourse fournit une API rest il me semble, donc si ça doit être possible: https://docs.discourse.org/openapi.json

J'adore ce genre de réponse. «y'a une api, c'est bon, tu peux coder ton client dans ton coin». Ça me fait penser à ceux qui me traitent de passéiste à vouloir garder XMPP pour qu'on continue à avoir nos clients desktops et pas des bousins en JavaScript, avec exactement le même argument de l'API.
La présence d'une API, si tant est qu'elle soit complète, n'est pas suffisant. Ne serait-ce que du point de vue du développeur d'un client : Si demain une fonctionnalité est ajoutée sur l'interface web mais absente de l'API, et qu'elle rend des éléments invisibles, comment faire ? Comment être notifié de l'arrivée de nouvelles APIs ? Et c'est pas un travail anodin, c'est long et fastidieux de faire un client pour ce genre d'usage.
Puis du point de vue d'un utilisateur qui explique qu'on lui retire son outil, «t'as qu'à t'en coder un», c'est une excellente idée ma foi…

Également, d'un point de vue philosophique, pourquoi est-ce-que je développerais un client pour un logiciel, certes libre, mais avec un protocole propriétaire à ce logiciel, et chapeauté par une entreprise dans un paradis fiscal ? Dans mon taf précédent, on subissait Slack, j'avais commencé à coder un client alternatif en Qt… Je l'ai utilisé un temps, mais j'en ai arrêté le développement, car au final rendre Slack utilisable, c'est améliorer cet outil, et c'est clairement pas à moi de le faire sur mon temps libre…

Je n'ai pas cherché mais il y a probablement déjà des interfaces pour terminaux.

J'ai cherché, je n'en ai pas trouvé. En tout cas pas dans les paquets Archlinux, ni les paquets Debian, ni sur Internet.

D'ailleurs, ça n'a pas été listé lors de la discussion du projet Debian sur une éventuelle utilisation de Discourse, cf https://lwn.net/Articles/817668/