En résumé : l'installateur a fait l'objet de quelques légères modifications ; le noyau standard reste un 2.4 mais deux noyaux de la série 2.6.x sont disponibles ; X.Org est disponible en version 6.9.0 ; KDE 3.5.4 ; Xfce 4.2.3.2 ; Mozilla a été remplacée par Seamonkey ; dernières versions de Firefox et Thunderbird ...
NdM Merci également à Marc Poiroud et Madko de nous avoir proposé une dépêche à ce sujet. Concernant l'installateur, il a fait l'objet de quelques légères modifications qui passeront probablement inaperçues. L'une des corrections concerne les fichiers du noyau config et System.map : en cas de sélection d'un noyau personnalisé lors de l'installation, ils seront enfin installés correctement. En effet, jusqu'à présent, il fallait les copier manuellement depuis le CD car ils n'étaient tout simplement pas installés, ou du moins ceux qui l'étaient correspondaient ... au noyau par défaut (a/kernel-ide) ! Une autre correction concerne l'installation NFS dont l'étape du renseignement du dossier exporté contenant l'arborescence slackware/ était assez floue : l'installateur tentera maintenant de monter le dossier parent qui correspond souvent à l'export NFS et si cela échoue, le dossier renseigné sera monté (comportement jusqu'à présent). Ce point de l'installation NFS causait pas mal de soucis à ceux qui essayaient une installation NFS pour la première fois : ceux qui ont déjà tenté une installation NFS comprendront la confusion qui existait autour de cela :)
Le noyau standard reste un noyau Linux de la série 2.4 (2.4.33.3) mais deux noyaux de la série 2.6.x sont disponibles lors de l'installation : huge26.s qui correspond au noyau 2.6.17.13 et test26.s qui correspond au tout récent noyau 2.6.18. Il est recommandé d'utiliser l'un de ces noyaux si vous possédez des périphériques SATA et que le noyau sata.i ne suffit pas. Et si vous choisissez un de ces noyaux 2.6.x lors de l'installation, pensez ensuite à installer leurs paquetages respectifs plus complets et plus modulaires lors du premier amorçage de votre système Slackware : pour le noyau 2.6.17.13, il s'agit des paquetages présents dans extra/linux-2.6.17.13/ et pour le noyau 2.6.18, vous les trouverez dans testing/linux-2.6.18/. N'oubliez surtout pas de lire le fichier /boot/README.initrd après l'installation d'un noyau Linux 2.6.x ! Sachez aussi que contrairement à Linux Slackware 10.2, les noyaux 2.6.x ne sont pas livrés avec des paquetages ALSA à part : ce sont les pilotes ALSA inclus dans ces noyau qui ont été utilisés.
X.Org est disponible en version 6.9.0 : il s'agit de la version monolithique de X.Org 7.0.0. Les célèbres polices vectorielles DejaVu, qui sont une version améliorée des polices BitStream Vera, sont fournies en standard. Les environnements graphiques fournis comprennent divers gestionnaires de fenêtres (les mêmes que Slackware 10.2) ainsi que les dernières versions stables des environnements KDE (3.5.4) et Xfce (4.2.3.2). Par contre, GNOME n'a toujours pas été réintroduit ;^) On regrettera que Blackbox soit toujours en version 0.65.0 car la dernière version 0.70.1 ne contient toujours pas les fichiers de langages.
La suite Mozilla a été remplacée par Seamonkey (1.0.5) car elle n'est officiellement plus maintenue par la fondation Mozilla. Le navigateur Mozilla Firefox et le client de messagerie Mozilla Thunderbird sont disponibles dans leur dernière version (1.5.0.7). Comme dans les versions précédentes, les paquetages de Mozilla Firefox et Mozilla Thunderbird contiennent les binaires officiellement diffusés par Mozilla : il ne s'agit pas de paquetages réalisés et personnalisés à partir des sources. Sachez ainsi que si vous compilez une application telle que Devhelp qui nécessite un moteur Gecko, celui inclu avec Mozilla Firefox ne pourra pas être utilisé : vous devrez installer Seamonkey qui contient les fichiers nécessaires pour lier l'application à son moteur Gecko.
PHP (4.4.0) est maintenant lié aux bibliothèques Freetype et surtout GD qui est finalement fournie avec Linux Slackware vu sa popularité au sein des applications PHP. Un paquetage de PHP 5.0 est disponible dans extra/ et ceux qui attendaient Apache 2 ne le trouveront pas : il n'est tout simplement pas fourni, ni dans testing/, ni dans extra/. Le fichier /etc/rc.d/rc.inet1 responsable du démarrage du réseau a été substanciellement retravaillé et de nombreuses options commentées sont disponibles dans /etc/rc.d/rc.inet1.conf.
À noter l'apparition d'un fichier CHANGES_AND_HINTS.TXT qui contient diverses informations utiles sur l'évolution de Linux Slackware 10.2 vers 11.0. On y trouve notamment les paquetages ajoutés et ceux qui ont été supprimés ainsi que diverses recommandations. Parmi les logiciels ajoutés, on notera Ruby, un langage de programmation interprété orienté objet qui devient de plus en plus populaire.
Pour mettre à jour un système Linux Slackware 10.2 vers la version 11.0, suivez comme d'habitude les instructions du fichier UPGRADE.TXT. Ceux qui souhaiteraient installer Linux Slackware pour la première fois peuvent consulter le Slackware-HOWTO ou voir comment se déroule une Installation de Linux Slackware. Dans tous les cas, pensez à lire le nouveau fichier CHANGES_AND_HINTS.TXT et le traditionnel fichier RELEASE_NOTES avant toute installation. Vous pouvez commander Linux Slackware sur la Boutique Slackware pour soutenir son développement, mais vous pouvez aussi télécharger ses images ISO via FTP, HTTP ou BitTorrent. Linux Slackware 11.0 est maintenant disponible sur 3 CDs d'installation (contenu : CD1, CD2, CD3) ainsi que sur DVD.
Aller plus loin
- L'annonce (2 clics)
# Pour mettre à jour
Posté par madko (site web personnel) . Évalué à 1.
[^] # Re: Pour mettre à jour
Posté par Yth (Mastodon) . Évalué à 4.
Il y a aussi slackpkg, dans extra/, qui ne gère pas les dépôts non-officiels type linuxpackages.org, mais marche très bien pour mettre à jour une « vanilla-slack ». Il est dans le style des utilitaires Slackware, utilisant dialog.
Yth.
[^] # Re: Pour mettre à jour
Posté par madko (site web personnel) . Évalué à 1.
jtesterais slackpkg ça m'a l'air bien
[^] # Re: Pour mettre à jour
Posté par Thomas Debesse (site web personnel) . Évalué à 4.
Si tu souhaites utiliser Gnome, il existe un projet non-officiel : Freerock Gnome [3], actuellement en version 2.14.3, qui s'installe facilement avec slapt-get, et qui est très bien intégré à la slackware.
[1] http://software.jaos.org/#slapt-get
[2] http://software.jaos.org/#gslapt
[3] http://gsb.freerock.org/
ce commentaire est sous licence cc by 4 et précédentes
[^] # Re: Pour mettre à jour
Posté par octane . Évalué à 3.
donc: swaret --upgrade glibc
puis le reste
En gardant le CD de boot sous la main pour reparer s'il y a des betises. Enfin, bien lire le upgrade tips dans tout les cas.
pour gnome, il existe plusieurs sites qui le proposent sous forme de paquet slack habituels, avec une intrusion minimale dans le reste de la distro, par exemple:
http://gsb.freerock.org
[^] # Re: Pour mettre à jour
Posté par GEDsismik (site web personnel) . Évalué à 1.
# Et PAM ?
Posté par Dabowl_92 . Évalué à 2.
Je pose cette question car c'est un pré-requis indispensable quand on veut faire de l'authentification centralisée avec LDAP...ou tout autre mécanisme de gestion de compte utilisateur.
A moins qu'il existe autre chose d'équivalent sous slackchauveware ?
Merci d'éclairer ma lanterne
[^] # Re: Et PAM ?
Posté par Prosper . Évalué à 5.
Les choix de la slackware et de Patrick me paraisse être tout à fait cohérent , on ne peut vouloir les derniers trucs à la mode qui ne servent qu'a épater la galerie, et une distribution rock solid. ( à la limite la seule chose qui me désole est le choix de sendmail comme MTA par défault )
[^] # Re: Et PAM ?
Posté par Dabowl_92 . Évalué à 3.
Et PAM intègre beaucoup de mécanisme de gestion de comptes utilisateurs qui améliorent la sécurité justement comme la vérification du mot de passe choisi par l'utilisateur (dictionnaire etc...), la validité d'une session, le "use first pass" qui evite de taper le mot de passe deux fois si ton compte est local et pas sur LDAP, bref plein de choses qui sont utiles à Linux et qui permettent de l'intégrer dans un système d'information.
Et IBM a choisi d'intégrer PAM dans AIX 5.3 justement...alors bon...
Je ne pense pas que les choix de Patrick, vont amener Linux sur le desktop ni vont aider son intégration dans les SI, c'est fort dommage.
[^] # Re: Et PAM ?
Posté par vrm (site web personnel) . Évalué à -4.
Sinon c'est une tres bonne distro pour faire du presque embarqué, tres simple et compacte.
[^] # Re: Et PAM ?
Posté par Mr_Moustache . Évalué à 2.
C'est pas un peu léger pour justifier l'emploi d'un outil troué?
Je trouve justement que d'utiliser des logiciels de qualité est primordial pour amener Linux sur le desktop et son intégration dans les SI.
Sinon on va encore entendre dire "Mais tu sais Linux, ça ne vaudra jamais du proprio".
Et ça, c'est fort dommage.
[^] # Re: Et PAM ?
Posté par Dabowl_92 . Évalué à 5.
2/ Cite moi quels sont les autres outils sous Linux proposant les mêmes fonctionnalités que PAM ?
3/ Si Linux, ne propose pas de fonctionnalité lui permettant de s'intégrer dans un SI, ben on l'intègre pas, c'est tout simple
4/ Si PAM était un logiciel troué jusqu'à la moelle, si PAM était aussi faible en terme de sécurité, explique moi pourquoi IBM l'intègre dans son Unix propriétaire depuis la version 5.3 ? Explique moi pourquoi, seul la slackware et pas les autres distrib ne l'intègre pas ?
5/ A l'heure actuelle, Linux ne vaut pas le proprio concernant la gestion des comptes utilisateurs, en effet prenons pour exemple AIX:
--> ACL par défaut dans le système depuis la version 4.3.3
--> Limitations du CPU usage par utilisateur
--> Limitations de la taille des fichiers que l'utilisateur peut créer
--> Limitations du nombre d'inode par user
--> Quota utilisateur
--> Application d'une politique de sécurité sur l'ensemble des comptes users, vérouillage des comptes, durée de validité d'une session, login retries...
Sous Linux, si on veut s'approcher de ça, il faut PAM, désolé :-)
[^] # Re: Et PAM ?
Posté par Boa Treize (site web personnel) . Évalué à 2.
Moi aussi ça me désole.
[^] # Re: Et PAM ?
Posté par Jérôme Pinot (site web personnel) . Évalué à 9.
http://search.cert.org/query.html?col=certadv&col=incnot(...)
2/ http://www.padl.com
9 fois sur 10, tu peux faire sans, mais comme PAM est très connu, les gens ne cherchent pas d'alternative. Il faut voir au cas par cas. Si c'est vraiment requis pour ton utilisation, bah tu l'installes, tu es libre, hein.
3/ L'intérêt de Linux c'est que justement, tu peux en faire ce que tu veux. Et tu sais quoi ? Tu peux installer PAM sur ta Slack, c'est pas bien dur. Je te laisse chercher.
4/ OpenBSD n'utilise pas PAM, pour des raisons techniques de sécurité. Il y en a plein le web (une partie que tu ne lis pas, probablement), tu peux commencer ici :
http://mail-index.netbsd.org/tech-userlevel/2001/06/26/0000.(...)
5/ AIX c'est gainial. Supaire. Mais sapusaipalibre.
[^] # Re: Et PAM ?
Posté par Dabowl_92 . Évalué à 2.
D'autre part, on remarque aussi que certaines alertes sont rapportées par Luke Howard (of PADL), le "concurrent" direct, c'est une bonne chose pour eux de montrer que PAM sapu par rapport à leurs produit.....
2/ Merci pour cette alternative, et je reconnais ne pas avoir cherché d'autre produit que PAM puisque que ça correspondait à mes besoins.
3/ Je n'en doute pas un seul instant, mais je n'ai pas de slack sous la main et probablement jamais :-)
4/ Merci encore pour cette info, mais désolé de ne pas avoir scruté tout le web en entier, tout simplement parce que je n'utilise pas les *BSD (peut-être à tort)....peut-être un jour, j'y viendrais :-)
5/ Super l'argument, mais bon, ça fait longtemps que j'ai arrêté l'intégrisme, ça ne mène à rien ;-)
[^] # Re: Et PAM ?
Posté par iug . Évalué à 1.
Pour les limites Ulimit c'est faire ça.
Avec quelques bons scripts de démarrage, tu a aussi les deux autres choses.
Du coup, je comprend pas ton histoire sur AIX.
[^] # Re: Et PAM ?
Posté par Dabowl_92 . Évalué à 2.
O_o
Hop, un copier-coller d'une doc :
La mise en oeuvre de droits sur les fichiers d’un système unix peut parfois manquer de souplesse.
Un fichier peut se voir affecter des droits pour trois types d’utilisateur différents :
--> Le propriétaire (owner)
--> Le groupe propriétaire (owner group)
--> « Le reste du monde » (other)
Imaginons un instant un fichier exemple.txt. L’utilisateur titi (propriétaire du fichier) peut le lire et le modifier. Les utilisateurs du groupe propriétaire peuvent juste le consulter. Le « reste du monde » ne le voit même pas....
Qu’advient-il de l’utilisateur toto qui n’est ni propriétaire, ni membre du groupe propriétaire et pour qui on souhaite donner des droits en écriture sur le dit fichier (même droit que l’utilisateur titi) ?
De fait, l’absence de gestion de droits atomiques (droits utilisés sur les fichiers Windows de type NTFS depuis plusieurs années) est un grief qui a souvent été reproché aux systèmes Unix.
AIX, intègre depuis la version 4.3.3, les ACL (Access Control List) qui permettent une gestion atomiques des droits sur les fichiers.
[^] # Re: Et PAM ?
Posté par Boa Treize (site web personnel) . Évalué à 7.
En l'absence d'ACL, sous Linux, on est obligé de créer un groupe d'utilisateurs pour chaque combinaison possible de gens et d'ensembles de fichiers auxquels ils peuvent avoir accès. La combinatoire devient très vite ingérable, ce qui limite les permissions à des scénarios assez simples, d'autant plus que le nombre de groupes auxquels un utilisateur peut appartenir est assez limité (16 ou 32, de mémoire). Simples, mais suffisants dans la plupart des cas. Pour les autres, il y a les ACL.
Exemple typique et concret :
Des équipes d'étudiants qui font un TP. Chaque équipe a un groupe Unix bien sûr, pour que les fichiers créés par ses membres soient lisibles des autres membres, et pour qu'à l'inverse les membres de l'équipe ne puissent pas aller lire les fichiers des autres équipes. Jusqu'ici tout va bien.
Arrivent les assistants de TP. S'il n'y avait qu'un assistant, il serait root ou un truc du genre et n'aurait pas de problème. Mais il y a beaucoup d'équipes, donc plusieurs assistants, et pour diverses raisons, on ne veut pas qu'ils partagent le même compte, encore moins le compte root.
Donc on galère à mettre les assistants dans tous les groupes d'élèves qu'ils doivent encadrer, on se confronte à la limite du nombre de groupe maximum par utilisateur, on galère à maintenir tout ça, et en plus c'est pas propre car l'assistant peut modifier les fichiers des élèves.
Avec les ACL, il suffit de donner le droit de lecture seule à l'assistant qui va bien sur les répertoires (et sous-répertoires) qui vont bien, et c'est tout.
[^] # Re: Et PAM ?
Posté par Mark Havel . Évalué à 10.
De toutes façons, ce n'est pas le but ni l'esprit de Slackware que de pousser Linux "sur le desktop" ou de le faire utiliser par le plus grand nombre.
[^] # Re: Et PAM ?
Posté par Ellendhel (site web personnel) . Évalué à 2.
Si à titre personnel je l'emploie en desktop et en serveur, ce n'est pas forcément la distribution que je recommande au premier venu.
Si une personne qui veut savoir comment fonctionne un système Linux, la Slack est faite pour lui ; il pourra trifouiller et apprendre beaucoup de choses.
Pour une personne qui souhaite un desktop tout prêt et qui fuit les lignes de commandes je l'orienterais vers une autre distribution.
[^] # Re: Et PAM ?
Posté par Dabowl_92 . Évalué à -9.
Cela comprend donc le desktop d'une part, et l'utilisation en tant que serveur d'autre part, et je remarque l'auteur de la slackware ne pousse pas pour que sa distrib soit utilisée par le plus grand nombre, que ce soit en serveur ou workstation.
En somme, la slackware n'est pas une distrib industrialisable, j'avais déjà remarqué par ailleurs, que les slackeux étaient des barbus reclus et refusaient leur intégration dans la société
C'est dommage de voir que peu d'arguments sont apportés par les utilisateurs de la slackware, soit la distrib n'est pas industrialisable auquel cas soit, mais au lieu de dire ça, ils préfèrent moinsser et n'appporter aucune réponse de fond...
Je ne dis pas que la slack n'apporte rien, mais quand on utilise Linux et qu'on le défend, ce serait mieux qu'on fasse notre possible pour l'intégrer en tant qu'OS de professionnel et que sa place soit aussi bien en salle machine que sur le bureau de tartenpion<
Le comportement des slackeux, ne donne pas envie d'essayer cette distrib, je préfère rester sur debian, au moins la communauté est plus vaste et n'est pas centrée sur une seule et unique personne. C'est bizarre que Linux soit basé sur le même modèle et que ça fonctionne bien tout en évoluant...
[^] # Re: Et PAM ?
Posté par Marc Poiroud (site web personnel) . Évalué à 8.
Sincèrement, tu as fait le tour de la communauté Slack francophone avant d'écrire une connerie comme ça ?
En tout cas, il est clair que tu valorises énormément la communauté Debian avec tes interventions.
[^] # Re: Et PAM ?
Posté par Gabriel Linder . Évalué à 10.
[^] # Re: Et PAM ?
Posté par BARTHEL Patrick . Évalué à 5.
- La facilité avec laquelle on modifie les scripts et la qualité de leurs commentaires ;
- La non-gestion des dépendances ;
- Un login en mode console par défaut ;
- L'intégration de logiciels peu buggés ;
- La mise à jour annuelle ;
- sa simplicité d'utilisation pour les personnes qui veulent maitriser leur système sans être des gouroux de linux.
Je sais que ces arguments peuvent être facilement démontés ; Que certains d'entres eux s'appliquent aussi à d'autres distributions etc. Mais il reste qu'à mon sens la slackware reste la meilleure distribution... du moins pour l'utilisation que je fais de mon ordinateur.
[^] # Re: Et PAM ?
Posté par Boa Treize (site web personnel) . Évalué à 10.
Slackware est simple, claire, et fait le minimum de travail pour obtenir un maximum d'effet. C'est une des meilleures distro pour découvrir et apprendre les mécanismes fondamentaux d'un système Linux, tout y est comme documenté par les auteurs des divers packages qui la composent. C'est une distro qui ne gêne pas ceux qui cherchent à expérimenter ou personnaliser tout ou partie du système, et qui convient particulièrement bien à ceux qui veulent un contrôle total et détaillé sur ce qui tourne chez eux.
Elle est tout à fait utilisable en entreprise, même à grande échelle, à condition bien sûr de confier le travail (configuration, scriptage, déploiement, documentation de ce qui a été fait) à quelqu'un de compétent. Bien sûr des distributions comme RHEL sont plus à même de correspondre aux besoins typiques des entreprises, et dans une comparaison des avantages et des inconvénients de chaque choix RHEL l'emporte probablement dans la plupart des cas. Ceci n'implique pas, toutefois, qu'il n'y a pas des cas plus rares où Slackware puisse lui être préférée.
[^] # Re: Et PAM ?
Posté par munshausen . Évalué à 3.
Pourtant parfois, je me demande...
Elle est si simple d'utilisation que je me demande si je ne suis pas en train de perdre toutes mes connaissances concernant Linux.
J'installe, ça marche, je mets à jour, ça marche. Si ça, c'est pas du desktop compliant.
[^] # Re: Et PAM ?
Posté par Mark Havel . Évalué à 1.
[^] # Re: Et PAM ?
Posté par Yth (Mastodon) . Évalué à 2.
Yth, simplicité.
[^] # Re: Et PAM ?
Posté par camuche . Évalué à 10.
Et pourtant, c'est bien une distribution qui a été utilisée par des tas de nouveaux venus, étant donné que c'est la plus vieille des distributions...
Comme beaucoup de monde, j'ai débuté avec une Slack en 93, ce n'était même pas un kernel 1.0 :-)
À l'époque, il était quasiment obligatoire de recompiler le noyau.
Et pourtant, les nouveaux venus de l'époque s'en sortaient ! On a sans doute pris de mauvaises habitudes maintenant, à râler dès qu'une distro ne reconnaît pas tous les périphériques "out of the box", ou s'il faut éditer le moindre fichier de configuration.
[^] # Re: Et PAM ?
Posté par fabricius . Évalué à 5.
[^] # Re: Et PAM ?
Posté par Gabriel Linder . Évalué à 1.
[^] # Re: Et PAM ?
Posté par iug . Évalué à 3.
On a un peu trop tendance à sacrifier ces trois éléments de nos jours. Et cela va nous conduire à un système bugué ou personne ne comprend plus rien, mais sur le desktop. Comme d'autres.
[^] # Re: Et PAM ?
Posté par choupette . Évalué à 5.
J'ai débuté sous Linux principalement avec une Slack en 95 et c'est avec elle que j'ai le plus appris. C'est une distrib simple, du point de vue de son infrastructure, mais d'une remarquable finition. Et si malgré son "grand âge" elle est toujours aussi utilisée, c'est tout simplement que son concept plaît et que ca fonctionne (bien en plus :^)
Pour ceux qui veulent un "desktop" à la mode, qui fasse la purée et le café ISO-9001 AFAQ compliant comme chez Bill ou Steve, il y a plein d'autres distribs qui sont faites pour ça. C'est toute la force du libre: le choix.
[^] # Re: Et PAM ?
Posté par chaperon . Évalué à 2.
Ceci dit, le passage à l'init façon systemV (rc?.d avec des priorites) m'a un peu rebuté.
# Liens utiles
Posté par Marc Poiroud (site web personnel) . Évalué à 5.
[fr]
Slackware Francophone : http://www.slack-fr.org [news, wiki]
Portail Slackware Francophone : http://www.slackfr.org/ [news, forum]
Slackbuild.net : http://www.slackbuilds.net/
[en]
Paquetages Aliens : http://www.slackware.com/~alien/slackbuilds/
Slackbuilds.org : http://www.slackbuilds.org/
Linux Packages : http://www.linuxpackages.net/
Google Group : http://groups.google.co.uk/group/alt.os.linux.slackware
[Documentations en Anglais]
SlackBook : http://www.slackbook.org/
Slackware Linux Basics : http://www.slackbasics.org/
Slackwiki : http://slackwiki.org/
Pour les curieux qui n'auraient jamais installé une slack, cette version est parfaite pour tenter l'expérience. Une communauté joyeuse, qui sent bon et qui cours vite est là pour vous aider :
* sur IRC avec le canal de slack-fr.org sur irc.freenode.net avec le canal #slackware-fr
* sur le forum de slackfr.org qui aide toute les bonnes âmes.
* sur le forum de slackbuild.net où la technique est de rigueur.
Mais rassurez vous, on troll peu ... enfin surtout sur ...
[^] # Re: Liens utiles
Posté par _Hitek_ (site web personnel) . Évalué à 1.
Ah bon ? On parle bien du même forum ? ;-)
Je suis pas technicien pour un sou perso :-)
# Slackware, Debian edition
Posté par Jérôme Pinot (site web personnel) . Évalué à 10.
De l'aveu même de Patrick Volkerding, elle aurait du sortir avant fin Juin. Alors, que s'est-il passé ?
Il convient peut-être de rappeler tout d'abord, pour ceux qui l'ignoreraient, que Slackware est maintenue par essentiellement une personne : Patrick Volkerding. Il y a bien sur des contributeurs externes (très nombreux d'ailleurs pour cette version), mais les intégrations de correctifs, la validation des tests et le packaging final sont faits par un seul homme.
On comprend donc, dans ces circonstances, que Patrick, devenu papa en novembre 2005, ais du ralentir le développement de Slackware 11.0 pendant quelques mois.
La deuxième chose concerne les problèmes techniques. Il y en a eu de toutes sortes, pas forcément spécifiques à Slackware, mais il y un point sur lequel je voudrais insister : le chantier permanent qu'est la branche 2.6 du noyau Linux.
En effet, si le c½ur du système est toujours basé sur Linux 2.4 (donc la glibc), Slackware 11.0 intègre tout ce qui est nécessaire au 2.6, par défaut. Il y a donc eu beaucoup de travail pour avoir également une base stable sous ce noyau.
Sans détailler ce qui se passe pour le noyau lui-même, prenons l'exemple de udev, qui dépend très étroitement du noyau et qui est l'une des clés de voûte d'un système Linux «moderne».
En 3 ans et demi, udev en est à sa 101ème version, soit une nouvelle version tous les 12 jours en moyenne.
Ces changements rapides et les incompatibilités, parfois très importantes, qui en découlent ne facilitent pas la tâche des distributeurs. Si les Fedora, Novell et autres Debian ont l'envie de déployer la force de frappe nécessaire pour fournir leur propre noyau, leur propre udev corrigé et d'en faire des mises à jours hebdomadaire, ce n'est pas le cas des autres.
Le package udev de Slackware (version 97) a été corrigé 9 fois. Et pour assurer un fonctionnement avec un grand nombre de versions de Linux 2.6, Patrick Volkerding a ajouté 2 autres versions dans /extra (64 et 71).
Notons enfin le mal qu'ont eu les gens de LFS pour mettre à jour leur livre.
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.
[^] # Re: Slackware, Debian edition
Posté par gaston . Évalué à 2.
C'est plus ou moins ce qui est en train de se faire avec la 'branche' des 2.6.16.x : http://kerneltrap.org/node/7164
[^] # Re: Slackware, Debian edition
Posté par Marc Poiroud (site web personnel) . Évalué à 3.
[^] # Re: Slackware, Debian edition
Posté par gaston . Évalué à 1.
C'est à n'y rien comprendre.
Cette ancienne news explique un peu plus la creation de la 'branche' 2.6.16 : http://kerneltrap.org/node/6930
[^] # Re: Slackware, Debian edition
Posté par Boa Treize (site web personnel) . Évalué à 6.
Linus travaille sur 2.6.18, il patche, il modifie, il fait des release-candidate, et quand il est satisfait, il publie 2.6.19 et ça continue.
Par ailleurs, d'autres personnes suivent de près les patches intégrés à 2.6.18, ne retiennent que ceux qui corrigent des bugs, vérifient que le tout s'intègre bien et ne produit pas d'incompatibilité avec le 2.6.18 de base, et produisent des versions dérivées de 2.6.18 : bientôt 2.6.18.1, puis 2.6.18.2, etc.
Concrètement :
- 2.6.17 a été publié le 18 juin par Linus Torvalds
- 2.6.17.1 a été publié le 20 juin par Chris Wright
...etc...
- 2.6.17.13 a été publié le 9 septembre par Greg Kroah-Hartman
Pendant ce temps là, Linus Torvalds a continué à améliorer 2.6.17, ce qui a donné ça :
- 2.6.18 a été publié le 20 septembre par Linus Torvalds
- 2.6.18.1 n'a pas encore été publié, ce qui est un peu étonnant mais bon, si ça se trouve il n'y avait pas de bug dans 2.6.18 ;)
Pour plus de détails :
Ce que publie Linus Torvalds :
http://kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6(...)
Branche stable du noyau 2.6.17 :
http://kernel.org/git/?p=linux/kernel/git/stable/linux-2.6.1(...)
Branche stable du noyau 2.6.18 (pour l'instant identique à ce qu'a publié Linus) :
http://kernel.org/git/?p=linux/kernel/git/stable/linux-2.6.1(...)
[^] # Re: Slackware, Debian edition
Posté par Boa Treize (site web personnel) . Évalué à 2.
Je n'avais pas suivi cette histoire de Linux 2.6.16 qu'un des contributeurs veut maintenir indéfiniment, comme l'est actuellement la version 2.4 du noyau, et comme ont pu l'être (ou sont toujours ?) les versions 2.2 et 2.0.
Manifestement, Patrick Volkerding pense qu'utiliser une version stable 2.6.x.y, basée sur une 2.6.x d'il y a trois mois est suffisant pour n'avoir pas trop de bogues. Et au pire, il y a la version 2.4. ;-)
[^] # Re: Slackware, Debian edition
Posté par lezardbreton . Évalué à 2.
[^] # Re: Slackware, Debian edition
Posté par Boa Treize (site web personnel) . Évalué à 2.
X est déjà découpé en plusieurs packages (x11, x11-devel, x11-xdmx, etc.), ça ne gêne pas particulièrement lorsqu'une nouvelle version sort.
Patrick Volkerding a continué d'utiliser la version 6.9 parce qu'au niveau du contenu elle est quasi-identique à la version 7.0, et que ça lui économisait le développement de ces nouveaux scripts Slackbuild. Peut-être craignait-il aussi que le découpage effectué ne soit pas encore bien stable.
En tout cas, je suis prêt à parier que pour la prochaine version il les aura créés. :-)
[^] # Re: Slackware, Debian edition
Posté par _Hitek_ (site web personnel) . Évalué à 2.
[^] # Re: Slackware, Debian edition
Posté par clearstream . É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.
[^] # Re: Slackware, Debian edition
Posté par clearstream . Évalué à -6.
[^] # Re: Slackware, Debian edition
Posté par Yth (Mastodon) . Évalué à 9.
En particulier, le mainteneur de slack maintient des kernels 2.6 très à jour et parfaitement fonctionnel (2.6.17.13 ET 2.6.18), donc je ne vois pas où est le problème, et je ne vois pas de quoi tu parles. En plus il trouve même le temps de maintenir un 2.4 parfaitement à jour (2.4.33) ! Comme quoi c'est faisable...
Concernant udev, ben c'est dans la slack, pourquoi tu dis que ça n'y est pas ? Et Patrick maintient même plusieurs versions justement parce que ce n'est pas encore stable, et que lui cherche à maintenir un système le plus fonctionnel possible pour le plus de personnes possible.
Et pourquoi tu dis que la Slack ne contribue pas à Linux/udev ?
Parce que Patrick n'y contribue pas ? Ben on ne peut pas demander à *tout* les libristes d'y contribuer, d'ailleurs moi j'y contribue pas, et toi non plus probablement... En fait ça serait invivable si tout le monde mettait sa patte dedans. Par contre les slackers de manière générale contribuent aussi au libre, et il ne serait pas surprenant que parmis les devs ou contributeurs kernel ou udev, il y ait des adeptes de cette distribution extrêmement agréable pour un hacker. Alors, ça veut dire quoi "Slack ne contribue pas à Linux/udev" ?
Ma conclusion c'est que tu racontes n'importe quoi, de ce fait, je ne vois pas pourquoi tu te plains d'avoir été moinssé. Tu devrais remercier les lecteurs de leur bon sens.
Cordialement,
Yth.
[^] # Re: Slackware, Debian edition
Posté par clearstream . Évalué à -1.
Très bien. Il n'y a pas de problème et tout va bien.
Alors pourquoi ce dernier commentaire à un score de 10 ?
http://linuxfr.org/comments/760880,1.html
[^] # Re: Slackware, Debian edition
Posté par Yth (Mastodon) . Évalué à 3.
Mais qu'il arrive quand même à gérer tout ça et la Slackware gère un kernel 2.4 et un 2.6 à jour, un udev qui marche et un système stable et à jour.
L'auteur ne s'est pas plaint de cet état de fait en disant "ouin c'est plus dur pour Patrick", non, il n'a pas fait ça.
Toi tu dis "wééé, c'est dur, mais c'est normal, t'façon on s'en fout de lui il est tout seul, on fait pas comme ça l'arrange, parce qu'il a pas son mot à dire il est tout seul".
Ce qui est à la fois débile, méprisant et hors-sujet.
D'autres questions ?
Yth.
[^] # Re: Slackware, Debian edition
Posté par clearstream . Évalué à -1.
Je n'ai pas dit qu'il s'était plaint.
> Toi tu dis "wééé, c'est dur, mais c'est normal,
Je ne suis pas le seul. Commentaire de http://linuxfr.org/comments/760880,1.html
> t'façon on s'en fout de lui il est tout seul
Apprend à lire s'il te plait.
Je n'ai pas dit que je m'en fout de Slack. Mais les développeurs ont des priorités, doivent faire des choix pour contenter un maximum de personne et le chois qui a été fait n'est pas en faveur de Slack et de son mainteneur. C'est un fait. Point barre. Les difficultés des petites structures a dû être entendu. Mais que veux tu, le gros des développeurs viennent de grosse structure. Quand Jérôme Pinot le dit, ça ne te dérange pas, quand c'est moi tu en fais tout un fromage.
> on fait pas comme ça l'arrange, parce qu'il a pas son mot à dire
Il a son mot à dire. Arrêtes de dire des conneries.
> il est tout seul
Oui, il est tout seul. Malheureusement pour lui, les autres sont beaucoup plus nombreux. C'est un *fait* !
> Ce qui est à la fois débile, méprisant et hors-sujet.
Ce n'est pas débile, c'est un *fait*.
Ce n'est pas méprisant, c'est un *fait*.
Ce n'est pas hors-sujet, ça répond au commentaire de Jérôme Pinot.
Ecoutes bien, j'ai beaucoup de respect pour Slack et surtout pour son mainteneur qui réalise un travail ENORME. C'est un personnage "historique" de Linux et c'est grace à Slackware (distribution knoppix97 je crois) que j'ai découvert Linux.
Je comprend parfaitement que les gens apprécient Slackware. Une distribution qui ne casse pas tout du jour au lendemain. J'utilise Fedora, et parfois ça me "fatigue" de devoir mettre à jour mes connaissances pour utiliser pleinement ma distribution.
Slackware est indéniablement une distribution qui a sa place dans le paysage Linux. Mais les temps sont dures pour les petites structures et donc pour Slackware (Notes bien que je ne suis pas le seul à le dire). Je n'ai jamais dit que le mainteneur de Slackware était "naze" ou autre.
S'il te plait, apprend à lire.
# Version amd64?
Posté par Guillaume R. . Évalué à 1.
J'aime bcp slackware mais il n'y a pas encore de portage officiel vers la plateforme amd64 (il existe la bonne contrib d'un utilsateur Slamd64 certes).
Verra t-on un jour slackware s'ouvrir de façon officielle à cette architecture? Peut être Pat pourrait il élargir son équipe au moins pour cette arch qui est de plus en plus répandue non?
[^] # Re: Version amd64?
Posté par _Hitek_ (site web personnel) . Évalué à 3.
[^] # Re: Version amd64?
Posté par Marc Poiroud (site web personnel) . Évalué à 2.
il existe un projet non officiel :
http://www.slamd64.com/
[^] # Re: Version amd64?
Posté par Guillaume R. . Évalué à 1.
A la suite de quoi je l'avais testé: je n'avais pas réussi à l'installer suite à un bogue de l'installeur. Je l'ai appris sur le chan #slamd64. Apres un rsync sur le tree -current j'ai pu récuperer et mettre sur dvd l'image pour l'installer et cela marchait vraiment bien.
En fait je ne sais pas pourquoi mais j'aurais aimé avoir qque chose "d'officiel", une annonce que Slackware désormais supporterait les processeurs de ce type.
[^] # Re: Version amd64?
Posté par Yann Wanwanscappel . Évalué à 1.
J'ai installé récemment la 11.0 RC4 sur un HP Pavillion à base de Turion 64 (non je n'ai pas d'actions chez HP) sans trop de soucis (le seul problème que j'ai eu lors de l'installation étant que le clavier reste désespérement en QWERTY pendant l'install. En revanche une fois l'installation terminée, le passage en AZERTY est bien pris en compte.
Contrairement à la Slamd64 elle n'intègre pas de packages de compatibilité 32 bits (du moins en ce qui concerne la RC4), ce qui m'a empéché d'installer les drivers propriétaires ATI de ma carte vidéo (il semblerait qu'ils ne soient pas 100 % 64 bits).
La version 11.0 est sortie le 4 octobre, j'avoue ne pas encore l'avoir installé ;o)
# Slackware
Posté par Neuromancien . Évalué à -10.
Je préfère Arch Linux, dont la philosophie est proche de Slackware, mais qui dispose d'un outil puissant pour gérer les paquetages.
[^] # Re: Slackware
Posté par w3c . Évalué à 5.
Merci /.
w3c, d'une slackintosh-current.
[^] # Re: Slackware
Posté par Anonyme . Évalué à 2.
[^] # Re: Slackware
Posté par Yth (Mastodon) . Évalué à 2.
Parce que « tar » pour gérer les paquets ça a au moins l'avantage d'être stable, sûr, efficace, performant, et parfaitement testé par des millions de gens à travers le monde.
Côté dépendances c'est léger : la glibc, et gzip (parce que c'est des tgz).
Tout ça encapsulé dans une poignée de petit scripts shell, on a toute la puissance et la sobriété de la philosophie Unix : un petit programme simple qui fait bien une petite tâche simple.
Bref, chais pas comment c'est sous Arch linux, mais au moins là le gestionnaire de paquets ne risque pas de tomber en rade, ou alors le problème est un poil plus grave :p
Yth, grep est mon ami.
[^] # Re: Slackware
Posté par elb . Évalué à 1.
Très proche et différent à la fois. Les packages sont aussi des tar.gz. En plus des fichiers à installer le package contient un fichier .FILELIST (sans commentaire) et un fichier .PKGINFO qui contient un certain nombre de renseignements dont la liste des dépendances.
[^] # Re: Slackware
Posté par Boa Treize (site web personnel) . Évalué à 3.
Les mainteneurs affirment que de toute façon personne ne lit ce genre de doc et que tout le monde va sur Internet. C'est effectivement assez souvent le cas, mais c'est justement quand ce n'est pas le cas qu'on se retrouve à avoir le plus besoin de documentation...
(Et puis ça m'arrive encore d'accéder à Internet à 33 kbps, et dans ce cas, mieux vaut avoir un max de choses déjà en local.)
[^] # Re: Slackware
Posté par Anonyme . Évalué à 2.
... d'être simple à manipuler aussi. Par exemple, pour extraire le contenu d'un rpm, à défaut de rpm2targz ou d'alien, je suis obligé d'utiliser rpm2cpio. Avec un paquet tgz, tar -xvfz, c'est nickel.
D'autre part, d'après la page de manuel il est possible avec l'option -l de lister le contenu d'un paquet rpm, mais ça ne fonctionne pas au boulot (RHEL 3)... Qqn peut confirmer si cette option existe (toujours) ?
[^] # Re: Slackware
Posté par clearstream . Évalué à 2.
Ça existe depuis TRÈS longtemps.
Si ça ne fonctionnement pas chez toi, alors probablement que tu utilises mal rpm (désolé).
Si le rpm est installé :
$ rpm -q -l nom_paquet
Si le rpm n'est pas installé :
$ rpm -q -l -p [url ou fichier]
Pour avoir la liste des paquets installé :
$ rpm -q -a
=> man rpm
[^] # Re: Slackware
Posté par Anonyme . Évalué à 2.
Merci ;-) En lisant le man je pensais que -l suffisait.
Tu n'as pas à être désolé, c'était vrai. Même que je te plusse pour le service, parce que Google n'a pas été mon ami.
# SlackE17
Posté par Jérôme Pinot (site web personnel) . Évalué à 6.
http://slacke17.sourceforge.net/
SlackE17 est une distribution d'Enlightenment DR17 pour Slackware. Il y a 48 packages pour cette version 'octobre' (20061006).
Si vous utilisez Slackware 10.2, il vous faudra rester avec SlackE17 'avril' (20060408).
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.