De la possibilité d'une distribution en constante amélioration

Goldy · Le 10/11/2008, à 20:05

Bonjour,

J'étais en train de me poser la question suivante en lisant les différents topics de problèmes d'intrepid.

Est-il possible d'envisager un distribution dont la mise à jours serait permanente, stable mais en constante amélioration ?

Je remarque que le système de distribution dites "stable", pose une double frustration à l'utilisateur :

La première étant que chaque mise à jours risque une régression et est lourde à mettre en place. En effet, chaque nouvelle version part d'un état proche de zero à chaque fois pour arriver à un truc qui "marche", et la très courte période entre deux stable pose un véritable problème avec cette méthode de travaille.

La seconde est la frustration de devoir utiliser pendant 6 mois une distribution qui ne sera pas mise à jours d'un point de vue des bug non-critiques et des fonctionnalités. En gros, il est impossible à un développeur de mettre à jours son logiciel autrement qu'en attendant au minimum 6 mois (et plus encore si la dead-line est dépassé).

Je pense qu'on gagnerait en qualité et en stabilité en cherchant sur cette voix là, peut-être se rapprocher de ce que fait Debian avec Lenny, avec la possibilité de figer régulièrement la distribution, mais en permettant aux utilisateurs de continuer à la mettre à jours de façon permanente.

Bref, est ce que cette vision des choses est possible et est-ce que d'autres distributions utilisent ce modèle de développement ?

Dernière modification par Goldy (Le 10/11/2008, à 20:07)

Yann · Le 10/11/2008, à 20:06

Slackware?

Goldy · Le 10/11/2008, à 20:16

Yann a écrit :

Slackware?

Plait-il ?

Gage · Le 10/11/2008, à 20:21

Si tu envisages la possibilité de figer de temps en temps la distrib, Fedora correspond à ce que tu cherches : une distrib en constante amélioration. D'ailleurs, les mises à jour y sont classées en 3 catégories : bugs, sécurité, améliorations.

Si tu veux une distrib qui ne soit jamais figée, que tu peux installer et continuer à mettre à jour 5 ans plus tard, Gentoo fait ça. Note que ça n'est possible qu'avec une distrib source : le fait de choisir les options de compilation en local en non sur le serveur permet de maintenir un nombre plus restreint de paquets, sans limite de temps quant à la compatibilité.

Elzen · Le 10/11/2008, à 20:21

Goldy a écrit :

Je pense qu'on gagnerait en qualité et en stabilité en cherchant sur cette voix là, peut-être se rapprocher de ce que fait Debian avec Lenny, avec la possibilité de figer régulièrement la distribution, mais en permettant aux utilisateurs de continuer à la mettre à jours de façon permanente.

Ce que Debian fait avec Lenny ?

Debian se divise en trois branches: stable, testing et unstable.
La stable, c'est le truc hyper-testé avec lequel tu n'auras jamais aucun soucis. C'est, en gros, un cliché de l'état des choses à un moment donné.
La unstable, c'est le truc évolutif: une seule version qui évolue au fur et à mesure, mais qui, forcément, n'est pas aussi testée que l'autre, et donc présente quelques risques de crash (ceci dit, ça reste quand même grandement stable, malgré le nom).
La testing, c'est simplement une stable en préparation. Elle "suit" globalement l'évolution de la unstable, avançant un peu plus lentement, jusqu'au moment où on décide de prendre un nouveau cliché, et à ce moment, on transfère tout ce qui est actuellement testing en stable et on recommence.

