Migration Linux à Windows

Sam Hocevar , dans le message <slrnfaa88d.nbj.sam+news@poulet.zoy.org>,
a écrit :

Par ailleurs, de nos jours les distributions Linux convergent vers un
standard (que d'aucuns ici trouvent inutile, je sais) qui s'appelle LSB

Ça doit être moi dont il est question ici.

Je ne dis pas seulement que LSB est inutile, je dis qu'il est néfaste : il
tend à figer les choses (et même figer les choses façon redhat) là où il y
aurait pourtant pas mal de boulot à faire pour les améliorer.

Ce n'est pas dpkg qui s'occupe de la phase d'install mais
debootstrap.

Au fait, quelqu'un saurait comment on fait maintenant pour l'équivalent de
« base-config » qui a disparu ?

kevin@zipslack:~$ grep smb.conf /var/log/packages/samba-3.0.23a-i4 86-1

Deux poids, deux mesures ? grep smb.conf /var/lib/dpkg/info/samba *.list

Effectivement, j'ignorais completement. Ce qui m'impressionne chez de bian
c'est qu'il y a toujours une reponse a n'importe quelle question.

Pardon mais en quoi /var/log/packages/ serait-il moins imbitable que

/var/lib/dpkg/info ? Franchement, on ne peut deviner ni l'un ni l'autre ,
moi j'ignorais complètement /var/log/packages/,

Reellement dit sans agressivite aucune, as tu deja utilise une slack?
C'est peut etre une des premieres choses que tu apprends avec son
gestionnaire de paquetages:
man removepkg:
DESCRIPTION
removepkg removes a previously installed Slackware package, while writ-
ing a progress report to the standard output. A package may be s peci-
fied either by the full package name (as you'd see liste d in
/var/log/packages/), or by the base package name. For example , the

j'ai utilise pas mal de debian, et le coup du /var/lib/dpkg/info/*list
c'est la premiere fois que j'en entends parler.

Parce qu'on n'en a pas besoin : dpkg est là pour remplir ce rôle.
Sous Slackware, ils préfèrent que l'utilisateur doive se souvenir qu'il
faut faire un grep sur /var/log/packages (ça me rappelle solaris avec
son grep dans /var/sadm/install/contents : oui, ça ne s'invente pas)

bon bah j'ai appris un
truc, maintenant de là à trouver une différence fondamentale de l 'ordre
de Notes/Thunderbird entre les deux approches, je pense que tu n'es pas
loin d'exagérer un petit peu...

Pas vraiment. Mon point ce n'est pas de dire que l'une est mieux que

l'autre ou que machin lave plus blanc, mon point consiste a parler de
l'accessibilite de l'info.

Apprendre le systeme slack cela revient a avoir des connaissances
en shell et tout le reste decoule. La difference majeure entre toutes
les distros consiste dans la maniere de booter et la gestion des
paquetages (et la procedure d'install, mais dans la discussion
c'est secondaire).
Le boot d'une slack en une lecon:
/etc/inittab ca appelle rc.S et rc.M
/etc/rc.d/rc.S pour systeme init, c'est tres lisible,
/etc/rc.d/rc.M pour multi utilisateur init qui contient en gros une
succession de
if [ -x /etc/rc.d/rc.prog ]; then
. /etc/rc.d/rc.prog
fi
et ca finit par /etc/rc.d/rc.local
c'est tout. La lecture des scripts est suffisante. Simple et efficace.
L'info est la sous les yeux. Je suis capable de decomposer le boot point
par point. Sur une debian j'ai deja beaucoup plus de mal. Ca va s'arreter
a la lecture du runlevel et des Sxx associes. Les scripts vont utiliser
un ensemble de debianismes (runparts, start-stop-daemon, etc) et en cas d e
probleme puis de resolution, j'aurais toujours un doute pour savoir si
ma solution est debian-specifique ou si elle fonctionnera de partout.
Quand je lis un script
/etc/init.d/functions
check_adroite_agauche()
#commentaire abscons
start-stop-daemon --oknodo --startas -- -i -o programme
#autre commentaire abscons
j'ai du mal a savoir quoi faire lorsqu'il y a un probleme.
Le relancer a la main? Et dans six mois quand la machine va rebooter
il va repartir? Le relancer avec le script? ne fonctionne pas.
Decomposer le script en actions simples? Avec les tripotees de
lien dans /etc/alternatives, les functions, et les appels
dans tous les sens? Ingerable rapidement. Rebooter? pas sur un
serveur en prod qui rend d'autres services par ailleurs. Lire les man?
Il y a des gens qui attendent leur service. Alors quoi?
L'accessibilite de l'info est tellement compliquee que soit on a
un gourou a portee de main qui dit quoi faire (et je me demanderai ce
que moi je fous la), soit on va perdre des heures a la recherche de
l'info dans la doc. Ensuite, oui il y a l'argument de "tu ne l'apprends
qu'une fois, donc la deuxieme fois, tu sais". Mais nous parlons de
phenomenes non quotidiens, et le pourcentage de chance que tu te
souviennes parfaitement (et qu'entretemps ca n'ai pas change) de

Pour revenir a ce que je disais, apprendre slack cela revient a avoir
quelques connaissances shell et tout le reste vient sans forcer. Apprendr e
debian, cela revient a apprendre debian, comprendre debian et travailler
debian en utilisant des debianismes. On peut dire la meme chose de redhat ,
d'ailleurs. Mais redhat, j'ai arrete depuis longtemps alors que je
reviens de temps a autre a debian. Je devrais en reinstaller une dans
un qemu pour voir et troller avec des connaissances actuelles, d'ailleurs .
C'est bien netinstall, le minimum pour faire l'installation, non?

Ce qui est amusant, c'est de voir à quel point vous, les slackeux,
pouvaient être si désemparés devant d'autres systèmes que Slackware
alors même que vous prétendez pouvoir tout maîtriser par la
compréhension des scripts shells. Pourtant, les sources des autres
distributions Linux sont disponibles. Même cela peut prendre du temps,
tu es libre de les étudier en détail, ne serait-ce que pour comprendre
la VA ajoutée que cela apporte (ou pas). Alors qu'ici, on a déjà eu p as
mal d'exemples d'utilisateurs de Debian qui arrivent à utiliser autre
chose que Debian, comme des RedHat ou même des Unix propriétaires
(Solaris, AIX, HP-UX pour n'en citer que trois)...
Pourquoi est-ce si difficile de lire la documentation plutôt qu'aller
directement lire le code source ? Pourquoi est-ce si difficile de
rédiger un rapport d'anomalies au lieu de se poser la question si ça
vient de Debian ou pas ? Puisque la réponse peut prendre du temps, c'est
précisément la première chose à faire une fois que le problème es t
relativement cerné. Tu passeras à l'éventuel « workaround » ensui te.
D'ailleurs, on l'a déjà souligné mais il existe des supports commerci aux
que des sociétés offrent aux autres sociétés soucieuses de trouver une
solution rapide aux problèmes et anomalies rencontrés avec les Logiciel s
Libres : on n'est plus dans les années 90. Si tu peux te passer de
support commercial, très bien, mais ne nous dis pas que la résolution d e
ton problème ne peut alors attendre un jour ou deux.

Et puisque j'ai un gourou, je vais poser une question. Il est coutume
sur un groupe de discussion que je ne nommerai pas de s'amuser a oter
des glibc. Autant sur slack, il faut trois secondes pour la retirer
et la remettre (en gros boot sur le CD, puis installpkg -root /mnt/hd
glibc*tgz) autant sur debian je n'ai jamais reussi a trouver l'option
de dpkg qui pouvait me remettre la glibc. Ca doit bien exister
simplement, non?

Du genre boot sur n'importe quel CD, puis ar x libc6*deb, puis tar x
-C /mnt/hd data.tar.gz ?

dpkg n'a pas une option pour ca? Lors de la phase d'install, comment

dpkg fait pour mettre les fichiers au bon endroit? Pourquoi est ce
que debian m'envoie toujours chercher au dernier endroit la bonne
solution?

Toutes les informations nécessaires sont contenues dans le paquet lui-m ême.
Le format du paquet n'est qu'une archive ar. La commande n'est finalement
« qu'un » wrapper à ar. Pour les autres informations, la documentatio n ne manque
pas pour construire un paquet debian.

De plus, que faire lorsque le CD refuse de monter la partition?
De memoire les noyaux d'installation sont tout petit et les
modules sont caches je ne sais ou.
Si j'installe une debian, j'essaierai.

Les modules ne sont pas cachés et le menu d'installation sait très bien
charger les modules nécessaires s'ils sont présents. Ça n'a rien à voir
avec l'outil mais plutôt avec son utilisation.
Debian n'est pas Slackware. Debian ne partage pas sa philosophie, sa vision .
Ce sera donc forcément différent ci et là.

--
Raphaël SurcouF

Dixit Nicolas George :

Au fait, quelqu'un saurait comment on fait maintenant pour l'équivalent de
« base-config » qui a disparu ?

Mazette, avec toutes les questions de ce genre qui pleuvent depuis

quelques messages, on va pouvoir commencer à motiver un renommage de
fcol.debats en fcol.debian.

--{ Samuel Colin a plopé ceci: }--

Au fait, quelqu'un saurait comment on fait maintenant pour l'équivalent de
« base-config » qui a disparu ?

Mazette, avec toutes les questions de ce genre qui pleuvent depuis

quelques messages, on va pouvoir commencer à motiver un renommage de
fcol.debats en fcol.debian.

Impossible.
Fufe est en congés annuels.

--
<JX> je vais boire une adelscott
<CleeK> jx : pareil pour moi
<JX> et comme il ne faut JAMAIS boire le ventre vide
<JX> je vais manger une Guinness avec

Le 23-07-2007, Sam Hocevar <sam+news@zoy.org> a écrit :

Tant pis, on ne supporte pas Slack (et personne ne s'en plaint).

Qui est le 'on' ? Et de quel support parles tu?

De toute façon devant les outils Slackware je ne peux que m'énerver,
c'est dommage. Par exemple je n'ai jamais réussi à lancer une commande
sous l'id d'un utilisateur qui n'a pas de shell. Par exemple sur ma
Debian je fais "su -s /bin/sh ftp -c id" ; sous Slackware cette syntaxe
n'a jamais fonctionné. Ça a peut-être changé depuis, je ne sais pas.

kevin@zipslack:~$ man su | grep -- "-s"

kevin@zipslack:~$
Ceci dit:
/usr/doc/shadow-4.0.3/WISHLIST:- su -l, -m, -p, -s options (as in GNU su)
- done in the Debian patches

donc a ce que je comprends, ce sont des options qui existent dans les
patchs debian, et qui sont en WISHLIST...
(le man cite aussi que su depend beaucoup des options de compilation,
il faudrait aller voir le slackbuild pour verifier)

j'ai utilise pas mal de debian, et le coup du /var/lib/dpkg/info/*list
c'est la premiere fois que j'en entends parler.

Pourtant, sur Google, 80 000 occurrences de var/lib/dpkg/info contre
18 000 occurrences de var/log/packages.

Quand on connait, oui. Mais j'ignorais meme que les paquets

avaient la liste des fichiers le composant dans un fichier plat.

Pas vraiment. Mon point ce n'est pas de dire que l'une est mieux que
l'autre ou que machin lave plus blanc, mon point consiste a parler de
l'accessibilite de l'info.

L'accessibilité de l'info, tu l'as aussi dans man dpkg, qui non
seulement te dit que /var/lib/dpkg contient les fichiers donnant des
informations sur les paquets installés, mais te donne aussi la syntaxe
dpkg -L / dpkg --listfiles.

Celui qui sait, oui. Celui qui ne sait pas a du mal a trouver l'info.

Dois je reciter:
<slrnf849c5.43a.kevin@zipslack.local.tux>

toi qui connais sur le bout des doigts l'architecture des miroirs
debian, tu sais ou trouver tout cela. Mais suis bien mes meandres
pour trouver une disquette d'install et repose toi la question de
l'accessibilite de l'info. Je ne dis pas que l'info est absente, je
dis que l'info est compliquee a trouver.

On reprend dpkg? Lors d'un dpkg -l le nom des paquets est tronque pour
que les infos tiennent sur 80 colonnes. Pour des paquets
comme openoffice, le nom est un peu long et on ne voit pas la
bonne info. On agrandit le xterm, on retape dpkg -l. C'est toujours
limite a 80 colonnes. On tape confiant
dpkg --help ou dpkg -<tab> et ... rien. La solution passe par
une variable d'environnement COLUMNS. Une variable d'environnement!
Pas une option, pas automatiquement, hein. Mais honnetement, ca te
parait simple? Serieusement? Pourquoi ca ne choque aucun dev
debian de devoir utiliser cette methode? Pourquoi ne pas utiliser
celle ci:
dpkg regarde la taille du terminal et adaptes les colonnes selon.

Pour le nouveau, ca marche, il agrandit son xterm et il a son info.
Pour le power-user, on lui colle la variable COLUMNS s'il veut
afficher la sortie de dpkg en une largeur donnnee.
Et debian, c'est systematiquement cela. Il y a toujours une solution,
mais quel chemin pour y arriver.
Si je reprends slack, les paquets sont listables par un ls. Si je veux
trouver le plus vieux paquet installe, je lis le man ls. Et plus
tard, dans ma vie d'admin, ca me servira. La variable d'environnement
COLUMNS, c'est d'un interet plus limite.

c'est tout. La lecture des scripts est suffisante. Simple et efficace.

Simple, oui. Efficace, non. Il faudrait peut-être que Slackware
comprenne qu'on est au 21e siècle. De nos jours, tous les noyaux (que ce
soit Linux, mais aussi Solaris ou Darwin) sont passés ou sont en train de
passer à un système event-driven et asynchrone, réduisant les temps de
boot de manière drastique et supprimant les hacks pourris du genre « oh
ben je vais d'abord charger. Voir par exemple Initng, mais aussi Upstart,
et surtout SMF sur Solaris. La méthode rc.S/rc.M est complètement
dépassée et inefficace.

depassee, je ne sais pas. Disons qu'il y a des challengers. J'avais

entendu parler d'initng il y a quelques temps. Je vais retourner
voir initng et upstart.

L'info est la sous les yeux. Je suis capable de decomposer le boot point
par point. Sur une debian j'ai deja beaucoup plus de mal. Ca va s'arreter
a la lecture du runlevel et des Sxx associes. Les scripts vont utiliser
un ensemble de debianismes (runparts, start-stop-daemon, etc) et en cas de
probleme puis de resolution, j'aurais toujours un doute pour savoir si
ma solution est debian-specifique ou si elle fonctionnera de partout.

Je ne comprends pas ce que ça peut te faire que ce soit Debian-
specifique ou si elle fonctionnera partout.

Au hasard, savoir que su -s /bin/sh est un debianisme qui ne fonctionne pas
au moins sur un systeme? (Bon, c'etait facile et tire par les cheveux.)

J'ai appris linux sur slack, j'ai bosse ensuite sur suze, redhat, debian
solaris et HPUX. Ce que j'ai appris sur debian m'a servi pour debian (et
fink sur mac OS X, mais c'est secondaire). Ce que j'ai appris sur
slack m'a servi partout, puisque j'ai appris a me servir de grep, tar,
awk, find, cut, etc, a lire des scripts shells, a chercher l'info etc..

Si tu corriges un truc sur
Slack, ça ne marchera pas sur Debian ni sur aucune autre distribution
utilisant un init SystemV, ni sur OS X, ni sur Solaris, ce qui restreint
quand même l'utilité de la chose.

si apache a du mal a demarrer et que le script d'init m'a conduit a

apprendre apachectl, j'arriverai a redemarrer apache sur une debian.
Je ne sais pas s'il redemarrera apres un reboot, mais il aura
redemarre.
Si sur redhat j'ai appris a relancer un service en tapant:
service apache restart
je serais bien deconfit devant une debian avec apache a redemarrer.

Par ailleurs, de nos jours les distributions Linux convergent vers un
standard (que d'aucuns ici trouvent inutile, je sais) qui s'appelle LSB
et qui assure que les scripts d'init de chaque paquet fonctionneront
partout de la même façon.

le standard? systemV, BSD, initng ou upstart? C'est du logiciel

libre apres tout, je veux avoir le choix.

Ton argumentation devient un peu « Slackware contre le reste du
monde », et je ne dis pas que Slackware a tort, mais je constate
qu'aucune autre distribution n'est d'accord...

C'est bien pour ca qu'il existe pleins de distribs. Ensuite, il y

a du bon partout, des bonnes idees et des moins bonnes.

Je ne comprends pas pourquoi il est acceptable pour toi de lire le
man de removepkg mais pas celui de start-stop-daemon. Deux poids, deux
mesures encore.

Parcequ'une fois que j'ai lu le man de start-stop-daemon, il me restera

celui de update-rc.d, puis runparts, puis suivre les liens de
/etc/alternatives, puis lire les defaults, le README.debian dans
/usr/doc, etc etc.. Et apres avoir lu tout ca, je pourrais enfin commencer
a reflechir sur le programme qui pose probleme. Ca fait beaucoup.

A l'opppose, seulement avec ce que je t'ai dit plus haut, tu devrais
etre capable de te debrouiller sur slack.
Sur debian, pour moi, le chemin est encore long. Pour un interet
limite. A moins que je choisisse de n'utiliser plus que debian
partout et tout le temps. C'est un choix discutable.

C'est bien netinstall, le minimum pour faire l'installation, non?

Oui.

Je vais aller voir.

Du genre boot sur n'importe quel CD, puis ar x libc6*deb, puis tar x
-C /mnt/hd data.tar.gz ?

dpkg n'a pas une option pour ca?

Non. Mais je te signale que c'est toi qui as commencé la discussion
avec « Sur slack, on garde les outils unix de base. grep, cat, find, et
ca roule. » Je te donne une solution qui marche tout le temps.

Pour les paquets, je pensais utiliser la gestion des paquets. Si je

reinstalle une librairie de cette maniere, comment va se comporter
le gestionnaire de paquet? Va t'il fonctionner ensuite?

--
Kevin

Le 23-07-2007, Raphaël 'SurcouF' Bordet <surcouf@debianfr> a écrit :

Parce qu'on n'en a pas besoin : dpkg est là pour remplir ce rôle.

Bon, j'ai appris que dpkg -L me liste le contenu d'un paquet. Mais
maintenant, comment connaitre le nom du paquet lorsqu'on a un
fichier? Au hasard, dpid, c'est dans quel paquet?
kevin@zipslack:~$ grep dpid /var/log/packages/*
/var/log/packages/dillo-0.8.5-i386-1:usr/local/bin/dpid
Ca fonctionnera sans doute pareil vec /var/lib/dpkg/info/*list,
et ca, c'est efficace.

Ce qui est amusant, c'est de voir à quel point vous, les slackeux,

Maman, regarde! Je suis un slackeux!

que debian m'envoie toujours chercher au dernier endroit la bonne
solution?

Toutes les informations nécessaires sont contenues dans le paquet lui-même.
Le format du paquet n'est qu'une archive ar. La commande n'est finalement
« qu'un » wrapper à ar.

non. j'ose esperer que dpkg fait plus qu'etre un wrapper a ar. dpkg
verifie les dependances, signale au gestionnaire de paquet que le
paquet est installe et doit faire quelques trucs supplementaires.

Debian n'est pas Slackware.

Oui

Debian ne partage pas sa philosophie, sa vision.

Ah.

Ce sera donc forcément différent ci et là.

Oui.

--
Kevin

JKB wrote:

Ce n'est pas une question de puissance.

Ca doit etre du snobisme alors.

Disons que la courtoisie (et mon ulcère) m'empêche(nt) de dire tout
haut ce que je pense de toi.

Ta courtoisie doit etre souple vu les mots que tu as deja employe. Pour
ton ulcere, je te donne un truc, arrete de penser que tout le monde est
con, tu verras, tu te sentiras bien mieux.

Patrice Karatchentzeff wrote:

Cela s'appelle l'égo : les gens sont persuadés de faire mieux donc on
ne réutilise pas ce qui a été fait. Un très gros classique en
informatique.

D'un autre cote, quand j'upgrade un noyau, je reboote pas sur la
mauvaise version par defaut.

Et puis, cela permet de vendre aussi : « vous voyez, chef, le boulot
que j'ai fait ? ».

T'es gentil, tout le monde installe pas des serveurs web non plus.

Sam Hocevar wrote:

Pardon mais en quoi /var/log/packages/ serait-il moins imbitable que
/var/lib/dpkg/info ? Franchement, on ne peut deviner ni l'un ni l'autre,

Il y a pas de difference fondamentale.

Il y a pas de raison que la Slack fasse un truc intelligent qui ne soit
pas repris par Debian.

Sam Hocevar wrote:

Oui, mais pas beaucoup. Il est impossible de déployer et mettre à
jour facilement une Slack dans une VM ou un chroot, et je n'ai pas trop
de temps à perdre à bidouiller des scripts qui ne seront pas pérennes.
Tant pis, on ne supporte pas Slack (et personne ne s'en plaint).

C'est incroyable ca, un mec explique en un post les methodes de la
Slack, et la seule chose que l'autre Debian God trouve a repondre c'est
"on ne support pas Slack".

Mais qu'est ce qu'on en a a foutre de ce que tu supportes et de ce que
tu ne supportes pas ?

De toute façon devant les outils Slackware je ne peux que m'énerver,

Ben voila, moi c'est la meme chose avec la Debian. J'ai l'impression que
c'est toujours pense de travers.

Pourtant, sur Google, 80 000 occurrences de var/lib/dpkg/info contre
18 000 occurrences de var/log/packages.

Mais oui, on sait, elle est belle ta Debian, c'est la plus grande et ton
nom sera inscrit sur la stelle des grands du Libre a la rubrique Debian.

L'accessibilité de l'info, tu l'as aussi dans man dpkg, qui non
seulement te dit que /var/lib/dpkg contient les fichiers donnant des
informations sur les paquets installés, mais te donne aussi la syntaxe
dpkg -L / dpkg --listfiles.

Sous Slack, c'est pkgtool.

Simple, oui. Efficace, non. Il faudrait peut-être que Slackware
comprenne qu'on est au 21e siècle. De nos jours, tous les noyaux (que ce
soit Linux, mais aussi Solaris ou Darwin) sont passés ou sont en train de
passer à un système event-driven et asynchrone, réduisant les temps de
boot de manière drastique et supprimant les hacks pourris du genre « oh
ben je vais d'abord charger. Voir par exemple Initng, mais aussi Upstart,
et surtout SMF sur Solaris. La méthode rc.S/rc.M est complètement
dépassée et inefficace.

Oh, tu veux dire qu'apres tout ce bordel, une machine boote plus vite.

Excuse moi, j'ai toujours pas compris l'interet de booter en 20 secondes
plutot qu'en 30 ou en 40 secondes.