Spyhawk a écrit 1154 commentaires

Le problème est peut-être venu de mon côté, mais j'en doute, j'avais 2 machines: 1 pour l'install, l'autre pour avoir accès à la doc, et j'ai suivi bêtement celle-ci.
mais je me souviens parfaitement de la raison pour laquelle pacman refusais d'installer: dbus pas disponible dans la bonne version.

Le principe d'une install Arch est
1. d'installer la base avec les ISOs à jour,
2. mettre à jour la base,
3. commencer à construire sur cette base à jour.

Soit tu as oublié l'étape 2, ou alors t'as vraiment pas eu de chance et tu as fais ton install juste au moment ou la nouvelle version de dbus se propageait sur les miroirs (30 minutes à 4 heures, selon le miroir).

Si c'est l'utilisateur qui est responsable de ce que fait la distro maintenant…

Sur Arch, ça l'est. L'utilisateur est en contrôle totale de sa distrib, mais avant tout entièrement responsable de celle-ci.

Arch Linux targets and accommodates competent GNU/Linux users by giving them complete control and responsibility over the system.

Et si ce dernier point pose un problème à un utilisateur, c'est tout simplement que l'utilisateur en question n'a pas choisit la bonne distrib.

Peut-être ça oui (les bidulKit dépendent de dbus non? je sais pas, je les installe pas :D ).
Oui, c'est lié à dbus.

J'avais eu envie de tester arch parce que, justement, j'espérais apprendre un peu plus sur mon système,

J'ai personnellement beaucoup plus appris sur suse/opensuse (distrib réputée graphique et click-click) et très peu sur Arch, donc le choix de la distrib est assez relatif. Faut aussi dire qu'à l'époque, c'était plus compliqué qu'aujourd'hui.

Je comprend qu'on puisse aimer ça, mais c'est juste que quand je lis "arch, c'est facile, ça demande pas de maintenance, ça casse jamais […]" alors que l'esprit de la distro et ma propre expérience personnelle (très limitée pour le coup) disent le contraire… bref.

"Pas de maintenance" est clairement mensonger. Par contre, le niveau de maintenance requis est relativement bas (1 ou 2 interventions manuelles par mois) et prend très peu de temps seulement. Merger les *.pacnew prends seulement quelques secondes, mais encore faut-il le faire…

Et pour casser un système Arch qui marche, il faut vraiment y aller comme un bourrin, ou alors ne pas faire de maintenance/update pendant plusieurs mois (6 et plus). Là ça devient compliqué, parfois même très sport même si pas impossible (certains utilisent le non officiel Rollback Machine - perso je n'ai jamais fait et je n'en aurait probablement jamais besoin).

Un autre problème que je vois est que les utilisateurs débutants ne savent pas utiliser l'AUR sans un wrapper. C'est d'autant plus accentué que l'AUR helper le plus populaire (en tout cas dans la communauté FR) est disponible sous forme binaire dans le repo [archlinuxfr] ce qui est une totale aberration.

Je ne dis pas qu'Arch c'est de la merde, mais de dire que ça casse pas alors qu'il n'y a même pas de média d'installation exploitable par un nouvel arrivant, qui n'est pas un (gros) débutant avec linux, me semble quand même à l'opposé d'une distro qui casse jamais.

Euh, xorg n'est pas livré sur le média d'installation, donc je vois mal comment ton problème peut y être lié. Je pense que l'erreur vient de ton côté… A moins que tu ai utilisé un ancien média vieux de plusieurs mois/année, où là effectivement c'est pas évident (mais là aussi, t'avais qu'à prendre les derniers ISOs :P).

Donc, gentoo semble offrir plus de flexibilité que Debian
Gentoo est définitement plus flexible que Arch dans tous les cas. Tu en apprendras plus, c'est certain, mais je suis pas sûr que cette connaissance ne s'appliquera pas qu'à Gentoo. Arch, c'est un peu comme Slackware, minus le gestionnaire de paquet: "On apprend pas Slackware, mais Linux".

