Spyhawk a écrit 1154 commentaires

Bon, ben apparemment c'était plus simple de recoder un truc sur l'existant que porter des technologies internes vers la plateforme Linux.

Visual Studio Code, c'est en fait basé sur Atom, l'éditeur de GitHub basé sur la technologie Chromium, et qui est dispo sous licence MIT.

C'est un premier pas, mais faut pas espérer (ou pas) voir la suite VS sous Linux avant un bout de temps.

C'est triste, ton avis sur le comique d'anti répétition…

Libre à toi de faire joujou dans un monde réduit à l'Europe, mais dans le monde réel d'Internet et de l'informatique difficile de jouer sans les USA.

C'est ça le plus triste avec les brevets logiciels. Même s'ils ne sont pas valides en Europe, en pratique ils s'appliquent quand même de facto par effet réseau… :/

Comme chez OpenSuse ! Alors ça c'est cocasse…

Tiens, les gars de chez openSUSE devraient s'étonner qu'il y ait autant de projets à l'appellation similaire au leur!

Ben il l'a déjà trouvée, mais si un jour quelqu'un veut documenter la résolution de problème sur le wiki…

Ça, c'est déjà documenté dans le wiki :)

Actuellement je peux rien installer via yaourt et me retourne sans cesse une erreur au sujet de --assroot…

Le paramètre --asroot est déprécié depuis la dernière mise à jour de pacman. De plus, utiliser yaourt (construction de paquets AUR) en utilisateur root, comment dire… oui, Arch est vraiment un très, très mauvais choix pour toi.

Conclusion en cas de problème démerder vous ?

Conclusion: en cas de problème avec Arch, c'est démerdez-vous et placez la solution dans le wiki quand c'est résolu.

Sinon un début de solution a proposer ?

Y'a une certaine probabilité qu'il ne soit pas le premier à être confronté au problème, et qu'il suffit d'aller chercher la solution dans le wiki Arch. Mais faut encore vouloir ouvrir son navigateur et aller lire l'article qui va bien (le monsieur n'a "pas envie" de faire ce petit effort). J'ai pas essayé parce que j'ai pas de carte ATI/AMD, mais j'ai trouvé la solution en 20 secondes.

Il est clair qu'il a très mal choisi sa distribution. Avant d'installer Arch, faut encore s'assurer d'être dans le public cible, hein!

Je pourrais retrousser mes manches et m'occuper de ces deux problèmes, mais je n'en ai pas envie.

Ces quelques mots résument le journal, au final très peu intéressant.

Sinon moi j'aime pas les olives, surtout sur les pizzas 4 saisons avec anchois.

Je vois. Je vais ajouter une feature request dans le tracker.

etl +connect et://gg.illwieckz.net:27961

Heu oui, j'ai lu ton message un peu trop vite. "+connect" est nécessaire pour la ligne de commande, je faisais plutôt référence au lien dans le navigateur. On garde +connect pour compatibilité avec les clients Wolf:ET existants.

A propos de tes serveurs, les utilisateurs qui n'ont pas les .pk3 déjà installés recoivent ces paquets téléchargés automatiquement… mais c'est très très lent avec l'installation ET/ET:L de base (j'ai essayé sur ton serveur). Il faut utiliser un serveur FTP annexe qui s'occupe de distribuer les fichiers aux joueurs. Tu trouveras plus d'info sur Internet, par exemple, ici (bas de page) ou le canal IRC.

C'est le même principe qu'Unvanquished, mais sous Linux ça ne fonctionne pas avec la version statique. En effet, la gestion du protocole dépend des fichiers .desktop et .xml qui doivent être installés dans /usr/share/applications et /usr/share/mime/packages respectivement. La base de données MIME doit être ensuite mise à jour avec la commande update-mime-database /usr/share/mime.

Ca devraient en revanche fonctionner sans problèmes avec les versions empaquetées.

Donc maintenant je ne fais plus de apt-get upgrade je me contente de mettre à jour les programmes « terminaux » (browser, client mail, suite bureatique, etc…) ce qui va aller mettre à jour quelques bibliothèques, seulement quand c'est nécessaire… La seule exception étant le noyau que je mets à jour de temps en temps même si ce n'est pas nécessaire.

Les mises à jour partielles ne risquent-t-elles pas d'introduire des problèmes?

Je ne vois pas où tu veux en venir. Il n'y a rien à écrire, il n'y a qu'à maintenir l'existant parce que les mainteneurs qui faisaient un certain boulot décident de ne plus s'emmerder à le faire, et que si ceux qui en profitaient avant veulent toujours profiter de ce même travail, ben ils n'ont qu'à le faire eux-même.

Le problème chez Debian, c'est qu'elle se revendique plus ou moins comme une "démocratie au service de l'utilisateur", ou qu'elle est vue en tant que telle par une partie de ses utilisateurs. Y'a effectivement une recherche de consensus sur différents sujets, mais tant que les mainteneurs ne seront pas des esclaves, Debian est et restera une do-ocratie comme toutes les autres distrib communautaires.

Note que je ne parle même pas d'écrire une alternative, mais de se bouger les fesses pour maintenir les codes existants, comme proposé par debian qui accepte toutes contributions pour garder sysvinit fonctionnel.

Qu'est-ce qu'a apporté de bien systemd ? Du troll, des forks, du temps perdu pour tout le monde…