Les noms de versions comme Sarge, Etch et Lenny (tous les noms de versions excepté Sid qui désigne l'éternelle unstable, quoi) ne servent qu'à repérer de quel moment on parle. Actuellement, Sarge, c'est l'ancienne stable, Etch la stable actuelle, et Lenny, la future stable (donc actuellement en testing).
La version de Lenny n'a en elle-même rien de spécial: elle est en testing jusqu'à ce qu'on considère qu'elle soit au point (ce qui était prévu pour y a pas longtemps, mais qui a été reporté), et à ce moment-là, elle basculera en stable et la nouvelle version testing sera une nouvelle version différente de celle-là.

Goldy · Le 10/11/2008, à 20:36

Gage a écrit :

Si tu envisages la possibilité de figer de temps en temps la distrib, Fedora correspond à ce que tu cherches : une distrib en constante amélioration. D'ailleurs, les mises à jour y sont classées en 3 catégories : bugs, sécurité, améliorations.
Si tu veux une distrib qui ne soit jamais figée, que tu peux installer et continuer à mettre à jour 5 ans plus tard, Gentoo fait ça. Note que ça n'est possible qu'avec une distrib source : le fait de choisir les options de compilation en local en non sur le serveur permet de maintenir un nombre plus restreint de paquets, sans limite de temps quant à la compatibilité.

Effectivement, je m'intéresse de près à gentoo, mais j'ai peur d'être limité par le coté trop "open-source" de la bestiole. J'ai peur par exemple pour la capacité de faire fonctionner la totalité du matériel d'un ordinateur portable, mais dans l'absolue, c'est ce qu'il me conviendrait le mieux je pense.

il faudrait aussi que je jette un œil à fedora, si tu dis qu'elle n'est pas figé dans le temps.

@ ArkSeth

J'utilise une debian lenny sur un serveur, et je voulais dire que (je me trompe peut-être), une fois que la testing est stabilisé, alors elle continue d'exister, il suffit de rester en testing et non en stable, alors les paquets continue à être mis à jours et des fonctionnalités d'être ajoutées, seulement, je ne sais pas si c'est fait avec le soucis de respecter une certain stabilité ou si les paquets sont insérés dans les dépôts en attendant les rapports de bug.

Dernière modification par Goldy (Le 10/11/2008, à 20:38)

Elzen · Le 10/11/2008, à 20:48

Goldy a écrit :

@ ArkSeth
J'utilise une debian lenny sur un serveur, et je voulais dire que (je me trompe peut-être), une fois que la testing est stabilisé, alors elle continue d'exister, il suffit de rester en testing et non en stable, alors les paquets continue à être mis à jours et des fonctionnalités d'être ajoutées, seulement, je ne sais pas si c'est fait avec le soucis de respecter une certain stabilité ou si les paquets sont insérés dans les dépôts en attendant les rapports de bug.

Une fois que Lenny sera stabilisée, elle restera en stable, c'est-à-dire que quelques mois plus tard, elle sera à peu près "dans le même état" que Etch actuellement: toujours maintenue, mais un peu vieille.
Par contre, rien ne t'empêche de régler tes dépôts sur "testing" plutôt que sur "lenny", et dans ce cas, dès que Lenny sera passée en version stable, tu migreras automatiquement vers la version suivante (qui s'appellera Squeeze, me semble-t-il)

seb24 · Le 10/11/2008, à 20:49

La première étant que chaque mise à jours risque une régression et est lourde à mettre en place. En effet, chaque nouvelle version part d'un état proche de zero à chaque fois pour arriver à un truc qui "marche", et la très courte période entre deux stable pose un véritable problème avec cette méthode de travaille.

Une mise a jours tout les 2 ans ca va c'est raisonnable.

La seconde est la frustration de devoir utiliser pendant 6 mois une distribution qui ne sera pas mise à jours d'un point de vue des bug non-critiques et des fonctionnalités. En gros, il est impossible à un développeur de mettre à jours son logiciel autrement qu'en attendant au minimum 6 mois (et plus encore si la dead-line est dépassé).

D'ou l'interet de respecter les dates de sortie. De plus l'intégration de nouvelles fonctionnalités en permanence pose d'autres problèmes :
- une instabilité "chronique" : tu risque en effet d'intégrer des programmes buggés dans une installation stable ( surtout si tu veux les nouvelles versions). Ce qui ne permet pas d'avoir la garantie d'avoir un système stable dans le temps ( qui me dit que la mise a jours du paquet X ne vas foutre en l'air mon installation).
- Au niveau du support c'est beaucoup plus simple. Une personne qui dev une appli pour une 8.10 ou une 8.04 sait quelle versions de logiciels sont installé sur ces machines. Donc c'est plus facile a suivre et a supporter au niveau entreprise.

Cette gestion permet d'avoir un système figé, ca a ses avantages et inconvénients. Et en effet si tu préfére une évolution permanente, Debian propose ça il me semble.

valAa · Le 10/11/2008, à 20:53

Sinon il y a sidux, pas testé personnellement (je suis sur un vraie Sid), mais ça correspond à :
- une Debian Sid (mises à jour permanentes),
- plus des scripts pour faire ces mises à jour sans casser le système.