Juste pour remettre les choses à plat, je n’ai aucune haine. Mot que je trouve un peu fort d’ailleurs. Je me suis juste posé la question de pourquoi, certains mettaient leur distribution en avant de manière systématique et pas les autres. Ça me fait un peu penser aux « first » sur certains forum… Alors je me suis dis que ça ferait peut-être faire un bon journal de vendredi.

D'accord. Comme dit dans un autre message, d'autres distributions ont également connu ce phénomène (Debian, Mandrake, Gentoo, Ubuntu et maintenant Arch). Je vois que tu es assez ancien sur LinuxFR (compte crée en 2002), donc je me demande où tu es passé toutes ces années :P

Et pour commenter un peu plus sur cet "effet de mode" Arch, je ne pense pas que cela dessert les intérêts de la distribution elle-même. Arch se veut avant tout discrète et efficace plutôt que d'avoir une large base utilisateurs. Voir la FAQ:

Q) Arch needs more press (i.e. advertisement)
A) Arch gets plenty of press as it is. The goal of Arch Linux is not to be large, but rather, to provide an elegant, minimalist and bleeding edge distribution focused on simplicity and code-correctness. Organic, sustainable growth occurs naturally amongst the target user base.

Et être un utilisateur Arch, pour moi, c'est avant tout rester dans cet esprit non prosélitique.

Aussi, je suis certainement plus ancien que la moyenne des utilisateurs Arch (même si pas toujours en système principal), et voir comment la communauté évolue dans son ensemble ne me réjoui guère. Sincèrement, à lire les forums officiels certains n'ont strictement rien à faire sous Arch. Arch est vraiment sympa sur plein de points, mais elle n'est certainement pas destinée à tout le monde, bien au contraire.

A vue de nez, 6-7 mois. Le conflit de dépendance était, de mémoire (et la mémoire au bout de 6 mois… bref) , au sujet de dbus, ou un truc qui n'avait en tout cas rien à voir avec Xorg, si j'en crois les dépendances qu'il a dans Debian.

Le seul possible problème que je vois et qui pourrait(?) éventuellement correspondre est le passage de ConsoleKit/Polkit à logind en octobre passé. Ca a suivi logiquement la migration à systemd (plutôt un gros morceau dans l'année 2012), et ça a requis une intervention manuelle. Et c'est un fait, Arch demande explicitement des interventions manuelles et ne s'en dément pas. C'est fait par "design".

Alors là, je ne vois pas de quoi tu parles. Je ne vois personne ici faire de l’autosuggestion pour la gentoo. Les mises à jour, même s’il y en a beaucoup n’ont pas besoin d’un outil spécial pour ne rien casser.
Le seul reproche que tu pourrais faire, à la rigueur, c’est le temps d’installation de logiciel comme libreoffice, kde…

Je commence sérieusement à croire qu'il faut que tu ailles prendre l'air quelques minutes, et que tu fasses la mise au point sur ta haine d'Arch/des Archistes (même si je suis entièrement d'accord avec toi sur le caractère prosélitique énervant de certains).

Je ne fais aucun reproche à Gentoo. Par "difficulté", je faisais référence au processus d'installation qui donne quand même bien plus de fil à retordre que celui d'Arch. Pas plus, ni moins. En écrivant ce mot, je n'y ait même pas pensé d'une façon connotée négativement, bien au contraire!

J'ai testé. Pendant 3 jours, j'ai tenté d'installer un Xorg qui était cassé :)

Aucune idée à quoi tu fais référence. C'était une tentative récente?

Je compte bien passer à une autre distro après ma Debian adorée, et ce sera une distro plus difficile, sinon s'pas drôle, mais je pense que gentoo sera mon choix, pas arch.

Si tu cherches la difficulté, essai Gentoo. L'installation d'Arch est plutôt simple, et une fois la base posée on obtient un environnement de bureau complet en 2 ou 3 commandes additionnelles.

C'est le problème des dépêches écrites collaborativement. Même si tous les auteurs ayant participé sont cités, la dépêche est publiée sous un seul nom (typiquement celui qui à commencé la dépêche). Même problème avec les XPs générés par l'écriture d'une dépêche, ils ne sont pas redistribués entre tous les participants.

Vu la longueur de ton post, tu es sous Debian et tu attends la fin du freeze pour faire la mise à jour. J'ai bon?