Avant tout chez Debian, hein. Pour ceux qui y sont déjà passé, c'est du temps de gagné, du code à maintenir en moins, des utilisateurs déjà formés/déjà habitués (parce que y'a que Debian qui trainnasse pendant 3 ans). Et parmi les utilisateurs qui râlaient, y'en aucun qui s'est sorti les pouces du c*l pour travailler à maintenir l'alternative sysv, preuve que c'est pas si indispensable que ça, surtout quand on doit mettre la main à la pâte.

Pour les BSD, tu te trompes de cible: crache plutôt ton venin sur Gnome et consort, ce sont eux les responsables.

Pour ces gens la couleur représente une dimension supplémentaire de projection dans un espace par nature inaccessible.

C'est pour ça qu'en général, on recolorise l'image en "mappant" les niveaux de gris sur une plage de couleur. C'est pas toujours possible de rester fidèle à la réalité (puisque ça dépend de la plage de longeur d'onde sélectionnée initialement), mais on peut effectivement obtenir des images plus jolies visuellement après coup.

On utilise la fausse couleur parce qu'elle donne plus d'information utile que la "vraie" couleur du spectre visible. En gros, on va pas faire des photos à 150 millions de kilomètres rien que pour les beaux yeux du public tout en envoyant de l'information dégradée pour les scientifiques.

Les photos sont effectivement très belles, l'imaginaire que nous projetons dessus leur donne un éclat particulier mais je me demande pourquoi ces images sont en noir et blanc

C'est de la fausse couleur, tout simplement.

Oui, tu as entièrement raison à propos du CLA. Ce n'est cependant pas le cas des projets basés sur ioquake et j'ai oublié ce "détail" dans ce contexte. Merci de l'avoir rappelé!

Sans compter la facilité "BSD = viable" qui est limite du FUD…

J'aurais du utiliser les termes "du code libre est plus difficilement viable que du code que l'on peut fermer". Un code proprio n'obtient bien évidemment pas forcément le succès escompté.

Merci pour ce post détaillé et tes éclaircissements!

Autre exemple, Debian fait bien attention de mentionner (de manière lisible par une machine !) les licences de chaque fichier d'un paquet : http://dep.debian.net/deps/dep5/.

Et bien, je savais que Debian était très à cheval sur les licences, mais je ne pensais pas qu'ils iraient jusqu'à traquer les licences de chaque fichier…

C’est un ajout d’ioquake ou c’était comme cela dans le moteur quake 3 de base ?

Ca semble être rajouté par ioquake. Sinon, le projet lui même ne distribue pas de binaire "standalone", mais ça peut aussi se faire au niveau des distributions pour la version Linux. C'est peut être même très logique de découper ioquake par défaut pour éviter les redondances avec d'autre jeux basés sur ioquake.

Un moteur commun, oui très bonne idée, mais faut que chaque projet y mette la volonté.

Spearmint je connaissais, mais je n'ai aucune idée de sa popularité dans le milieu.

Le mod se link avec le moteur et le code du mod est aussi en GPLv2+ ou 3+ pour RTCW/ET. Du coup là aussi ça ne fait pas de sens de ne pas voir les mods comme de simples plugins du moteur (concrètement ce sont des .so chargés dynamiquement).

Le point que j'essayais de souligner est que ça ne sert pas à grand chose d'avoir du code de type OSP dans le moteur. Tu as plus l'air d'en vouloir à ioquake parce qu'ils n'ont pas fait évolué la partie mod dans ce sense, mais ce n'était pas forcément leur objectif.

Je n'ai jamais dis l'inverse et c'est ce qu'il se passe effectivement.

Implicitement, je voulais faire passer l'idée que tes contributions à ET:Legacy seraient bienvenues :), puisque tu avais l'air motivé à travailler sur le code de WolfET (à moins que tu pensais plutôt à WolfSP).

Ce que j'ai oublié de dire c'est que généralement avoir un code libre ferme pas mal de portes par rapport à l'industrie du JV.

Le troll GPLv2+/GPLv3+ est stérile, mais ça par contre c’est super intéressant, tu pourrais détailler plus ? :)

Mouai, alors ça je ne sais pas si c'est vraiment le cas. Un contre exemple est l'auteur d'OpenWolf qui a décroché un job dans l'industrie du jeu vidéo justement grâce à ses démonstrateurs.

Après, c'est sur qu'un jeu en GPL est très difficilement viable économiquement par rapport à du code BSD que l'on peut fermer (pour les versions futures) et en faire un jeu proprio.

Pourquoi ne peut-on pas lancer avec le moteur ioquake3 un mod complet ne reposant sur aucune donnée de Quake3 sans posséder les données de Quake3? Pourquoi ne peut-on pas lancer avec le moteur openarena un mod complet ne reposant sur aucune donnée tierce sans installer les données d’OpenArena?

J'ai jeté un oeil au code de ioquake, et je ne vois pas vraiment de raisons techniques que le fait de s'assurer que l'utilisateur dispose des données d'origine avant de se connecter. Peut être pour limiter la quantité en download, les données représentant une quantité de Mo pas négligeable s'il faut les télécharger à la volée (surtout il y a 10-15 ans).

Par contre, il est possible de compiler ioquake avec le paramètre "STANDALONE" qui enlève cette limitation pour les mods qui ne réutilisent aucunes données, c'est juste pas fait par défaut donc ça semble plus être un souci de packaging ici.