> Tant qu'une nouvelle branche de Linux ne sera pas ouverte, il sera difficile ou éphémère, pour une petite équipe, de distribuer un système stable, basé sur un Linux 2.6.
La branche 2.6 est *aussi* une branche de développement (d'où la non existance de branche 2.7). C'est un changement de direction de Linus avec l'accord de la majorité des développeurs et notament des "grosses" distributions (Red Hat et Novell). C'est un changement qui n'a pas été remis en cause.
Je trouve normal que Linus soit plus préoccupé par les contributeurs que par le mainteneur de slackware.
> En 3 ans et demi, udev en est à sa 101ème version, soit une nouvelle version tous les 12 jours en moyenne.
Udev n'a pas atteint la version 1.0. Donc, ça change. Notes que le trio (voire le quatuor avec Linux) udev/dbus/hal n'a pas atteint la version 1.0. Donc je ne comprend pas pourquoi tu gueules. Tu gueules seulement car c'est dans les autres distributions et pas dans Slack. Il n'y a pas d'API de figé. Et c'est normal, c'est encore en plein développement. Ces trois projets forme un tout et répond à la problématique des nombreux type de périphériques amovibles.
Alors deux choix :
1- on fige l'API et on a un truc qui suck
2- on ne fige pas l'API jusqu'à ce qu'on ait atteint un truc qui roxe
C'est l'option (2) qui a été choisi, sinon ça prendrait des années pour avoir un truc qui roxe.
L'option (1) a les problèmes suivant :
- il faut maintenir deux branches : une stable et une de développement
- la branche de développement est peu testée et potentielle non utilisable (donc peu de testeur)
- les distributeurs ne développent pas sur la branche de développement car ce n'est pas directement utilisable dans leur prochaine version
- les distributeurs finissent par faire des "mini-fork" par rapport à la branche stable. "mini-fork" souvent incompatible entre distributions. Ces développements ne sont pas consolidés en upstream.
L'option (2) a les problèmes suivant :
- pas facile pour les petites structures.
Je préfère de loin l'option (2) et tant pis pour Slackware qui ne contribue pas à Linux ni à udev/etc. Désolé.
Il est normal que Linux/udev/etc prêtent peu d'attention à ceux qui ne contribuent pas.
[^] # Re: Slackware, Debian edition
Posté par clearstream . En réponse à la dépêche Linux Slackware 11.0 est disponible. Évalué à -4.
La branche 2.6 est *aussi* une branche de développement (d'où la non existance de branche 2.7). C'est un changement de direction de Linus avec l'accord de la majorité des développeurs et notament des "grosses" distributions (Red Hat et Novell). C'est un changement qui n'a pas été remis en cause.
Je trouve normal que Linus soit plus préoccupé par les contributeurs que par le mainteneur de slackware.
> En 3 ans et demi, udev en est à sa 101ème version, soit une nouvelle version tous les 12 jours en moyenne.
Udev n'a pas atteint la version 1.0. Donc, ça change. Notes que le trio (voire le quatuor avec Linux) udev/dbus/hal n'a pas atteint la version 1.0. Donc je ne comprend pas pourquoi tu gueules. Tu gueules seulement car c'est dans les autres distributions et pas dans Slack. Il n'y a pas d'API de figé. Et c'est normal, c'est encore en plein développement. Ces trois projets forme un tout et répond à la problématique des nombreux type de périphériques amovibles.
Alors deux choix :
1- on fige l'API et on a un truc qui suck
2- on ne fige pas l'API jusqu'à ce qu'on ait atteint un truc qui roxe
C'est l'option (2) qui a été choisi, sinon ça prendrait des années pour avoir un truc qui roxe.
L'option (1) a les problèmes suivant :
- il faut maintenir deux branches : une stable et une de développement
- la branche de développement est peu testée et potentielle non utilisable (donc peu de testeur)
- les distributeurs ne développent pas sur la branche de développement car ce n'est pas directement utilisable dans leur prochaine version
- les distributeurs finissent par faire des "mini-fork" par rapport à la branche stable. "mini-fork" souvent incompatible entre distributions. Ces développements ne sont pas consolidés en upstream.
L'option (2) a les problèmes suivant :
- pas facile pour les petites structures.
Je préfère de loin l'option (2) et tant pis pour Slackware qui ne contribue pas à Linux ni à udev/etc. Désolé.
Il est normal que Linux/udev/etc prêtent peu d'attention à ceux qui ne contribuent pas.