Il y a plein de trucs qu'il faut configurer simplement pour que ca marche. Alors qu'un choix rationnel par défaut irait très bien. J'ai souvenir de trucs hallucinants dans le wiki du genre " Une fois le démon installé penser à lui attribuer un utilisateur dédié plutôt que celui de l'install pour que ca soit secure ". Simplement la semaine dernière.

Peut être Pdnsd? Et c'est plutôt l'exception que la règle.

Une bête installation de 0 n'a jamais réussi à faire tourner ni gnome3 ni gdm.

Faut pas pousser non plus, hein. Y'a plein d-Archers qui utilisent Gnome au quotidien. Je n'utilise pas Gnome, mais pour KDE un bête "pacman -S kdebase" suffit (ou quasiment).

Mais ce qu'on peut souvent en lire ici me semble assez loin de la réalité. Ne parlons même pas d'AUR ou quand tu regardes la gueule des packages et les discussions, tu fuis loin, très loin.

Les paquets dans l'AUR sont de qualité assez variables, c'est un fait. En général, se limiter au strict minimum de paquets AUR suffit largement à se prémunir des "systèmes qui pêtent à chaque mise à jour". Les paquets binaires sont plutôt bien maintenus, et même avec des paquets AUR il suffit de ne pas faire de mise à jour en total aveugle pour que ça passe sans problème (en gros, prendre sa responsabilité d'utilisateur Arch).

Après avoir installé Debian, je n'installe ni X ni un environnement de bureau.

Bah oui, puisque tu viens de les installer, justement. Et pour la configuration?

En fait, il n'y a pas d'Archers sur LinuxFR. On sait tous que Debian est la distribution unique, et que Slackware "is taking over the world":

Recommendations officielles du wiki LinuxFR:

Debian:

Si vous ne voulez pas avoir l'air d'un vieux schnoque dépassé sur LinuxFr, dites que vous êtes un utilisateur d'Arch-Linux ou d'Ubuntu à la limite.

Slackware:

Si vous ne voulez pas avoir l'air d'un dinosaure dépassé et au bord de l'extinction sur LinuxFR, dites que vous êtes un utilisateur d'Arch-Linux.

Ubuntu:

Si vous voulez survivre sur LinuxFR, dites que vous êtes un utilisateur de Debian ou à la limite d'Arch-Linux.

Bien sûr que c'était une blague. Ou alors je comprends parfaitement le problème de la reconnaissance des doctorats en France.

12 à 18h? Et ça ose se plaindre? :)

Pan ! Pan !

Donc pourquoi ne pas passer le code de ioQuake3 en GPLv3 ? D'ailleurs, dans un tel projet donné à la communauté, qui a le droit de prendre une telle décision ?

L'ensemble des contributeurs doivent donner leur accord. En cas de refus, la partie de code des individus concernés doit être réécrite.

Saluons l'intelligence de Raven pour avoir publié les sources sous GPLv2, et non GPLv3. Ca évite clairement les embrouilles juridiques (citées dans un récent journal) que connaissent Enemy-Territory et tous les dérivés qui ont repêcher du code sous GPLv3 incompatible.

Hônnetement, je ne sais pas. Ce genre de procédures sont longues et douloureuses comme tu le dis, et j'estime personnellement que le temps et l'énergie requis n'en vaille pas la chandelle. Les Debianneux sont de toute façon prêts à faire ce sacrifice :P

Par contre, on me souffle dans mon oreillette (sur #etlegacy) que ioquake3 est licencié sous 'GPLv2 and later' ce qui permet de porter les améliorations de ioquake3 dans ET:Legacy (mais pas l'inverse). Je n'ai en revanche pas réussi à vérifier cette information, ni sur le site web de ioquake3, ni dans les fichiers sur le dépôt GitHub.

Si c'est vrai, alors ça enlève cette ambiguité légale du pied d'ET:Legacy. Par contre, tous les projets qui ont pioché dans ET:XReal (et peut être XReal directement?) sont dans la muise pour l'éternité.

Tu veux dire qu'ils mélangent GPLv2 / GPLv3 en se disant que c'est pas grave ?

C'est cela. Juridiquement, il est illégal d'utiliser des bouts de code couverts sous l'une des licences avec l'autre. Dans le contexte d'ET, ca se traduit directement par un nouveau développement "from scratch" avec une masse de travail complètement absurde, ou alors par un effort communautaire qui est bancal juridiquement (même si en pratique je doute qu'il y ait des répercussions importantes).