Je ne sais pas comment ça fonctionne, mais il paraît que c'est tous les avantages d'une Sid, tout en réduisant de beaucoup les risques de mauvaises suprises. A toi de voir
http://sidux.fr/

Personnellement, je suis sous Debian Sid, et (malgré le fait que ça ne soit pas une distrib source ) j'ai des mises à jour constantes, que je pourrais continuer à faire dans 5 ans sans mise à niveau. Pas (ou très peu) de soucis, faut juste être parfois méfiant lors des mises à jour (lors de la release d'une nouvelle stable par exemple, avec l'afflux de nouveaux paquets).

Link31 · Le 10/11/2008, à 21:03

Goldy a écrit :

Yann a écrit :
Slackware?
Plait-il ?

Faute de frappe.
Il voulait dire Gentoo.

Rubyman · Le 10/11/2008, à 21:18

Mais justement, un système non basé sur des versions stables (comme la Debian unstable) est, justement, instable... Les mises à jours risquant de provoquer une régression ne disparaitront pas. Seulement, au lieu d'être contenues uniquement dans la mise à niveau, elles se cacheront parmi les mises à jours. Avec un système de versions stables, tu choisis ou non de faire la mise à niveau, conscient des risques que cela présente. Avec un système basé sur une unique version instable, la dite mise à jour foutant le support de ton matériel en l'air se cachera parmi les autres mises à jours, et tu peux te retrouver sans interface graphique du jour au lendemain.

Bien entendu, je ne veux pas dire qu'un système c'est le mal et que l'autre c'est le bien, mais que l'utilisation d'un système instable n'est certainement pas une solution au problème que tu soulèves !

Goldy · Le 10/11/2008, à 21:19

valAa a écrit :

Sinon il y a sidux, pas testé personnellement (je suis sur un vraie Sid), mais ça correspond à :
- une Debian Sid (mises à jour permanentes),
- plus des scripts pour faire ces mises à jour sans casser le système.
Je ne sais pas comment ça fonctionne, mais il paraît que c'est tous les avantages d'une Sid, tout en réduisant de beaucoup les risques de mauvaises suprises. A toi de voir
http://sidux.fr/
Personnellement, je suis sous Debian Sid, et (malgré le fait que ça ne soit pas une distrib source ) j'ai des mises à jour constantes, que je pourrais continuer à faire dans 5 ans sans mise à niveau. Pas (ou très peu) de soucis, faut juste être parfois méfiant lors des mises à jour (lors de la release d'une nouvelle stable par exemple, avec l'afflux de nouveaux paquets).

On gagnerait en sécurité en ajoutant une fonctionnalité permettant de "revenir en arrière", qui n'est pas possible sur les dérivées de debian (une mise a jours est une mise à jours, elle remplace le paquet dans les dépôts).

