rigolons avec : Frugalware et autres slackouarités...
39 réponses
minutte
ce pourrait =EAtre avec une autre des multitudes de distros d=E9riv=E9es de
Slackware, mais j'ai pris Frugalware apr=E8s avoir lu l'un des fils plus
bas sur ce forum, lui faisant sa chtite r=E9clame.
Slackware c'est tr=E8s bien, c'est avec elle que j'ai connu GNULinux, =E0
l'=E9poque du noyau 2.0, alors que j'utilisais FreeBSD...
Slackware a servi de base plus tard =E0 des choses pas mal telles Slax,
RIpLinux ou Tukaani.
Or il y a foultitude de d=E9riv=E9s proclamant tel ou tel avantage, plus
de con!-vivialit=E9, ou de rapidit=E9 (les fameux "optimis=E9" pour i686,
qui en descente, et vent dans le dos, p=E9dalent plus vite) ou
paquetages ou localisations, etc.
L'une des choses rigolottes de ces distros sont les
"screenshots" :-) : un xfce ou un kde ou un etc avec un fond d'=E9cran
qui tue. Sachant que X11 roule sous tous les unix connus et inconnus,
on voit mal ce que ces captures apportent comme information.Passons.
Mis =E0 part Tukaani, que je recommande vivement, toutes ces distros aux
noms plus d=E9fonc=E9s les uns que les autres, comportent des rat=E9s
parfois chiantes parfois amusantes.
Par exple les Vector et Zenwalk sont visiblement assembl=E9es par des
loulous qui ont encore le visage couvert d'acn=E9 et qui ne savent pas
ce qu'est le skuzzy (le bon vrai skuzzy avec les broches 50, 60, 80 et
les Centronics). En effet, leurs installateurs proposent de d=E9tecter
des composants du dernier cri, mais pas mes bonnes vieilles cartes
Adaptec.
Frugalware d=E9tecte mes choses skuzzy, mais l'installateur est
r=E9jouissant:
--> Please select your language:
offre la liste: english, espagnole (ol=E9 ol=E9! espagnolade ou
espa=F1ol ?), deutsch, francais (sans c=E9dille), indonesian (ont
visiblement pas os=E9 l'=E9crire en indon=E9sien), italiano, magyar,
nederlands, polski, portugu=EAs, slovensky (slovensk=FD), chinese (ont pas
os=E9 l=E0 non plus l'=E9crire en chinetoque...)
Le choix des langues laisse r=EAveur. La distro fut cr=E9e semble-t'il par
un magyar (ou hongrois , comme le prince du Danube qui veut devenir
roi de France au printemps 2007) et c'est bien de mettre le polonais
ou le slovaque. Mais pourquoi pas le tch=E8que alors, ou le roumain ou
le serbe ou l'ukrainien?
Parmi des langues majeures manquent le russe, l'hindi et le japonais.
Moi qui suit en Norv=E8ge j'=E9tais mal: lorsque le norv=E9gien manque dans
ce genre de menus on peut en g=E9n=E9ral se rabattre sur le danois ou le
su=E9dois. Pas avec Frugalware qui ignore les scandinaves mais offre
l'indon=E9sien...
Par curiosit=E9 je choisis "chinese" et confirme mais =E0 l'=E9cran suivant
rien: texte toujours en angliche, sans qu'on nous dise =E0 quoi se
r=E9f=E9rait alors le choix des langues propos=E9 en entr=E9e...
Bon, un =E9cran plus loin, chois des claviers, dans une longue liste o=F9
je perds une 1/2 heure =E0 trouver le no-latin1, car de classement
alphab=E9tique il n'y a point, mais une r=E9partition bord=E9lique par sous-
type de claviers (qwerty, qwertz, etc).Plus loin encore, lors du
partitionnement des disques, on est oblig=E9 de choisir une partition
swap sinon pas moyen de continuer.
Bref, reboot et effacement du CD. C'est tout de m=EAme une invention
pratique les CD r=E9-inscriptibles...
D'un autre c=F4t=E9, il est ind=E9niable que Slackware est plus vivante que
jamais, malgr=E9 les faibles d'esprit qui clament le contraire.
D'un autre côté, il est indéniable que Slackware est plus vivante que jamais, malgré les faibles d'esprit qui clament le contraire.
Sans compter qu'à l'usage, je n'ai pas remarqué que les binaires slack compilés en 486 étaient spécialement plus lents que ceux compilés en 686. En fait il est connu que seuls les programmes très intensifs en processeurs valent la peine d'être recompilés : gcc lui même, puis les trucs genre ffmpeg, moteurs troidé, etc.
qu'il n'y a pas de différence entre un programme compilé pour un vieux processeur 386 et un programme pour processeur recent,je n'y croit pas
La question n'est pas au niveau de la compilation, mais au niveau du code source: tant que celui-ci n'est pas adapté pour tirer parti des optimisations permises par le processeur-cible, le gain est négligeable. Par exemple, sur un G5 à 1,8Ghz avec John the Ripper qui, justement, permet de charger des portions de code "adaptées" au processeur-cible:
En compilant avec l'option macosx-ppc32 (32 bits, sans module Altivec) Benchmarking: Traditional DES [32/32 BS]... DONE Many salts: 261331 c/s real, 271654 c/s virtual Only one salt: 258220 c/s real, 266207 c/s virtual
En compilant avec l'option macosx-ppc64 (64bits, sans module Altivec) Benchmarking: Traditional DES [64/64 BS]... DONE Many salts: 627953 c/s real, 656794 c/s virtual Only one salt: 589107 c/s real, 606077 c/s virtual
En compilant avec l'option macosx-ppc32-Altivec (32 bits, avec module Altivec) Benchmarking: Traditional DES [128/128 BS AltiVec]... DONE Many salts: 961049 c/s real, 990772 c/s virtual Only one salt: 838208 c/s real, 882231 c/s virtual
350% de gain, sans changer de matos... ;-)
Sur plate-forme i386, j'ai déjà vu des gains semblables suivant que MMX ou les différentes versions de SSE soient ou non activées.
Mais pour une utilisation "desktop", les facteurs ralentissants sont les accès disque, ou encore l'interaction avec l'utilisateur, et donc l'optimisation du code pour l'accélérer n'a pas vraiment d'intérêt.
D'un autre côté, il est indéniable que Slackware est plus vivante que
jamais, malgré les faibles d'esprit qui clament le contraire.
Sans compter qu'à l'usage, je n'ai pas remarqué que les binaires slack
compilés en 486 étaient spécialement plus lents que ceux compilés en
686. En fait il est connu que seuls les programmes très intensifs en
processeurs valent la peine d'être recompilés : gcc lui même, puis les
trucs genre ffmpeg, moteurs troidé, etc.
qu'il n'y a pas de différence entre un programme compilé pour un vieux
processeur 386 et un programme pour processeur recent,je n'y croit pas
La question n'est pas au niveau de la compilation, mais au niveau du
code source: tant que celui-ci n'est pas adapté pour tirer parti des
optimisations permises par le processeur-cible, le gain est négligeable.
Par exemple, sur un G5 à 1,8Ghz avec John the Ripper qui, justement,
permet de charger des portions de code "adaptées" au processeur-cible:
En compilant avec l'option macosx-ppc32 (32 bits, sans module Altivec)
Benchmarking: Traditional DES [32/32 BS]... DONE
Many salts: 261331 c/s real, 271654 c/s virtual
Only one salt: 258220 c/s real, 266207 c/s virtual
En compilant avec l'option macosx-ppc64 (64bits, sans module Altivec)
Benchmarking: Traditional DES [64/64 BS]... DONE
Many salts: 627953 c/s real, 656794 c/s virtual
Only one salt: 589107 c/s real, 606077 c/s virtual
En compilant avec l'option macosx-ppc32-Altivec (32 bits, avec module
Altivec)
Benchmarking: Traditional DES [128/128 BS AltiVec]... DONE
Many salts: 961049 c/s real, 990772 c/s virtual
Only one salt: 838208 c/s real, 882231 c/s virtual
350% de gain, sans changer de matos... ;-)
Sur plate-forme i386, j'ai déjà vu des gains semblables suivant que MMX
ou les différentes versions de SSE soient ou non activées.
Mais pour une utilisation "desktop", les facteurs ralentissants sont les
accès disque, ou encore l'interaction avec l'utilisateur, et donc
l'optimisation du code pour l'accélérer n'a pas vraiment d'intérêt.
D'un autre côté, il est indéniable que Slackware est plus vivante que jamais, malgré les faibles d'esprit qui clament le contraire.
Sans compter qu'à l'usage, je n'ai pas remarqué que les binaires slack compilés en 486 étaient spécialement plus lents que ceux compilés en 686. En fait il est connu que seuls les programmes très intensifs en processeurs valent la peine d'être recompilés : gcc lui même, puis les trucs genre ffmpeg, moteurs troidé, etc.
qu'il n'y a pas de différence entre un programme compilé pour un vieux processeur 386 et un programme pour processeur recent,je n'y croit pas
La question n'est pas au niveau de la compilation, mais au niveau du code source: tant que celui-ci n'est pas adapté pour tirer parti des optimisations permises par le processeur-cible, le gain est négligeable. Par exemple, sur un G5 à 1,8Ghz avec John the Ripper qui, justement, permet de charger des portions de code "adaptées" au processeur-cible:
En compilant avec l'option macosx-ppc32 (32 bits, sans module Altivec) Benchmarking: Traditional DES [32/32 BS]... DONE Many salts: 261331 c/s real, 271654 c/s virtual Only one salt: 258220 c/s real, 266207 c/s virtual
En compilant avec l'option macosx-ppc64 (64bits, sans module Altivec) Benchmarking: Traditional DES [64/64 BS]... DONE Many salts: 627953 c/s real, 656794 c/s virtual Only one salt: 589107 c/s real, 606077 c/s virtual
En compilant avec l'option macosx-ppc32-Altivec (32 bits, avec module Altivec) Benchmarking: Traditional DES [128/128 BS AltiVec]... DONE Many salts: 961049 c/s real, 990772 c/s virtual Only one salt: 838208 c/s real, 882231 c/s virtual
350% de gain, sans changer de matos... ;-)
Sur plate-forme i386, j'ai déjà vu des gains semblables suivant que MMX ou les différentes versions de SSE soient ou non activées.
Mais pour une utilisation "desktop", les facteurs ralentissants sont les accès disque, ou encore l'interaction avec l'utilisateur, et donc l'optimisation du code pour l'accélérer n'a pas vraiment d'intérêt.
Doug713705
Le lundi 5 mars 2007 12:02, Mihamina Rakotomandimby (R12y) s'est exprimé de la sorte sur fr.comp.os.linux.debats :
En ce moment, est-ce que la détection de matériel est bonne? En ce qui me concerne parfaite.
(Machine très récente : Core Duo et tout le toutim)
Le noyau de base a pas mal de drivers en modules qui sont chargés automatiquement au boot.
Après, restent les périphériques un peu moins diffusés auquel cas une recompilation du noyau règle l'affaire en quelques minutes.
Une fois fait, c'est un modèle de stabilité.
En 5 ans, je n'ai jamais vu un plantage pour une autre raison qu'un périphérique défectueux où mal installé (genre CG ATI / driver proprio qui pue)
Mais bon... la Slack, c'est en lui tripatouillant les tripes que je la préfère ;-) -- @+ Doug [Linux user #307925] - Slackware RuleZ ;-) [Pourquoi t'es qui, qu'est ce que tu fais par où ?] -- Pour me contacter enlever no-spam (2X) --
Le lundi 5 mars 2007 12:02, Mihamina Rakotomandimby (R12y) s'est exprimé de
la sorte sur fr.comp.os.linux.debats :
En ce moment, est-ce que la détection de matériel est bonne?
En ce qui me concerne parfaite.
(Machine très récente : Core Duo et tout le toutim)
Le noyau de base a pas mal de drivers en modules qui sont chargés
automatiquement au boot.
Après, restent les périphériques un peu moins diffusés auquel cas une
recompilation du noyau règle l'affaire en quelques minutes.
Une fois fait, c'est un modèle de stabilité.
En 5 ans, je n'ai jamais vu un plantage pour une autre raison qu'un
périphérique défectueux où mal installé (genre CG ATI / driver proprio qui
pue)
Mais bon... la Slack, c'est en lui tripatouillant les tripes que je la
préfère ;-)
--
@+
Doug [Linux user #307925] - Slackware RuleZ ;-)
[Pourquoi t'es qui, qu'est ce que tu fais par où ?]
-- Pour me contacter enlever no-spam (2X) --
Le lundi 5 mars 2007 12:02, Mihamina Rakotomandimby (R12y) s'est exprimé de la sorte sur fr.comp.os.linux.debats :
En ce moment, est-ce que la détection de matériel est bonne? En ce qui me concerne parfaite.
(Machine très récente : Core Duo et tout le toutim)
Le noyau de base a pas mal de drivers en modules qui sont chargés automatiquement au boot.
Après, restent les périphériques un peu moins diffusés auquel cas une recompilation du noyau règle l'affaire en quelques minutes.
Une fois fait, c'est un modèle de stabilité.
En 5 ans, je n'ai jamais vu un plantage pour une autre raison qu'un périphérique défectueux où mal installé (genre CG ATI / driver proprio qui pue)
Mais bon... la Slack, c'est en lui tripatouillant les tripes que je la préfère ;-) -- @+ Doug [Linux user #307925] - Slackware RuleZ ;-) [Pourquoi t'es qui, qu'est ce que tu fais par où ?] -- Pour me contacter enlever no-spam (2X) --
Patrice Karatchentzeff
Michel Campfort a écrit :
[...]
Tout à fait . Je m'y suis mis à la 3.1 , c'etait le 2.0.?? et les modules sont arrivés plus tard . Il était conseillé de se compiler
Les modules, c'est le 2.0.0
un noyau pour alléger la bête ! Y'avait pas cups , non plus . . .
Le Mon, 05 Mar 2007 20:38:23 +0100, linuxkiller a écrit :
Slack 2.0 ou 3.0, je ne me souviens plus (Juin 1996)
Oui, moi aussi c'était dans cette période là.
-- Ce qu'il y a d'enivrant dans le mauvais goût c'est le plaisir aristocratique de déplaire. C. Baudelaire.
Emmanuel Florac
Le Mon, 05 Mar 2007 23:37:55 +0100, Doug713705 a écrit :
En 5 ans, je n'ai jamais vu un plantage pour une autre raison qu'un périphérique défectueux où mal installé (genre CG ATI / driver proprio qui pue)
Moi j'ai eu des plantages lliés au chipset VIA KT600, un beau tas de merde... Le matos est tellement vérolé qu'il ne boote pas s'il y a un périphérique USB branché!
-- L'église est une secte qui a réussi. Ernest Renan.
Le Mon, 05 Mar 2007 23:37:55 +0100, Doug713705 a écrit :
En 5 ans, je n'ai jamais vu un plantage pour une autre raison qu'un
périphérique défectueux où mal installé (genre CG ATI / driver proprio qui
pue)
Moi j'ai eu des plantages lliés au chipset VIA KT600, un beau tas de
merde... Le matos est tellement vérolé qu'il ne boote pas s'il y a un
périphérique USB branché!
--
L'église est une secte qui a réussi.
Ernest Renan.
Le Mon, 05 Mar 2007 23:37:55 +0100, Doug713705 a écrit :
En 5 ans, je n'ai jamais vu un plantage pour une autre raison qu'un périphérique défectueux où mal installé (genre CG ATI / driver proprio qui pue)
Moi j'ai eu des plantages lliés au chipset VIA KT600, un beau tas de merde... Le matos est tellement vérolé qu'il ne boote pas s'il y a un périphérique USB branché!
-- L'église est une secte qui a réussi. Ernest Renan.
Miod Vallat
Ya des gens qui utilisent des 386?
Oui, sur des embarqués, patate
T'es sûr ? la dernière fois que j'ai mis du x86 dans de l'embarqué, c'était un PII à 250 MHz... et cela date d'au moins 5 ans.
Oui mais là c'est une patate embarquée, il faut donc un processeur plus compact pour qu'il tienne à l'intérieur.
Ya des gens qui utilisent des 386?
Oui, sur des embarqués, patate
T'es sûr ? la dernière fois que j'ai mis du x86 dans de l'embarqué,
c'était un PII à 250 MHz... et cela date d'au moins 5 ans.
Oui mais là c'est une patate embarquée, il faut donc un processeur plus
compact pour qu'il tienne à l'intérieur.
