Plus je m'=E9loigne de Debian plus je vois ses "probl=E8mes".
Je r=E9sume.
1) Debian est une tr=E8s bonne distrib pour les serveurs, d'accord.
A mon avis, leur fa=E7on de geler les paquets requiert =E9norm=E9ment de
ressources, et cette fa=E7on de faire devrait =EAtre r=E9serv=E9e aux
entreprises. (Puisque une entreprise comme RH, on l'a paie en partie
pour les backports des probl=E8mes de s=E9curit=E9. Si RH utilisait les
derni=E8res versions upstream elle serait moins ch=E8re).
Bon, ils veulent le faire quand m=EAme, fort bien, mais pourquoi le
faire sur 25000 paquets ? Est-ce vraiment raisonnable ? C'est des
questions que j'aimerais qu'ils se posent.
2) Debian semble essayer de viser =E9galement les utilisateurs desktop.
Sauf que ni -testing, ni -unstable ne sont faits officiellement pour.
Là, tu m'intéresses. Vu que certains disques apparaissent tantôt en /dev/hd, tantôt en /dev/sd selon la conf du noyau (et l'ordre de montage des devices qui peut être aléatoire), ça risque d'être difficile.
De toute façon, il y a d'autres problèmes du même tonneau avec une incompatibilité de la libc et des noyaux. Ça peut devenir très sportif et un truc automatique ne pourra jamais remplacer deux neurones.
Y'a pas à dire: linux est prêt pour le desktop. Il n'y a plus qu'à montrer à madame Michu comment touiquer son /dev, comme ça elle pourra monter simplement (c'est-à-dire coder un script en bash) sa clé usb.
-- Joe Cool
JKB a écrit :
Là, tu m'intéresses. Vu que certains disques apparaissent tantôt en
/dev/hd, tantôt en /dev/sd selon la conf du noyau (et l'ordre de
montage des devices qui peut être aléatoire), ça risque d'être
difficile.
De toute façon, il y a d'autres problèmes du même tonneau avec une
incompatibilité de la libc et des noyaux. Ça peut devenir très
sportif et un truc automatique ne pourra jamais remplacer deux
neurones.
Y'a pas à dire: linux est prêt pour le desktop. Il n'y a plus qu'à
montrer à madame Michu comment touiquer son /dev, comme ça elle pourra
monter simplement (c'est-à-dire coder un script en bash) sa clé usb.
Là, tu m'intéresses. Vu que certains disques apparaissent tantôt en /dev/hd, tantôt en /dev/sd selon la conf du noyau (et l'ordre de montage des devices qui peut être aléatoire), ça risque d'être difficile.
De toute façon, il y a d'autres problèmes du même tonneau avec une incompatibilité de la libc et des noyaux. Ça peut devenir très sportif et un truc automatique ne pourra jamais remplacer deux neurones.
Y'a pas à dire: linux est prêt pour le desktop. Il n'y a plus qu'à montrer à madame Michu comment touiquer son /dev, comme ça elle pourra monter simplement (c'est-à-dire coder un script en bash) sa clé usb.
-- Joe Cool
JKB
Le 23-10-2008, ? propos de Re: Debian, Patrick Lamaizière ?crivait dans fr.comp.os.linux.debats :
JKB:
Récemment, sur ma debian etch (stable) actuelle et qui marche très bien en 2.6.18-6-686, le paquet "linux-image-2.6.24-etchnhalf.1-686" a été installé --> reboot incapable de monter la racine. Je soupçonne fortement que c'est à cause de fstab qui référence les partitions par /dev/hdXY alors que etchnhalf doit attendre des champs UUID.
Je conçois que ce genre de blague puisse irriter l'admin confronté à des users chafoins...
Non. Ça, c'est la merde intrinsèque du noyau et de Linus qui a décidé un jour que les /dev/hd (IDE) devaient devenir des /dev/sd (parce que SCSI, c'est bien [et je suis d'accord], et qu'on va émuler les SATA en SCSI). Debian n'y est pour strictement rien.
C'est fort ça, Linux transforme un disque pourri en IDE en un disque SCSI ?
En interne, oui... Avec un truc du genre ide-scsi remis à jour.
JKB
-- Le cerveau, c'est un véritable scandale écologique. Il représente 2% de notre masse corporelle, mais disperse à lui seul 25% de l'énergie que nous consommons tous les jours.
Le 23-10-2008, ? propos de
Re: Debian,
Patrick Lamaizière ?crivait dans fr.comp.os.linux.debats :
JKB:
Récemment, sur ma debian etch (stable) actuelle et qui marche très bien
en 2.6.18-6-686, le paquet "linux-image-2.6.24-etchnhalf.1-686" a été
installé --> reboot incapable de monter la racine. Je soupçonne
fortement que c'est à cause de fstab qui référence les partitions par
/dev/hdXY alors que etchnhalf doit attendre des champs UUID.
Je conçois que ce genre de blague puisse irriter l'admin confronté à des
users chafoins...
Non. Ça, c'est la merde intrinsèque du noyau et de Linus qui a
décidé un jour que les /dev/hd (IDE) devaient devenir des /dev/sd
(parce que SCSI, c'est bien [et je suis d'accord], et qu'on va
émuler les SATA en SCSI). Debian n'y est pour strictement rien.
C'est fort ça, Linux transforme un disque pourri en IDE en un disque
SCSI ?
En interne, oui... Avec un truc du genre ide-scsi remis à jour.
JKB
--
Le cerveau, c'est un véritable scandale écologique. Il représente 2% de notre
masse corporelle, mais disperse à lui seul 25% de l'énergie que nous
consommons tous les jours.
Le 23-10-2008, ? propos de Re: Debian, Patrick Lamaizière ?crivait dans fr.comp.os.linux.debats :
JKB:
Récemment, sur ma debian etch (stable) actuelle et qui marche très bien en 2.6.18-6-686, le paquet "linux-image-2.6.24-etchnhalf.1-686" a été installé --> reboot incapable de monter la racine. Je soupçonne fortement que c'est à cause de fstab qui référence les partitions par /dev/hdXY alors que etchnhalf doit attendre des champs UUID.
Je conçois que ce genre de blague puisse irriter l'admin confronté à des users chafoins...
Non. Ça, c'est la merde intrinsèque du noyau et de Linus qui a décidé un jour que les /dev/hd (IDE) devaient devenir des /dev/sd (parce que SCSI, c'est bien [et je suis d'accord], et qu'on va émuler les SATA en SCSI). Debian n'y est pour strictement rien.
C'est fort ça, Linux transforme un disque pourri en IDE en un disque SCSI ?
En interne, oui... Avec un truc du genre ide-scsi remis à jour.
JKB
-- Le cerveau, c'est un véritable scandale écologique. Il représente 2% de notre masse corporelle, mais disperse à lui seul 25% de l'énergie que nous consommons tous les jours.
Eric Masson
Patrick Lamaizière writes:
'Lut,
C'est fort ça, Linux transforme un disque pourri en IDE en un disque SCSI ?
Ben de la même manière qu'OpenBSD pour les disques sata attachés via un contrôleur ahci.
J'ai aussi vu passer un post sur une des listes FreeBSD qui envisage d'interfacer les contrôleurs ahci avec CAM.
Ça ne semble pas complètement idiot, vu que les périphériques sata sont assez proches des scsi au niveau du jeu de commandes reconnu.
-- Infertilité masculine, femme seule ou homosexuelle, et malgré tout un grand désir de se perpétuer... j'ai la semence qu'il vous manque ! Pas sérieux s'abstenir. -+- j.vicious in GNU - Le représentant de mes couilles -+-
Patrick Lamaizière <patnews1@davenulle.org> writes:
'Lut,
C'est fort ça, Linux transforme un disque pourri en IDE en un disque
SCSI ?
Ben de la même manière qu'OpenBSD pour les disques sata attachés via un
contrôleur ahci.
J'ai aussi vu passer un post sur une des listes FreeBSD qui envisage
d'interfacer les contrôleurs ahci avec CAM.
Ça ne semble pas complètement idiot, vu que les périphériques sata sont
assez proches des scsi au niveau du jeu de commandes reconnu.
--
Infertilité masculine, femme seule ou homosexuelle, et malgré tout un
grand désir de se perpétuer... j'ai la semence qu'il vous manque ! Pas
sérieux s'abstenir.
-+- j.vicious in GNU - Le représentant de mes couilles -+-
C'est fort ça, Linux transforme un disque pourri en IDE en un disque SCSI ?
Ben de la même manière qu'OpenBSD pour les disques sata attachés via un contrôleur ahci.
J'ai aussi vu passer un post sur une des listes FreeBSD qui envisage d'interfacer les contrôleurs ahci avec CAM.
Ça ne semble pas complètement idiot, vu que les périphériques sata sont assez proches des scsi au niveau du jeu de commandes reconnu.
-- Infertilité masculine, femme seule ou homosexuelle, et malgré tout un grand désir de se perpétuer... j'ai la semence qu'il vous manque ! Pas sérieux s'abstenir. -+- j.vicious in GNU - Le représentant de mes couilles -+-
Joe Cool
Eric Masson a écrit :
Ben de la même manière qu'OpenBSD pour les disques sata attachés via un contrôleur ahci.
J'ai aussi vu passer un post sur une des listes FreeBSD qui envisage d'interfacer les contrôleurs ahci avec CAM.
Ça ne semble pas complètement idiot, vu que les périphériques sata sont assez proches des scsi au niveau du jeu de commandes reconnu.
On ne devrait jamais laisser la charge de concepteur aux pisseurs de code. Mais voilà, on se retrouve avec une architecture super abstraite, qui nous traduit à la volée du Haskell en cartes perforées puis passe le tout au module noyau interpréteur de troutrous. Ensuite on s'étonne d'avoir du logiciel basé sur des technologies d'il y a 40 ans (et oui, UNIX a 40 ans, c'était déjà dépassé quand linux est né).
Tant qu'on se farcira une communauté de crétins ébaubis devant la moindre linuxerie, aucun SE «libre» ne pourra être prêt pour le desktop.
-- Joe Cool
Eric Masson a écrit :
Ben de la même manière qu'OpenBSD pour les disques sata attachés via un
contrôleur ahci.
J'ai aussi vu passer un post sur une des listes FreeBSD qui envisage
d'interfacer les contrôleurs ahci avec CAM.
Ça ne semble pas complètement idiot, vu que les périphériques sata sont
assez proches des scsi au niveau du jeu de commandes reconnu.
On ne devrait jamais laisser la charge de concepteur aux pisseurs de
code. Mais voilà, on se retrouve avec une architecture super abstraite,
qui nous traduit à la volée du Haskell en cartes perforées puis passe le
tout au module noyau interpréteur de troutrous. Ensuite on s'étonne
d'avoir du logiciel basé sur des technologies d'il y a 40 ans (et oui,
UNIX a 40 ans, c'était déjà dépassé quand linux est né).
Tant qu'on se farcira une communauté de crétins ébaubis devant la
moindre linuxerie, aucun SE «libre» ne pourra être prêt pour le desktop.
Ben de la même manière qu'OpenBSD pour les disques sata attachés via un contrôleur ahci.
J'ai aussi vu passer un post sur une des listes FreeBSD qui envisage d'interfacer les contrôleurs ahci avec CAM.
Ça ne semble pas complètement idiot, vu que les périphériques sata sont assez proches des scsi au niveau du jeu de commandes reconnu.
On ne devrait jamais laisser la charge de concepteur aux pisseurs de code. Mais voilà, on se retrouve avec une architecture super abstraite, qui nous traduit à la volée du Haskell en cartes perforées puis passe le tout au module noyau interpréteur de troutrous. Ensuite on s'étonne d'avoir du logiciel basé sur des technologies d'il y a 40 ans (et oui, UNIX a 40 ans, c'était déjà dépassé quand linux est né).
Tant qu'on se farcira une communauté de crétins ébaubis devant la moindre linuxerie, aucun SE «libre» ne pourra être prêt pour le desktop.
-- Joe Cool
Cumbalero
Joe Cool a écrit :
UNIX a 40 ans, c'était déjà dépassé quand linux est né).
Tu confonds les mots "éprouvé" et "dépassé".
L'univers à plus de 13 milliards d'années, ça n'en fait pas un truc dépassé.
A+ JF
Joe Cool a écrit :
UNIX a 40 ans, c'était déjà dépassé quand linux est né).
Tu confonds les mots "éprouvé" et "dépassé".
L'univers à plus de 13 milliards d'années, ça n'en fait pas un truc
dépassé.
UNIX a 40 ans, c'était déjà dépassé quand linux est né).
Tu confonds les mots "éprouvé" et "dépassé".
UNIX est dépassé et éprouvant. Ce système date d'une époque ou l'informatique était encore considérée comme une sous-discipline de l'électronique; l'informaticien type était électronicien et le prof de physique servait de prof d'info. UNIX reprend des concepts issu de la vie de bureau (fichiers, répertoires, administrateurs) et de ce fait ignore totalement l'idiosyncrasie de la gestion des données: il se retrouve boursouflé par une multitude de greffons, modules, comme autant de béquilles et d'emplâtres sur lesdites béquilles.
Depuis 40 ans, la puissance des machines a été multiplié par quelques milliards; mais question SE... on pilote aujourd'hui des deux-chevaux munies du moteur d'une Ariane 5; on comprend mieux pourquoi les ingénieurs rechignent à freiner, sans compter que la quasi-totalité des techniciens informaticiens ont des compétences adaptées au monde d'il y a 40 ans, vous y compris
-- Joe Cool
Cumbalero a écrit :
Joe Cool a écrit :
UNIX a 40 ans, c'était déjà dépassé quand linux est né).
Tu confonds les mots "éprouvé" et "dépassé".
UNIX est dépassé et éprouvant. Ce système date d'une époque ou
l'informatique était encore considérée comme une sous-discipline de
l'électronique; l'informaticien type était électronicien et le prof de
physique servait de prof d'info. UNIX reprend des concepts issu de la
vie de bureau (fichiers, répertoires, administrateurs) et de ce fait
ignore totalement l'idiosyncrasie de la gestion des données: il se
retrouve boursouflé par une multitude de greffons, modules, comme autant
de béquilles et d'emplâtres sur lesdites béquilles.
Depuis 40 ans, la puissance des machines a été multiplié par quelques
milliards; mais question SE... on pilote aujourd'hui des deux-chevaux
munies du moteur d'une Ariane 5; on comprend mieux pourquoi les
ingénieurs rechignent à freiner, sans compter que la quasi-totalité des
techniciens informaticiens ont des compétences adaptées au monde d'il y
a 40 ans, vous y compris
UNIX a 40 ans, c'était déjà dépassé quand linux est né).
Tu confonds les mots "éprouvé" et "dépassé".
UNIX est dépassé et éprouvant. Ce système date d'une époque ou l'informatique était encore considérée comme une sous-discipline de l'électronique; l'informaticien type était électronicien et le prof de physique servait de prof d'info. UNIX reprend des concepts issu de la vie de bureau (fichiers, répertoires, administrateurs) et de ce fait ignore totalement l'idiosyncrasie de la gestion des données: il se retrouve boursouflé par une multitude de greffons, modules, comme autant de béquilles et d'emplâtres sur lesdites béquilles.
Depuis 40 ans, la puissance des machines a été multiplié par quelques milliards; mais question SE... on pilote aujourd'hui des deux-chevaux munies du moteur d'une Ariane 5; on comprend mieux pourquoi les ingénieurs rechignent à freiner, sans compter que la quasi-totalité des techniciens informaticiens ont des compétences adaptées au monde d'il y a 40 ans, vous y compris
-- Joe Cool
Eric Masson
Joe Cool writes:
On ne devrait jamais laisser la charge de concepteur aux pisseurs de code.
On ne devrait pas laisser n'importe qui poster sur Usenet, non plus...
-- Un groupe spécifique aux débutants permettrai aux gens qui sont "middle-class" de pouvoir continuer à se former et à aller plus profond dans Linux. -+-EF In : <http://www.le-gnu.net> - Fais moi tout -+-
Joe Cool <zierouhli@free.fr> writes:
On ne devrait jamais laisser la charge de concepteur aux pisseurs de
code.
On ne devrait pas laisser n'importe qui poster sur Usenet, non plus...
--
Un groupe spécifique aux débutants permettrai aux gens qui sont
"middle-class" de pouvoir continuer à se former et à aller plus
profond dans Linux.
-+-EF In : <http://www.le-gnu.net> - Fais moi tout -+-
On ne devrait jamais laisser la charge de concepteur aux pisseurs de code.
On ne devrait pas laisser n'importe qui poster sur Usenet, non plus...
-- Un groupe spécifique aux débutants permettrai aux gens qui sont "middle-class" de pouvoir continuer à se former et à aller plus profond dans Linux. -+-EF In : <http://www.le-gnu.net> - Fais moi tout -+-
Patrice Karatchentzeff
Joe Cool a écrit :
UNIX est dépassé et éprouvant. Ce système date d'une époque ou l'informatique était encore considérée comme une sous-discipline de l'électronique; l'informaticien type était électronicien et le prof de physique servait de prof d'info. UNIX reprend des concepts issu de la vie de bureau (fichiers, répertoires, administrateurs) et de ce fait ignore totalement l'idiosyncrasie de la gestion des données: il se retrouve boursouflé par une multitude de greffons, modules, comme autant de béquilles et d'emplâtres sur lesdites béquilles.
Votre troll est dépassé et saoûlant. Cela ne pourrait s'appliquer aujourd'hui qu'à un système d'exploitation très connu et qui se farcit moyennant des pirouettes infâmes une compatibilité binaire avec des 2CV qui fonctionnaient sur 8 bits...
La force des UNIX a toujours été leur capacité à innover et surtout à se moderniser...
UNIX est dépassé et éprouvant. Ce système date d'une époque ou
l'informatique était encore considérée comme une sous-discipline de
l'électronique; l'informaticien type était électronicien et le prof
de physique servait de prof d'info. UNIX reprend des concepts issu
de la vie de bureau (fichiers, répertoires, administrateurs) et de
ce fait ignore totalement l'idiosyncrasie de la gestion des données:
il se retrouve boursouflé par une multitude de greffons, modules,
comme autant de béquilles et d'emplâtres sur lesdites béquilles.
Votre troll est dépassé et saoûlant. Cela ne pourrait s'appliquer
aujourd'hui qu'à un système d'exploitation très connu et qui se farcit
moyennant des pirouettes infâmes une compatibilité binaire avec des
2CV qui fonctionnaient sur 8 bits...
La force des UNIX a toujours été leur capacité à innover et surtout à
se moderniser...
UNIX est dépassé et éprouvant. Ce système date d'une époque ou l'informatique était encore considérée comme une sous-discipline de l'électronique; l'informaticien type était électronicien et le prof de physique servait de prof d'info. UNIX reprend des concepts issu de la vie de bureau (fichiers, répertoires, administrateurs) et de ce fait ignore totalement l'idiosyncrasie de la gestion des données: il se retrouve boursouflé par une multitude de greffons, modules, comme autant de béquilles et d'emplâtres sur lesdites béquilles.
Votre troll est dépassé et saoûlant. Cela ne pourrait s'appliquer aujourd'hui qu'à un système d'exploitation très connu et qui se farcit moyennant des pirouettes infâmes une compatibilité binaire avec des 2CV qui fonctionnaient sur 8 bits...
La force des UNIX a toujours été leur capacité à innover et surtout à se moderniser...
D'une manière générale, il faut utiliser soit apt-get, soit aptitude, mais pas les deux.
Il y a longtemps que j'ai remarqué çà.
Moi ça ne fait pas très longtemps. Depuis la mise à jour de sarge vers etch, en fait. Jusqu'ici j'utilisais apt-get parce que j'ai des bécanes un peu poussives sur lequelles aptitude est très lent, et pour faire un simple update && upgrade ça gave grave par rapport à apt-get. Or donc, lors de cette migration, pour laquelle les notes de publication recommandent d'utiliser aptitude, il s'est trouvé que ce dernier voulait me virer un tas de paquets installés par apt-get. Grmbl.
Et je suis tout à fait d'accord. Poussons un cran plus loin:
Aptitude vs. Synaptic, ça donne quoi exactement, si on mélange ?
Bonne question. On m'a dit récemment à mon grand étonnement qu'il valait mieux éviter. Je n'ai jamais utilisé synaptic.
Salut,
Thierry B. a écrit :
--{ ciol a plopé ceci: }--
D'une manière générale, il faut utiliser soit apt-get, soit aptitude,
mais pas les deux.
Il y a longtemps que j'ai remarqué çà.
Moi ça ne fait pas très longtemps. Depuis la mise à jour de sarge vers
etch, en fait. Jusqu'ici j'utilisais apt-get parce que j'ai des bécanes
un peu poussives sur lequelles aptitude est très lent, et pour faire un
simple update && upgrade ça gave grave par rapport à apt-get. Or donc,
lors de cette migration, pour laquelle les notes de publication
recommandent d'utiliser aptitude, il s'est trouvé que ce dernier voulait
me virer un tas de paquets installés par apt-get. Grmbl.
Et je suis tout à fait
d'accord. Poussons un cran plus loin:
Aptitude vs. Synaptic, ça donne quoi exactement, si on mélange ?
Bonne question. On m'a dit récemment à mon grand étonnement qu'il valait
mieux éviter. Je n'ai jamais utilisé synaptic.
D'une manière générale, il faut utiliser soit apt-get, soit aptitude, mais pas les deux.
Il y a longtemps que j'ai remarqué çà.
Moi ça ne fait pas très longtemps. Depuis la mise à jour de sarge vers etch, en fait. Jusqu'ici j'utilisais apt-get parce que j'ai des bécanes un peu poussives sur lequelles aptitude est très lent, et pour faire un simple update && upgrade ça gave grave par rapport à apt-get. Or donc, lors de cette migration, pour laquelle les notes de publication recommandent d'utiliser aptitude, il s'est trouvé que ce dernier voulait me virer un tas de paquets installés par apt-get. Grmbl.
Et je suis tout à fait d'accord. Poussons un cran plus loin:
Aptitude vs. Synaptic, ça donne quoi exactement, si on mélange ?
Bonne question. On m'a dit récemment à mon grand étonnement qu'il valait mieux éviter. Je n'ai jamais utilisé synaptic.