Peut-être en utilisant la possibilité de snapshot de lvm (il faudrait que ça soit automatisé dès qu'une mise à jours est effectuée).

Goldy · Le 10/11/2008, à 21:23

Rubyman a écrit :

Mais justement, un système non basé sur des versions stables (comme la Debian unstable) est, justement, instable... Les mises à jours risquant de provoquer une régression ne disparaitront pas. Seulement, au lieu d'être contenues uniquement dans la mise à niveau, elles se cacheront parmi les mises à jours. Avec un système de versions stables, tu choisis ou non de faire la mise à niveau, conscient des risques que cela présente. Avec un système basé sur une unique version instable, la dite mise à jour foutant le support de ton matériel en l'air se cachera parmi les autres mises à jours, et tu peux te retrouver sans interface graphique du jour au lendemain.
Bien entendu, je ne veux pas dire qu'un système c'est le mal et que l'autre c'est le bien, mais que l'utilisation d'un système instable n'est certainement pas une solution au problème que tu soulèves !

Justement, je suis bien conscient de ça, et c'est la raison pour laquelle je cherche une solution de compromis. Le problème des distributions à développement continue comme SID, c'est qu'elles sont instables par nature. Il faudrait trouver un moyen d'obtenir une meilleurs mise à jours de fonctionnalité, tout en garantissant une bonne stabilité.

Donc dans un certain sens, ce qui convient le mieux est testing, qui permet effectivement (j'avais besoin d'en être certain) d'avoir cette mise à jours continue de paquets tout en garantissant un minimum de stabilité (réduire au maximum le risque de corruption du système).

Dernière modification par Goldy (Le 10/11/2008, à 21:25)

Keldath · Le 10/11/2008, à 22:32

testing est la plus appropriée oui. Pour plus de détails :

Comment fonctionne la distribution de test ?
La distribution de test est une distribution générée automatiquement. Elle est générée à partir de la distribution instable par un ensemble de scripts qui tentent d'intégrer les paquets qui selon toute vraisemblance ne contiennent pas de bogues critiques pour la publication. Ils s'assurent que les dépendances des autres paquets de la distribution de test soient toujours préservées.
Un paquet (ou une version particulière) sera déplacé dans la distribution de test lorsqu'il satisfera les critères suivants :
1. Il doit avoir été dans la distribution instable pendant 10, 5 ou 2 jours, en fonction de l'urgence de la mise en ligne ;
2. Il devra être compilé et à jour sur toutes les architectures sur lesquelles il a été compilé par le passé dans la distribution instable ;
3. Il doit avoir moins (ou le même nombre) de rapport de bogue entrant dans la catégorie critique pour la parution dans la prochaine distribution que la version actuellement dans la "distribution de test" ;
4. Toutes ces dépendances doivent soit être satisfaites par les paquets d'ores et déjà présents dans la distribution de test, ou bien être satisfaites par un ensemble de paquets qui sont installés au même instant ;
5. L'opération d'installation des paquets dans la distribution de test ne doit pas casser un seul paquet actuellement dans cette distribution ;
Un paquet qui satisfait aux trois premiers critères ci-dessus est un "Candidat Valide".

Source : http://www.debian.org/devel/testing

Yannick_LM · Le 10/11/2008, à 22:44

Note que ça n'est possible qu'avec une distrib source : le fait de choisir les options de compilation en local en non sur le serveur permet de maintenir un nombre plus restreint de paquets, sans limite de temps quant à la compatibilité.

ArchLinux suit le même modèle de développement que Gentoo.
(ça fait deux ans et demi que mon ArchLinux est à jour , et c'est une distribution binaire.

Cela dit, les paquets sont optimisés pour une architecture x86.

valAa · Le 10/11/2008, à 23:35

Oui, testing semble être un compromis, mais il y a quand même un cycle :

- beaucoup de nouveaux paquets qui rentrent après la release de la stable.
- beaucoup de mises à jour ensuite...
- ... puis le gel ... qui peut durer quelques temps quand même (lenny est en gel depuis juillet par exemple). Durant ce gel pas de mises à jour, seulemnt des corrections de bugs en vue de la release.

-> Et puis ça repart.

Il y a quand même donc : une période un peu "ennuyeuse" (le gel) et quelques risques d'instabilités (après la release).

Dernière modification par valAa (Le 10/11/2008, à 23:36)

Link31 · Le 11/11/2008, à 00:06

Rubyman a écrit :

Mais justement, un système non basé sur des versions stables (comme la Debian unstable) est, justement, instable... Les mises à jours risquant de provoquer une régression ne disparaitront pas. Seulement, au lieu d'être contenues uniquement dans la mise à niveau, elles se cacheront parmi les mises à jours

Certainement pas. Il y a deux branches sous Gentoo : la ~arch (versions de test des paquets) et la arch (version stable). Les deux permettent une mise à jour permanente.

Quant aux régressions, la plupart d'entre elles sont éliminées pendant la phase de test (~arch). Un paquet ne passe jamais en stable sans que quelqu'un ait explicitement confirmé son fonctionnement, et cela pour chaque architecture supportée.

Donc c'est possible d'avoir des mise à jour permanentes tout en restant sous une branche stable. N'oublie pas qu'il y a d'autres distributions que Debian !

Effectivement, ce n'est possible qu'avec des distributions source. Mais avec la puissance des processeurs actuels, il y a de moins en moins de différences avec les distributions binaires. La plupart des paquets se compilent en quelques minutes maximum.

Dernière modification par Link31 (Le 11/11/2008, à 00:12)

"-" · Le 11/11/2008, à 00:19

Mouais enfin faut aussi penser à l'impact sur la planète, car OpenOffice, Firefox ou KDE, qui ont chacun une mise à jour par mois demandent chacun plusieurs heures pour compiler...
Et à chaque fois ça oblige à laisser le PC allumé pendant une journée de travail ou la nuit juste le temps de compiler, ce qui consomme pas mal d'énergie... 3 ou 4 kW à chaque fois.

"-".

Dernière modification par "-" (Le 11/11/2008, à 00:20)

Elzen · Le 11/11/2008, à 00:28

Le jour où on en sera à mesurer le taux de mises à jour pour économiser la planète...

Deux remarques:
1./ Windows Vista.
2./ Même avec tout le gaspillage qu'on fait, l'électricité est très loin d'être la priorité environnementale.

philpep-tlse · Le 11/11/2008, à 00:36

"-" a écrit :

Mouais enfin faut aussi penser à l'impact sur la planète, car OpenOffice, Firefox ou KDE, qui ont chacun une mise à jour par mois demandent chacun plusieurs heures pour compiler...
Et à chaque fois ça oblige à laisser le PC allumé pendant une journée de travail ou la nuit juste le temps de compiler, ce qui consomme pas mal d'énergie... 3 ou 4 kW à chaque fois.
"-".

OpenOffice et firefox existent en version binnaire sur Gentoo.
Et kde c'est moisi

Gentoo, ça oblige d'utiliser des petits soft pratiques si t'as pas une machine tu tonnerre de dieux... Donc ce n'est pas une mauvaise chose.

Rubyman · Le 11/11/2008, à 00:46

Link31 a écrit :

Rubyman a écrit :
Mais justement, un système non basé sur des versions stables (comme la Debian unstable) est, justement, instable... Les mises à jours risquant de provoquer une régression ne disparaitront pas. Seulement, au lieu d'être contenues uniquement dans la mise à niveau, elles se cacheront parmi les mises à jours
Certainement pas. Il y a deux branches sous Gentoo : la ~arch (versions de test des paquets) et la arch (version stable). Les deux permettent une mise à jour permanente.
Quant aux régressions, la plupart d'entre elles sont éliminées pendant la phase de test (~arch). Un paquet ne passe jamais en stable sans que quelqu'un ait explicitement confirmé son fonctionnement, et cela pour chaque architecture supportée.
Donc c'est possible d'avoir des mise à jour permanentes tout en restant sous une branche stable. N'oublie pas qu'il y a d'autres distributions que Debian !
Effectivement, ce n'est possible qu'avec des distributions source. Mais avec la puissance des processeurs actuels, il y a de moins en moins de différences avec les distributions binaires. La plupart des paquets se compilent en quelques minutes maximum.

Donc c'est possible d'avoir des mise à jour permanentes tout en restant sous une branche stable

Ce que j'appelle une version stable/instable, c'est dans le sens utilisé par Debian, pas dans le sens "buggé ou pas". Ce que j'appelle une version "stable" est donc une version "figée" qui ne reçoit que des mises à jours de sécurités, ce qui évite les régressions possibles. Le fait qu'un paquet soit d'abord testé sur la ~arch avant de passer sur la arch (si j'ai bien compris le système de fonctionnement de Gentoo), cela ne permet pas d'éviter les bugs ou problèmes dont je parle, qui ne concernent qu'un nombre très réduit d'utilisateurs. Par exemple, la mise à jour de Xorg vers la dernière version aura forcément pour conséquence la désactivation des drivers NVIDIA (special) legacy, incompatibles avec le nouveau Xorg, et donc une régression assez importante.

Link31 · Le 11/11/2008, à 01:47

Rubyman a écrit :

Le fait qu'un paquet soit d'abord testé sur la ~arch avant de passer sur la arch (si j'ai bien compris le système de fonctionnement de Gentoo), cela ne permet pas d'éviter les bugs ou problèmes dont je parle, qui ne concernent qu'un nombre très réduit d'utilisateurs. Par exemple, la mise à jour de Xorg vers la dernière version aura forcément pour conséquence la désactivation des drivers NVIDIA (special) legacy, incompatibles avec le nouveau Xorg, et donc une régression assez importante.

Si, c'est justement à ça que sert le test des paquets. Dans le cas dont tu parles (que je n'ai d'ailleurs jamais rencontré), il suffirait d'indiquer une incompatibilité entre les deux paquets ("blocage"), ce qui aura pour effet d'empêcher l'utilisateur d'avoir ces deux paquets installés en même temps. S'il veut le nouveau Xorg, il lui faudra mettre à jour le driver nvidia si possible, ou le désinstaller.

Le blocage de certains paquets entre eux est une solution à utiliser en dernier recours, mais au moins quand on voit un blocage on sait qu'on a échappé à un désastre
(et on fait bien attention à ne pas en provoquer un autre en débloquant la situation, cf. le problème récent avec ss et com_err sous Gentoo)

Dernière modification par Link31 (Le 11/11/2008, à 03:57)

\\Ouranos// · Le 11/11/2008, à 03:15

Hmmm.... je suis aussi très intéréssé par ce genre de distrib', et Debian me semble un poil plus adaptée pour l'instant. Je tenterai pitetre une Gentoo.

|-Corpse-| · Le 11/11/2008, à 10:34

Heu, Archlinux !!! Le principe est identique à Gentoo, sauf que la distrib est basée sur des binaires et pas sur les sources. Donc la mise-à-jour est très rapide, et on a en permanence les toutes dernières versions des logiciels.

Dernière modification par |-Corpse-| (Le 11/11/2008, à 10:34)

Elzen · Le 11/11/2008, à 13:27

|-Corpse-| a écrit :

Heu, Archlinux !!! Le principe est identique à Gentoo, sauf que la distrib est basée sur des binaires et pas sur les sources.

Sachant que le principe de Gentoo est d'être basé sur les sources et pas les binaires, quelqu'un m'explique ?

Ubuntu-fr

Navigation

Liens de recherche

Annonce

#1 Le 10/11/2008, à 20:05

De la possibilité d'une distribution en constante amélioration

#2 Le 10/11/2008, à 20:06

Re : De la possibilité d'une distribution en constante amélioration

#3 Le 10/11/2008, à 20:16

Re : De la possibilité d'une distribution en constante amélioration

#4 Le 10/11/2008, à 20:21

Re : De la possibilité d'une distribution en constante amélioration

#5 Le 10/11/2008, à 20:21

Re : De la possibilité d'une distribution en constante amélioration

#6 Le 10/11/2008, à 20:36

Re : De la possibilité d'une distribution en constante amélioration

#7 Le 10/11/2008, à 20:48

Re : De la possibilité d'une distribution en constante amélioration

#8 Le 10/11/2008, à 20:49

Re : De la possibilité d'une distribution en constante amélioration

#9 Le 10/11/2008, à 20:53

Re : De la possibilité d'une distribution en constante amélioration

#10 Le 10/11/2008, à 21:03

Re : De la possibilité d'une distribution en constante amélioration

#11 Le 10/11/2008, à 21:18

Re : De la possibilité d'une distribution en constante amélioration

#12 Le 10/11/2008, à 21:19

Re : De la possibilité d'une distribution en constante amélioration

#13 Le 10/11/2008, à 21:23

Re : De la possibilité d'une distribution en constante amélioration

#14 Le 10/11/2008, à 22:32

Re : De la possibilité d'une distribution en constante amélioration

#15 Le 10/11/2008, à 22:44

Re : De la possibilité d'une distribution en constante amélioration

#16 Le 10/11/2008, à 23:35

Re : De la possibilité d'une distribution en constante amélioration

#17 Le 11/11/2008, à 00:06

Re : De la possibilité d'une distribution en constante amélioration

#18 Le 11/11/2008, à 00:19

Re : De la possibilité d'une distribution en constante amélioration

#19 Le 11/11/2008, à 00:28

Re : De la possibilité d'une distribution en constante amélioration

#20 Le 11/11/2008, à 00:36

Re : De la possibilité d'une distribution en constante amélioration

#21 Le 11/11/2008, à 00:46

Re : De la possibilité d'une distribution en constante amélioration

#22 Le 11/11/2008, à 01:47

Re : De la possibilité d'une distribution en constante amélioration

#23 Le 11/11/2008, à 03:15

Re : De la possibilité d'une distribution en constante amélioration

#24 Le 11/11/2008, à 10:34

Re : De la possibilité d'une distribution en constante amélioration

#25 Le 11/11/2008, à 13:27

Re : De la possibilité d'une distribution en constante amélioration

Pied de page des forums