Mais fournir les sources sous GPLv3 est clairement une grosse tâche dans la libération du moteur d'ET. Le plus drôle étant que ce code bancal juridiquement se retrouve dans des projets qui sont à l'origine 100% en accord avec leur licence GPLv2.

A noter qu'ET:Legacy est à la fois une amélioration du moteur, et un mod ET (au même titre que etpub, etpro, noquarter..)

Un très bon résumé de la situation qui a amener à ET:Legacy est disponible dans le wiki officiel.

En gros, Quake 3 a été libéré sous GPLv2, alors que W:ET l'a été sous la licence GPLv3 qui est… incompatible. Le moteur ioquake étant bien plus avancé et bien plus propre, il n'était pas possible de backporter les améliorations du moteur incluses dans iowolfet, et il aurait fallut forwardporter les amélioration de ioquake3 dans iowolfet. Comme personne n'aime faire le travail deux fois, et que personne ne voulait mettre les mains dans ce merdier juridique, le code de iowolfet a végété sans véritable amélioration. Du moins chey icculus.

Dès lors, parmi les groupes subséquents (wolfet-merge, raedwulf-et, ETXreaL, openterritory, OpenWolf et ET: Legacy) la plupart, voir tous, ne prennent pas en considération cette violation de licence (en particulier le code de ETXReal, et donc Unvainquished).

Un autre problème subsiste toujours, celui des données (assets) qui sont toujours couvertes par la licence non libre originale d'iD Software.

Aujourd'hui, la plupart de ces "forks" sauvages sont inactifs. Seul ET:Legacy bat son plein, et se démarque de ETXReal par la compatibilité binaire avec les serveurs W:ET existants, et une grosse période de nettoyage. Depuis son annonce public il y a un an, environ un tiers du code a été éliminé. Pour l'heure, il n'y a toujours pas de grosse amélioration visuelle visible, et la partie "mod" n'en est quasiment qu'à la définition de la direction qu'il va prendre (fun, pro?) à part quelques fonctionnalités considérées comme essentielle. Mais avec ce projet, ET semble avoir un futur très prometteur.

C'est possible, mais de loin pas obligatoire. Un client n'a aucune contrainte et peut ne jamais te donner le code source modifié.
Encore une fois, la GPL protège le client, mais pas les éventuelles parts de marché de l'auteur original.

L'objectif de la GPL n'est pas d'enfermer, son objectif est d'interdire à une boite privé de prendre le code, de l'améliorer et de prendre ensuite tes parts de marché avec sa version sans que tu ais son code. C'est tout.

Pour moi, le reste est du blabla de juriste globalement…

Ben non, même pas. Rien n'empêche la boîte privée de ne jamais te donner son code. Elle n'a que l'obligation de donner le code source à ses clients, et peut sans problème te piquer tes parts de marché. On en avait récemment discuté dans ce journal.

Il y a quelques mois, la communauté francophone parlait d'une n-ième tentative de rapprochement entre Alionet et la partie francophone "officielle" du Projet openSUSE. Qu'est ce que ça donne? C'est retombé dans l'oubli?

Sinon, merci pour la news. Du beau travail :)

La, imagine le choc, il y en a un qui est en train de se rendre compte que ses idées sont complètement incompatibles avec l'Open Source, tout son mode open source s'écroule.

(désolé, pas pu résister :))

La licence que tu cherches est la Reciprocal Public License. Elle vise justement à combler le "trou" de la GPL que tu cites.

La RPL est approuvée par l'OSI, mais pas la FSF qui la considère comme "non-libre" (voir Wikipedia).

Tous les paquets ne passent pas par [testing] ou [community-testing]. Seulement les paquets susceptibles de casser quelque chose de critique et qui doivent être testés, et ceux qui nécessitent la recompilation d'autres paquets.