Elle peut s'installer grâce à un installateur "le dropline-installer" qui propose également, à la manière pkgtool, de mettre à jour, et/ou de supprimer l'installation existante.
Un bon moyen de tester Gnome 2.8 sans avoir à compiler quoi que ce soit, et en attendant des paquets officiels pour Slackware.
NdM: Patrick Volkerding, le mainteneur de Slackware, envisage de ne plus inclure Gnome dans Slackware, et de laisser cette tâche à Dropline Gnome (voir lien). Des paquets pour Slackware de Gnome 2.8 sont disponibles ici :
http://slackpacks.tchelinux.com.br/Gnome-2.8/
Aller plus loin
- Site Dropline Gnome (3 clics)
- Abandon de Gnome dans Slackware ? (4 clics)
# A propos de l'abandon.
Posté par Pierre Tramo (site web personnel) . Évalué à 10.
- Les dépendances de gnome 2 : http://developer.gnome.org/dotplan/porting/gnome-2.0-depends.png(...)
- Celle de gnome 2.2 :
http://www.cs.kun.nl/%7Eadridg/geek/gnome-deps.gif(...)
- Et celle du dernier, le 2.8 : http://www.gtkmm.org/jhbuild_dot_gnomemm.png(...)
[^] # Re: A propos de l'abandon.
Posté par Mr_Moustache . Évalué à 7.
Comme déjà indiqué dans d'autres journaux, Dropline n'est pas une solution envisagable par tous les Slackers qui n'ont, pour la plupart, pas envie de voir un groupe mettre son nez dans l'homogénéité de leur distribution préféré..
Tout cela est pour l'instant au conditionnel, alors ne nous emballons pas..
Wait&See
[^] # Re: A propos de l'abandon.
Posté par modr123 . Évalué à 3.
mandrake ne l'a pas encore
suse non plus (il sont pas propriétaire ximain ?)
Fedora l'a
Débian ne l'a pas ( sauf en expérimental , fait pas les packageurs d'ubuntu )
ubuntu l'a ( oui , mais les packageurs sont aussi des devellopeurs de gnome )
gentoo l'a , mais on peut aussi l'installer avec garnome ( attention mettre a jour libexif et creer un réptoire similaire a ceux qui existe dans le répertoire platform pour libgnome-cups )
hal marche aussi avec un gnome-2.6 ( testé sur une debian testing en récupérant un ou deux paquets sur experimental python?)
il n' a pas de raisons de s'inquieter pour l'instanct
[^] # Re: A propos de l'abandon.
Posté par Ayrton . Évalué à 2.
> ubuntu l'a ( oui , mais les packageurs sont aussi des devellopeurs de gnome )
Pour Fedora il manque "oui , mais les packageurs sont aussi des devellopeurs de gnome".
L'absence ou la présence de Gnome 2.8 est actuellement un problème de timing.
Mandrake : vienne de sortir une distribution. C'était trop tôt pour ajouter Gnome 2.8
SuSE : idem Mandrake
Fedora : A l'origine de FC3, gnome 2.8 était prévu. Au pire Fedora recule la date de sortie.
Debian : Debian est en freeze pour Sarge. Gnome 2.8 est arrivé trop tard.
Ubuntu : Comme Fedora, distribution "dédié" gnome 2.8.
Gentoo : l'a. Mouaif... C'est "spécial" Gentoo
Toutes les prochaines distributions auront Gnome 2.8 (sauf Debian Sarge :-)).
Il reste le "problème" Slackware.
Je précise un peu pour Mandrake, SuSE et Fedora. Mandrake 10.1 "official" et SuSE 9.2 sortiront environ en même temps que Fedora 3.
Mais Fedora n'a pas la contrainte du packaging (mettre à jour la doc, faire les boîtes, valider le produit pas le département qualité pour ne pas faire exploser la hotline, graver les CD, coordonner les différences fournisseurs, attendre que le driver proprio bidule soit dispo).
[^] # Re: A propos de l'abandon.
Posté par modr123 . Évalué à 1.
Pat a toujours mis un certain temps pour passer une nouveau gnome dans testing et ce n'est pas nouveau
[^] # 2 notes:
Posté par imr . Évalué à 4.
-Aucun des commentaires qui parlent à la place du responsable slackware sur le forum dropline n'est pour l'instant authentifié, ils ont chacun 1 commentaire sur ce forum.
-les commentaires en questions qui le citent disent que ses raisons sont:
* une semaine pour compiler gnome, c'est l'horreur (NdM: pas nouveau)
* le design de gnome 2.8 dépend du kernel 2.6, de dbus et de hal et il traiterait tout ça de "bloat insecure".
et pour dropline aussi il est cité comme le qualifiant de "IMHO, Dropline has made some really questionable design decisions, and it's likely to always be less reliable than what Slackware ships. "
Donc tout ça me parait bizarre, gnome 2.8 serait un bloat insecure et personne ne le saurait et pour remédier à ça il préférerait ne pas fournir sa version de gnome et laisser ses utilisateurs utiliser quelque chose au design moisi?
...mouais... Je vais attendre et voir ce que dit le monsieur en personne avant de croire à tout ce qui est sur ce forum.
[^] # Re: 2 notes:
Posté par gnumdk (site web personnel) . Évalué à -2.
Bon, si c'est vrai, ca sera marrant de voir comment il va réagir quand kde 4 va arriver avec Hal + dbus :)
[^] # Re: 2 notes:
Posté par oliv . Évalué à -2.
Je n'ai pas l'impression que les utilisateurs KDE lancent des trolls anti-Gnome. J'ai plus souvent vu le contraire ...
PS: je n'utilise ni l'un, ni l'autre: Rox rules my world ;)
[^] # Re: 2 notes:
Posté par gnumdk (site web personnel) . Évalué à 3.
Ps: j'utilise Kde ;)
[^] # Re: 2 notes:
Posté par Croconux . Évalué à 6.
Pour avoir compilé un Gnome entier sur une LFS je confirme que c'est l'horreur pour les dépendances. Alors je veux bien croire Pat. La technique de base est "je tente de compiler dans un certain ordre et si le configure me gueule dessus je compile le truc qui lui manque".
KDE n'est pas forcément super évident à compiler la première fois mais au moins on ne change pas les dépendances ni l'ordre dans lequel il faut tout compiler à chaque version. C'est ce que dit Pat. Il s'est fait chier une fois à faire des scripts pour faire ses paquets et à chaque sortie de version il lance son script et youpla ça roule. Avec Gnome il y a de subtiles changements qui deviennent vite énervant. Vouloir faire modulaire c'est bien mais il faut choisir correctement où on coupe les morceaux. Si on fait un truc modulaire mais que tous les modules dépendent les uns des autres dans un ordre aléatoire c'est qu'on a pas coupé au bon endroit.
Bon, si c'est vrai, ca sera marrant de voir comment il va réagir quand kde 4 va arriver avec Hal + dbus :)
Si on choisi correctement ses interfaces on se contrefout de savoir ce qu'il y a en dessous. tout ce qui change c'est la couche basse qui doit cacher ce genre de détails à tout le reste du sytème.
[^] # Re: 2 notes:
Posté par itstimetogo . Évalué à -4.
On ne fait pas d'omelette sans casser des oeufs.
> Vouloir faire modulaire c'est bien mais il faut choisir correctement où on coupe les morceaux. Si on fait un truc modulaire mais que tous les modules dépendent les uns des autres dans un ordre aléatoire c'est qu'on a pas coupé au bon endroit.
Tu peux être précis.
Ton commentaire ne ressemble qu'a un troll.
Où gnome n'est pas "coupé au bon endroit" ?
> Si on choisi correctement ses interfaces on se contrefout de savoir ce qu'il y a en dessous. tout ce qui change c'est la couche basse qui doit cacher ce genre de détails à tout le reste du sytème.
Ce n'est pas ce que fait Gnome ?
[^] # Re: 2 notes:
Posté par Mr_Moustache . Évalué à 1.
[^] # Re: 2 notes:
Posté par Ayrton . Évalué à 7.
Hummm...
Je n'ai pas essayé mais gnome 2.8 doit surement être compilable sans Hal. Le nombre de paquet qui utilise Hal est assez limité.
Hal a besoin d'udev. En fait Hal a "seulement" besoin de hotplug mais sans udev il y a des problèmes de permission d'accès aux périphériques et Gnome-volume-manager devient moins intéressant. Un périphérique est ajouté mais tu ne peux pas l'utiliser... Il a fallut ajouter, "sur le tard", dans udev un moyen pour changer les permissions des fichiers dans /dev. Avant c'était uniquement fait au login.
Donc pour Hal, il faut Linux 2.6.
> il traiterait tout ça de "bloat insecure".
Pour bloat, je ne suis pas d'accord. La mécanique udev est certe subtile mais pas "bloat". C'est un /dev dynamique mais côté userland avec des hooks sur le noyau donc forcément ce n'est pas aussi "pure" qu'un /dev static ou uniquement géré par le noyau (devfs). Mais ça permet des choses indispensables pour un Desktop moderne.
Pour "insecure", il n'a pas totalement tord. Il y avait des problèmes et il reste un problème. Hal a la "facheuse" habitude de rendre montable par l'utilisateur (pas root) tout ce qu'il trouve. Avant pour monter un périphérique il fallait l'expliciter (via fstab). Ça va être corrigé dans peu de temps (Hal sera configurable pour indiquer ce qu'il gérer dans fstab).
> Donc tout ça me parait bizarre, gnome 2.8 serait un bloat insecure et personne ne le saurait et pour remédier à ça il préférerait ne pas fournir sa version de gnome et laisser ses utilisateurs utiliser quelque chose au design moisi?
J'ai suivit FC3 de loin, ajouter udev et hal est assez "douloureux".
A ça, il y a deux raisons :
* udev :
- udev doit être embarqué dans initrd ou il faut aussi un /dev statiques temporaire
- rc.sysinit doit être adapté pour udev
- Il n'y a plus de chargement à la demande des drivers lorsque ça passe par un fichier spécial. Il faut donc détecter au boot les drivers necessaires et les charger.
- "install" de modprobe.conf ne marche pas s'il faut les fichiers spéciaux du périphérique.
Harald Hoyer a fait une bonne présentation de l'utilisation d'udev dans FC3 :
http://people.redhat.com/~harald/udev.html(...)
* C'est tout nouveau comme concept dans Unix : L'argument parait "bête" mais ça soulève plein de problèmes qu'il faut résoudre en pensant différament.
Par exemple, pour restaurer la configuration de la carte son, avant on utilisait modprobe.conf. Ça ne marche plus car avec udev les fichiers spéciaux sont créés _après_ insmod. Donc "alsactl restore" par modprobe ne marche pas car alsa ne trouve pas les fichiers spéciaux. De plus, udev (via hotplug) sépare les services et les modules. Par exemple, à une carte son, il peut y avoir plusieurs services (pcm, mixer, etc). Pour modprobe, c'est un évènement (chargement d'un module). Pour udev, c'est autant d'évènements qu'il y a de services. Dans ce contexte, il n'est pas facile de savoir si le driver de la carte son est disponible ou en cours de chargement (ça a aussi montré quelques bugs dans les drivers :-)).
Corriger tous ces nouveaux problèmes a demandé un effort considérable. Il serait instructif de faire une comparaison entre FC3T1 et FC3T3 (qui sort aujourd'hui) pour voir la quatité de travail réalisé autour d'udev/hal les fichiers d'init etc. C'est énorme compte tenu du délai et que ces projets sont bas niveau. Quand udev ne marche pas, plus rien ne marche :-)
Peut-être que le mainteneur de Slack a été "dégouté" par ça. Surtout s'il veut conserver la compatibilité avec Linux 2.4. C'est faisable mais si j'étais mauvaise langue je dirais "qu'il faut vraiment l'avoir que ça à foutre" pour s'attarder sur la compatilité avec Linux 2.4.
Ça soulève un problème intéressant et nouveau. Les distributeurs qui ont une grosse "force de frappe" mènent Linux à un rythme que les "faibles" ne peuvent pas toujours suivre.
Ajoutons que le mainteneur de Slack est tout seul et qu'il utilise KDE. Dans ce cas, je comprend qu'il n'ait plus la motivation de s'arracher les cheveux sur Gnome.
[^] # Re: 2 notes:
Posté par Erwan . Évalué à 3.
En effet, seul gnome-vfs a besoin de hal et on peut le compiler sans. Sur ma Gentoo j'avait d'abord compile sans, en fait je n'utilisais pas hal, et ca marchait tres bien.
Apres en avoir entendu parler plus en details j'ai installe hal et je n'ai eu qu'a recompiler gnome-vfs et compiler gnome-volume-manager.
[^] # Re: A propos de l'abandon.
Posté par Mouns (site web personnel) . Évalué à -4.
on va faire comme si j'ai rien dit, je vais me faire moinser ...
... non c trop dur ...
gnome 2.0 tournait sans XFree ?
gnome 2.0 n'avait pas d'internationnalisation ?
gnome 2.0 n'avait pas ... ****bzzzzzzzzziiiiiiii.........!!!!!!!!
... suite à des parasites provenant d'une planete lointaine, nous somme dans l'obligation d'interompre notre programme, ami mouton, toi, le jackeek qui crache sur ton semblable le decideur pressé, continue à comparer des choses incomparables.
sinon les mainteneurs font ce qu'ils veulent, surtout quand ils font tout le boulot.
[^] # Re: A propos de l'abandon.
Posté par Mouns (site web personnel) . Évalué à -1.
Je rappelle que c'est en "pensant" que les astronomes et l'eglise ont condamné sans reflechir, un lache celebre.
[^] # Re: A propos de l'abandon.
Posté par lezardbreton . Évalué à 2.
[^] # Re: A propos de l'abandon.
Posté par gnumdk (site web personnel) . Évalué à 3.
Si c'est le cas, il doit y avoir moyen de le builder sans ses dépendances vu qu'il tourne sous windows et donc sans gnome ;)
Puis il a dit qu'il ne s'occuperait plus de gnome, ca veux pas dire que dropline ne fera pas parti de la slack (sur un cd 3 ou autre)
[^] # Re: A propos de l'abandon.
Posté par lezardbreton . Évalué à 2.
[^] # Re: A propos de l'abandon.
Posté par Ayrton . Évalué à 2.
Plus il y a de fonctionnalités, plus il y a de dépendances. Mettre toutes les fonctionnalités dans un gros paquet ne diminue pas le nombre de dépendances (elles deviennent "invisibles" mais elles sont toujours là) et tend à rendre le code moins réutilisable et l'ensemble moins modulaire ou organisable. D'ailleur Qt va être splitté en plusieurs librairies.
Quand on voit que certains rechignent à utilise une petite librairie comme glib, et "préfèrent" tout recoder, images ce que ça donne si glib pango gtk+ gnomelib est dans la même librairie.
Splitter un projet comme Gnome en "petit bout" est bien.
Le problème avec ces discussions de "trop de dépendances" est qu'il est souvent centré sur les désires d'une personne seulement.
Personne A :
- Il n'utilise pas Gnome et veut Hal. Lui il va dire qu'il faut séparer Hal du reste.
Personne B :
- Il utilise tout Gnome et veut un gros gnome.tar.gz avec Hal (et toussa) car sinon il trouve pénible l'installation depuis les sources.
Personne C :
- Il ne développe pas pour Gnome spécifiquement mais veux quelques fonctionnalités de Gnome sans copier tout Gnome. Par exemple il veux Gconf ou Pango ou libbonobo mais sans avoir à installer nautilus, gdm et gnome-panel. Si un trou de sécurité est corrigé, il ne veut pas recompiler tout Gnome mais seulement le "petit" paquet affecté.
Personne D :
- Elle veut bien maintenir un sous-ensemble de gtk+ (pango) mais pas tout gtk+
On voit qu'il y a B qui n'est pas content actuellement. Des gens qui compilent depuis les sources pour avoir un programme sont rares. Donc, on peut le mettre de côté :-)
Ceci dit, la construction des paquets peut être améliorer et il faut peut-être augmenter l'effort sur garnome.
[^] # Re: A propos de l'abandon.
Posté par Croconux . Évalué à 3.
Ca n'a pas besoin d'être dans la même bibliothèque mais personellement je regrouperais gtk et pango.
Glib fourni des services de base (string, etc). c'est normal que ce soit séparé du reste. Gnomelib fourni tout ce qui permet l'intégration d'un programme dans Gnome. C'est aussi normal que ce soit une surcouche de Gtk.
Gtk, lui, fourni toutes les classes graphiques. Sauf que si je veux gérer les caractères étendus (langues asiatiques), bah là il me faut un machin en plus qui s'appelle pango. Même chose pour Gdk : Je fait un GUI j'utilise les Gtk_machin sauf que pour certaines choses il me faut utiliser les objets Gdk_machin.
Je ne vois que 3 couche dans tout ça : Une couche de base (Glib), une couche graphique non lié à un environnement de bureau particulier (Gtk), et une couche d'intégration à Gnome (Gnomelib). D'un coup ça devient plus simple que les whatmille librairies.
[^] # Re: A propos de l'abandon.
Posté par itstimetogo . Évalué à 3.
Il faut ouvrir un peut plus les yeux.
Pourquoi GConf serait dans gnomelib ?
GConf est un moyen pour stocker des informations de configuration et peut être utilisé sans Gtk+ ou gnome. Ça peut-être utilisé par des applis non graphiques.
gnome-vfs est un moyen unifier d'accès à des ressources (fichier, ftp, etc) et peut-être extrait de gnomelib. gnome-vfs peut être utilisé par des applis non graphique.
Pango peut-être utilisé sans Gtk (pour tout rendu UTF8). Un Qt au-dessus de pango est possible.
Je ne vais pas multiplier les exemples.
Si les choses sont comme ça, c'est qu'il y a des raisons à ça.
La majorité des utilisateurs n'ont pas à connaitre ces détails. Il y a des logiciels pour s'occuper des dépendances et récuperer evolution avec tout "son bordel" de dépendance.
Ça me ferait mal de mettre à jour un GROS gnomelib pour un petit fix dans gnome-vfs ou GConf.
[^] # Re: A propos de l'abandon.
Posté par itstimetogo . Évalué à 2.
Gtk+ utilise pango. Il n'y a rien à faire pour que Gtk+ utilise pango.
> Même chose pour Gdk : Je fait un GUI j'utilise les Gtk_machin sauf que pour certaines choses il me faut utiliser les objets Gdk_machin.
Gdk fait l'affichage. Gtk+ s'occupe des widgets.
Donc, si tu utilises un widget (menu déroulant, bouton), c'est Gtk+ (qui fera l'affichage avec Gdk).
Si tu fais de l'affichage direct (drawing), c'est Gdk. Gimp pour l'affichage des images utilise Gdk. Pour son menu gimp utilise Gtk.
Les widgets sont gérés par Gtk+ (quand les afficher, supporter une hirarchie de widgets, attacher des évènements, lier les widgets entre eux, appliquer le thème choisi par l'utilisateur, etc).
Gdk ne fait pas ça. Il n'y a pas de thème pour gdk, etc.
Gdk est une surcouche d'X11. Si tu portes tout Gtk+ pour framebuffer il faut adapter Gdk et pas Gtk.
Encore un foi ce découpage existe car il y a de BONNES raisons à ça.
[^] # Re: A propos de l'abandon.
Posté par Ayrton . Évalué à 0.
J'ai lu que Qt va être splitté en 3 paquets.
Xorg va aussi est splitté en différents projets (driver, libX11, police, extensions, etc).
T'as pas fini de gueuler :-)
[^] # Re: A propos de l'abandon.
Posté par modr123 . Évalué à 1.
on peut le faire avec jhbuild et graphviz
# Différences ?
Posté par Anonyme . Évalué à 2.
J'ai pu lire que Dropline modifiait beaucoup (jusqu'à quel point ?) l'organisation de la slackware.
Je demande cela, car j'ai l'habitude de n'installer que les paquets de GNOME nécessaires à l'execution des applications GNOME (je n'utilise pas l'environnement en lui-même). Est-il possible de n'installer que les paquets de base ?
Dans les requirements du site, il est indiqué qu'il est nécessaire d'installer pilotlink pour pouvoir utiliser les paquets dropline; sur mon installation je n'ai pas besoin de ce package (support pour PDA): y a t il des possibilités de configuration pour sélectionner les dépendances de manière plus fine que celle par défaut ?
[^] # Re: Différences ?
Posté par Psychofox (Mastodon) . Évalué à 3.
Ce qui change le plus l'organisation de la slackware, c'est l'installation de PAM. P Volkerding ne veut pas de PAM dans la slackware pour des raisons de sécurité.
[^] # Re: Différences ?
Posté par Ayrton . Évalué à -1.
!!!!????!!!!
Tu peux préciser s'il te plait. PAM c'est pour la sécurité comme son nom l'indique :
Pluggable Authentication Modules
[^] # Re: Différences ?
Posté par Psychofox (Mastodon) . Évalué à 3.
Et il compte rester sur sa position un moment :
"If you see a security problem reported which depends on PAM, you can be glad you run Slackware. I think a better name for PAM might be SCAM, for Swiss Cheese Authentication Modules, and have never felt that the small amount of convenience it provides is worth the great loss of system security. We miss out on half a dozen security problems a year by not using PAM, but you can always install it yourself if you feel that you're missing out on the fun. (No, don't do that.) OK, I'm done ranting here. :-)"
[^] # Re: Différences ?
Posté par Ayrton . Évalué à -2.
Pour Fedora (sur un an : FC1 et FC2) il y a UNE mise à jour de pam. La mise à jour est pour FC1 et ne conserne pas un problème de sécurité.
M'enfin, s'il préfère bosser sous root...
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 3.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Différences ?
Posté par Ayrton . Évalué à 0.
Besoin de persistance pour l'authentification root (ça t'évite de taper 50 fois le mots de passe lorsque tu lances le programme de configuration de bind, puis le programme pour configurer la carte graphique, puis le programme pour faire la mise à jour, etc), PAM est utile.
Changer les droits de /dev/cdwriter pour qu'un utilisateur puisse graver un CD (sans que cdrecord est le SUID), PAM est utile (c'est mieux que d'ajouter des privilège à l'utilisateur en l'ajoutant aux groupes disk, sound, etc, et au moins avec PAM il n'y a pas de conflit).
Fixer des limits en fonction d'une configuration compliqués, PAM est utile.
Mais surtout, la souplesse de PAM (marche avec des plugins) est disponible pour _toutes_ les applis qui utilisent PAM. Si tu veux que l'application titi soit lancée avec les mêmes conditions que les serveurs X11, c'est trivial a faire. Si tu veux virer la persistance du mot de passe root, tu peux le faire pour _toutes_ les applis à la fois.
Ça évite des tonnes de réécriture de code et donc des trous de sécurité.
Tu peux trouver ça inutile puisque Linux est né sans ça. Mais on est en 2004 et non en 1994. Lorsque je me loggue je veux, que dis-je, j'exige que le graveur, la carte son, la carte TV, etc marche "out of the box" sans me faire chier à éditer /etc/group ou faire les horribles "chmod o+w /dev/...."
Si je suis admin et que je veux que seul l'utilisateur toto puisse faire un startx. Je veux pouvoir le faire sans sans appliquer un patch 2 000 lines à X11 puis recompiler le bousin.
PS : il ne faut pas confondre PAM et sudo.
[^] # Re: Différences ?
Posté par ckyl . Évalué à 1.
PAM n'a rien a voir avec SU ou SUDO. PAM fournit un ensemble de primitive aux developpeurs pour gerer l'authentification et une facon simple de configurer les regles d'access au administrateurs systemes.
Apres :
-> Si tu preferes recoder dans *chaque* appli la gestion de l'authentification aucun probleme. Enfin entre auditer LinuxPAM ou OpenPAM et auditer 3049565 applis gerant elles meme leur auth moi j'ai vite fait mon choix
-> Si tu preferes patche a la main les applis pour leur permet de changer de mode d'auth. ca me pose pas non plus de probleme.
Le seul problème avec PAM est que dans la floppee de module seul quelques uns ont ete audites correctement.
PAM est la pour etre utilise par su et sudo justement !
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 2.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Différences ?
Posté par Ayrton . Évalué à -3.
Quelque part oui. Avec pam, lorsque je lance par exemple system-config-display, il me demande le mot de passe root (et en graphique si je suis sous X11).
Si cette "feature" ne me plait pas, je n'ai qu'a éditer /etc/pam.d/system-config-display.
Certe, tu peux configurer sudo pour faire environ la même chose. Mais tu dois passer root pour faire ça.
Avec PAM les droits de /dev/cdwriter etc sont en order _sans_ utiliser root pour ajouter un compte au group disk (qui donne accès à TOUS les disques) ou faire un chmod/chown.
Avec PAM, j'ai tout ça (et bien plus) sans jamais faire un su(do), un chown par là, un addgroup ici, etc.
PAM (et bien d'autres éléments complexes qui semblent rebuter le mainteneur de Slack (Il est tout seul pour un distribution, c'est compréhensible)) permet d'avoir un Unix (un *vrai* avec un contrôle rigoureux des droits) pour desktop qui ne sucks pas.
[^] # Re: Différences ?
Posté par gnumdk (site web personnel) . Évalué à 2.
Le nombre de fois ou je me suis retrouvé sous X sans acces au devices paske j'avais logué un autre utilisateur en console. Et à la fin tu met tout le monde dans le groupe video, tu modifie le fichier de conf de pam_console en 660 sur le device, et tu te retrouves dans le meme cas de figure que sans pam_console et tu te dis: "mais a quoi ca sert a par me casser les couilles?" :)
C'est anti unix et en plus ca ne sert a rien, tu fais la meme chose avec des groupes et des droits.
De plus ton argument du "sans jamais faire un su(do), un chown par là, un addgroup ici, etc." ne tient pas vu que udev fait le boulot comme un grand:
/etc/udev/permissions.d/udev.permissions.
[^] # Re: Différences ?
Posté par ckyl . Évalué à 2.
Si tu mets les utilisateurs locaux dans un groupe qui a toujours access au peripherique tu permets aux utilisateurs de voir les fichiers des autres.
Dans les lieux publiques du style universite t'as surement pas envie que toute la fac puisse recuperer les fichiers de ta cle usb...
A chaque probleme sa solution. Si pam_console n'est surement pas adapte pour ta machine perso, pour le moment sur certaines configuration je n'ai rien trouve de meilleur... Et on peut pas dire que je porte reellement ce module dans mon coeur.
> C'est anti unix
Le probleme d'unix c'est qu'il s'agit d'un modele qui va sur sa trentaine et que beaucoup aimerait voir comme la solution ultime car linux est basé dessus. Les groupes UNIX c'est pourtant un peu la misère quand meme hein... Et que tu vois l'etat des ACLs (chose de base par exemple) dans les projets libre ca fait plutot pleurer qu'autre chose. En l'occurence on a besoin de pam_console par ce que le systeme n'offre pas de meilleure alternative.
Un jour il faudra se remettre a evoluer quand meme dans le domaine du systeme.
[^] # Re: Différences ?
Posté par gnumdk (site web personnel) . Évalué à 3.
>peripherique tu permets aux utilisateurs de voir les fichiers des autres.
Oui, mais comme expliqué plus bas, pam_console ne regle malheureusement pas le probleme.
[^] # Re: Différences ?
Posté par Ayrton . Évalué à 0.
C'est bien, tu dois être content.
Si tu veux ACL, t'installes ACL. Mais ACL ne résoud toujours pas le problème conflit. Si deux types accèdent à la même ressource (graver un CD), ça merde.
Avec des mecs comme toi, je vais militer pour la suppression des consoles et ne garder que X11.
> C'est anti unix
Tu pourrais aussi dire anti-gnu. T'es pas à un troll près.
Où tu as vu que les fichiers dans /dev ne doivent jamais changer de propriétaire ?
pam_console n'est qu'une partie de pam (c'est un "plugin" parmi d'autres). Si tu n'aimes pas pam_console (c'est subjectif) édites les fichiers /etc/pam.d/* et vires "session ... pam_console.so" . Un "grep" d'aidera à trouver rapidement ces fichiers (si tu connais grep).
Et voilà. C'est anti-Unix ça aussi ?
Pour le reste des caractéristiques de PAM, lis la doc et ne t'étales pas sur tes impressions car tu as utilisé une distribution qui utilise PAM.
> udev fait le boulot comme un grand:
> /etc/udev/permissions.d/udev.permissions
Ha Ha Ha.
Tu ne connais pas PAM ni udev. T'es charmant.
udev crée des fichiers à la volé et doit leur affecter les droits qui sont fixé généralement avec MAKEDEV (à la création/packaging de /dev). Mais MAKEDEV n'est pas forcément disponible (dans initrd ou en début de boot). De plus MAKEDEV a ses limites. Entre autre il gène les périphériques pour un nombre limité de périphériques avec des paires majeur/mineur _déjà_ connu. Avec udev tu peux avoir 5 000 disques durs. MAKEDEV n'a pas les droits pour 5 000 disques durs (problème des paires majeur/mineur préalloués qu'évite udev ; Linux 2.7 va peut-être virer toute notion de paires majeur/mineur pour en faveur d'un "id" ou "handler" (le nom n'est pas encore connu) alloué dynamiquement (1,2,3...)).
Donc, /etc/udev/permissions.d/udev.permissions n'est rien d'autre que MAKEDEV mais adapté à udev. Si tu regardes de plus près, udev.permissions à les MÊME permissions que celles que tu trouves dans /etc/makedev.d/ (fichier de config de MAKEDEV). Il défini les droits, owner et group par _défaut_. Il ne connait rien au login. Quelque soit la personne loggué, c'est toujours le même propriétaire du fichier spécial.
Dans udev de Fedora, il y a /etc/udev/permissions.d/ _ET_ pam_setowner pour avoir l'équivalent de pam_console.so . En effet, il faut faire le boulot de pam_console.so non au login ou au lancement d'une appli mais à lors de l'arrivé d'un nouveau périphérique. PAM ne supporte pas ça (PAM est déclenché par programme) et udev a été "hacké" pour conserver la logique de pam_console.so.
udev crée les fichiers en tenant compte de /etc/udev/permissions.d/ (équivalent de MAKEDEV) puis lance pam_setowner qui va, par exemple, mettre le propriétaire de /dev/cdrom à titi.
pam_setowner utilisera le fichier /etc/security/console.perms comme configuration (comme le fait pam_console.so). Encore un truc que tu ne connais pas mais ça ne t'empêche pas de juger ce qui est pro-Unix et Anti-Unix.
[^] # Re: Différences ?
Posté par gnumdk (site web personnel) . Évalué à 4.
Ca tombe bien, c'est ce que j'ai dit.
>Quelque soit la personne loggué, c'est toujours le même propriétaire du fichier spécial.
Ca tombe bien, j'ai jamais dit ca ;) Cite moi en train de dire que udev change le propriétaire du device ;)
>Si deux types accèdent à la même ressource (graver un CD), ça merde.
When a user logs in at the console and no other user is currently
logged in at the console, pam_console.so will change permissions and
ownership of files as described in the file /etc/security/console.perms.
Donc en clair, le seul moyen de pouvoir graver, c'est d'attendre que l'utilisateur de devant ait fini. Tu vas me dire que c'est ok, je te repond non, c'est nul, qui te dit que l'utilisateur de devant va vouloir se déloguer ;) Moi, a sa place, je ne le ferai pas, tu veux graver, le méchant pam_console m'a donné tout les droit parce que j'etait la avant? ben tant pis :p
Tu vois, si vraiment l'accés concurrent à un device est un probleme, avec sudo + un utilisateur dédié à la gravure et ayant seul accés au graveur, avec quelque lignes de shell, tu fais un systeme de file d'attente pour la gravure.
$ sudo burn coin.iso
5 gravures en attentes...
$ ....
MESSAGE SYSTEM: C'est votre tour de graver votre CD, tapez sudo burn confirm pour confirmer! Votre gravure sera annulée dans 5 minutes si vous ne confirmez pas...
$sudo burn confirm
Et voila, ca ressemble étrangement à ce que l'on trouve sur les serveur de build de mdksoft pour les installations de packages concurentes, et c'est propre. Pas ton vieux truc immonde qui considere que seul le premier utilisateur a le droit de faire quelque chose et qui doit se déloguer pour donner ce droit au suivant ;)
>Encore un truc que tu ne connais pas...
Ah ah ah, nan, je connais pas pam_console, je connais suffisement et j'ai assez tester pour savoir que c'est la merde, que ca ne repond en aucun cas au besoin que tu trouves dans une université par exemple (puisque c'est la que j'ai eu l'occasion de voir ses limites ;)
[^] # Re: Différences ?
Posté par ckyl . Évalué à 0.
evidement pam_console est fait pour donner l'acces a des peripheriques predefinis a l'UTILISATEUR LOCAL(au singulier) actuellement loge localement sur la machine. Un station typique c'est UN utilisateur local.
Si c'est pas ta configuration ne l'utilise pas ou apprend a t'en servir (on peut changer les permissions par defaut).
Ta critique est infondée puisque tu l'utilise pour un usage qu'il n'est pas censé gérer !
Note: seul l'utilisateur se logguant depuis la console physique est considere, le autre n'ont rien.
Note 2: en sachant configurer la chose c'est possible, la preuve sur la machine de mes parents y'a 3 sessions X en permanences.... Meme si dans ce cas ca n'apporte rien, hormis d'etre plus facile a gerer qu'une floppee de chmod.
[^] # Re: Différences ?
Posté par gnumdk (site web personnel) . Évalué à 5.
Sans blague ;)
Tu sais que y'a encore des serveurs ou on peut etre plusieurs utilisateurs locaux sans connexion distante et avec un clavier/souris chacun? :)
Parce que une station ou y'a qu'un utilisateur, je vois plus le probleme d'acces concurrent à un device ;)
>Ta critique est infondée puisque tu l'utilise pour un usage qu'il n'est pas censé gérer !
Ben, je vois pas quand pam_console doit le gérer alors, avec un user on me dit que non, avec plusieurs on me dit que non :)
>Si c'est pas ta configuration ne l'utilise pas ou apprend a t'en servir (on peut
>changer les permissions par defaut).
Donc t'es en train de me dire de changer les droits dans la conf de pam_console? Mais a quoi sert pam_console alors? Changer les droits, je peux deja le faire avec chmod :) Mais sur une distrib bien foutu, j'ai meme pas a le faire ;)
>seul l'utilisateur se logguant depuis la console physique est considere, le autre n'ont rien.
Oui, mais plusieurs utilisateurs peuvent se connecter depuis cette derniere et ceux avec un clavier/ecran chacun :) Donc non, les autres n'ont pas rien, ils sont en attente que le second se délogue :)
>en sachant configurer la chose c'est possible, la preuve sur la machine de mes
>parents y'a 3 sessions X en permanences.... Meme si dans ce cas ca n'apporte
>rien, hormis d'etre plus facile a gerer qu'une floppee de chmod.
Tres mauvais exemple, tu me donnes un argument pour te prouver par a+b que c'est naze pam_console :) Sur ma machine sous Mandrake, si je lance une seconde session X(via gdm ou kdm par exemple), mon second utilisateur n'a pas accés à la carte son. Sur une debian je fais la meme opération et les deux utilisateurs ont accés a cette derniere. Alors certe, j'ai qu'a ajouté mon second utilisateur dans le groupe audio, mais je vois plus du tout l'interet de pam_console.
[^] # Re: Différences ?
Posté par ckyl . Évalué à 1.
> Tu sais que y'a encore des serveurs ou on peut etre plusieurs utilisateurs locaux sans connexion distante et avec un clavier/souris chacun? :)
Oui je viens de t'expliquer que pam_console n'etait pas prevu pour gerer ce type d'utilisation. Si tu veux laisser l'access au lecteur de disquette dans ce cas de figure. Passe ton chemin ou met des permissions pour le groupe. Niveau secu c'est top je te dis pas... c'est *possible* ce n'est pas la configuration a la sortie de la boite.
> Parce que une station ou y'a qu'un utilisateur, je vois plus le probleme d'acces concurrent à un device ;)
pam_console ne resoud pas les access concurent (je le l'ai jamais dit 007 peut etre). pam_console empeche deux utilisateurs d'avoir les droits sur les peripheriques dans sa configuration de base.
-> gentil se log par gdm, il recupere les permissions sur tout les peripheriques locaux de la machine.
-> maichant se log par ssh, il ne peut plus s'amuser a aller jouer avec les peripheriques de gentil. Comme il est logger par ssh et dans le cas typique d'utilisation des stations, on s'en branle qu'il puisse monter la disquette, il n'est pas physiquement sur la machine. Si tu cherches du plus spécifique tu configures....
> Donc t'es en train de me dire de changer les droits dans la conf de pam_console?
boulet... Comme tout logiciel celui ci se parametre pour correspondre a tes besoins si la config par defaut ne te va pas. Tu connais un seul logiciel qui repond au besoin de tout les utilisateurs sur terre avec la config par defaut ? moi pas
> Oui, mais plusieurs utilisateurs peuvent se connecter depuis cette derniere et ceux avec un clavier/ecran chacun :)
encore une fois, tout est possible. ll est aussi possible de config pour que ca marche en ouvrant de joli probleme de secu.
> Tres mauvais exemple, tu me donnes un argument pour te prouver par a+b que c'est naze pam_console
Ha ? Je viens de te prouver qu'on pouvait faire que ca marche... Entre chercher en permanence quel sont les droits sur les periphs (un erreur est vite arrivee !) et remplir un chmod/chown automatique dans un fichier et avoir une vue clair de ce qui se passe en ce moment. Je sais lequel j'ai choisi.
M'enfin tout ce que tu prouves c'est que tu ne sais pas de quoi tu parles, que tu sais utiliser debian et pas mdk. Hormis ca je trouve pas. Et si tu n'avais pas compris, ils se partages certaines ressources sans problemes mais avec le bordel que ca amene en prime. Mais tu trouves aussi peut etre normal que lorsque quelqu'un s'absente en xlockant son term, on puisse passer derriere en ouvrant une autre session pour recuperer les donnees sur les disques amovibles...
[^] # Re: Différences ?
Posté par Ayrton . Évalué à -2.
Tout à des limites. Toi t'es limité aux Unix du début des années 80.
Tester sans comprendre et surtout juger en terme crétin comme "anti unix", "c'est la merde" alors que c'est utilisé par tout le monde sauf Monssiieeuurr ... est crétin.
Tu mélanges tout, tu n'y comprends rien et t'es un crétin.
T'as le profiles idéals pour tenir des jugements de crétin et gérer des bécanes à la petit semaine de façon non sécurisé, car tu n'y comprends rien, avec des chown et addgroup de débutant lu dans le chapitre 0 consacré à l'instroduction aux préliminaires d'un manuel d'initiation à Unix.
T'es un crétin.
[^] # Re: Différences ?
Posté par Ayrton . Évalué à 0.
Fais "man batch" (regarde '-q') pour les files.
Pour la communication utilise mail ou le système multicast de syslog.
Pour les locks, utilise lockfile. Pour "délocker" un simple "rm", lors de acquitement manuel de l'utilisateur, suffit et tu graves la galette suivante.
Avec ça plus quelques scripts shell tu auras ton serveur de gravage (qui n'a rien à voir avec pam_console). Mets le tout sous GPL qu'on rigole.
Evidement, avec des éléments aussi "rustres" et car c'est un serveur il te faudras encore sudo/su et tu pourras crier très fort : Vive sudo, à mort pam_console !
[^] # Re: Différences ?
Posté par Ayrton . Évalué à -2.
De tout manière, 90 % des postes Linux ont PAM. Pour information, PAM a été développé initialement pour les Unix commerciaux et existe sur _tous_ les unix commerciaux. Je dis ça pour le type qui prétend que PAM est anti-Unix.
Encore pour information, PAM peut autoriser un utilisateur en utilisant kerberos ou une base de donnée ou n'importe quoi d'autre. PAM peut fixer correctement la variable DISPLAY lorsque c'est un login distant. PAM permet de dire que pour tel programme, si c'est l'utilisateur bidule qui se connecte depuis la machine machin, alors il est autorisé. Ces fonctionnalités sont appliqués pour _toutes_ les applis qui utilisent pam.
Que ça ne vous empêche pas de bêtement détester PAM car vous ne connaissez pas PAM.
[^] # Re: Différences ?
Posté par ckyl . Évalué à 4.
my 2 cents.
[^] # Re: Différences ?
Posté par Psychofox (Mastodon) . Évalué à 4.
e vous fiez pas au FUD des "adorateurs" de Slack qui veulent un OS qui sucks pour le desktop.
c'est pas du FUD ça ? ;)
1. Personne n'a dit dans ces commentaires qu'il haïssait PAM. J'ai moi-même cité P. Volkerding qui n'aime pas PAM parce qu'il le trouve pas secure, parce que quelqu'un voulait savoir pourquoi PAM n'était pas dans la slack. Moi, j'ai mis une dropline sur le pc de mon épouse et j'en suis satisfait.
2. L'idée, c'était d'expliquer pourquoi la slack n'avait pas PAM par défaut, pas de critiquer PAM. On sait bien qu'il a ses avantages, même Volkerding le sait. Y'a des gens qui pensent à la sécurité en premier, d'autres au côté pratique, d'autres aux possibilités offertes, bref, ni toi ni moi ne peuvent prétendre qu'il existe une solution meilleure que l'autre, tout dépend de ce que l'on veut.
3. la slack ne suxor pas plus qu'une autre distro et un utilisateur peut faire les mêmes choses sur sa slack (avec ou sans PAM) que sur d'autres distros, bref, arrête de pleurnicher en tapant des pieds parce que des gens veulent pas utiliser PAM, que dirait ta mère ?
[^] # Re: Différences ?
Posté par Ayrton . Évalué à -2.
si
> 1. Personne n'a dit dans ces commentaires qu'il haïssait PAM.
Je ne comprends pas pourquoi je me fais moinsser alors que j'explique ce qu'est PAM.
Des gens disent "ça pue, ça sert à rien" et je prends de mon temps pour expliquer pourquoi PAM est sur 100 % des Unix et 90 % des Linux et je me fais moinser. Je trouve ça anormal. gnumdk qui ne connait pas PAM et traite PAM d'anti-Unix n'est pas moinsé. Expliques ça.
> Moi, j'ai mis une dropline sur le pc de mon épouse et j'en suis satisfait.
Le sexisme...
> 2. L'idée, c'était d'expliquer pourquoi la slack n'avait pas PAM par défaut
Bien. J'ai lu ton post. J'ai rien critiqué à ton post.
> Y'a des gens qui pensent à la sécurité en premier, d'autres au côté pratique
PAM n'est pas synonyme d'insécurité. Au contraire.
> tout dépend de ce que l'on veut.
L'explication donné par Volkerding ne portait pas sur le "ce que l'on veut". Ou alors oui, mais de façon "fudiène" (uniquement argumenté en prétendant que PAM est un problème de sécurité).
> arrête de pleurnicher en tapant des pieds parce que des gens veulent pas utiliser PAM, que dirait ta mère ?
Sexiste et bas.
[^] # Re: Différences ?
Posté par gnumdk (site web personnel) . Évalué à 1.
Mais c'est pas vrai quand meme, tu le fais expres de me faire dire des truc que je n'ai pas dit?
JE PARLAIS DE PAM_CONSOLE, PAS DE PAM, c'est compliqué a comprendre?
C'est pam_console qui sux(sur un poste de travail, il ne sert a rien, sur un serveur, il ne sert à rien non plus, voir mon exemple plus haut), pas pam!
[^] # Re: Différences ?
Posté par Psychofox (Mastodon) . Évalué à 1.
> Le sexisme...
gné ? explique-moi tout ça, un mot c'est pas une phrase
>> arrête de pleurnicher en tapant des pieds parce que des gens veulent pas utiliser PAM, que dirait ta mère ?
> Sexiste et bas.
C'est pas sexiste, je te compare juste à un gamin qui va pleurnicher vers sa maman paskeutouslesgenssontmechantsilsmemoinssent. Change d'attitude si tu ne veux pas être pris pour un gamin ;)
[^] # Re: Différences ?
Posté par Ayrton . Évalué à -1.
> gné ? explique-moi tout ça, un mot c'est pas une phrase
En quoi le fait que dropline _te_ (et pas ton éponse) satisfasse sur le PC de ton éponse est significatif ?
En rien sauf si tu considères que les femmes sont plus concon que les mecs.
Si ton frère utilisait dropline, tu ne l'auras sûrement pas mentionné car cet un mec.
> Change d'attitude si tu ne veux pas être pris pour un gamin
Marrant ces formules toutes faites qui passe partout.
Je ne vais pas te faire la morale.
[^] # Re: Différences ?
Posté par Psychofox (Mastodon) . Évalué à 2.
-moi j'utilise xfce + rox donc gnome, je ne l'utilise pas assez pour m'en plaindre.
-je n'ai pas eu de retours négatifs de sa part (bugs, plantages, etc)
-c'est moi qui lui administre son pc et ça s'update facilement.
Tu pourrais dire qu'administrer le pc de sa compagne, c'est sexiste, mais si j'ai mentionné que j'avais installé dropline sur le poste de mon épouse, c'est bien sur parce qu'elle ne savait pas le faire et n'avait pas envie d'apprendre. J'aurai donc mentionné mon frère tout aussi bien mais :
1) il ne vis pas chez moi.
2) il ne m'a jamais demandé de lui installer quoique ce soit.
3) il connait bosse dans l'informatique donc n'a pas besoin de moi.
bref, non ne me fait pas la morale, tu l'as déja faites sans même me connaître assez pour en avoir les moyens.
[^] # Re: Différences ?
Posté par Ayrton . Évalué à 1.
Je ne t'es pas fait la morale mais un reproche. C'est différent.
Te faire la morale c'est ça :
Considères les femmes comme l'égal des hommes et entre autre :
- Arrètes de prendre les femmes pour des cruches, et de croire que tout le monde prend les femmes pour des cruches. Par exemple de considérer comme implicite qu'une femme qui utilise Linux est forcément sur un PC qu'elle n'administre pas.
- Arrètes de considérer que ce qui est important lorsqu'une fille utilise un PC, c'est que le mec qui administre le PC en soit satisfait.
> Tu pourrais dire qu'administrer le pc de sa compagne, c'est sexiste
Prendre ça (ma femme ...) comme preuve de la simplicité, du côté userfriendly de Linux est très clairement sexiste.
On voit rarement (jamais en fait), lorsque l'aspect userfriendly de Linux est abordé, des phrases qui débutent avec :
- "j'ai mon frère qui utilise Linux ..."
Par contre ce type de phrase est courant :
- "J'ai ma (copine|soeur|mère) qui utilise Linux ..."
Je suis un mec et ta phrase m'a sautée yeux pour des raisons que tu n'as pas encore compris manisfestement.
T'as de la "chance" qu'il n'y ait pas de femmes ici.
[^] # Re: Différences ?
Posté par Ayrton . Évalué à -1.
Juste, j'ai oublié ce qui fait une "morale" :
- "sinon tu pourriras en enfer".
C'est le pendant de "si tu ne veux pas être pris pour un gamin".
[^] # Re: Différences ?
Posté par yoplait . Évalué à -2.
Et dans ce genre de contexte, j'en ai vu plein qui parlaient de leur frere, j'en ai vu plein qui parlaient de leur pere et j'en ai vu plein qui parlaient d'un pote quelconque. Je trouve que tu racontes n'importe quoi.
[^] # Re: Différences ?
Posté par Ayrton . Évalué à -1.
Où il est dit :
- "ça fait 3 semaines que mon frère de 12 ans ..."
Tu compares un gamin de 12 ans à l'épouse de PsychoFox...
[^] # Re: Différences ?
Posté par Psychofox (Mastodon) . Évalué à 4.
Ton post fait plus de mal aux femmes que bcp d'autres bien plus machistes, tu fais passer les féministes pour des hystériques. Après on s'étonne que rien ne bouge :P
[^] # Re: Différences ?
Posté par Ayrton . Évalué à -2.
T'as pas l'air de ne pas comprendre que ton préjugé que tout le monde accepte comme acquis que si la personne consernée est une femme, alors forcément elle ne sait pas ou ne veux pas installer/administer une bécane est sexiste.
Si je lis :
- ma femme est contente avec Linux
je ne conclus rien sur la facilité d'utilisation de Linux.
Mais toi tu penses que la phrase précédente va être interprété par tout le monde comme ça :
- ma femme qui n'est pas très douée en informatique est contente avec Linux qui est suffisament simple pour elle.
C'est définitivement sexiste.
> t'es bizarre.
T'es sexiste.
> tu fais passer les féministes pour des hystériques
Dis que tu as oublié de préciser dans ton post initiale que ton épouse ne sait pas (ou ne veux pas) administrer une bécane au-lieu de défendre des propos clairement sexiste. C'est beaucoup plus simple que de ramer "hytériquement" comme tu le fais actuellement.
Tout le monde peut se tromper (et j'ai surement déjà tenu des propos sexistes sans le faire exprès). J'accepte parfaitement ce type d'erreur si elle est reconnue. Je deviens "hystérique" quand quelqu'un ne se rend pas compte des propos sexiste qu'il tient. Que cette personne soit sexiste ou non.
> Après on s'étonne que rien ne bouge
Tu penses qu'en laissant passer des propos sexistes ça va changer ?
Pas moi.
Au fait, laisses ta femme lire ce thread et qu'elle dise ce qu'elle en pense. C'est la première concernée.
[^] # Re: Différences ?
Posté par Psychofox (Mastodon) . Évalué à 1.
Ou vois-tu ce préjugé ? Tu interprète des choses avec du vide, avec justement des mots qui ne sont pas dans mes posts.
Dis que tu as oublié de préciser dans ton post initiale que ton épouse ne sait pas (ou ne veux pas) administrer une bécane au-lieu de défendre des propos clairement sexiste.
Si elle savait installer/administrer sa becane, j'aurais mis, "mon épouse a installé dropline et en est très contente". Malheureusement pour moi, elle ne sait pas le faire, donc j'ai dis naturellement "J'ai mis dropline sur le pc de mon épouse". c'est implicite qu'elle ne sait pas administrer son pc sinon je n'y toucherais même pas. pfff.
Si je lis :
- ma femme est contente avec Linux
je ne conclus rien sur la facilité d'utilisation de Linux
Tu insinues que j'aurais mentionné ma compagne en rapport avec la facilité d'utilisation de linux alors que je n'en n'ai parlé nulle part. J'ai parlé d'être satisfait ou pas d'un produit, ça n'a rien à voir avec le niveau de connaissance en informatique de l'utilisateur. Ou ai-je mis que Dropline est un truc de débutant ?
Tu préfères quoi, que je dise "J'ai installé dropline sur le pc de quelqu'un", et ajouter un masculin neutre inutilement ?
J'ai l'impression que tu t'es retrouvé pris dans ton propre sexisme, en interprètant d'une façon sexiste mes propos et en me le reprochant. Si tu comprends de façon sexiste ce que je dis, je ne peux rien pour toi, c'est de ton côté qu'il faut réviser ton interprétation sexiste de mes propos
Au fait, laisses ta femme lire ce thread et qu'elle dise ce qu'elle en pense. C'est la première concernée.
Elle l'a lu puisque j'ai rédigé mes réponses devant elle. A propos, mon épouse (épouse: Nom.Féminin. Personne officiellement unie à une autre par le mariage.) et moi n'aimons pas qu'on l'appelle "ma femme", nous trouvons ça sexiste car ces termes incluent une notion d'appartenance à un autre (sa femme: la femme de quelqu'un). Comme quoi, je peux pinailler aussi si tu veux et on n'en finit pas. T'as pas de bol d'être tombé sur un couple de féministes militants ;)
[^] # Re: Différences ?
Posté par Ayrton . Évalué à 0.
- "Moi, j'ai mis une dropline sur le pc de mon épouse et j'en suis satisfait."
Si on ne part pas de préjugés sexistes cette phrase est totalement sans intérêt dans le contexte de la discussion sur PAM.
Pour ton info, dropline utilise PAM donc je ne vois pas le rapport avec les raisons du mainteneur de Slack de na pas utiliser PAM.
Donc qu'as-tu voulu dire ?
Que dropline c'est bien et fait ton/votre bonheur ?
J'en suis enchanté.
> Elle l'a lu puisque j'ai rédigé mes réponses devant elle.
Mouaifff...
> n'aimons pas qu'on l'appelle "ma femme"
Désolé.
[^] # Re: Différences ?
Posté par Psychofox (Mastodon) . Évalué à 2.
J'ai justement mentionné ça pour montrer que ce n'est pas parce qu'on considère l'avis de P Volkerding comme valable qu'on est forcément contre PAM dans tous les cas.
[^] # Re: Différences ?
Posté par Ayrton . Évalué à 0.
Oublions ce thread.
[^] # Re: Différences ?
Posté par Pablo Saratxaga (site web personnel) . Évalué à 2.
C'est vrai que pour un vieux usage classique avec les mots de passe dans /etc/passwd ou /etc/shadow ça va; mais maintenant imagine que tu veuilles utiliser un système d'identification via un lecteur d'empreintes digitales, ou de cartes à puces; avec une Slacwkare ce n'est pas possible (sauf patcher et recompiler tous les programmes necessitant l'authentification), avec PAM tu as juste quelques ficheirs texte de config à modifier.
Ou imagine encore (cas réel et vécu) que tu veuilles restreindre l'accès en console à certaines heures et jours poru certains comptes, et pour d'autres comptes permettre un accès distant (ssh, etc) mais seulement depuis certaines adresses ip et à certaiens heures.
Impossible sur une Slackware (je ne saurai même pas dire où commencer à patcher le serveur ssh par exemple).
Avec un système PAM je n'ai eu qu'à écrire en petit module PAM, en copiant largement des modules existants, de façon à qu'il lise un fichier de config et fasse des tests sur non seulement le nom de login et mot de passe, mais aussi la date système et l'adresse ip distante (ou bien si c'est via console locale) et compare ça avec le fichier de config, et une ligne à rajouter dans la config pam de ssh/login etc pour leur dire d'utiliser le nouveau petit module PAM.
Je ne voyais pas trop l'interêt de PAM avant, mais quand j'ai eu à faire ça j'ai bien vu l'interêt de la chose.
Slackware est, à bien des égards, une distribution personelle, faite par une personne pour ses besoins; et elle est difficilement adaptable à des situations non prévues au départ (sauf grosses modifications et recompilations, ce qui reviens en fait à faire une distribution derivée); d'autres distributions utilisent abondamment la modularité (PAM, mais aussi d'autres choses) ce qui permets une très grande adaptabilité sans devoir faire des modifications de bas niveaux ou des patchs dans les sources.
[^] # Re: Différences ?
Posté par Ayrton . Évalué à 0.
Je veux juste ajouter que PAM n'augmente pas les privilèges des programmes. Il ne s'occupe que de l'authentification (sauf quelques modules particuliers qui fixent un contexte (pam_console, pam_selinux, pam_xauth, etc)). En général les systèmes avec PAM sont plus restrictifs que les systèmes sans PAM car PAM a une granulosité plus fine et permet de bien cibler les conditions d'authentification. Sans PAM, les conditions d'authentifications sont très limités.
Le gros problème de PAM, conséquence aussi de son intérêt, est qu'un trou de sécurité dans PAM affecte tous les programmes qui utilisent PAM (ou les programmes qui utilise le module qui a un problème). Je préfère peu de code (car beaucoup de réutilisation) bien audité que beaucoup de code mal audité.
Ceci n'a rien à voir avec sudo (qui peut utiliser PAM).
[^] # Re: Différences ?
Posté par Anonyme . Évalué à 1.
Quelles sont les différences entre les paquets officiels de la slackware, et ceux générés par Dropline ?
Ca, on au aura compris que chez dropline, il mette du PAM partout et que ca ne plait pas à certains. Donc j'en conclut que PAM es la source de perturbation de la slackware originale.
Est-il possible de n'installer que les paquets de base ?
... personne ? ...
y a t il des possibilités de configuration pour sélectionner les dépendances de manière plus fine que celle par défaut ?
Une réponse à cette question m'interesserait tout particulièrement. Je vais meme la préciser:
y a t il des possibilités de configurer les scripts de compilation de manière centralisée dans le but de supprimer certaines dépendances, comme par exemple PAM ou pilotlink?
En fait j'aurais du me limiter à celle-la (mea culpa), ca aurait éviter tout cet énervement qui aboutit à des échanges relativement stériles
merci
[^] # Re: Différences ?
Posté par Anonyme . Évalué à 1.
ca serait bien de pouvoir éditer ses commentaires...
[^] # Re: Différences ?
Posté par itstimetogo . Évalué à 1.
Pour Slack, je ne sais pas. Gentoo répond à ce besoin. Par contre il faut tout recompiler (normal).
La doc gentoo :
http://www.gentoo.org/doc/fr/handbook/handbook-x86.xml(...)
Si c'est une importante priorité pour toi, Gentoo devrait faire ton bonheur.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.